Attack Modeling for Information Security and Survivability

Many engineering disciplines rely on engineering failure data to improve their designs. Unfortunately, this is not the case with information system engineers, who generally do not use security failure data—particularly attack data—to improve the security and survivability of systems that they develop. Part of the reason for this is that, historically, businesses and governments have been reticent to disclose information about attacks on their systems for fear of losing public confidence or for fear that other attackers would exploit the same or similar vulnerabilities. Specific, detailed attack data has just not been available. However, increased public interest and media coverage of the Internet's security have resulted in increased publication of attack data in books, Internet newsgroups, and CERT security advisories, for example. Engineers can now use this data in a structured way to improve information system security and survivability. This technical note describes and illustrates an approach for documenting attack information in a structured and reusable form. We expect that security analysts can use this approach to document and identify commonly occurring attack patterns, and that information system designers and analysts can use these patterns to develop more survivable information systems.


List of Figures
Imagine what would result if bridge builders had ignored the lessons learned from the torsional oscillations that caused the Tacoma Narrows Bridge to collapse.Or if shipbuilders had ignored the lessons learned about inadequate lifeboat space that allowed the great loss of life when the Titanic sank.Engineering success requires that we also learn from less famous disasters.The aerospace community, for example, has institutionalized a means for learning from air traffic accidents that has resulted in very low risk of death during air travel, despite its inherent hazards.

The Problem
Information system engineers generally do not use security failure data-particularly attack data-to improve their designs and implementations.This is partly because of a lack of publicly available data [Anderson 93].Businesses and governments are reticent to draw attention to attacks on their systems for fear that other attackers will exploit the same or similar vulnerabilities.Even after their systems are strengthened to block attacks, organizations resist divulging the attack for fear of losing public confidence.
Despite organizational reticence to disclose attacks on their systems, attack data have become more available over the past decade, primarily because of increased public interest and media coverage of Internet security.Organizations such as the Software Engineering Institute's CERT® Coordination Center were formed primarily to help protect business and government information systems from Internet-based security attacks, in part by publishing security advisories that did not disclose the names of the organizations involved.Many books on the subject of how hackers break into systems have been published [Klander 97,Scambray 01].
Nevertheless, recent research shows that information system engineers are not learning from these documented security attacks [Arbaugh 00].Information systems being built and managed today are prone to the same or similar vulnerabilities that have plagued them for years.
Information system engineers need a better way to use and analyze attack data to learn from previous experience.This paper proposes a means to document information-security attacks in a structured and reusable form.We expect that security analysts will be able to use the structures described to identify commonly occurring attack patterns derived from real attack data. 1 Further, we expect that information system designers and analysts will be able to use ® CERT and CERT Coordination Center are registered in the U.S. Patent and Trademark Office.
1 These structures are not intended for use by victims of an attack, but by analysts who more fully understand attacker profiles and the impact of specific attacks on system operation.
the attack patterns to develop more survivable systems.Future work will refine and validate the approach through its application to real-world examples.
We base our documentation approach on a structure called the attack tree [Schneier 99].Section 2 describes the attack tree format and semantics.Section 3 describes a structure for capturing and reusing generic patterns of information-security attacks.Section 4 defines a model for refining attack trees that is based on the specification and reuse of these generic attack patterns.Section 5 summarizes this paper and characterizes future work.

ACME Enterprise
Throughout the paper we use attacks on a fictitious company, called ACME, Inc., to illustrate concepts and issues.Figure 1  Attack trees have existed in various forms, and under various names, for many years, but have been most recently described as a systematic method to characterize system security based on varying attacks [Schneier 00].They refine information about attacks by identifying the compromise of enterprise security or survivability as the root of the tree.The ways that an attacker can cause this compromise iteratively and incrementally are represented as lower level nodes of the tree.An enterprise typically has a set, or forest, of attack trees that are relevant to its operation.The root of each tree in a forest represents an event that could significantly harm the enterprise's mission.Each attack tree enumerates and elaborates the ways that an attacker could cause the event to occur.Each path through an attack tree represents a unique attack on the enterprise.

Structure and Semantics
We decompose a node of an attack tree either as • a set of attack sub-goals, all of which must be achieved for the attack to succeed, that are represented as an AND-decomposition, or • a set of attack sub-goals, any one of which must be achieved for the attack to succeed, that are represented as an OR-decomposition.
Attack trees can be represented graphically or textually.We represent an AND-decomposition as follows:

