Update taxonomy for data components and sources

[seansica]

Data components and data sources are being overhauled. This Issue captures those changes and iterates the x_mitre_attack_spec_version. This will be a breaking change.

[seansica]

MITRE ATT&CK Detection Strategy Schema Specification - Draft 1 (2025-05-28)

Overview

MITRE ATT&CK Detection Strategies are a new object type that will be used for detecting techniques within the ATT&CK framework. There is a one-to-one relationship between detection strategies and techniques, meaning each technique will have exactly one associated detection strategy that defines how to detect that specific technique.

Detection Strategy Structure

Each detection strategy contains a list of analytics. These analytics are delineated by detection strategies AND platforms. Given that there are three supported platforms (Mac, Linux, and Windows), this means that detection strategies will typically contain 1 to 3 analytics - one for each supported platform where the technique can be detected.

Analytics and Their Core Properties

Each analytic has two "core" properties that define its detection capabilities: x_mitre_log_sources and x_mitre_mutable_elements.

Log Sources

The x_mitre_log_sources field contains references to Log Source objects and is immutable in the sense that the list of log sources will never change for a given analytic. These references are delineated by a STIX ID reference to a valid x-mitre-log-source object, as well as a key into the specific permutation of log source that is relevant for this analytic.

Log Sources map to specific techniques and data components. While they are immutable objects, they come in different "shapes and forms" depending on the platform and other factors. Thus, we treat the Log Source object as a sort of dictionary that the Analytic indexes into to fetch the relevant name and channel information.

For example, there is one Log Source object for the 'Process Creation' technique, but within this scope, there can be different permutations of the log source, each delineated by a name and channel key. The Log Source reference from an analytic will include a reference to the Log Source object itself, as well as the specific permutation keys that are relevant for that given analytic.

This design allows for a single Log Source object to support multiple platforms while enabling analytics to reference only the specific permutations that apply to their detection logic.

Mutable Elements

The x_mitre_mutable_elements field contains an array of elements that can be tuned or customized based on the specific environment or deployment context. Each mutable element defines a field that can be adjusted and provides a description of why this field is tunable or environment-specific.

These elements allow detection engineers to adapt the analytics to their specific environments, accounting for variations in legitimate software behavior, organizational policies, or other environmental factors that might affect detection accuracy.

STIX Object Model

Both Detection Strategy and Log Source objects are tracked as STIX objects, which means they are fully version controlled and include a unique id field along with other standard STIX metadata fields such as created, modified, type, spec_version, x_mitre_version, and x_mitre_attack_spec_version. This ensures proper versioning and tracking of changes over time.

Analytics, Log Source References, Log Source Permutations, and Mutable Elements are embedded objects within their parent STIX objects and do not have independent STIX lifecycle management.

Relationship Model

The overall relationship model creates a hierarchical structure where:

• Each Detection Strategy corresponds to exactly one ATT&CK technique
• Each Detection Strategy contains multiple Analytics (typically one per supported platform)
• Each Analytic references multiple Log Sources through Log Source Reference objects
• Each Log Source Reference points to a specific Log Source object and identifies which permutations within that object are relevant
• Each Analytic can contain multiple Mutable Elements that define customizable detection parameters

Mermaid Diagram

