CAR to OWL Mapping v1.0

Overview

CAR (Cyber Analytics Repository) is the MITRE-maintained knowledge base of detection analytics, data models, and sensor capabilities for identifying adversary behavior aligned with ATT&CK techniques. This mapping implements CAR as a three-entity schema linking detection analytics to ATT&CK offensive techniques and data model observables to sensor capabilities. CAR bridges the gap between attack tactics (ATT&CK) and defensive detection mechanisms (D3FEND), enabling organizations to map which analytics detect which techniques and how those analytics correlate to defensive countermeasures.

Sources

• MITRE CAR Program: http://car.mitre.org/
• Raw Data Location: data/raw/car/analytics/, data/raw/car/data_model/, data/raw/car/sensors/
• Format: YAML
• Scale: 100+ analytics, 10 data model entities, 7 sensor definitions
• Namespace: http://www.motherhacker.me/kgcs/ontology/car#
• External Framework Integrations: ATT&CK (techniques, tactics), D3FEND (defensive techniques), Data Models (cyber observables)
• Architecture: Three-entity federation pattern (Analytic → ATT&CK technique; Sensor → DataModel)

Entity Distribution

Target Ontology

• File: standards/car/car-ontology-v1.0.owl
• Core Classes Used:
  • kgcs:DetectionAnalytic (base for CAR analytics)
  • kgcs:CyberObservable (base for data models)
  • kgcs:DataSource (base for sensors)
• New CAR Namespace: car: <http://www.motherhacker.me/kgcs/ontology/car#>
• Core Import: Explicit owl:imports <http://www.motherhacker.me/kgcs/ontology/core#>
• Design Pattern: Federation with bidirectional relationships to ATT&CK and D3FEND

Entity Mapping

Primary Entity Types

Supporting Entity Types

Field Mapping: Analytic Entity

Core Required Fields

Optional Array Fields

Complex Object Fields

Coverage Array Structure

Field Mapping: DataModel Entity

Core Fields

Complex Fields

DataModelAction Properties

DataModelField Properties

Field Mapping: Sensor Entity

Core Fields

Complex Field

SensorMapping Properties

Relationship Mapping

Critical: Analytic-to-ATT&CK Relationships

Validation Rule: Every DetectionAnalytic MUST have at least one car:coverage_technique pointing to a valid attack:Technique. This is the core semantic assertion that links defensive analytics to offensive techniques.

Cross-Standard: Analytic-to-D3FEND Relationships

Sensor-to-DataModel Relationships

Analytic-to-Sensor Relationships

Analytic-to-DataModel Relationships

Transformation Notes

ATT&CK Coverage Integration Strategy (CRITICAL)

Semantic Binding:

CAR Analytic X --[car:coverage_technique]--> ATT&CK Technique Y
means: "This analytic can detect/identify organizations where ATT&CK Technique Y has been executed or is present"

ETL Implementation:

1. Parse coverage array in analytic YAML
2. For each coverage object:
   • Extract technique field (e.g., "T1039")
   • Extract tactics array (e.g., ["TA0009"])
   • Extract optional subtechniques array (e.g., ["T1021.002"])
   • Extract optional coverage level (Low, Moderate, High)
3. Create ObjectProperty assertions:
   • car:coverage_technique linking to attack:Technique
   • Derived car:coverage_tactic linking to attack:Tactic
4. Create CoverageBucket object capturing full coverage metadata

Bidirectional Index Support:

Enable queries such as:

SELECT ?analytic ?coverage_level WHERE {
  ?analytic car:coverage_technique attack:T1059 ;
            car:coverage ?coverage_bucket .
  ?coverage_bucket car:coverageLevel ?coverage_level .
}

Coverage Level Semantics:

• Low - Minimal or occasional detection capability
• Moderate - Reasonable detection coverage, may have false positives or gaps
• High - Comprehensive detection capability with high confidence

D3FEND Alignment (Optional but Recommended)

Semantic Binding:

CAR Analytic X --[car:has_d3fend_mapping]--> D3FEND DefensiveTechnique Y
means: "This analytic detects or supports the implementation of this defensive technique"

ETL Implementation:

1. Parse optional d3fend_mappings array in analytic YAML
2. For each D3FEND mapping:
   • Extract iri, id, label fields
   • Create reference to corresponding d3fend defensive technique
3. Create ObjectProperty assertion linking to d3fend namespace

Example:

car:CAR_2013_01_003 car:has_d3fend_mapping d3fend:IPCTrafficAnalysis .

This enables questions like: "What analytics support the IPC Traffic Analysis defensive technique?" and "What defenses does this analytic support?"

Data Model Federation

Semantic Binding:

CAR Sensor X --[car:sensor_provides]--> DataModel Y
CAR Analytic Z --[car:analyzes_observable]--> DataModel Y
means: "Sensor X collects Y-observable data that Analytic Z analyzes"

ETL Implementation:

