Attack Trees, Threat Trees, and Attack Graphs

Attack trees, threat trees, and attack graphs are visual representations of

possible attacks against given targets that help visualize more complex series of events (attack patterns) that may be combined to cause a security compromise (see Section 3.2 on threats to software). Attack and threat trees and attack graphs provide alternative formats for capturing abuse case and misuse case information. The holistic view provided by the trees and graphs also clarifies the dependencies between attack patterns that exploit software vulnerabilities and those that target vulnerabilities at other levels (e.g., system, network, personnel, procedure). This view can increase the understanding of risk managers so that they can better target and coordinate the countermeasures to these vulnerabilities across all layers of the system.

The following is an example of a non-graphical version of an attack tree [192]

that includes several attack patterns that exploit software vulnerabilities:

Goal—Fake Reservation

1. Persuade an employee to add a reservation.

1.1 Blackmail an employee.

1.2 Threaten an employee.

2. Access and modify the flight database.

2.1 Perform SQL injection from the web page (V1).

2.2 Log into the database.

2.2.1 Guess the password.

2.2.2 Sniff the password (V7).

2.2.3 Steal the password from the web server (AND).

2.2.3.1 Get an account on the web server.

2.2.3.1.1 Exploit a buffer overflow (V2).

2.2.3.1.2 Get access to an employee account.

2.2.3.2 Exploit a race condition to access a protected file (V3).

Figure 5-8 similarly illustrates an attack graph [193] that includes several attack patterns that exploit software vulnerabilities.

Software Security Assurance State-of-the-Art Report (SOAR)

15 Assumptions and Constraints.4 Scope.

Section 5 SDLC Processes and Methods and the Security of Software

Figure 5-8. Example of an Attack Graph

Not all attack and threat trees and attack graphs lend themselves to manual analysis because of their sheer size and complexity. Some trees and graphs have been generated to depict real-world distributed attacks targeting large networked systems; these trees and graphs have included hundreds and even thousands of simultaneous different branches and paths leading to the completion of the attack.

According to some who have attempted to use attack and threat trees, they are difficult if not impossible to use by anyone who is not a security expert.

Because a tree is a “list of security-related preconditions,” it is unrealistic to expect a non-expert to accurately generate an appropriate list of security-related preconditions. Microsoft is one software development organization that has discovered that painstakingly generated security-related preconditions (attack or threat trees) actually form patterns that can then be standardized as patternspatterns reusable attack patterns (or, in Microsoft parlance, “threat tree patterns”) that are easily comprehensible by non-security-expert developers. This pattern-based approach is rapidly supplanting use of attack and threat trees and graphs as a preferred threat modeling approach in many development organizations.

See Section 3.2.3.1 for a discussion of the ways in which attack patterns can and are being used throughout the software life cycle.

BUFFER

!PACHE

CHUNK PACKET

BUFFER

BUFFER

!PACHE

HOST ARBITRARY

!PACHE

HTTP 

OVERFLOW /2

!.$

15/25-ARBITRARY

-Y31, 



INFORMATION

HOST

 N

Software Security Assurance State-of-the-Art Report (SOAR) 15 Assumptions and Constraints.5 Assumptions and Constraints.

Section 5 SDLC Processes and Methods and the Security of Software

For Further Reading

“Attack Trees”, (Washington, DC: US CERT).

Available from: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements/236.html Bruce Schneier, “Attack Trees—Modeling Security Threats”, Dr. Dobb’s Journal, (December, 1999).

Available from: http://www.schneier.com/paper-attacktrees-ddj-ft.html

Oleg Sheyner, et al., Automated Generation and Analysis of Attack Graphs: 2002, Presentation at the IEEE Symposium on Security and Privacy, (May 2002).

Available from: http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/calder/www/sp02.html

Oleg Sheyner and Jeannette M. Wing, “Tools for Generating and Analyzing Attack Graphs: 2003”

Presentation at the Workshop on Formal Methods for Components and Objects, 2004: 344–371.

Available from: http://www-2.cs.cmu.edu/~wing/publications/SheynerWing04.pdf

5.2.3.1.8 System Risk Assessment Methods and Software-Intensive Systems

Even though system risk assessment methods cover a broad range of

information security concerns, they also usually include adequate mechanisms and techniques for incorporating detailed software security assessments and threat modeling scenarios into a larger system security risk assessment. The challenge is that system risk assessment is in and of itself such a demanding, time-consuming activity that there are often no time, resources, or motivation to extend the risk assessment to the lower level of granularity required to assess individual software components of the system.

Systems risk analysts, then, generally proceed without consulting the software engineers who build those components. The result is that several security threats, vulnerabilities, and countermeasures that are unique to software components and best understood by software developers are not reflected in the system risk assessment. The result is, at best, an inaccurate report of the actual risks to the software intensive system.

This said, until recently, the absence of software-specific risk

assessment and threat modeling techniques and tools left only one option to software teams: attempt to apply system-level risk assessment techniques (and supporting tools) to software components (and development projects).

The following are the most popular, well-established of the system security risk assessment techniques. All of these are have been used in software security risk assessments.

u Automated Security Self-Evaluation Tool (ASSET)—[194] NIST’s ASSET provides automated self-assessments against its own established criteria for security controls. ASSET is, in essence, an automated version of the questionnaire in NIST SP 800-26, Guide for Information Security Program Assessments and System Reporting Form. ASSET differs from other tools in that it is aimed only at facilitating Federal agency compliance with security assurance provisions mandated by law (e.g., FISMA), policy (e.g., DoDD 8500.1), and standards (e.g., FIPS 200).

Software Security Assurance State-of-the-Art Report (SOAR)

15 Assumptions and Constraints.6 Context.

Section 5 SDLC Processes and Methods and the Security of Software

u Central Communication and Telecommunication Agency (CCTA) Risk Analysis and Management Method (CRAMM)—[195] Developed by Siemens Corporation and Insight Consulting, offers both quantitative and qualitative measurements of risk. Its distinguishing feature is its Controls Database of more than 3,000 security controls defined by a variety of security agencies and standard bodies. For each control, the database describes where the control would be appropriate and ascertains its cost and effectiveness against a variety of security breaches. The program delineates costs to the user and enables the user to rank or prioritize controls.

u Mission Oriented Risk and Design Analysis (MORDA)—[196] The MORDA methodology was developed by the NSA to provide a state-of-the-art quantitative risk assessment method. MORDA employs a variety of tools to execute a comprehensive risk management approach: attack tree models, IA models, and multiple-objective decision analysis. Each model yields mathematical outputs capturing figures such as estimated losses from attacks, predicted attack frequency, and effectiveness of

countermeasures. Those quantitative outputs inform investment decisions aimed at enhancing security controls, reengineering, and upgrades or downgrades of existing system features. MORDA is the methodology that has been mandated for use in risk assessment of DoD Global Information Grid (GIG) applications and enterprise services.

u Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)—[197]

The SEI’s OCTAVE differs from MORDA in that it offers a qualitative approach. OCTAVE inventories critical assets, threats to those assets, vulnerabilities associated with those assets, and risk levels. The user is guided through a step-by-step process to catalog risk and generate relevant “Threat Profiles,” which map a critical asset to its sources of potential risk through flowcharts. Analysts from all parts of the organization are involved in the assessment process.