Charles Wilson's Blog

With all the recent cyber activity, there has been a renewed interest in threat modeling. Generally speaking, this is a good thing. But what should we threat model, you ask? The answer is everything. And when do we need the threat modeling to be done? Why, yesterday, of course.

We all know that everything and yesterday are unattainable goals. Still, those of us in the threat modeling community do our best with the time and material we have to work with. Leaving aside the aspect of time for a moment, let’s look deeper into the material aspect.

When I say material, I’m referring to both the scope of the threat model and what we know about it. For the longest time organizations would play “hide the data” and call that their security solution. That might take the form of “in a secure facility,” “in a sealed box,” “using obfuscated code,” and the like. The key here is that security was a function of someone else’s moat protecting your crown jewels. Over time, we threw an ever increasing number of resources at the creation and sophistication of those moats.

The problem with moats is that unless you never need to get from inside to outside, there’s always a well-paved path to get across it. Now you say, “we’ve got that covered, we watch everything coming and going.” Now in addition to the moat, you’ve got to invest in more and more complex gatekeepers. And the problem with gatekeepers is that they create friction. Friction expresses itself as the consumption of resources. For computers, those resources are time, processing power and storage.

When we create computer-based products, there’s a desire to make them at as low a cost and as quickly as possible. Settings aside the cost aspect, let’s consider time-to-market and how it’s impacted by the aforementioned gatekeepers. Making systems work is hard enough, but once you add encryption and authentication and secure enclaves and the like, well, it gets really hard. The natural tendency is to make it work and then make it secure (if you have time left in your schedule).

So, by the time the average company engages security, one of two scenarios is in play. Scenario one: there’s a default assumption that security is someone else’s problem (moat-land). Scenario two: security can be overlaid in the remaining time and space.

The problem with the first scenario is that it’s been a flawed model since the 1980’s (probably earlier). As soon as you allow people to connect things to a greater world, someone is going to connect them in way that you didn’t expect. And someone is going to get over your moat. Then where will you be? Our entire history as a species is replete with stories of Trojan horse tales. Why would we imagine that the technology realm would be any different?

The problem with the second scenario is that is treats security as a feature and not an emergent property of the system. Simply put, “you can’t bolt security on.” You certainly can’t secure the complex systems we now assemble on a daily basis from an assortment of open source, third-party, and proprietary bits when you try to do so after the fact.

This certainly paints a gloomy picture for security. But what, you may ask, does this have to do with threat modeling and what is compositional threat modeling? Both good questions. Let’s get into it.

Fundamentally, threat modeling is a design activity. That is, threat modeling considers a system’s design and evaluates if sound security principles are being used. There are a myriad way to undertake this consideration. Probably the most famous being Adam Shostack‘s four questions framework. This methodology cuts to the core of threat modeling. There are any number of tools available to help automate and systematize the threat modeling process. All of them presume a fully-formed system design. Now, given that the system may have been assembled from multiple sources, you may not have that fully-formed design available. What does that mean? It means that you don’t get a complete picture of system’s design deficiencies. Now, if everyone knows this, the organization is able to make reasonable risk decisions. Many time, however, non-security individuals look at the results of a threat model and consider them the totality of possible deficiencies. This is the reality of the world.

There’s another issue with threat modeling the system in its totality after the fact. A threat model is a kind of network diagram and subject to the same kind of combinatorial explosion. This has two negative impacts. First, it’s hard to preform a systematic analysis of the model in a timely fashion when you have hundreds of interconnections to consider. Second, when deficiencies number in the thousands, the development teams and their management are unlikely to want to even look at them. They are, after all, only possible issues.

So, how can we address these diverse issues? I use a  technique that I call compositional threat modeling.

Let’s consider a really simplistic example. The following diagram shows two things communicating across a trust boundary.

I could choose to threat model this system as a whole and would need to consider the impact of both my (Thing 1) inbound data flow on me and outbound data flow on Thing 2. Alternately, I could consider only things that impacted me (consider Thing 2 out of scope). This would yield a focused set of deficiencies applying only to Thing 1. I could then perform a complementary analysis with the focus on Thing 2. Now I have a pair that I can say form a fully modeled system by composition.

The advantages to this approach are numerous. The deficiencies identified are highly focused, so teams will be more likely to consider them. The methodology scales well. The threat models are more light weight (easier to maintain). The threat modeling process can more readily accommodate a diversity of element sources and different timelines of inclusion or availability. Threat models can be created and shared in ways that do not expose organizational IP. The threat models are easier to navigate (multiple resolution views are a natural consequence).

References:

Rock strata image by Matt Affolter (QFL247), CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=14715935