classDiagram
    class STIXObject {
        <<abstract>>
        +string id
        +string type
        +string spec_version
        +string created
        +string modified
        +string x_mitre_version
        +string x_mitre_attack_spec_version
        ... other props ...
    }

    class DetectionStrategy {
        <<STIX Object>>
        +string name
        +string created_by_ref
        +string x_mitre_technique_of
        +string x_mitre_modified_by_ref
        +string x_mitre_contributors
        +Analytic[] x_mitre_analytics
        +MitreDomain[] x_mitre_domains
        +ExternalReference[] external_references
    }
    
    class object_marking_refs {
        // TODO figure out where to put this
    }

    class ExternalReference{
        +string source_name
        +string description
        +string url
        +string external_id
    }

    class MitreDomain{
        <<enumeration>>
        enterprise-attack
        ics-attack
        mobile-attack
    }

    class Analytic {
        +Platform platform
        +string x_mitre_detects
        +LogSourceReference[] x_mitre_log_sources
        +MutableElement[] x_mitre_mutable_elements
    }
    
    class MutableElement {
        +string field
        +string description
    }
    
    class LogSourceReference {
        +string ref
        +string[] keys
    }
    
    class MitreLogSource {
        <<STIX Object>>
        +string name
        +string x_mitre_data_component_ref
        +LogSourcePermutation[] x_mitre_log_source_permutations
    }
    
    class LogSourcePermutation {
        +string name
        +string channel
    }
    
    class Platform {
        <<enumeration>>
        WINDOWS
        LINUX
        MACOS
    }

    STIXObject <|-- DetectionStrategy : is a
    STIXObject <|-- MitreLogSource : is a
    
    DetectionStrategy "1" --> "1..*" Analytic : contains
    Analytic "1" --> "0..*" LogSourceReference : references
    Analytic "1" --> "0..*" MutableElement : contains
    LogSourceReference "1" --> "1" MitreLogSource : ref points to
    LogSourceReference "1" --> "1..*" LogSourcePermutation : keys index into
    MitreLogSource "1" --> "1..*" LogSourcePermutation : contains
    Analytic --> Platform

Loading

[seansica]

MITRE ATT&CK Detection Strategy Schema Specification - Draft 2 (2025-06-03)

Overview

MITRE ATT&CK Detection Strategies are a new STIX Domain Object (SDO) within the ATT&CK framework for defining detection approaches for specific techniques. Each Detection Strategy maintains a one-to-one relationship with an ATT&CK technique through STIX Relationship Objects (SROs).

Core Objects and Relationships

Detection Strategy (STIX Object)

Detection Strategy objects serve as the top-level container for detection logic associated with a specific ATT&CK technique. Rather than embedding analytics directly within the Detection Strategy object, these objects maintain references to separate Analytic objects to avoid object bloat and eliminate nested list structures.

Key Properties:

• x_mitre_analytics: Array of STIX ID references to Analytic objects (soft relationships)
• x_mitre_domains: Applicable ATT&CK domains (enterprise, mobile, ICS)

Relationships:
Detection Strategies are linked to ATT&CK Techniques through STIX Relationship objects with relationship_type: 'detects', where the Detection Strategy serves as the source and the Technique as the target.

Analytic (STIX Object)

Analytic objects have been promoted to full STIX objects to provide better modularity and avoid the complexity of nested data structures. Each Analytic represents platform-specific detection logic and maintains its own independent lifecycle management.

Key Properties:

• platform: Target platform (Windows, Linux, macOS)
• x_mitre_detects: Description of what the analytic detects
• x_mitre_log_sources: Array of STIX ID references to Log Source objects (soft relationships)
• x_mitre_mutable_elements: Array of tunable detection parameters

Cardinality: Detection Strategies will typically reference 1-3 Analytics (one for each supported platform where the technique can be detected).

MITRE Log Source (STIX Object)

Log Source objects define immutable log source configurations that can be referenced across multiple analytics. These objects come in different "shapes and forms" depending on the platform and other factors, with each Log Source containing multiple permutations for different deployment scenarios.

Key Properties:

• name: Human-readable log source name
• x_mitre_log_source_permutations: Platform-specific configurations

Relationships:
Log Sources are linked to Data Components through STIX Relationship objects with relationship_type: 'found-in', where the Data Component serves as the source and the Log Source as the target.

Log Source Permutation

Log Source Permutations remain as embedded objects within Log Source objects and define platform-specific configurations.

Properties:

• name: Log source identifier (e.g., "sysmon", "auditd")
• channel: Specific log channel or event type

