Practical Threat Analysis and Risk Management
Bruce Schneier, author of Applied Cryptography, has proposed a different method for analyzing risk: attack trees. An attack tree, quite simply, is a visual representation of possible attacks against a given target. The attack goal (target) is called the root node; the various subgoals necessary to reach the goal are called leaf nodes.
To create an attack tree, you must first define the root node. For example, one attack objective might be “steal Mommenpop, Inc.'s customers' account data”. Direct means of achieving this could be 1) obtain backup tapes from Mommenpop's fileserver, 2) intercept e-mail between Mommenpop, Inc. and their customers and 3) compromise Mommenpop's fileserver over the Internet. These three subgoals are the leaf nodes immediately below our root node (Figure 4).
Next, for each leaf node you determine subgoals that will achieve that leaf node's goal, which become the next layer of leaf nodes. This step is repeated as necessary to achieve the level of detail and complexity with which you wish to examine the attack. Figure 5 shows a simple but more-or-less complete attack tree for Mommenpop, Inc.
No doubt you can think of additional plausible leaf nodes at the two layers shown in Figure 5 and additional layers as well. Suppose for our example, however, that this environment is well secured against internal threats (seldom the case), and that these are the most feasible avenues of attack for an outsider.
We see in this example that backup media are obtained most probably by breaking into the office; compromising the internal fileserver involves hacking in through a firewall, and there are three different avenues to obtain the data via intercepted e-mail. We also see that while compromising Mommenpop, Inc.'s SMTP server is the best way to attack the firewall, a more direct route would simply be to read e-mail passing through the compromised gateway.
This is extremely useful information; if this company is considering sinking more money into its firewall, it may decide that their money and time are better spent securing their SMTP gateway. But as useful as it is to see the relationships between attack goals, we're not done with this tree yet.
After an attack tree has been mapped to the desired level of detail, you can start quantifying the leaf nodes. For example, you could attach a cost figure to each leaf node that represents your guess at the cost of achieving that leaf node's particular goal. By adding cost figures in each attack path, you can estimate relative costs of different attacks. Figure 6 shows our example attack tree with costs added (dotted lines indicate attack paths).
In Figure 6 we've decided that burglary, with its risk of being caught and being sent to jail, is an expensive attack. Nobody will perform this task for you without demanding a significant sum. The same is true of bribing a system administrator at the ISP; even a corruptible ISP employee will be concerned about losing his or her job and getting a criminal record.
Hacking is a bit different, however. While still illegal, it's often perceived as being less risky than burglary. Furthermore, most organizations' computer defenses aren't nearly as difficult to breach as their physical defenses.
Having said that, hacking through a firewall takes more skill than the average script-kiddie possesses and will take some time and effort; therefore, this is an expensive goal. But hacking an SMTP gateway should be easier, and if one or more remote users can be identified, the chances are good that the user's home computer will be easy to compromise. Therefore, these two goals are much cheaper.
Based on the cost of hiring the right kind of criminals to perform these attacks, the most promising attacks in this example are hacking the SMTP gateway and hacking remote users. Mommenpop Inc., it seems, had better take a close look at their perimeter network architecture, SMTP server's system security and remote-access policies and practices.
Cost, by the way, is not the only type of value you can attach to leaf nodes. Boolean values such as feasible and not feasible can be used; a “not feasible” at any point on an attack path indicates that that entire path is infeasible. Alternatively, you can assign effort indices, measured in minutes or hours. In short, you can analyze the same attack tree in any number of ways, creating as detailed a picture of your vulnerabilities as you need to.
The cost estimates in Figure 6 are all based on the assumption that the attacker will need to hire others to carry out the various tasks. These costs might be computed very differently if the attackers themselves are skilled system crackers; in such a case time estimates for each node might be more useful than cost estimates.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
48 min 41 sec ago
4 hours 24 min ago
- Reply to comment | Linux Journal
4 hours 56 min ago
- All the articles you talked
7 hours 20 min ago
- All the articles you talked
7 hours 23 min ago
- All the articles you talked
7 hours 24 min ago
11 hours 49 min ago
- Keeping track of IP address
13 hours 40 min ago
- Roll your own dynamic dns
18 hours 54 min ago
- Please correct the URL for Salt Stack's web site
22 hours 5 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?