1. Extract data model entity definitions (10 types: Process, File, Flow, etc.)
2. For each sensor, parse mappings array:
   • Link sensor to DataModel entities via object field
   • Link to DataModelActions via action field
   • Link to DataModelFields via fields array
3. For each analytic, parse data_model_references:
   • Link to hierarchical data model fields (e.g., "flow/message/dest_port")

Cardinality and Validation Rules

Critical Constraints:

Recommended Constraints:

Sensor Abstraction Levels

Sensors vary in abstraction and vendor:

ETL Handling: Preserve sensor-specific event identifiers (e.g., Sysmon Event ID 11 for file creation) in mapping notes.

Status and Lifecycle

Analytic Status:

All CAR analytics are considered stable and production-ready. If future CAR versions introduce status variations (Draft, Deprecated, etc.):

car:status a owl:DatatypeProperty ;
    rdfs:range xsd:string ;
    rdfs:comment "Status: stable (default), beta, deprecated, obsolete" .

Version Tracking and Pinning

KGCS CAR Mapping Alignment:

KGCS car-ontology-v1.0.owl <-- aligned with --> CAR v1.0 (Latest)

If CAR versions change:

• Option 1: Create new car-ontology-v2.0.owl alongside v1.0
• Option 2: Add version-aware properties: car:compatibleWithCARVersion xsd:string

ETL Implementation

Data Ingestion Pipeline

Stage 1: Load CAR Raw Files

Input: data/raw/car/analytics/*.yaml
       data/raw/car/data_model/*.yaml
       data/raw/car/sensors/*.yaml
Parse: YAML parser (PyYAML, SnakeYAML, etc.)
Extract: All analytic, data model, and sensor definitions
Filter: Exclude incomplete/draft entries

Stage 2: Validate Against Schema

Validation:
  ✓ Every analytic has CAR-YYYY-MM-NNN format ID
  ✓ Coverage array has minimum 1 entry
  ✓ Technique IDs match T[0-9]{4} pattern
  ✓ Tactic IDs match TA[0-9]{4} pattern
  ✓ Information domain is in allowed enum
  ✓ Required fields present (title, submission_date, description)

Stage 3: Link to ATT&CK Framework

For each coverage entry:
  Extract technique ID (e.g., "T1039")
  Resolve to attack:Technique URI: http://www.motherhacker.me/kgcs/ontology/attack#T1039
  Create car:coverage_technique relationship
  Create derived car:coverage_tactic from technique's attack:belongs_to

Stage 4: Link to D3FEND Framework (Optional)

For each d3fend_mapping entry:
  Extract iri, id, label
  Resolve to d3fend defensive technique IRI
  Create car:has_d3fend_mapping relationship

Stage 5: Index and Store

Create RDF triples for all entities and relationships
Store in KGCS knowledge graph
Build indices for fast queries:
  - Analytic by ID (CAR-YYYY-MM-NNN)
  - Techniques by analytic
  - Sensors by data model type
  - Analytics by platform support

Query Examples

Query 1: Find all analytics detecting a specific technique

PREFIX car: <http://www.motherhacker.me/kgcs/ontology/car#>
PREFIX attack: <http://www.motherhacker.me/kgcs/ontology/attack#>

SELECT ?analytic ?title ?coverage_level WHERE {
  ?analytic car:coverage_technique attack:T1059 ;
            rdfs:label ?title ;
            car:coverage ?coverage_bucket .
  ?coverage_bucket car:coverageLevel ?coverage_level .
}
ORDER BY DESC(?coverage_level)

Query 2: Find analytics with D3FEND defensive coverage

SELECT ?analytic ?title ?d3fend_defense WHERE {
  ?analytic car:has_d3fend_mapping ?d3fend_defense ;
            rdfs:label ?title ;
            car:coverage_technique ?technique .
  ?technique attack:belongs_to attack:Reconnaissance .
}

Query 3: Find which sensors support a specific data model

SELECT ?sensor ?sensor_version ?actions WHERE {
  ?sensor car:sensor_provides car:Process ;
          car:sensorName ?sensorname ;
          car:sensorVersion ?sensor_version ;
          car:hasMapping ?mapping .
  ?mapping car:action ?actions .
}

Query 4: Find data model references used by a specific analytic

SELECT ?analytic ?datamodel ?fields WHERE {
  ?analytic car:analyticId "CAR-2013-01-003" ;
            car:references_datamodel ?datamodel .
  ?datamodel car:hasField ?fields .
}

Summary

CAR integration into KGCS leverages a three-entity federation model: Detection Analytics link to ATT&CK offensive techniques, Sensors map to cyber observable DataModels, and optional D3FEND mappings enable unification of offensive-defensive-detection alignment. The 100+ CAR analytics, 10 data models, and 7 sensor definitions are ingested via deterministic schema validation, enabling organizations to query "What analytics detect technique X?" and "What defenses support detection of Y?" across the full defensive-offensive spectrum.