Here is a tool every security expert should use now and then, in my humble opinion: attack trees. Attack trees are really something that comes from a technique in industrial safety engineering called ‘fault trees’ and it is related to dependency analysis using directed graphs. But it can be very useful when modeling threats in complex ICT systems – like an appstore/smartphone ecosystem. See for instance the attack tree in this paper on appstore security (see picture below).
The reason I used attack trees in that setting was simple: After using STRIDE (a threat modeling technique) we ended up with around 70 different technical threats (ranging from spoofing app developer identity, spoofing a legit user, spoofing a legit app stores, to tampering the reputation system of an app store, tampering the app being uploaded, et cetera, et cetera. We needed something to make sense of these threats and understand which threats meant what.
Now what is ‘normally’ done is that you take each threat, try to quantify the corresponding impact (which is notoriously hard), you get a risk and you list the risks from the biggest down. To simplify you could group similar threats (similar cause or similar impact) – 10 is often a good number 🙂
But of course, when an incident happens, often multiple threats are involved! Take the example above: A weakness in the authentication of app developers alone would not matter if app vetting were perfect. But it is not. And this allows for a successful attack. A dry (flat) analysis of what are the risks associated to the threats would not show how an attacker could get an infected app online by first attacking the app developer’s credentials and then subverting the app vetting mechanism. A flat list of risks would not reveal the relation between app vetting and app developer authentication.
I believe attack trees provide a much better picture. Let’s go back to the example. See the diagram to the right. Using one simple drawing we could show the main 10 threats, see their role in incidents, their impact, and it allowed us to group the app store security defenses in five groups!
Let me conclude by mentioning some other nice properties of attack trees:
- Flexible – It allows to work at any abstraction level, just by adjusting the goals. Small systems, big systems.
- Visual – It is a visual technique, which works well for communicating – for technical audience as well as C-level and board room.
- Formal – Researchers have shown attack trees have some nice formal properties, like reductions, extensions, and projections (“what is the cheapest attack?”). See http://www.win.tue.nl/~sjouke/publications/papers/attacktrees.pdf for a nice article about this. This means it could also be implemented well in automated tools (such as GRC tools).
- Attack scenarios – Besides showing the threats and risks, trees also read like incident scenarios. This is a nice extra, because security is often better understood via stories and scenarios.
- Brainstorm tool – One of the most complicated tasks of a security officer is to improve threat modeling inside the organization. Things easily get overlooked. Attack trees are a great (and fun) brainstorm tool, accessible and easy to use even for non-technical employees. It allows the people in the room to play the part of hazard, criminal, attacker.
Of course it is not a silver bullet, and the challenge (as always) is to find the right level of abstraction, to show the threats a clear picture without losing too much detail. For me it is a great tool – and I would like to see it used more often. Flat lists of risks can become boring and lacking in clarity and detail.
Did you ever try attack trees, and what did you think? Did you run into limitations?