Attack Trees to Assess Security

At this point, we all know that optimizing poorly performing code must be done only after analysis points you to the bottleneck. Right? It makes no sense to optimize code on a hunch, because your hunches are usually wrong, and if they are wrong then the time spent optimizing is all wasted. If there is a performance issue then the first step is always to pull out the profiler, and let that pinpoint the issue. Maybe you prefer printf statements with timings. Whatever.

But what do you do when you contemplate application security? Do you start to research authentication frameworks like SASL? Do you start using HTTP over SSL? I do. Application security for me starts and ends with the programming language and its frameworks, because those are the pieces that an application developer can effect. I've never known how to step back and ask where the security weakpoints are. Or step back and ask who I'm protecting it from. I'm a lot like the programmer that optimizes code without performance statistics. Jumping straight to code based security solutions is premature and wasteful unless backed by proper analysis. Spending 40 hours getting SASL integrated into your application without knowing definitively that front door authentication is the most likely exploit is a lot like spending 40 hours on a whim converting all your String objects to character arrays because it'll be faster (true story, and it wasn't faster).

All this is why I think attack trees are so cool. Attack trees are a threat modeling tool created by Bruce Schneier. They provide a process for thinking about what you're trying to protect, what the most likely attack would be, and how much it is worth. The outcome is a clearer picture of who would be most likely to attack your system and how they would do it. This information is what you use to determine the security needed on your application, and how much energy to expend creating it.

So what is an attack tree? It's just a visual representation of all the possible ways of attacking your system, in tree form of course. Here is an attack tree for reading someone else's email (taken from Core Security Patterns):

The root node of an attack tree is the goal of the attack, and child nodes are actions that can attain that goal. The leaf nodes (bottom-most nodes) are direct actions that can be taken to achieve the goal. Brainstorming the possible security holes can be an enlightening process, but it isn't the end point of the analysis. The real knowledge is generated by using the tree to answer questions.

• What is the cheapest attack? Assign each leaf a relative monetary value and the tree clearly shows the lowest cost attack.
  
• What is the easiest attack? Assign each leaf a relative difficulty and the tree shows which attack is easiest to perform. If hacking your app's authentication mechanisms isn't the easiest attack, then perhaps researching SASL is wasted effort.
  
• Which attacks require specialized equipment or skills?
  
• Which attacks are legal?
  
• Which attacks are most likely to work?
  

These questions can be combined to find the easiest path from a leaf node to the root. For instance, the cheapest low-risk attack, requiring no special equipment or skills, that cannot be prosecuted if caught is really something to worry about. The expensive attack, requiring advanced security skills and equipment, and easily prosecutable, is not your greatest risk. As the original article points out, the areas that most people think are vulnerable usually aren't. How much time has been spent debating whether PGP encryption algorithms should use a 1024 or 2048 bit key length (your company probably revisits this discussion every few years, by the way)? Meanwhile, keyboard sniffers and trojan horses are far and away an easier method to intercept data when compared to breaking the RSA encryption algorithm. This perspective of being able to make these types of relative judgments about security risks is exactly what attack trees are designed to do.

An important question to answer before making security decisions is, "How much is what you're protecting worth?" Imagine that what you are protecting is worth US$100,000. Any attack costing more than that can safely be ignored. The bumbling crooks spending more to crack the safe than the safe contains are Hollywood myths. Similarly, if closing the security hole costs more than US$100,000 then it isn't worth your time. There is no point on spending more on a safe than what the contents of the safe is worth. Give the contents away freely and don't buy the safe in the first place. Your accountants will thank you.

And what about who you are protecting the system from? Are you worried about organized criminals, who are willing to purchase expensive equipment and risk going to jail? Or is it bored teenagers with broadband, who might think twice about breaking the law or doing anything time consuming? What about a terrorist, who might even be willing to die for their cause? Knowing beforehand who might be attacking your system will rule out certain paths through the attack tree.

As Bruce Schneier wrote, "Security is not a product -- it's a process. Attack trees form the basis of understanding that process." Just like a profiler is a tool to guide optimization decisions, attack trees are a tool to guide security decisions. I was so impressed with the concept when I read about it in Core Security Patterns, that I had to dig a little deeper. It's been worth it. The original article appeared in Dr. Dobb's Journal, way back in 1999. 8 years old, but it was new to me, at least!