Skip to main content

STIX 2.1 as the Foundation

⚠️🚧 Work in Progress
This document is a work in progress. Content may change, and some sections may be incomplete.

Why STIX was chosen and how it shapes the architecture

The decision to build the ATT&CK Data Model on STIX 2.1 as a foundation was neither obvious nor simple. This explanation explores why STIX was chosen, what alternatives were considered, and how this foundational choice shapes every aspect of the library's architecture.

The Standards Decision​

What is STIX 2.1?​

STIX (Structured Threat Information eXpression) 2.1 is an OASIS standard for representing cyber threat information in a structured, machine-readable format. It provides:

  • Standardized object types for representing threats, indicators, campaigns, and relationships
  • JSON-based format that is both human-readable and machine-parsable
  • Relationship modeling through explicit relationship objects
  • Extensibility mechanisms for custom properties and object types
  • Version management and object lifecycle handling

Why STIX for ATT&CK?​

MITRE chose STIX 2.1 as the distribution format for ATT&CK data for several strategic reasons:

Industry Standardization​

Rationale: Using an industry standard ensures long-term viability and interoperability.

Benefits:

  • ATT&CK data can be consumed by existing STIX-compliant tools
  • Organizations can integrate ATT&CK into broader threat intelligence workflows
  • No vendor lock-in - data remains in a standard, open format
  • Skills transfer between ATT&CK and other STIX-based systems

Rich Relationship Modeling​

Rationale: ATT&CK's value comes from relationships between objects (techniques, tactics, groups, etc.).

STIX provides:

  • Explicit relationship objects with typed connections
  • Bidirectional relationship navigation capabilities
  • Complex relationship patterns (many-to-many, hierarchical, etc.)
  • Metadata on relationships (confidence, timestamps, descriptions)

Extensibility Without Breaking Standards​

Rationale: ATT&CK needs custom properties while remaining standards-compliant.

STIX enables:

  • Custom properties with x_ prefix namespace
  • Custom object types with standard STIX structure
  • Extension points that don't break parsers
  • Clear separation between standard and custom elements

Architectural Implications​

The choice of STIX 2.1 as the foundation has profound implications for how the ATT&CK Data Model is architected:

Object Identity and References​

STIX ID Structure​

Every ATT&CK object has a STIX ID with the format {type}--{uuid}:

// STIX IDs are the primary identifiers
"id": "attack-pattern--0042a9f5-f053-4769-b3ef-9ad018dfa298"
"id": "x-mitre-tactic--78b23412-0651-46d7-a540-170a1ce8bd5a"
"id": "intrusion-set--18854f55-ac7c-4634-bd9a-352dd07613b7"

Architectural Impact:

  • All object lookups must handle UUID-based identifiers
  • Cross-references use STIX IDs, not human-readable names
  • Database storage and indexing must accommodate UUID primary keys

ATT&CK IDs as External References​

Human-readable ATT&CK IDs (T1055, G0006, etc.) are stored as external references, not primary identifiers:

{
    "id": "attack-pattern--0042a9f5-f053-4769-b3ef-9ad018dfa298",
    "external_references": [
        {
            "source_name": "mitre-attack",
            "external_id": "T1055",
            "url": "https://attack.mitre.org/techniques/T1055"
        }
    ]
}

Architectural Impact:

  • ATT&CK ID lookups require searching external references
  • Validation must ensure first external reference contains ATT&CK ID
  • APIs must provide both STIX ID and ATT&CK ID access patterns

Relationship Architecture​

Explicit Relationship Objects​

STIX models relationships as separate objects, not embedded references:

// ❌ Not STIX - embedded reference
{
    "type": "attack-pattern",
    "tactics": ["TA0001", "TA0002"]
}

// ✅ STIX - explicit relationship
{
    "type": "relationship",
    "relationship_type": "uses",
    "source_ref": "attack-pattern--12345...",
    "target_ref": "x-mitre-tactic--67890..."
}

Architectural Impact:

  • Relationship navigation requires separate relationship processing
  • Memory overhead for maintaining relationship indexes
  • Complex queries need to traverse multiple object types
  • Relationship metadata (descriptions, confidence) naturally supported