/T\
Graphical: This represents a goal Go that can be achieved if the attacker achieves each of Gi through G n .
We represent an OR-decomposition similarly: This represents a goal Go that can be achieved if the attacker achieves any one of G t through G n .Generally we use the textual representation in this paper, since the graphical representation tends to be awkward for non-trivial attack trees.
Attack trees consist of any combination of AND-and OR-decompositions.We generate individual intrusion scenarios from an attack tree by traversing the tree in a depth-first manner.For example, In general, leaf goals are added onto the end of scenarios as they are generated.ORdecompositions cause new scenarios to be generated.AND-decompositions cause existing scenarios to be extended.Intermediate nodes of the attack tree do not appear in the intrusion scenarios because they are elaborated by lower level goals.
Attack trees allow the refinement of attacks to a level of detail chosen by the developer.They exhibit the property of referential transparency as characterized in Prowell: "Referential transparency implies that the relevant lower level details of an entity are abstracted rather than omitted in a particular system of higher level description, so that the higher level description contains everything needed to understand the entity when placed in a larger context" [Prowell 99].
This property permits the developer to explore certain attack paths in more depth than others, while still allowing the developer to generate intrusion scenarios that make sense.In addition, refining the branches of the attack tree generates new branches, resulting in intrusion scenarios at the new lower level of abstraction.

ACME Attack Tree
Figure 2 exemplifies a high-level attack tree where the root node compromise to ACME security is the disclosure of proprietary secrets.Notice that we include physical and social engineering attacks as well as technological attacks.The first branch of the top-level OR-decomposition deals with so-called dumpster-diving attacks, both on-site and after refuse has been removed.The second branch elaborates attacks that monitor emanations (e.g., visual or electromagnetic) from locations just outside the perimeter.Branches 3 and 4 cite attacks that exploit trusted insiders and physical access (either local or remote), respectively.Finally, branches 5 and 6 characterize technological attacks over the Internet or over the public telephone network (PTN).Considering attacks that exploit both technical and non-technical weaknesses of an enterprise's operation is critical to robust information security and survivability [Schneier 00,Anderson 93].

Survivability
Although the intrusion scenarios for the attack tree in Figure 2 are very high level, we will list them below to illustrate the referential transparency property of attack trees.Recall that intermediate nodes are not included in an intrusion scenario because they are completely elaborated by lower level nodes.We use the notation (i, j, k) to represent the intrusion scenario leaf goal i, followed by step j, and followed by step k.
The scenarios for this sub-tree that lead to access to sensitive shared intranet resources directly (i.e., 5.3.5.1) are as follows (note: we omit the 5.3.prefix from each leaf label for compactness): 1) The set of scenarios for gaining access to sensitive data from a protected account on the Web server (5.3.5.2) is identical to the above set with 5.2 substituted for 5.1.These 24 scenarios would replace the scenario (5.3) in the original list of intrusion scenarios for the attack tree in Figure 2.This expanded list represents the intrusion scenarios for the refined attack tree.The practicality of attack trees to characterize attacks on real-world systems depends on being able to reuse previously developed patterns of attack.This section describes two structures that support such reuse: an attack pattern for characterizing an individual type of attack, and an attack profile for organizing attack patterns to make it easier to search for and apply them.

Attack Patterns
We define an attack pattern as a generic representation of a deliberate, malicious attack that commonly occurs in specific contexts.Each attack pattern contains • the overall goal of the attack specified by the pattern • a list of preconditions for its use • the steps for carrying out the attack • a list of postconditions that are true if the attack is successful The preconditions include assumptions that we make about the attacker or the state of the enterprise that are necessary for an attack to succeed.Example preconditions include the skills, resources, access, or knowledge that the attacker must possess, and the level of risk that he or she must be willing to tolerate.The postconditions include knowledge gained by the attacker and changes to the enterprise state that result from successfully carrying out the attack steps when the preconditions hold.Over the past decade, the most common form of security vulnerability has been the incorrect handling of buffer overflows by computer programs [Cowan 00].As shown in Figure 4, when a program is invoked an activation record is added to the system's execution stack.Each activation record contains the return address when the program terminates and any local variables and buffers.In certain programs, excessively long user input can cause the internal buffer to overflow.As shown, the buffer overflow can overwrite the local variables, return pointer, and other portions of adjacent memory.An attacker can, therefore, construct the user input to change the return pointer to return to malicious code of the attacker's choosing.This malicious code runs on return with the privilege of the original program.If the program runs with administrator privilege, which is often the case, the attacker essentially has complete control of the system.This pattern of attack is captured as follows: Buffer Overflow Attack Pattern: Goal: Exploit buffer overflow vulnerability to perform malicious function on target system Precondition: Attacker can execute certain programs on target system Attack: AND 1. Identify executable program on target system susceptible to buffer overflow vulnerability 2. Identify code that will perform malicious function when it executes with program's privilege 3. Construct input value that will force code to be in program's address space 4. Execute program in a way that makes it jump to address at which code resides Postcondition: Target system performs malicious function The Buffer Overflow Attack demonstrates one way for an attacker to exploit with malicious intent a program's trust in user input.This is an example of a more general class of attacks called Input Validation Attacks: if the program would have validated user input, perhaps truncating it appropriately, the program would not be vulnerable to the attack.Another example in this class is the Unexpected Operator Attack.Rather than being vulnerable to excessively long input values, programs susceptible to the unexpected operator vulnerability simply do not expect that certain operators will be included in the input.For example, the program p in Figure 5 expects that a file name will be passed as input so that the program can use the data contained in the file for some purpose.The program vulnerability is exploited when an attacker appends the input file name with a command composition operator (";" in this example) and a malicious command (removing all files at the current directory and below).The pattern associated with this attack is similar in form to the Buffer Overflow Attack Pattern:

Unexpected Operator Attack Pattern:
Goal: Exploit unexpected operator vulnerability to perform malicious function Precondition: Attacker can execute certain programs on the target system Attack: AND 1. Identify executable program on the target system susceptible to unexpected operator vulnerability 2. Identify (unexpected) operator that permits composing system calls 3. Identify system call that would perform malicious function when executed with program's privilege 4. Construct unexpected input by composing legal input value with system call using the unexpected operator 5. Execute program on the target system with unexpected input Postcondition: Target system performs malicious function The reference model represents an architecture template with parameters that may include specific variants.The attack patterns are also defined in terms of the variants.As we will describe more fully in the next section, attack profiles are specified independently of any particular enterprise.An enterprise whose architecture is consistent with a profile's reference model may use the profile's attack patterns, once instantiated, to help construct attack trees relevant to the enterprise's operation.Different attack profiles may address different levels of attacker access, resources, and skills, as well as different configurations of system components.Therefore, different attack profiles may help refine an enterprise-specific attack tree along different lines of attack.
Figure 6 depicts a reference model for the Internet-Based Enclave Attack Profile.The variants of this reference model are the italicized terms shown in the figure: User, System, Intranet, Firewall, and Attacker.That is, these elements may vary depending on the details of the specific enterprise.Attack patterns are also specified in terms of these, and potentially other, variants.The Buffer Overflow Attack Pattern is a member of this profile and can be restated in terms of the variants as follows:

Attack Tree Refinement
As shown in the flow chart of Figure 7, an attack tree can be refined from the root node compromise as a combination of manual extensions and pattern applications.Manual extensions depend greatly on the security expertise of the person developing the attack tree.Pattern application also depends on such expertise, but to a lesser extent.Some of this security expertise is built into an attack pattern library.Henceforth, we assume such a library already exists.

Figure 7: Attack Tree Refinement Process
A good attack pattern library provides a set of attack profiles that are rich enough to characterize the attacks that may take place on a broad range of enterprise architectures.Refining a particular enterprise's attack tree involves first finding those attack profiles that are consistent with the enterprise architecture.The developer searches the attack patterns of consistent attack profiles for a refinement of an attack path contained in the enterprise attack tree.Once found, the developer can appropriately instantiate and apply the attack pattern to extend the enterprise attack tree.This process of pattern application intermixed with manual extension continues until the attack tree is sufficiently refined.
The rest of this section discusses in greater detail what it means for an attack profile to be consistent with an enterprise architecture, what it means for an attack pattern to be applicable to an enterprise attack tree, and how to instantiate and apply an attack pattern to refine the enterprise attack tree.The decision of when to halt the process is at the discretion of the developer.

Profile/Enterprise Consistency
As we mentioned previously, the reference model associated with an attack profile can be viewed as an architecture template.The parameters of this template are the reference model variants.If a set of values exists for these variants that unifies the attack profile's reference model with some portion of the enterprise architecture, we say that the attack profile is consistent with the enterprise architecture.The attack patterns associated with the profile are written with respect to the profile's reference model and in terms of the profile's variants.These attack patterns are, therefore, relevant to the enterprise architecture.
As a specific example of an attack profile's consistency with an enterprise architecture, look at the Network-Based Enclave Attack Profile that we described previously.The reference model for this profile, illustrated in Figure 6, is consistent with the ACME enterprise architecture, shown Figure 1.This can be seen by instantiating the profile's variants as follows: Org as ACME, Intranet as ACME Intranet, and Firewall as ACME Firewall.
Although the ACME Intranet was not explicitly labeled as such in Figure 1, it can be characterized as shown in Figure 8.The remaining variants associated with the reference model remain abstract, representing simply arbitrary Users, Attackers, and Systems to be instantiated at a later stage of refinement.

