MITRE CAR
CAR (Cyber Analytics Repository) is MITRE's knowledge base of detection analytics built against the Mitre Attack adversary model. Where ATT&CK catalogues what an adversary does, CAR catalogues concrete, validated ways to detect it โ each analytic expressed as a hypothesis with the data, sensor, and logic needed to test it.
Overview
- Maintainer: MITRE Corporation
- First released: 2013 (car.mitre.org; migrated from MediaWiki to GitHub ~2019)
- URL: https://car.mitre.org ยท https://github.com/mitre-attack/car
- Licence: Apache 2.0
- Form: Structured YAML analytics + pseudocode + per-tool implementations (Splunk, EQL, Sigma, Logpoint, Dnif)
What an Analytic Contains
Each CAR analytic (e.g. CAR-2013-05-004 Execution with AT) is a self-contained detection package:
| Component | Purpose |
|---|---|
| Hypothesis | The detection theory โ what behaviour should be observable |
| Information domain | Host, network, process, or external |
| ATT&CK references | The techniques and tactics the analytic detects |
| Glossary / data model | Names the events and fields used (partnered with OSSEM's Common Data Model) |
| Pseudocode | Implementation-agnostic description of the analytic logic |
| Unit test | A trigger you can run to validate the analytic fires |
| Implementations | Real queries for specific tools (Splunk, EQL, Sigma, โฆ) |
Methodology
CAR analytics are developed in four steps:
- Identify and prioritise adversary behaviours from ATT&CK
- Identify the data necessary to detect the behaviour
- Identify or create a sensor to collect that data
- Build the analytic to detect the behaviour
CAR was intended as shared community content: contributions must address an ATT&CK technique, should have been used operationally, must detect behaviours (not malware artifacts/IOCs), and โ for sensor mappings โ only built-in OS utilities or open-source tools are accepted (no commercial product vendor mappings).
Relationship to ATT&CK
- ATT&CK is the adversary-side language; CAR is the detector-side layer against it
- Mitre Attack and CAR are deliberately separate projects: keeping threat articulation separate from possible detections avoids ATT&CK's defensive content being overly prescriptive โ there are many valid ways to detect a technique, and organisations must choose what fits their environment
- CAR is a starting point and platform for open analytic collaboration, explicitly not the be-all/end-all for defending against ATT&CK techniques
- The BZAR library (Bro/Zeek ATT&CK-Based Analytics and Reporting) ships as CAR source code for the Zeek network sensor
Relationship to D3FEND
CAR and D3Fend are sibling defensive projects โ both hang off ATT&CK as the common language, answering different questions:
| CAR | D3FEND | |
|---|---|---|
| Layer | Detection | Defence / countermeasures |
| Format | Analytics (pseudocode + queries + tests) | Machine-readable knowledge graph |
| Question answered | "How do I write the detection?" | "What do I harden, isolate, deceive, or evict with?" |
CAR was never formally mapped into D3FEND; they are complementary rather than linked. In practice: D3FEND selects the countermeasure, CAR-style analytics (and ATT&CK's native detections) implement the visibility.
Status: Superseded in Role
CAR is largely historical โ MITRE moved detection engineering into ATT&CK itself:
- ATT&CK v15 (Apr 2024): the Detections sections swapped CAR-style pseudocode for real-world query languages (e.g. Splunk SPL)
- ATT&CK v16: added ~231 native analytics (85 Execution, 120 Credential Access, 26 Cloud) plus a STIX analytic-extraction script
- The standalone CAR repository has not been meaningfully updated in years
Its lasting value is methodological โ analytics as testable hypotheses (data model โ sensor โ pseudocode โ unit test) โ which remains the backbone of modern detection engineering. Sigma rules still carry car.* tags linking back to the repository.
Australian Angle
CAR's hypothesis-driven analytic structure is a standard reference in detection-engineering work delivered to Australian government and critical-infrastructure clients (including the CyberCX Assessments practice), and remains useful training material for structuring SIEM detections. For production coverage, ATT&CK's native detections and Sigma rules โ mapped against the ACSC Essential Eight / ISM mitigations for control validation โ have superseded it.
Related Pages
- Mitre Attack โ the adversary-side knowledge base CAR detects against
- D3Fend โ MITRE's defensive-countermeasure counterpart; CAR's sibling project
- Cyber Kill Chain โ the higher-level intrusion lifecycle model ATT&CK (and therefore CAR) refines
- Security Control Frameworks โ the operational control catalogues that translate detections into policy