Bidirectional Relationship Handling​

STIX relationships are directional, but ATT&CK concepts often need bidirectional navigation:

// Forward: technique → tactics
const tactics = technique.getTactics();

// Reverse: tactic → techniques (derived from relationships)
const techniques = tactic.getTechniques();

Architectural Impact:

  • Relationship indexes must support both forward and reverse lookups
  • Implementation classes abstract bidirectional complexity
  • Memory usage includes reverse relationship mappings

Validation Architecture​

Schema Compliance Layers​

STIX compliance creates multiple validation layers:

  1. STIX Base Compliance: All objects must be valid STIX objects
  2. ATT&CK Extensions: ATT&CK-specific properties must be valid
  3. ATT&CK Business Rules: Domain-specific validation (e.g., ATT&CK ID formats)
// Validation hierarchy
const techniqueSchema = stixDomainObjectSchema    // STIX base
    .extend(attackBaseObjectSchema.shape)         // ATT&CK extensions
    .extend(attackPatternSchema.shape)            // Technique-specific
    .superRefine(attackIdRefinement)              // ATT&CK business rules
    .superRefine(tacticRefinement);               // Cross-object validation

Architectural Impact:

  • Complex validation chains with multiple failure points
  • Error messages must map from schema violations to user-understandable problems
  • Extension points must maintain STIX compliance

Custom Property Naming​

STIX requires custom properties to use namespace prefixes:

{
    "type": "attack-pattern",
    "name": "Process Injection",           // Standard STIX
    "x_mitre_platforms": ["Windows"],      // ATT&CK custom
    "x_mitre_is_subtechnique": false,      // ATT&CK custom
    "x_custom_confidence": 85              // User custom
}

Architectural Impact:

  • Naming conventions must be enforced in validation
  • TypeScript types must accommodate x_ prefixed properties
  • Schema extensions require careful namespace management

Benefits of STIX Foundation​

Interoperability Advantages​

Ecosystem Integration​

Because ATT&CK data is valid STIX, it integrates naturally with:

  • Threat Intelligence Platforms (MISP, OpenCTI, ThreatConnect)
  • Security Orchestration platforms with STIX support
  • Government systems that mandate STIX compliance
  • Analyst tools that consume STIX feeds

Toolchain Compatibility​

STIX compliance enables:

// ATT&CK data can be processed by generic STIX tools
import { STIXParser } from 'stix-parser';
import { registerDataSource } from '@mitre-attack/attack-data-model';

// Both approaches work with the same data
const genericParser = new STIXParser();
const stixObjects = genericParser.parse(attackBundle);

const attackSource = new DataSource({ source: 'file', file: 'attack.json' });
const attackModel = loadDataModel(await registerDataSource(attackSource));

Long-term Sustainability​

Standards Evolution​

STIX provides a migration path for future evolution:

  • STIX 2.2+: Upgrading STIX versions brings new capabilities
  • Backward compatibility: STIX versioning preserves older data
  • Community development: STIX improvements benefit ATT&CK automatically

Vendor Independence​

STIX ensures no single vendor controls the data format:

  • Open standard: OASIS governance prevents vendor lock-in
  • Multiple implementations: Many parsers and tools available
  • Specification stability: Changes go through formal standardization process

Costs of STIX Foundation​

Complexity Overhead​

Learning Curve​

STIX introduces concepts that may be unfamiliar:

  • UUID-based identifiers instead of human-readable names
  • Relationship objects instead of embedded references
  • External references for human-readable identifiers
  • Custom property conventions for extensions

Implementation Complexity​

STIX compliance requires more sophisticated implementation:

// Simple approach - direct property access
const tacticName = technique.tactic;  // ❌ Not how STIX works

// STIX approach - relationship traversal
const tactics = technique.getTactics(); // ✅ Follows STIX patterns
const tacticNames = tactics.map(t => t.name);

Performance Implications​

Memory Overhead​

STIX's explicit relationship modeling increases memory usage:

  • Separate relationship objects consume additional memory
  • Relationship indexes for navigation speed
  • UUID storage instead of smaller integer IDs

