上QQ阅读APP看书，第一时间看更新

Building an attack tree

If you haven't done it before, building an attack tree can seem like a daunting task, and it is difficult to know where to start. To begin, a tool is needed to both build the model and run analysis against it. One example is SecurITree, a capabilities-based attack tree modeling tool built by the Canadian company Amenaza (the Spanish word for threat) (http://www.amenaza.com/). Building an attack tree is perhaps best described with a simple example.

Suppose an attacker wishes to accomplish the overarching goal of redirecting an Unmanned Aircraft Systems (UAS), that is, a drone, while in flight. The following diagram shows the top-level activities of the attack tree to accomplish this:

You will notice the two well-known logic operator symbols for AND (smooth and rounded top) and OR (pointy top). The root node, entitled Redirect UAS, represents the end objective and is made up of an OR operator. This means that any one of its children can satisfy the end goal. In this case, the attacker may redirect the aircraft by any of the following methods:

Corrupting its navigation database: A navigation database maps named locations to positions in space (latitude, longitude, and, typically, altitude above mean sea level). In practice, there are many potential ways to compromise a navigation database, for example, either directly on the aircraft, its ground control station, or even in the navigation and mapping supply chain (this is true of manned aviation too, as commercial airliner flight computers have extensive navigation databases).
Spoofing GPS: In this case, the attacker could choose to perform an active RF-based GPS attack in which they generate and transmit false GPS timing data that the drone interprets as a false location. In response, the drone (if under autonomous flight) navigates unknowingly, based on its falsely perceived location, and follows a path maliciously designed by the attacker. (Note: we assume there is no machine vision or other passive navigation system in use.)
Spoofing the ground control station (GCS): In this option, the attacker can find a way to spoof the drone's legitimate operator and attempt to send malicious routing commands.

Now, let's expand the attack tree a bit (the tiny arrow pointing to a horizontal line at the bottom of each node indicates the node is expandable). Specifically, let's expand the Corrupt Navigation Database goal node:

This Corrupt Navigation Database node is an AND operator; therefore, each and every one of its children in the tree must be satisfied. In this case, each of the following is needed:

Some attack that exploits a transitive trust relationship needed to get into the supply chain of the navigation database
A compromise of the navigation database server
The modification of the Geographic Information System (GIS) tables within the navigation database (for example, tell the drone that its destination is 100 m to the north-east and below its actual destination and it might just crash into the ground or a building)

Two of the nodes, Exploit Transitive Trust and Compro DB server, each have subtrees. The third node, Modify GIS Tables, does not and is therefore called a leaf node. Leaf nodes represent the actual attack vector entry points into the model, that is, the attacker's activities, whereas its parents (AND/OR nodes) represent either specific device states, system states, or goals that the attacker may achieve through their activities.

Expanding the Exploit Transitive Trust subtree gives us the following diagram:

Without going into detail on every node, it becomes apparent that careful thought and consideration goes into developing an effective, usable attack tree. In summary, trees have subtrees that can be very simple or complex. Typically, the more complex the subtree, the greater the need to analyze it offline of the main tree in what is called subtree analysis. In practice, proper rigor in attack tree modeling requires a number of experts in each of the subtree domains. It is strongly suggested that attack tree modeling become a normal part of IoT system (or device) security engineering.

The SecurITree tool goes much further than just creating tree diagrams. Its dialogs assist you in modeling each attack goal by establishing indicators, such as the following:

Capabilities of the attacker, such as technical ability, notice ability, and cost of the attack
Behaviors and probabilities of the attack such as how the attack would be conducted and the likelihood of success
Impact of the attack to the victim (note that by the time the subtree impacts aggregate up to the root node, the final impact can be enormous)
Benefits to the attacker (of given impacts) are motivating impacts for the attack
Detriments to the attacker are demotivators for the attack

Once all of this data is input into the tool, the real fun begins in the analysis and reporting. The tool computes each and every attack vector (attack scenario) based on all of the possible tree traversals and logic operators that define each attack goal. For each attack scenario, the total cost of the attack, its probability, and its total impact are computed and then sorted according to whatever criteria you select. Note that even a moderately sized tree can generate thousands, tens of thousands, or hundreds of thousands of attack scenarios, though not all are necessarily interesting or likely (the process of whittling down the attack scenarios to the ones that count most is called reduction).

Once the attack scenarios are generated, interesting reports can be created, for example, a graph of willingness-to-capability ratios (for the analyzed attack scenarios). The slope of the curve can indicate interesting aspects of the psychology of the selected attacker profile, such as to what extent they may continue to pursue attacks in the face of limited capability. This information can be quite useful in selecting and prioritizing the security controls and other mitigations you select. Other reports can be generated as well. For example, cumulative risk can be graphically displayed over a defined period of time as a function of the number of computed attack scenarios (based on each one's characteristics).

The tool has many other interesting and useful features as well. Recommendations for using this tool include the following:

Prune your trees into separate files (subtrees) and allow experts in each subtree domain (whether internal or external to your organization) to maintain their area. In some cases, certain subtrees remain fairly static and can potentially be shared between companies and industries, as long as the attack tree indicators are aligned.
Add trees and subtrees to your version control system and update any time major system designs are changed, or when anything that might affect the threat profile of your IoT device, system, or deployment changes.
Create and maintain (again in version management) your attacker profiles. They will most certainly change over time, especially if your deployment begins to collect new and more valuable types of privacy information. Even your company's growth and financial resources can impact your attacker profile.

Real-world attacks may involve numerous feedback loops within the attack tree. Successive attacks and compromises of multiple intermediate devices and systems—each called a pivot—may allow an attacker to reach his final goal. This is something you don't want.

Keep in mind, however, that the cyber-physical aspects of the IoT introduce new attack flavors for the root node, goals that may surpass the severity of data exfiltration, denial of service, and other conventional cyber threats. The new options are the possible physical world interactions and controls ranging from turning off a light bulb to turning off a human heart.

To that end, we must also discuss fault trees.