This is the enumerated catalog of common attack patterns. A category is a collection of attack patterns sharing a common attribute. The shared attribute may any number of things. The Compound_Element structure represents a meaningful aggregation of several attack patterns. Each View element represents a perspective with which one might look at the attack patterns in CAPEC. The View_Attributes structure is a collection of common elements which might be shared by all Views. The ID attribute provides a unique identifier for the entry. It will be static for the lifetime of the entry. In the event that this entry becomes deprecated, the ID will not be reused and a pointer will be left in this entry to the replacement. This is required for all Views. The Name is a descriptive attribute used to give the reader an idea of what perspective this view represents. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. This is required for all Views. The Status attribute defines the status level for this view. This field provides a description of this Category. Its primary subelement is Description_Summary which is intended to serve as a minimalistic description which provides the information necessary to understand the primary focus of this entry. Additionally, it has the subelement Extended_Description which is optional and is used to provide further information pertaining to this attack pattern. This description should be short and should limit itself to describing the key points that define this entry. Further explanation can be included in the extended description element. This is required for all entries. This element provides a place for details important to the description of this entry to be included that are not necessary to convey the fundamental concept behind the entry. This is not required for all entries and should only be included where appropriate. 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”. 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. 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 describes the level of skills or specific knowledge required by an attacker to execute this type of attack. 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). 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 provides contextual detail for the skill or knowledge level. This field describes the resources (CPU cycles, IP addresses, tools, etc.) required by an attacker to effectively execute this type of attack. 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. The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is an Attack Pattern, Category, or Compound_Element and another structure. This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. This structure contains one or more Background_Detail elements, each of which holds information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the entry itself. It should be filled out where appropriate. This element contains background information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the category itself. It should be filled out where appropriate. This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. This structure contains one or more Research gap elements, each of which identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. The References element contains one or more Reference elements, each of which provide further reading and insight into this attack pattern. This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. This attribute provides a unique identifier for the entry. It will be static for the lifetime of the entry. In the event that this entry becomes deprecated, the ID will not be reused and a pointer will be left in this entry to the replacement. This is required for all Categories. The Name is a descriptive name used to give the reader an idea of what the commonality is amongst the children of this category. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. This is required for all Categories. The Status attribute defines the status level for this category. This element is an individual attack pattern. This field provides a description of this Structure, whether it is an Attack Pattern, Category or Compound Element. Its primary subelement is Description_Summary which is intended to serve as a minimalistic description which provides the information necessary to understand the primary focus of this entry. Additionally, it has the subelement Extended_Description which is optional and is used to provide further information pertaining to this attack pattern. This description should be short and should limit itself to describing the key points that define this entry. Further explanation can be included in the extended description element. This is required for all entries. This element provides a place for details important to the description of this entry to be included that are not necessary to convey the fundamental concept behind the entry. This is not required for all entries and should only be included where appropriate. The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is an Attack Pattern, Category, or Compound_Element and another structure. This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. This structure contains one or more Background_Detail elements, each of which holds information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the entry itself. It should be filled out where appropriate. This element contains background information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the attack pattern itself. It should be filled out where appropriate. This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. This structure contains one or more Research gap elements, each of which identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. The References element contains one or more Reference elements, each of which provide further reading and insight into this attack pattern. This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. This attribute provides a unique identifier for the entry. It will be static for the lifetime of the entry. In the event that this entry becomes deprecated, the ID will not be reused and a pointer will be left in this entry to the replacement. This is required for all Compound_Elements. The Name is a descriptive name used to give the reader an idea of the meaning behind the compound attack pattern structure. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. This is required for all Compound_Elements. The Abstraction defines the abstraction level for this attack pattern. The abstraction levels for Compound_Elements and Attack Patterns are the same. For example, if the Compound_Element is a chain, and all elements of the chain are Meta level, then the Compound_Element Abstraction attribute is Meta. This is required for all Compound_Elements. The Structure attribute defines the structural nature of this compound element - that is, composed of other attack patterns concurrently, as in a composite, or consecutively, as in a chain. The Status attribute defines the status level for this compound element. 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. 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 "Explore," "Experiment," or "Exploit." 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. The View_Attributes structure is a collection of common elements which might be shared by all Views. The View_Structure element describes how this view is being constructed. Valid values are: Implicit Slice = a slice based on a filter criteria; Explicit Slice = a slice based on arbitrary membership, as defined by specific relationships between entries; Graph = a bounded graphical slice based on ChildOf relationships. The View_Objective element describes the perspective from which this View is constructed. The View_Audience element provides a reference to the targeted audiences or groups for this view. The Audience element provides a reference to the target audience or group for this view. The Stakeholder element specifies what types of members of the CAPEC community might be interested in this view. The Stakeholder_Description el provides some text describing what properties of this View this particular Stakeholder might find useful. The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is a Attack Pattern, Category, or Compound_Element and another structure. This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. This structure contains one or more Research gap elements, each of which identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. The References element contains one or more Reference elements, each of which provide further reading and insight into this view. This should be filled out when the view is based on sources or projects that are external to the CAPEC project. The View_Filter element holds an XSL query for identifying which elements are members of an implicit slice. This should only be present for implicit slices. This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is a Attack Pattern, Category, or Compound_Element and another structure. Each Relationship identifies an association between this structure, whether it is an Attack Pattern, Category, or Compound_Element and another structure. The relationship also identifies the views under which the relationship is applicable. This element contains a list of the individual Views to which this relationship pertains. Specifies the unique ID of the individual view element to which this relationship pertains. This ID must correspond to a View. The ordinal attribute is used to determine if this relationship is the primary ChildOf relationship for this entry for a given Relationship_View_ID element.. This attribute can only have the value "Primary" and should only be included for the primary parent/child relationship. This element contains a list of the individual Chains this relationship pertains to. This element specifies the unique ID of an individual chain element this relationship pertains to. The Relationship_Target_Form element defines the form of the target of this relationship, such as Category, Attack Pattern, View or Compound_Element. The Relationship_Nature element defines the nature of the relationship between this element and the target element, such as ChildOf, HasMember or Requires to name a few. This Relationship_Nature denotes the specified entry as a top level member of this View. This value for Relationship_Nature can only be used in Views. The complementary relationship is MemberOf. This Relationship_Nature denotes membership of this entry in the top level of the View specified in Relationship_Target_ID. The complementary relationship is HasMember. This Relationship_Nature denotes a specified entry as a parent of this entry. In general, this means that the parent will be a higher level representation of this entry from the perspective of the View provided in Relationship_View_ID. The complementary relationship is ParentOf. This Relationship_Nature denotes a specified entry as a child of this entry. In general, this means that the child will be a lower level representation of this entry from the perspective of the View provided in Relationship_View_ID. The complementary relationship is ChildOf. This Relationship_Nature denotes a specified entry as having some similarity with this entry which does not fit any of the other Relationship_Nature values. In this case, a Relationship_Note should also be provided explaining the connection. The complementary relationship is itself (PeerOf). This Relationship_Nature denotes a Compound_Element of Compound_Element_Structure="Composite". All entries that a Composite Requires must exist simultaneously in order for the Compound_Element to exist. The complementary relationship is RequiredBy. This Relationship_Nature denotes an entry that is required in order for the Compound_Element specified in Relationship_Target_ID to exist. The complementary relationship is Requires. This Relationship_Nature denotes the starting point in this chain as the entry specified by Relationship_Target_ID. This Relationship_Nature can only be used for Compound_Elements with Compound_Element_Structure="Chain". For named chains, the complementary relationship is StartsChain. This Relationship_Nature denotes this entry as the starting point in the chain specified in Relationship_Target_ID. For named chains, the complementary relationship is StartsWith. This Relationship_Nature denotes a chain where this entry can precede the entry specified by Relationship_Target_ID in a sequential fashion. It is important to note that not all CanPrecede relationships are captured in a Compound_Element chain, only the most common for now. The complementary relationship is CanFollow. This Relationship_Nature denotes a chain where this entry can follow the entry specified by Relationship_Target_ID in a sequential fashion. It is important to note that not all CanFollow relationships are captured in a Compound_Element chain, only the most common for now. The complementary relationship is CanPrecede. This Relationship_Nature denotes an entry that, in the proper environment and context, can also be perceived as the entry specified by Relationship_Target_ID. This relationship is not necessarily reciprocal. The Relationship_Target_ID specifies the unique ID of the target element of the relationship. This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. This element contains a note regarding the relationships between CAPEC entries. This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. This element describes a significant maintenance task within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. This element contains any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. This element contains alternate terms by which this attack pattern may be known and a description to explain the context in which the term may be relevant. This is not required for all entries and should only be included where appropriate. This element contains the actual term for the Alternate_Term element. Each term should follow the same conventions as the entry Name attribute. This element provides context to each Alternate_Term by which this attack pattern may be known. This structure contains one or more Research gap elements, each of which identifies potential opportunities for the attack research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. This element identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. This structure contains one or more Submission elements. This element houses the subelements which identify the submitter and the submitter's comments related to this entry. This element has a single attribute, Submission_Source, which provides a general idea of how the initial information for this entry was obtained, whether internal to the CAPEC team, external, donated, etc. This element should contain the name of the author for this entry. This element should identify the author's organization. This element should provide the date on which this content was authored in YYYY-MM-DD format. This element provides the author with a place to store any comments regarding the content of this attack pattern entry, such as assumptions made, reasons for omitting elements, contact information, pending questions, etc. This attribute identifies how the initial information for this entry was obtained. This structure contains one or more Contribution elements. This element houses the subelements which identify the contributor and contributor's comments related to this entry. This element has a single attribute, Contribution_Mode, which indicates whether the contribution was part of feedback given to the CAPEC team or actual content that was donated. This element should contain the name of the author for this entry. This element should identify the author's organization. This element should provide the date on which this content was authored in YYYY-MM-DD format. This element provides the author with a place to store any comments regarding the content of this attack patterns entry, such as assumptions made, reasons for omitting elements, contact information, pending questions, etc. This attribute indicates whether the contribution was part of feedback given to the CAPEC team or actual content that was donated. This structure contains one or more Modification elements. This element houses the subelements which identify the modifier and modifier's comments related to this entry. A new Modification element should exist for each modification of the entry content. This element has a single attribute, Modification_Source, which indicates whether this modification was made by a CAPEC team member or an external party. This element should contain the name of the person modifying this entry. This element should contain the modifier's organization. This element should contain the date of the modifications. This element provides the modifier with a place to store any comments regarding the content of this attack pattern entry, such as assumptions made, reasons for omitting elements, contact information, pending questions, etc. This attribute identifies how significant the modification is to the attack pattern with regard to the meaning and interpretation of the pattern. If a modification has a value of Critical, then the meaning of the entry or how it might be interpreted has changed and requires attention from anyone previously dependent on the attack pattern. This attribute indicates whether this modification was created by a CAPEC team member or provided by an external party. This structure contains one or more Previous_Entry_Name elements, each of which describes a previous name that was used for this entry. This should be filled out whenever a substantive name change occurs. This element identifies a name that was previously used for this entry. This lists the date on which this name was changed to something else. Typically, this date will be closely aligned with new releases of CAPEC. Block is a Structured_Text element consisting of one of Text_Title, Text, Code_Example_Language, or Code followed by another Block element. Structured_Text elements help define whitespace and text segments. Presentation Element: This element is used to definebold-faced title for a subsequent block of text. Presentation Element: This element is used to define a paragraph of text. Presentation Element: This element is used to identify the programming language being used in the following block of Code Presentation Element: This element is used to define a line of code. Presentation Element: This element is used to define a comment in code. Presentation Element: This element is used to define an image. Presentation Element: This element is used to define an image. This element provides the location of the image file. This element provides a title for the image. Block is a Structured_Text element consisting of one of Text_Title, Text, Code_Example_Language, or Code followed by another Block element. Structured_Text elements help define whitespace and text segments. Block is a Structured_Text element consisting of one of Text_Title,Text, Code_Example_Language, or Code followed by another Block element. Structured_Text elements help define whitespace and text segments. This attribute identifies the nature of the content containedwithin the Block. The References_List_Type contains one or more Reference elements, each of which provide further reading and insight into the item. This should be filled out as appropriate. Each Reference subelement should provide a single source from which more information and deeper insight can be obtained, such as a research paper or an excerpt from a publication. Multiple Reference subelements can exist. The sole attribute of this element is the id. The id is optional and translates to a preceding footnote below the context notes if the author of the entry wants to cite a reference. Not all subelements need to be completed, since some are designed for web references and others are designed for book references. The fields Reference_Author and Reference_Title should be filled out for all references if possible. Reference_Section and Reference_Date can be included for either book references or online references. Reference_Edition, Reference_Publication, Reference_Publisher, and Reference_PubDate are intended for book references, however they can be included where appropriate for other types of references. Reference_Link is intended for web references, however it can be included for book references as well if applicable. This element identifies an individual author of the material being referenced. It is not required, but may be repeated sequentially in order to identify multiple authors for a single piece of material. This element identifies the title of the material beingreferenced. It is not required if the material does not have a title. This element is intended to provide a means of identifying the exact location of the material inside of the publication source, such as the relevant pages of a research paper, the appropriate chapters from a book, etc. This is useful for both book references and internet references. This element identifies the edition of the material being referenced in the event that multiple editions of the material exist. This will usually only be useful for book references. This element identifies the publication source of the reference material, if one exists. This element identifies the publisher of the reference material, if one exists. This element identifies the date when the reference was included in the entry. This provides the reader with a time line for when the material in the reference, usually the link, was valid. The date should be of the format YYYY-MM-DD. This field describes the date when the reference was published YYYY. This element should hold the URL for the material being referenced, if one exists. This should always be used for web references, and may optionally be used for book and other publication references. The id attribute is optional and is used as a mechanism forciting text in the entry. If an id is provided, it is placed between brackets and precedes this reference and the matching id should be used inside of the text for the attack pattern itself where this reference is applicable. All reference ids assigned within an entry must be unique. 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 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. This field captures possible outcomes for this attack step. 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. 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. 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. This subelement identifies an individual consequence that may result from this attack pattern. This subelement describes the technical impacts that can result from successful execution of this attack pattern. This subelement provides additional commentary about this consequence. The Common_Consequence_ID stores the value for the related Common_Consequence entry identifier as a string. Only one Common_Consequence_ID element can exist for each Common_Consequence element (ex: CC-1). However, Common_Consequences across CAPEC with the same ID should only vary in small details. 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 element contains one or more Alternate_Term elements, each ofwhich contains other names used to describe this attack pattern. 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 skills or specific knowledge required by an attacker to execute this type of attack. 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). 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 provides contextual detail for the skill or knowledge level. 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, 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 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 purposes 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 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 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 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 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 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. The Status attribute defines the status level for this view.