20 Years of STRIDE: Looking Back, Looking Forward

Today, let me contrast two 20-year-old papers on threat modeling. My first paper on this topic, "Breaking Up Is Hard to Do," written with Bruce Schneier, analyzed smart-card security.  We talked about categories of threats, threat actors, assets — all the usual stuff for a paper of that era. We took the stance that "we experts have thought hard about these problems, and would like to share our results."

Around the same time, on April 1, 1999, Loren Kohnfelder and Praerit Garg published a paper in Microsoft's internal "Interface" journal called "The Threats to our Products." It was revolutionary, despite not being publicly available for over a decade. What made the Kohnfelder and Garg paper revolutionary is that it was the first to structure the process of how to find threats.  It organized attacks into a model (STRIDE), and that model was intended to help people find problems, as noted:

The S.T.R.I.D.E. security threat model should be used by all MS products to identify various types of threats the product is susceptible to during the design phase. Identifying the threats is the first step in a proactive security analysis process.

STRIDE was not the first suggestion for a systematic approach. In his 1994 book, Fundamentals of Computer Security Technology, Ed Amaroso outlined a way to create threat trees, "starting with a general, abstract description of the complete set of threats that exists for a given system, and then introducing detail in an iterative manner, refining the description carefully and gradually."

The invention of STRIDE is the key inflection point in the development of threat modeling from art to engineering practice. By moving us from folk wisdom to structure, STRIDE unleashed a flood of work towards making threat modeling accessible to all engineers.

At Microsoft, the frames included:

Asset/Entry is a model derived from the physical world. For example, imagine a burglar stealing your stereo. The stereo is your asset, and the windows, doors, and chimney are the entry points. You track from one to the other and consider controls, such as locks or alarms, that stop or detect an attacker. 

Patterns and Practices is a framework that Microsoft has used for talking about development and operations for quite a long time; I believe it predates threat modeling. Patterns and Practices is more descriptive: This is what people do. They draw diagrams like these. They find that spoofing threats tend to associate with account creation patterns…

STRIDE per Element noted that certain threats happen less for types of elements: data flows aren't spoofed (endpoints are); data stores are not subject to elevation of privilege.

Beyond Microsoft, over the past two decades, there has been a Cambrian explosion of tools.  Some are built on STRIDE, others not, but they all owe a debt to it.

That explosion, and my attempts to make sense of it led to an understanding that different approaches often centered on either assets, attackers or the systems being built. Even the asset- and attacker-centered approaches had a way of scoping what are we working on. All had ways of addressing what can go wrong. These are the first two questions in my four-question frame; the others are what are we going to do about it, and did we do a good job?

The debt we owe to STRIDE is the idea that a model can give us a broadly applicable structure. That structure can go beyond just a single issue, such as "known plaintext" to multiple attacks. Now, if I'm using the known plaintext as an example, many readers will know that there's chosen plaintext, adaptive chosen plaintext, and more variants. But those attacks are centered on cryptosystems and do us little good outside it. I've used STRIDE on everything from operating systems to a single addition to a web service. It's broad in a way that its predecessors were not. 

The debt we owe STRIDE is also a debt that we owe Microsoft, for ongoing investments in tools, techniques, and software, and freely sharing much of that. 

Using STRIDE gives me the ability to understand the firehose of new attack variants and see them as small variants on other work. (For that, I use STRIDE and "memory corruption," which is enough for most attacks.)

We should celebrate having a model that started in the era of desktop computing and has survived into the age of mobile, cloud, and web, and shows few signs of becoming obsolete.

Related Content:        

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.