Jun 10, 2009

Threat modeling: bringing it all together

There are few ways to do threat modeling. For those that are in the financial sector, it's all about business risks. For those in the technology sector, it's all about fending off direct attacks. What both approaches have in common is the fact they all try to identify and counter any event that may offset the normal order of operation within a given business process. One at the business level, while the other at the more technical level. Because both approaches have different starting and ending points, there is the risk of having gaps in the overall risk analysis process.



Why do I say this? If we look at the technical threat modeling exercise, everything begins with identifying the individual assets and the threats that affect them. The gap in this approach is that the application's business goals are not stated clear. Protecting assets is good, but why do they need to be protected? How do you convey to your higher-level management and external stakeholders that a particular asset needs protection? You simply speak in terms that can be understood by your audience: business goals. Similarly, if you look at the business risk analysis exercise, how do you ensure that the security test/audit of your application will cover all venues of attacking your system? How can you provide documentation of adequate security assessment coverage at the time of a breach? You simply provide your test plan, which is most likely derived from the attack vectors and pre-conditions in your threat model.

So what's the purpose of complicating things? As risk analysis is an essential part of ensuring any system's security, it is also essential that the report that is produced during this analysis provide meaningful, yet actionable information. Here are the steps that can help achieve that:
1. Gather information on the business goals of the system.
2. Identify the business risks that will harm those business goals.
3. Decompose the business risks into technical risks that can realize if a security breach occurs.
4. For each technical risk, build a tree of attack vectors that lead to the realization of this technical risk.
5. For each attack vector, identify the pre-conditions that are necessary for this attack vector to execute.
6. Using the attack vectors, their pre-conditions, and your knowledge of the system's attack surface, draft a document (most likely a test plan) that covers all possible venues of attack.

Thoughts?

1 comment:

Gabe said...

I personally believe that the distinction you perceive at the beginning of this post - that is, financial sector threat modeling vs. technology sector threat modeling - is not a real difference but just a side-effect of the nature of the two sectors.

All threat modeling is done for a business reason - you don't do threat modeling to produce nice wallpapers or to be kind to your neighbor, you do it to meet a certain business goal. It is essential, then, that threat modeling begins with the "business goals"->"business risk"->"technical risk" mapping step that you are talking about. All threat models should in fact start like this. However, for software vendors - like Microsoft - the technical risks happen to overlap with the business risks, and that's why IMHO you see this step missing in the MS-sanctioned way of doing threat modeling.

In other words, when you do threat modeling for a bank, you need to start from the business goals and business risks in order to understand that a certain database is an asset to protect. On the other hand, when you do threat modeling of a system being sold by a software vendor, you already know that whatever user data gets touched by that system, it'll be an asset to protect.

My two cents.