Pattern Application
Determining which attack profiles are consistent with the enterprise architecture is only the first step.Analysts must also determine which attack patterns in consistent profiles help refine the enterprise attack tree.This requires identifying a pattern whose goal helps to achieve the goal identified at an attack tree node.We say that such patterns, when properly instantiated, are applicable to the enterprise attack tree.
For example, suppose we want to use the Buffer Overflow Attack Pattern, defined previously, to refine the ACME attack tree in Figure 3.We notice that an attacker could achieve goal 5.3.5.2 (i.e., Access sensitive data from privileged account on ACME Web server) by getting access to such a privileged account and then scanning for files that contain sensitive data.Furthermore, the attacker could achieve the first of these subgoals by exploiting a buffer overflow vulnerability on the ACME Web server.But this looks similar to the goal of the Buffer Overflow Attack Pattern.
We can use the Buffer Overflow Attack Pattern if we instantiate it so that the System under attack is the ACME Web server and the malicious function that is executed provides the attacker with access to a privileged account: We do not require a rote substitute of the instantiations, but rather allow rewording to sound natural as long as it preserves the pattern's original intent.Figure 10 shows a refined portion of the attack tree as a result of applying the above attack pattern.Thus, we can refine the ACME attack tree in a way that permits the use of the pattern.This directed refinement of enterprise attack trees to apply a specific attack pattern is a common way to enable reuse.11 illustrates the three distinct types of pattern application.Each row shows the attack tree that results from applying an attack pattern, with a generic instantiation, to a particular type of node of an enterprise attack tree.Attack trees and patterns with no AND-or ORdecomposition signifier can be either an AND-or an OR-decomposition.For example, the application of an attack pattern to the leaf node of an enterprise attack tree, shown in the first row of Figure 11, does not depend on whether that node or pattern are AND-or ORdecomposed.It does depend, however, on an instantiation of the pattern that achieves the leaf node to be refined.We represent the instantiation of an attack pattern as the instantiation of each goal of the pattern, which is denoted abstractly as an "/" followed by the goal node instantiated.Thus, for leaf node application, the instantiation of the goal of the pattern (J'G R ) must achieve the leaf node to be refined (G K+ i)-The refinement of the ACME attack tree using the Buffer Overflow Attack Pattern, shown in Figure 10, exemplifies a leaf node pattern application.

Enterprise
Attack Non-Leaf Node Application to AND-Decomp

^A . / \
G K G K +n *G S /Gs+m

Figure 11: Applying Attack Patterns
The non-leaf node applications, shown in the second and third rows of Figure 11, depend on whether the node is OR-decomposed or AND-decomposed.Applying an attack pattern at an OR-decomposed node, as in the second row, simply results in another OR-branch added to the attack tree at that node.This OR-branch represents another path for the attacker to achieve the goal Gj by means of the instantiated attack pattern.Applying a pattern at an AND-decomposed node, as in the third row, results in an attack tree with two alternative paths for the attack to achieve Gj, one by means of the original attack and one by means of the instantiated attack pattern.In this case, the user must differentiate the original attack from the new attack pattern.The differentiated goal is represented abstractly as dGj.
To illustrate applying an attack pattern to an intermediate node of an attack tree, one would instantiate the Unexpected Operator Attack Pattern described in Section 3.1, as we did for the Buffer Overflow Attack Pattern.The resulting pattern, where the System under attack is the ACME Web server and the malicious function that is executed provides the attacker with access to a privileged account, is as follows:

Conclusions
The objective of this technical note is to describe a means for documenting informationsecurity attacks in a structured and reusable form.Within this scope, we show how to document possible attacks on an enterprise in the form of attack trees.Each attack tree enumerates and elaborates the ways that an attacker can compromise the enterprise's ability to accomplish its mission.We describe how to document and organize generic patterns of attack and how to reuse these to facilitate attack tree construction.The many examples provided illustrate the structures and techniques employed.This paper probably raises more questions than it answers.For example: • How does one derive requirements and improve system designs from known attacks?• What types of analysis can one perform on attack trees?
• To what level of detail should one refine attack trees?
• At what level(s) of detail should one characterize attack patterns?
• Is there a more structured language for attack patterns that would facilitate their combination and analysis?• How does one deal with the volatility of actual vulnerability discovery and system patching?• How does one prioritize the branches of an attack tree according to likelihood and impact?• How does one determine an attacker's ability and motivation for executing particular attacks?
These are a few of the questions that are driving future research.The overall goal of this research is to develop methods to derive requirements and designs for enterprise systems and operations that better survive active and malicious attacks.We believe that incorporating lessons learned from previous attacks is an important aspect of this research and that the attack tree is a useful structure to organize historical attack data.As work progresses, we will strive to refine the approach to facilitate more systematic analysis validate the practicality and scalability of the approach develop a broad range of attack profiles to support reuse formalize the model of attack tree refinement and analysis determine the proper role of automation to support the approach

