Description and globally unique ID for a kind of environment or context that is required. Used in Attack Steps, Indicators of Susceptibility, and Security Controls, etc. Either positive, negative, or inconclusive indicators that the system under consideration is susceptible to the attack step. That is, some reason to believe that the attack step will or will not succeed. This field contains a brief description of the indicator. References the defined environments where this indicator of susceptibility is applicable. This field contains a unique integer identifier for the indicator. Each indicator has a mandatory type attribute that can be one of the values “Positive,” “Negative,” or “Inconclusive.” For example, a positive indicator of susceptibility to parameter tampering is the existence of parameters in the URL. Although it does not guarantee susceptibility, it indicates a cause for further examination. A negative indicator for the technique of privilege escalation is a lack of credentials and user identifiers in an application. Again, this is not a conclusive measure of resistance to attack, but an indicator that the attack step technique is unlikely to bear significant fruit. An inconclusive indicator of susceptibility to dynamic code injection is a page whose URL ends in .jsp, .asp, or .do but which has no visible explicit parameters. Such URLs typically indicate dynamic processing, but since no visible parameters are passed, it is inconclusive whether dynamic code could be injected into the application. A particular technique that may accomplish this attack step. This field contains a brief description of the attack step technique. References the defined environments where this attack step technique is applicable. An indicator of the outcome of an Attack Step. Successful outcomes are those that further the attacker's goals. Failure outcomes are those that do not further the attacker's goals. Inconclusive outcomes are those that do not indicate success or failure, but are likely outcomes. This field contains a unique integer identifier for the outcome. An outcome has a mandatory type attribute that can be one of the values “success,” “failure,” or “inconclusive.” It indicates what results of executing the attack step techniques should be considered successes, which should be considered failures, and which ones are inconclusive. Outcomes’ successes are determined relative to the attacker’s point of view. It is a success if the attack step got the attacker closer to his goal of attacking the application. It is a failure if the attacker got no closer to his goal. An action that a defender can take against a particular Attack Step to avoid the impact or to thwart the attacker's goals. A detective control alerts the defender to the fact that the attack step was carried out (regardless of whether the step was successful or not). A corrective control reacts to the attack step in some way to attempt to neutralize or minimize the effectiveness of the attack step. Preventative controls try to make an attack step impossible to complete. This field contains a unique integer identifier for the security control. Each security control has a mandatory type attribute that can be one of the values “Detective,” “Corrective,” or “Preventative.” Detective controls detect an attacker’s activities in the attack step, whether the activities are successful or not. Corrective controls attempt to mitigate an attacker’s success by responding to a successful outcome. They are not related to or normalized against outcomes. Preventative controls are those that make the attack step unlikely or impossible to succeed. Segment the attack steps into the various phases of attack. One of three phases "Explore," "Experiment," or "Exploit." Each phase should appear at most once, and attack steps should be grouped by what kind of activities the attacker is carrying out. The exploration and experimentation phases may or may not occur during a particular attack, because the attacker may already know exactly how to exploit a system. One of three phases "Explore," "Experiment," or "Exploit." Each phase should appear at most once, and attack steps should be grouped by what kind of activities the attacker is carrying out. Brief description of an individual action step in carrying out the attack This field contains a short descriptive title for the attack step. It should be kept as short as possible but also clearly convey the nature of the attack step being described. This field contains a brief description of the attack step. This field captures various techniques that the attacker can use to achieve the attack step’s goal. For example, an attacker may use tools such as WebScarab and Tamper Data in the experimentation phase of a SQL Injection attack pattern. The techniques include references to environments, because not all techniques work in all environments These are indicators that the application may or may not be susceptible to the given attack step (not necessarily the pattern as a whole). This field captures possible outcomes for this attack step. This field captures security controls for this attack step that describe ways in which the attack step can be detected, corrected, or prevented. These are presented from a defender’s point of view, where the defender may be a developer, tester, operations administrator, or other resource resisting the attacker. "Explore," "Experiment," or "Exploit." This is the enumerated catalog of common attack patterns. This element is an individual attack pattern. This field contains a detailed description of the attack including the chain of actions taken by the attacker. More comprehensive descriptions could include relevant attack trees and/or exploit graphs to more clearly elaborate this type of attack. Brief description of what the attack involves and what weaknesses it is leveraging for exploit. Outline of the steps involved in an attacker executing the typical flow of the attack. This field describes the conditions that must exist or the functionality and characteristics that the target software must have or behavior it must exhibit for an attack of this type to succeed. This field describes an individual attack prerequisite. On a rough scale (Very Low, Low, Medium, High, Very high), what is the typical severity of impact to the targeted software if this attack occurs? The severity of a specific attack instance can vary greatly depending on the specific context of the target software under attack. This field is intended to capture an overall typical average value for this type of attack with the understanding that it will not be completely accurate for all attacks. On a rough scale (Very Low, Low Medium, High, Very High), what is the overall likelihood of this type of attack typically succeeding considering the attack prerequisites, targeted weakness attack surface, skill required and resources required as well as available and likely implemented blocking solutions? The likelihood of exploit of a specific attack instance can vary greatly depending on the specific context of the target software under attack. This field is intended to capture an overall typical average value for this type of attack with the understanding that it will not be completely accurate for all attacks. On a rough scale (Very Low, Low Medium, High, Very High), what is the overall likelihood of this type of attack typically succeeding considering the attack prerequisites, targeted weakness attack surface, skill required and resources required as well as available and likely implemented blocking solutions? This field captures any useful explanation for the defined Likelihood. This field describes the mechanism of attack used by this pattern. This field can help define the applicable attack surface required for this attack. This field describes the mechanism of attack used by this pattern. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined vectors which is currently incomplete and will grow as new relevant vectors are identified. This field can help define the applicable attack surface required for this attack. This field contains explanatory examples or demonstrative exploit instances of this attack, which are intended to help the reader understand the nature, context and variability of the attack in more practical and concrete terms. This field describes an individual example or exploit instance. This field describes in detail a specific example or exploit instance of this attack. It should outline the context of the attack, the targeted software, the targeted weaknesses or vulnerabilities, the specific set of actions involved in the attack and the resulting impact of the attacks success or failure (in the case of counterexamples). This field lists the specific vulnerabilities targeted by this exploit instance of the attack. Specific vulnerabilities should reference industry-standard identifiers such as Common Vulnerabilities and Exposures (CVE) numbers and/or US-CERT numbers. This field describes the level of skill or specific knowledge required by an attacker to execute this type of attack. This should be communicated on a rough scale (Low, Medium, High) as well as in contextual detail. For example: • Low - Basic computer familiarity • Low - Basic SQL knowledge • Medium - Moderate scripting and shell experience and ability to disassemble and decompile • High - Expert knowledge of LINUX kernel • High - Detailed knowledge of target software development practices and business context (former employee) • Etc. This field describes the resources (CPU cycles, IP addresses, tools, etc.) required by an attacker to effectively execute this type of attack. This field describes techniques typically used to probe and reconnoiter a potential target to determine vulnerability and/or to prepare for this type of attack. This field describes an individual probing technique. This field describes activities, events, conditions or behaviors that could serve as indicators that an attack of this type is imminent, in progress or has occurred. This field describes an individual indicator/warning. This field describes techniques typically used to disguise the fact that an attack of this type is imminent, in progress or has occurred. This field describes an individual obfuscation technique. This field describes actions or approaches that can potentially prevent or mitigate the risk of this attack. These solutions and mitigations are targeted to improve the resistance of the target software and thereby reduce the likelihood of the attack’s success or to improve the resilience of the target software and thereby reduce the impact of the attack if it is successful. This field describes an individual blocking solution or mitigation. What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. This information is useful for aligning attack patterns to threat models and for determining which attack patterns are relevant for a given context. What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined motivations/consequences which is currently incomplete and will grow as new relevant possibilities are identified. This information is useful for aligning attack patterns to threat models and for determining which attack patterns are relevant for a given context. This field describes the technical contexts in which this pattern is relevant. This could involve factors such as platform, OS, language, architectural paradigm, etc. The specific factors to be part of this field have yet to be determined. This field will be iteratively refined as more is learned through the identification and elaboration of new attack patterns. This information is useful for aligning attack patterns to attack surfaces and for determining which attack patterns are relevant for a given context. This field describes, as precisely as possible, the mechanism and format of an input-driven attack of this type. Injection vectors must take into account the grammar of an attack, the syntax accepted by the system, the position of various fields, and the ranges of data that are acceptable. This field describes the code, configuration or other data to be executed or otherwise activated as part of an injection-based attack of this type. This field describes the area within the target software that is capable of executing or otherwise activating the payload of an injection-based attack of this type. The activation zone is where the intent of the attacker is put into action. The activation zone may be a command interpreter, some active machine code in a buffer, a client browser, a system API call, etc. This field is a description of the impact that the activation of the attack payload for an injection-based attack of this type would typically have on the confidentiality, integrity or availability of the target software. Which specific weaknesses does this attack target and leverage? Specific weaknesses (underlying issues that may cause vulnerabilities) reference the industry-standard Common Weakness Enumeration (CWE). This list should include not only those weaknesses that are directly targeted by the attack but also those whose presence can directly increase the likelihood of the attack succeeding or the impact if it does succeed. This field describes an individual related weakness. The CWE_ID is a field that exists for all weaknesses enumerated in the Common Weakness Enumeration (CWE). It is a unique value that allows each weakness to be unambiguously identified. The CWE_ID field for the attack pattern contains the value of the CWE_ID for the specific related weakness. This field describes the nature of the relationship between this weakness and the attack pattern. Weaknesses that are specifically targeted by the attack are of type “Targeted”. Weaknesses which are not specifically targeted but whose presence may increase the likelihood of the attack succeeding or the impact of the attack if it does succeed are of type “Secondary”. What specific vulnerabilities does this attack target and leverage? Specific vulnerabilities should reference industry-standard identifiers such as Common Vulnerabilities and Exposures (CVE ) numbers and/or US-CERT numbers. As vulnerabilities are much more specific and localized than weaknesses, it is typically rare that an attack pattern will target specific vulnerabilities. This would most likely occur if they are targeting vulnerabilities in underlying platforms, frameworks, libraries, etc. This field describes an individual related vulnerability. This field uses the unique reference ID for a specific related vulnerability utilizing an industry standard vulnerability listing (e.g., CVE-2006-4192, VU#650769, etc.). This field contains a short textual description of the specific related vulnerability taken from the industry standard vulnerability listing. This field identifies other attack patterns that are somehow related to, dependent on, typically chained together, etc. with this pattern. This field describes an individual related attack pattern. This field contains a unique identifier for the related pattern of the form “AP-####” (e.g., AP-0012). This field contains a short descriptive name for the related pattern. It should be kept as short as possible but also clearly convey the nature of the attack being described. This field defines the nature of the relationship between this pattern and the related pattern. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined relationship types. This enumerated list of choices is likely to grow as new, useful types of relationships are identified. This field provides a mechanism to provide further context and description to the nature of the relationship. This field identifies specific security requirements that are relevant to this type of attack and are general enough to offer opportunities for reuse. This field describes an individual relevant security requirement. This field identifies specific relevant design patterns that are recommended as providing resistance or resilience to this attack, or which are not recommended as they are particularly susceptible to this type of attack. This field describes an individual design pattern that is recommended due to its likelihood of increasing the software’s resistance or resiliency to this type of attack. This field describes an individual design pattern that is not recommended due to its likelihood of decreasing the software’s resistance or resiliency to this type of attack. This field identifies specific security patterns that are recommended as providing resistance or resilience to this type of attack. This field describes an individual relevant security pattern. This field identifies specific security principles relevant to this attack pattern. The security principles that this field references come from the set available on the Build Security In website. This field describes an individual security principle. This field identifies existing security guidelines that are relevant to identifying or mitigating this type of attack. This field describes an individual related guideline. This field describes the generalized purpose of the pattern in order to enable the capture of pattern composibility. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined purposes which may be currently incomplete and may grow as new relevant possibilities are identified. This field characterizes the typical relative impact of this pattern on the confidentiality, integrity and availability of the targeted software. This field describes the typical impact of this pattern on the confidentiality characteristics of the targeted software and related data. This field describes the typical impact of this pattern on the integrity characteristics of the targeted software and related data. This field describes the typical impact of this pattern on the availability characteristics of the targeted software and related data. This field characterizes the technical context where this pattern is applicable. This field outlines the architectural paradigms of target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined paradigms which may be currently incomplete and may grow or change as new relevant possibilities are identified. This field outlines the frameworks used as part of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined frameworks which may be currently incomplete and may grow or change as new relevant possibilities are identified. This field outlines the platforms (OS) of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined platforms which may be currently incomplete and may grow or change as new relevant possibilities are identified. This field outlines the implementation languages of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined platforms which may be currently incomplete and may grow or change as new relevant possibilities are identified. This field is intended to be a catch-all field for assisting in searching and subsecting a collection of patterns according to criteria not contained elsewehre in this schema. This field contains an individual keyword to be used for tagging and searching. This field enumerates reference resources that were used to develop the definition of this attack pattern and those that could prove valuable to the reader looking for further information on this attack. This field should describe the reference clearly and unambiguously by name and with some method of address such that the reader can locate the resource for further reference. This field describes the identity of the pattern submitter. This field describes the organization of the pattern submitter. This field describes the date on which the pattern was submitted to CAPEC. This field captures any relevant description or explanation of the submission. This field describes the identity of the pattern modifier. This field describes the organization of the pattern modifier. This field describes the date on which the pattern was modified in CAPEC. This field captures any relevant description or explanation of what was modified and why.