Processing Complexity​

STIX relationship traversal is more complex:

// Direct approach - O(1) property access
const platforms = technique.platforms;

// STIX approach - O(n) relationship lookup
const relationships = bundle.objects.filter(obj =>
    obj.type === 'relationship' &&
    obj.source_ref === technique.id &&
    obj.relationship_type === 'targets'
);

Mitigation: The library pre-processes relationships into indexes to restore O(1) lookup performance.

Alternative Approaches Considered​

Custom JSON Format​

Approach: Design a custom, ATT&CK-optimized JSON structure.

Advantages:

  • Simpler structure tailored to ATT&CK use cases
  • Better performance through optimized layout
  • No STIX complexity overhead

Disadvantages:

  • No interoperability with existing tools
  • Requires custom parsers for every integration
  • No standards body governance
  • Limited extension mechanisms

Why rejected: Isolation from broader threat intelligence ecosystem outweighed performance benefits.

GraphQL Schema​

Approach: Use GraphQL to define ATT&CK data structure and relationships.

Advantages:

  • Modern API technology with excellent tooling
  • Built-in relationship traversal
  • Type system with validation
  • Query optimization capabilities

Disadvantages:

  • Requires GraphQL server infrastructure
  • Less suitable for static data distribution
  • No existing threat intelligence ecosystem integration
  • Over-engineering for data model use case

Why rejected: Added infrastructure requirements without clear benefits over STIX.

Relational Database Schema​

Approach: Define ATT&CK as relational database tables with foreign keys.

Advantages:

  • Mature technology with extensive tooling
  • Excellent query capabilities through SQL
  • Strong consistency guarantees
  • Well-understood by most developers

Disadvantages:

  • Requires database infrastructure for simple data access
  • Poor fit for distributed, document-oriented data
  • Limited extension mechanisms
  • No standard for threat intelligence interchange

Why rejected: Infrastructure requirements too heavy for a data modeling library.

Living with STIX Decisions​

Embracing STIX Patterns​

Rather than fighting STIX complexity, the library embraces STIX patterns while abstracting complexity:

Implementation Classes Hide Complexity​

// STIX relationship traversal is complex...
const tacticRelationships = bundle.objects.filter(obj =>
    obj.type === 'relationship' &&
    obj.source_ref === technique.id &&
    obj.relationship_type === 'uses' &&
    bundle.objects.find(target =>
        target.id === obj.target_ref &&
        target.type === 'x-mitre-tactic'
    )
);

// ...but implementation classes make it simple
const tactics = technique.getTactics();

Validation Abstracts STIX Requirements​

// Users don't need to understand STIX validation rules...
const isValid = techniqueSchema.safeParse(data).success;

// ...the schema handles STIX compliance automatically

Working with STIX Strengths​

The library leverages STIX strengths while mitigating weaknesses:

Relationship Richness​

STIX's explicit relationships enable rich metadata:

// Relationship objects can carry additional context
const relationship = bundle.objects.find(obj =>
    obj.type === 'relationship' &&
    obj.relationship_type === 'uses' &&
    obj.source_ref === group.id &&
    obj.target_ref === technique.id
);

// Access procedure descriptions from relationship
const procedureDescription = relationship.description;

Extension Mechanisms​

STIX custom properties enable organization-specific additions:

// Extend techniques with custom intelligence
const extendedTechniqueSchema = techniqueSchema.extend({
    x_org_threat_level: z.enum(['low', 'medium', 'high']),
    x_org_last_observed: z.string().datetime()
});

Future Evolution​

STIX Standards Development​

The library's STIX foundation positions it for future standards evolution:

  • STIX 2.2: New relationship types and object properties
  • STIX Extensions: Formal extension mechanisms beyond custom properties
  • Performance Improvements: Standards-level optimizations for large datasets

ATT&CK Specification Evolution​

STIX provides a stable foundation as ATT&CK specifications evolve:

  • New Object Types: STIX patterns accommodate new ATT&CK concepts
  • Relationship Types: New relationship semantics fit STIX relationship model
  • Version Management: STIX versioning handles ATT&CK specification updates