New to CAPEC? Start Here
Home > CAPEC List > Reports > Schema Differences between Version 2.7.1 and Version 3.0  

Schema Differences between Version 2.7.1 and Version 3.0

Version 2.7.1 Schema File: capec_schema_v2.7.1.xsd -> Version 3.0 Schema File: capec_schema_v3.0.xsd

Major changes from 2.7.1 --> 3.0:

  1. Make the <Attack_Pattern_Catalog> the only valid root element. The previous 2.7.1 schema allows any number of elements to be valid root elements. As part of this change, the other children (Attack_Patterns, Views, Categories, and External_References) become optional. The previous <Attack_Pattern_Catalog> requires the existence all of the child element, even if they are empty.
  2. The <Compound_Element> has been removed. The rationale for this is that named chains and composites are attack patterns themselves and should therefore be defined by <Attack_Pattern> elements.
  3. Add the <External_References> element to the attack pattern catalog. In the previous 2.7.1 schema, references were defined inside an individual attack patterns, but assigned an ID so that they could be reused if the reference was used elsewhere. It is cleaner and easier to understand if there is a central collection of references that individual attack patterns can pull from as needed. As a side benefit, there is no longer a need to have a local reference ID as the main ID can be used.
  4. Vulnerabilities are no longer included in a CAPEC. CAPECs should reference CWEs, when possible. CWEs are associated with CVEs.
  5. Simplify element names :

    Current Element Name New Element Name
  6. Tweak the child elements of a <View> :

    Current Elements New Elements Note / Reason
    View_Structuremoved to the "Type" attribute
    View_AudienceAudiencechanged to require description
    RelationshipsMembersonly allowed relationship is <Has_Member>
    Relationship_Notescombined with <Notes>
    Maintenance_Notescombined with <Notes>
    Other_NotesNotesadded "Type" attribute
    Alternate_Termsdoesn't make sense for views
    Research_Gapsdoesn't make sense for views
  7. Tweak the child elements of a <Category> as it currently uses the same Common_Attributes group as attack patterns do. Many of these fields are not applicable to categories. The following set of fields are children of the <Category> element in the 3.0 schema.

    • Summary
    • Relationships (memberOf and hasMember)
    • Taxonomy_Mappings
    • References
    • Notes (with new Type attribute)
    • Content_History

    The removed fields are:

    • Related_Weaknesses
    • Attack_Prerequisites
    • Methods of Attack
    • Attacker_Skills_or_Knowledge_Required
    • Resources_Required
    • Attack_Motivation-Consequences
    • Background_Details
    • Alternate_Terms
  8. Remove the following child elements of <Attack Pattern> as they are only used in a limited manner and did not hold any unique information.

    • Target Attack Surface
    • Methods of Attack
    • Probing Techniques
    • Obfuscation Techniques
    • Injection Vector
    • Payload
    • Activation Zone
    • Payload Activation Impact
    • Related Vulnerabilities
    • Relevant Security Requirements
    • Relevant Design Patterns
    • Relevant Security Patterns
    • Related Security Principles
    • Related Guidelines
    • Purposes
    • CIA Impact
    • Technical Context
    • Keywords
  9. For attack patterns, the "Description" element is now a simple string. Previously there was a <Description> element with two children; a short description was named <Summary>, and the other was named <Attack_Execution_Flow>. The 3.0.0 schema removes the subelement <Summary> and changes the name of <Attack_Execution_Flow> to <Execution_Flow>, which has been repurposed as a top-level element.
  10. Only use the RelationshipsType complex type for categories and views (for views, the element name has been changed to <Members>). Also limit the values to memberOf and hasMember since these are the only ones that are appropriate for views and categories. For attack patterns, add a new <Related_Attack_Pattern> element that holds all the different types of relationships that attack patterns can have with each other. The reason for this change is to eliminate the incorrect use memberOf and hasMember relationships with attack patterns, and the incorrect use of parentOf and childOf with categories.
  11. Combine all the different note elements into a single <Notes> element. Add a type attribute that allows for a distinction between: maintenance, relationship, research gap, terminology and other. This is done to simplify the schema and the resulting XML by having less elements.
  12. The StructuredTextType leverages the existing XHTML standard.
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018