For example, a single Log Source object for 'Process Creation' might contain permutations for Windows (sysmon, channel: 1), Linux (AuditD, channel: SysCall==PTrace), and macOS (UnifiedLogs, channel: Process).

Mutable Element

Mutable Elements remain as embedded objects within Analytic objects and define tunable detection parameters for environment adaptation.

Properties:

• field: Detection field name
• description: Rationale for tunability and environment-specific considerations

Relationship Architecture

The schema employs a combination of soft relationships (STIX ID references) and formal STIX Relationship objects:

Soft Relationships (STIX ID References):

• Detection Strategy → Analytics (via x_mitre_analytics)
• Analytics → Log Sources (via x_mitre_log_sources)

Formal STIX Relationships:

• Detection Strategy → Technique (relationship_type: 'detects')
• Data Component → Log Source (relationship_type: 'found-in')

This hybrid approach provides flexibility for frequently accessed references while maintaining formal relationship tracking for cross-domain relationships.

STIX Object Model

Detection Strategy, Analytic, and Log Source objects are all tracked as full STIX objects with complete version control and lifecycle management. Each includes standard STIX metadata fields such as id, type, spec_version, created, modified, x_mitre_version, and x_mitre_attack_spec_version.

Mutable Elements and Log Source Permutations remain as embedded objects within their parent STIX objects and do not have independent STIX lifecycle management.

Schema Simplifications

This updated schema eliminates several previous properties and relationships:

• Removed x_mitre_technique_of from Detection Strategy objects (replaced by STIX Relationships)
• Removed x_mitre_data_component_ref from Log Source objects (replaced by STIX Relationships)
• Eliminated direct Technique-to-Data Component relationships (replaced by Detection Strategy-to-Technique and Data Component-to-Log Source relationships)

These changes create a cleaner separation of concerns and provide better modularity for managing detection logic across the ATT&CK framework.

Class Diagram

classDiagram
    class DetectionStrategy {
        <<SDO>>
        +string id
        +string type
        +string spec_version
        +string created
        +string modified
        +string name
        +string created_by_ref
        +string x_mitre_version
        +string x_mitre_attack_spec_version
        +string x_mitre_modified_by_ref
        +string x_mitre_contributors
        +string[] object_marking_refs
        +Analytic[] x_mitre_analytics
        +MitreDomain[] x_mitre_domains
        +ExternalReference[] external_references
    }

    class ExternalReference{
        +string source_name
        +string description
        +string url
        +string external_id
    }

    class MitreDomain{
        <<enumeration>>
        enterprise-attack
        ics-attack
        mobile-attack
    }

    class Analytic {
        <<SDO>>
        +string id
        +string type
        +string spec_version
        +string created
        +string modified
        +string x_mitre_version
        +string x_mitre_attack_spec_version
        +Platform platform
        +string x_mitre_detects
        +LogSourceRef[] x_mitre_log_sources
        +MutableElement[] x_mitre_mutable_elements
    }

    class LogSourceRef {
        +string ref
        +string[] keys
    }

    class MutableElement {
        +string field
        +string description
    }
    
    class LogSource {
        <<SDO>>
        +string id
        +string type
        +string spec_version
        +string created
        +string modified
        +string x_mitre_version
        +string x_mitre_attack_spec_version
        +string name
        +LogSourcePermutation[] x_mitre_log_source_permutations
    }

    class LogSourcePermutation {
        +string name
        +string channel
    }
    
    class Platform {
        <<enumeration>>
        WINDOWS
        LINUX
        MACOS
    }

    DetectionStrategy --> Analytic : x_mitre_analytics
    DetectionStrategy --> MitreDomain
    DetectionStrategy --> ExternalReference
    Analytic --> Platform
    Analytic --> MutableElement
    Analytic --> LogSourceRef
    LogSourceRef --> LogSource : ref
    LogSourceRef --> LogSourcePermutation : keys
    LogSource --> LogSourcePermutation

Loading

Relationship Diagram