Figure 1 :
Figure 1: ACME, Inc. Enterprise Architecture Figure 2: High-Level Attack Tree for ACME Figure 3: Web Server Attack Refinement Figure 4: Buffer Overflow Attack Figure 5: Unexpected Operator Attack Figure 6: Internet-Based Enclave Attack Reference Model Figure 7: Attack Tree Refinement Process Figure 8: ACME Enterprise Intranet Figure 9: PTN-Based Enclave Attack Reference Model Figure 10: Buffer Overflow Attack Refinement Figure 11: Applying Attack Patterns Figure 12: Unexpected Operator Attack Refinement

Figure 12 :
Figure 12: Unexpected Operator Attack Refinement depicts the ACME enterprise environment and architecture.The important features to notice are that ACME's property is physically protected by a fence around the perimeter.The only entrance to the property is through the fenced perimeter.In addition to the perimeter fence, physical security consists of a guarded front gate.The local networks are split between the Headquarters' LAN and the Network Services' LAN.Internet users connect to the ACME Web server through a firewall.Dial-up users get access to a particular server on the Network Services' LAN.

Compromise: Disclosure of ACME proprietary secrets OR 1. Physically
OR 1. Get physical, on-site access to Intranet 2. Get physical access to external machines 5. Attack ACME intranet using its connections with Internet OR 1. Monitor communications over Internet for leakage 2. Get trusted process to send sensitive information to attacker over Internet 3. Gain privileged access to Web server 6. Attack ACME intranet using its connections with public telephone network (PTN) OR 1. Monitor communications over PTN for leakage of sensitive information 2. Gain privileged access to machines on intranet connected via Internet Figure 2: High-Level Attack Tree for ACME Notice that the profile variants system and attacker appear in the example above.Another variant, malicious function, does not occur as a variant of the profile's reference model.The underlined phrase is defined in the profile's glossary:Buffer overflow vulnerability: A flaw in a program that, when executed with excessively long input values, causes an internal buffer to overflow overwriting portions of the execution stack and adjacent memory. CMU/SEI-2001-TN-001 Of course, other attack profiles could be used to refine the ACME attack tree, such as the PTN-Based Enclave Attack Profile.This profile contains patterns of attack over the public telephone network through dial-up modems.The reference model for this profile, shown in Figure9, is vulnerable to the Scan-Dialing Attack: Attacker knows Org telephone exchange 2. Attacker knows user name of User on System Attack: AND 1. Scan-dial Org telephone exchange for answering modems 2. Determine that connection is through Modem to System 2. Crack User's password on System 3. Login as User on System Postcondition: Attacker has access to User's account on System CMU/SEI-2001-TN-001

.5.2 Access sensitive data from privileged account on ACME Web server AND 1.
Exploit unexpected operator vulnerability to perform access privileged account Precondition: Attacker can execute certain programs on ACME Web server Attacker can access privileged account Figure 12 shows the attack tree of Figure 10 refined to apply this pattern at node 5.3.5.2.1.The third row in Figure 11 represents this type of attack pattern application.Notice that we use the goal of the Buffer Overflow Attack Pattern as the differentiated goal.Get access to privileged account on ACME Web server OR 1. Exploit buffer overflow vulnerability to access privileged account AND 1. Identify executable program on ACME Web server susceptible to buffer overflow vulnerability 2. Identify code that would provide access to privileged account when executed with the program's privilege 3. Construct input value that will force code to be in the program's address space 4. Execute program in a way that makes it jump to address at which code resides 2. Exploit unexpected operator vulnerability to access privileged account AND 1. Identify executable program on ACME Web server susceptible to unexpected operator vulnerability 2. Identify (unexpected) operator that permits composing system calls 3. Identify system call that would provide access to privileged account when executed with program's privilege 4. Construct unexpected input by composing legal input value with system call using the unexpected operator 5. Execute program on ACME Web server with unexpected input 2. Scan files for sensitive data CMU/SEI-2001-TN-001Unexpected Operator Attack Pattern:(instantiated)Goal: