CAPEC to OWL Mapping v1.0

Overview

CAPEC (Common Attack Pattern Expression and Enumeration) is the MITRE-maintained repository of common attack patterns used by adversaries. Each attack pattern describes a methodology for targeting specific weaknesses, covering attack prerequisites, execution flows, and typical severity outcomes. CAPEC patterns map to the core ontology's kgcs:AttackPattern class, providing detailed attack methodology semantics complementary to ATT&CK tactics and techniques. This mapping bridges CAPEC schema v3.5.0 XML structures into KGCS OWL representation for integrated threat modeling and attack surface analysis.

Sources

• data/schemas/CAPEC/ap_schema_latest.xsd (CAPEC v3.5.0, October 2021)
• MITRE CAPEC Knowledge Base: http://capec.mitre.org/
• CAPEC namespace: http://capec.mitre.org/capec-3
• XML Schema defines root Attack_Pattern_Catalog with:
  • AttackPatterns collection (unbounded)
  • Categories collection (groupings by effect/intent)
  • Views collection (perspective-based organization)
  • ExternalReferences collection (citations, resources)

Target Ontology

• standards/capec/capec-ontology-v1.0.owl (to be created)
• Core classes used: kgcs:AttackPattern (from core ontology)
• New CAPEC namespace: capec: <http://www.motherhacker.me/kgcs/ontology/capec#>
• Import: owl:imports <http://www.motherhacker.me/kgcs/ontology/core#>
• Inheritance: All CAPEC classes extend or relate to core cybersecurity semantics

Entity Mapping

Field Mapping: Attack Pattern (Primary Entity)

Core Required Fields

Optional Metadata Fields

Complex Type Aggregations

Field Mapping: Category and View Entities

Category Fields

View Fields

Relationship Mapping

Attack Pattern Relationships (Critical)

Related patterns are organized by nature of relationship, reflecting attack methodology dependencies:

Exclude_Related Logic: Relationship can have exception contexts (e.g., "ChildOf X except in Y context") - preserved in Transformation Notes.

Critical External Relationships

CWE Linkage (Weakness Exploitation - CRITICAL)

Logic: Multiple CWEs = ANY one (or specific combination) may enable the attack. Does NOT imply all must be present for success.

Implementation: Create bidirectional reference enabling queries:

• Forward: "What CWEs does this CAPEC pattern exploit?"
• Reverse: "What CAPEC patterns exploit CWE-89?"

Category/View Organization

Cross-Taxonomy Mapping

Supported Taxonomies: ATT&CK, WASC, OWASP Attacks, others

Transformation Notes

CWE Integration Strategy (Critical for ETL)

Semantic Binding:

CAPEC Pattern X exploitsCWE [CWE-Y, CWE-Z]
means: "Successful execution of Pattern X requires the presence of Weakness Y OR Z (or combination)"

ETL Implementation:

1. Parse Related_Weakness CDATA containing <Related_Weakness CWE_ID="[integer]"/>
2. Create capec:exploitsCWE ObjectProperty linking to external CWE instance URI
3. Format CWE URI: http://www.motherhacker.me/kgcs/ontology/cwe#CWE_[ID]
4. Example: CAPEC-18 (SQL Injection) → capec:exploitsCWE → CWE-89
5. Validation: Alert if pattern has zero CWE references (recommend minimum 1)

Bidirectional Index Support: Enable queries such as:

SELECT ?pattern WHERE {
  ?pattern capec:exploitsCWE cwe:CWE_89 .
}

Attack Pattern Abstraction Levels (Hierarchy)

Meta          [Generalized approach, technology-agnostic, parent patterns]
  ├─ Standard [Focused technique/methodology, general approach]
  │  └─ Detailed [Low-level specifics, technology/implementation-bound]

Ontology Implementation Options:

Option 1: Datatype Property (Recommended)

capec:abstraction a owl:DatatypeProperty ;
    rdfs:domain kgcs:AttackPattern ;
    rdfs:range xsd:string ;
    rdfs:comment "Enum values with implicit hierarchy (client imposes ordering)" .

Option 2: Class Hierarchy

capec:DetailedPattern rdfs:subClassOf capec:StandardPattern ;
  rdfs:subClassOf capec:MetaPattern .

ETL Rule: Enforce hierarchy: Meta-level patterns cannot have Detailed parents.

Status Lifecycle & Interpretation

ETL Implementation: Filter based on status in ETL rules; provide status-aware query results for trust scoring.

Complex Type Handling

1. ExecutionFlow → Ordered Sequence

XML Structure Example:

<Execution_Flow>
  <Attack_Step Number="1" Phase="Explore">
    <Description>Attacker searches for target...</Description>
  </Attack_Step>
  <Attack_Step Number="2" Phase="Experiment">
    <Description>Attacker tests for vulnerability...</Description>
  </Attack_Step>
</Execution_Flow>

OWL Representation (rdf:Seq for ordering):

[ rdf:type rdf:Seq ;
  rdf:_1 [ capec:stepNumber 1 ;
           capec:stepPhase "Explore" ;
           capec:stepDescription "Attacker searches for..." ] ;
  rdf:_2 [ capec:stepNumber 2 ;
           capec:stepPhase "Experiment" ;
           capec:stepDescription "Attacker tests for..." ]
]

Phase Enumeration: Explore (reconnaissance), Experiment (testing), Exploit (execution)

2. Prerequisites → Unordered Bag

Representation: rdf:Bag of text descriptions (unordered, typically 1-5 items)

capec:prerequisites [ rdf:type rdf:Bag ;
  rdf:_1 "Attacker has network access to target" ;
  rdf:_2 "Target system has unpublished vulnerability"
]

3. SkillsRequired → Typed Objects with Levels

OWL Class:

capec:SkillRequirement a owl:Class ;
  rdfs:subClassOf [
    owl:onProperty capec:skillName ;
    owl:hasValue "SQL Injection"
  ] .

Instance Structure:

[ capec:skillName [ rdfs:label "SQL Injection" ] ;
  capec:skillLevel "Medium" ;
  capec:skillDescription "Understanding of SQL mechanics..."
]

Skill Levels: High (expert knowledge), Medium (intermediate training), Low (basic/widely available)

4. Consequences → Typed Objects with Scope + Impact

OWL Class:

capec:Consequence a owl:Class ;
  rdfs:domain kgcs:AttackPattern ;
  rdfs:properties (capec:scope capec:technicalImpact capec:likelihood)

Instance Structure:

[ capec:scope "Integrity" ;
  capec:technicalImpact "Modify Data" ;
  capec:likelihood "Always"
]

Scope Values: Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation, Other

Technical Impacts: Modify Data, Read Data, Unreliable Execution, Resource Consumption, Execute Unauthorized Commands, Gain Privileges, Bypass Protection, Hide Activities, Alter Logic, Other

5. Mitigations/Indicators/Resources/Examples → Unordered Bags

capec:mitigations [ rdf:type rdf:Bag ;
  rdf:_1 "Implement prepared statements" ;
  rdf:_2 "Apply input validation whitelist" ;
  rdf:_3 "Use web application firewall"
]

Taxonomy Mapping Quality Indicators

Cross-Framework Mapping:

ETL Mapping Structure:

[ capec:externalConceptId "ATTACK-T1190" ;
  capec:externalFramework "ATT&CK Enterprise" ;
  capec:mappingQuality "Exact" ;
  capec:mappingNotes "Technique describes exploitation; CAPEC describes methodology"
]

Identifier Uniqueness Constraints

Enforcement Rules:

1. capec:capecId globally unique integer; NEVER reused (even if pattern deprecated)
2. capec:categoryId globally unique; same reuse prevention rule
3. capec:viewId globally unique; same reuse prevention rule
4. When deprecating: Keep placeholder entry with deprecated comment, do NOT reassign ID

ETL Validation:

SELECT ?id (COUNT(?pattern) as ?count) WHERE {
  ?pattern capec:capecId ?id .
} GROUP BY ?id HAVING (?count > 1)
-- Should return empty result set

Alternate Terms Handling

XML Structure:

<Alternate_Terms>
  <Alternate_Term>
    <Term>SQL Injection Attack</Term>
    <Description>Traditional reference in older literature</Description>
  </Alternate_Term>
</Alternate_Terms>

OWL Representation:

[ capec:term "SQL Injection Attack" ;
  capec:termContext "Traditional reference in older literature"
]

Content History & Provenance

Tracking: Author, submission date, modification dates with importance levels (Normal/Critical)

OWL Class:

capec:ContentHistory a owl:Class ;
  properties: (capec:submitter capec:submissionDate capec:modifications)

Modification Importance: Indicate critical vs. normal changes for trust scoring.

Relationship Exclude Logic

Edge Case Handling: Some relationships have exceptions (e.g., "ChildOf X, except when inherited from Y")

ETL Handling: Store Exclude_Related as annotation property describing conditions where relationship does NOT hold.

capec:excludedCondition [ rdf:value "Does not apply in mobile context" ]

ETL Test Priorities

1. Identifier Uniqueness - Validate capec:capecId, categoryId, viewId are globally unique with zero duplicates
2. CWE Bindings - Ensure every pattern has minimum 1 CWE reference; validate CWE existence in external ontology
3. Abstraction Hierarchy - Verify Pattern hierarchies respect Meta → Standard → Detailed ordering
4. Status Filtering - Implement ETL rules to handle Draft/Incomplete (do not load), Deprecated (audit trail), Stable/Usable (production)
5. Cross-Taxonomy Consistency - Validate mapping quality indicators align with actual concept correspondence
6. Circular References - Detect and prevent circular parent-child relationships in pattern hierarchy