SHIELD Active Defense Framework to OWL Mapping v1.0

Overview

The MITRE SHIELD framework is an active defense knowledge base that complements the offensive ATT&CK framework by defining defensive tactics, techniques, opportunities, use cases, and procedures for protecting against adversary operations. SHIELD provides a comprehensive model for defensive engagement strategies, enabling organizations to organize and execute defensive operations against attackers.

Within KGCS, SHIELD serves as the primary defensive counterpart to offensive ATT&CK, enabling defensive-offensive alignment through explicit relationships between defensive entities and attack techniques. The hierarchical structure of SHIELD (Tactic → Technique → Opportunity → UseCase + Procedure) mirrors industry best practices for organizing defensive activities from strategic to tactical levels.

SHIELD's positioning in KGCS enables cross-framework analysis: threat modeling can trace from offensive ATT&CK techniques through SHIELD defensive operators to D3FEND mitigations and CAR detection analytics, providing comprehensive coverage analysis.

Sources

MITRE SHIELD Framework Reference:

• Primary Source: MITRE SHIELD active defense framework
• Raw Data Location: data/raw/shield/ (JSON files)
• Entity Types: 6 (tactics, techniques, opportunities, use_cases, procedures, mappings)
• Scale: 8 core defensive tactics, 36+ defensive techniques, 100+ strategic opportunities, 260+ practical use cases, 66 executable procedures

Raw Data Files:

• tactics.json - 8 fixed SHIELD defensive tactics (DTA0001-DTA0008)
• techniques.json - 36+ defensive techniques (DTE0001+)
• opportunities.json - 100+ strategic opportunities (DOS0001+)
• use_cases.json - 260+ practical implementation scenarios (DUC0001+)
• procedures.json - 66 technical procedures (DPR0001+)
• mapping.json - ATT&CK cross-references with relationship types

Namespace:

• SHIELD Ontology Namespace: http://www.motherhacker.me/kgcs/ontology/shield#
• Prefix: shield:

Target Ontology

File: standards/shield/shield-ontology-v1.0.owl (to be implemented in Task 11)

Core Classes Used (from KGCS core ontology):

• kgcs:DefensiveTechnique - Base class for SHIELD tactics and techniques representing defensive approaches
• kgcs:EngagementConcept - Base class for SHIELD opportunities, use cases, and procedures representing engagement scenarios

New Classes to Define (in shield ontology):

• shield:DefensiveTactic - Strategic defensive tactic (8 total: Channel, Collect, Contain, Detect, Disrupt, Facilitate, Legitimize, Test)
• shield:DefensiveTechnique - Tactical defensive technique implementation (36+ instances)
• shield:Opportunity - Strategic opportunity for defensive application (100+ instances)
• shield:UseCase - Practical use case demonstrating defensive implementation (260+ instances)
• shield:Procedure - Concrete technical procedure or implementation step (66 instances)
• shield:AttackMapping - Cross-reference entity linking SHIELD to ATT&CK framework

Design Pattern: Hierarchical tactic-technique-opportunity-usecase federation with explicit ATT&CK defensive-offensive alignment enabling bidirectional coverage analysis.

Entity Mapping

Field Mapping

Tactic Entity (shield:DefensiveTactic)

Cardinality Rationale: Every tactic must contain at least one technique to be meaningful in defensive operations.

Technique Entity (shield:DefensiveTechnique)

Cardinality Rationale: Techniques may optionally enable multiple opportunities, supporting many-to-many flexibility.

Opportunity Entity (shield:Opportunity)

Cardinality Rationale: CRITICAL SEMANTIC RULE: Every opportunity must have at least one corresponding use case to ensure every strategic defensive opportunity has concrete implementation scenarios.

Use Case Entity (shield:UseCase)

Cardinality Rationale: Use cases may optionally reference technical procedures, but procedures are often implicit or applied incrementally.

Procedure Entity (shield:Procedure)

Cardinality Rationale: Procedures are concrete technical implementation details with no required relationships; many use cases can reference the same procedure, and procedures can exist independently.

ATT&CK Mapping Entity (shield:AttackMapping)

Cardinality Rationale: Mappings are flexible on optional metadata but require core relationship definition for defensive-offensive alignment.

Relationship Mapping

Critical: Tactic-to-Technique Containment

Inverse Property: shield:belongs_to_tactic (Technique → Tactic)

Critical: Technique-to-Opportunity Enablement

Inverse Property: shield:supported_by_technique (Opportunity → Technique)

Critical: Opportunity-to-UseCase Realization

Inverse Property: shield:realizes_opportunity (UseCase → Opportunity)

CRITICAL VALIDATION RULE: This cardinality constraint is essential for semantic integrity. Every strategic opportunity without implementation scenarios creates empty defensive postures in the knowledge graph.

Critical: UseCase-to-Procedure Implementation

Inverse Property: shield:used_by_usecase (Procedure → UseCase)

ATT&CK Defensive-Offensive Alignment

5 Relationship Types for ATT&CK Mapping:

Property Definitions:

• shield:mapToAttack - Maps SHIELD entity to ATT&CK framework
• shield:relationshipType - Type of defensive-offensive relationship
• shield:attackTechniqueId - Target ATT&CK technique
• shield:attackTacticId - Optional associated ATT&CK tactic context
• shield:defensiveCoverage - Coverage effectiveness level

Transformation Notes

Tactic Enumeration (Fixed 8 Core Tactics)

SHIELD defines exactly 8 defensive tactics implementing diverse strategic defensive approaches:

Hierarchical Relationship Model

SHIELD's defensive hierarchy organizes from strategic to tactical:

Tactic (Strategic Level)
  │
  ├─ DTA0001-0008 (8 core tactics)
  │
  ├─ Technique (Implementation Method)
  │   │
  │   ├─ DTE0001-DTE0036+ (36+ defensive techniques)
  │   │
  │   ├─ enables
  │   │
  │   └─ Opportunity (Specific Context/Scenario)
  │       │
  │       ├─ DOS0001-DOS0253+ (100+ opportunities)
  │       │
  │       ├─ has (MINIMUM 1 REQUIRED)
  │       │
  │       └─ UseCase (Practical Application)
  │           │
  │           ├─ DUC0001-DUC0261+ (260+ use cases)
  │           │
  │           ├─ implements (Optional)
  │           │
  │           └─ Procedure (Concrete Technical Steps)
  │               │
  │               └─ DPR0001-DPR0066+ (66 procedures)
  │
  └─ ATT&CK Cross-Mapping
      │
      ├─ Links to offensive techniques via 5 relationship types
      │
      └─ Enables defensive-offensive alignment analysis

Cardinality Rules (CRITICAL)

• Tactic→Technique: Minimum 1 (each tactic must organize ≥1 technique)
• Opportunity→UseCase: Minimum 1 REQUIRED (CRITICAL semantic integrity rule - every opportunity must have ≥1 concrete use cases)
• UseCase→Procedure: Optional (0 or more; procedures are implementation details)
• All→ATT&CK: Optional (0 or more) but recommended for coverage analysis

CRITICAL CONSTRAINT ENFORCEMENT: Opportunities without use cases represent incomplete defensive postures and should be rejected by validation rules.

Identifier Uniqueness & Extensibility Rules

• Tactic IDs (DTAxxxx): Global unique, fixed 8 values (DTA0001-DTA0008 only)
• Technique IDs (DTExxxx): Global unique, extensible (DTE0001+), allow gaps for deprecation
• Opportunity IDs (DOSxxxx): Global unique, extensible (DOS0001+), sparse numbering permitted
• Use Case IDs (DUCxxxx): Global unique, extensible (DUC0001+), sparse numbering permitted
• Procedure IDs (DPRxxxx): Global unique, extensible (DPR0001+), versioning allowed
• ATT&CK References: External identifiers (T####, T####.###, TA####) mapped bidirectionally

Enforcement: Never reuse IDs once deprecated; leave placeholders in number sequences for future expansion.

ATT&CK Mapping Relationship Semantics (5 Types)

1. detects - Detection-based relationships where SHIELD identifies, observes, or logs adversary technique execution

   • Example: Network Monitoring technique detects T1040 (Network Sniffing)
   • Enables: "What SHIELD techniques detect this technique?"

2. mitigates - Defensive techniques reducing attack effectiveness, impact, or success likelihood

   • Example: Endpoint Protection technique mitigates T1110 (Brute Force)
   • Enables: "What SHIELD techniques mitigate this technique?"

3. enables - Controlled execution of adversary techniques in defensive environments (red team, sandboxes, honeypots)

   • Example: Decoy System enables controlled T1592 (Gather Victim Identity Information) in isolated environment
   • Enables: "What SHIELD systems allow testing this technique?"

4. tests - Defender capability testing against specific techniques via purple team exercises

   • Example: Test Procedure tests T1595 (Active Scanning) to probe defender visibility
   • Enables: "What SHIELD procedures test this technique?"

5. engages_with - Active engagement and deception operations targeting specific techniques

   • Example: Deception Campaign actively engages_with T1598 (Phishing for Information) via fake targets
   • Enables: "What SHIELD tactics actively engage with this technique?"

Defensive-Offensive Bidirectionality

Mappings enable powerful bidirectional queries supporting threat modeling workflows:

Defensive View: "What SHIELD operators defend against technique T1234?"

• Follow inverse of shield:attackTechniqueId relationships
• Supports defensive-offensive alignment analysis

Offensive View: "What does ATT&CK technique T1234 trigger in SHIELD?"

• Follow shield:attackTechniqueId relationships
• Supports threat impact assessment

ETL Implementation

Stage 1: Load SHIELD JSON Files

Input: Raw SHIELD data files from data/raw/shield/

├── tactics.json           (8 tactics, fixed)
├── techniques.json        (36+ techniques)
├── opportunities.json     (100+ opportunities)
├── use_cases.json         (260+ use cases)
├── procedures.json        (66 procedures)
└── mapping.json           (ATT&CK cross-references)

Processing:

1. Parse JSON files with JSON parser
2. Extract entity definitions maintaining all relationships
3. Validate schema compliance (pattern matching, enum values)
4. Load into in-memory entity store with relationship graph

Output: Validated entity store ready for RDF triple generation

Stage 2: Validation Against Schema

Critical Validation Checks:

✓ All entity IDs match format (DTA/DTE/DOS/DUC/DPR[0-9]{4})
✓ All enum fields valid:
  - Tactic names from fixed 8 values
  - Relationship types from {detects, mitigates, enables, tests, engages_with}
  - Coverage levels from {Low, Moderate, High}
✓ All required fields present:
  - Tactics: id, name, description, long_description, technique_ids (minItems: 1)
  - Techniques: id, name, description, long_description
  - Opportunities: id, description, use_case_ids (minItems: 1, CRITICAL)
  - UseCases: id, description
  - Procedures: id, description
✓ Tactic IDs exactly 8 entries (DTA0001-DTA0008)
✓ Opportunities have ≥1 use case IDs (CRITICAL validation rule)
✓ Tactics have ≥1 technique IDs
✓ All referenced IDs exist in respective entity sets:
  - technique_ids point to existing DTE#### techniques
  - opportunity_ids point to existing DOS#### opportunities
  - use_case_ids point to existing DUC#### use cases
  - procedure_ids point to existing DPR#### procedures
✓ All ATT&CK technique IDs match T[0-9]{4} or T[0-9]{4}\.[0-9]{3} pattern
✓ All ATT&CK tactic IDs match TA[0-9]{4} pattern
✓ No missing cross-references (all back-references resolvable)

Confidence: This validation ensures data integrity before RDF triple creation.

Stage 3: Link to ATT&CK Framework

Processing:

For each mapping entity in mapping.json:
  1. Extract shieldId (e.g., DTE0001)
  2. Extract attackId (e.g., T1007)
  3. Resolve to attack:Technique URI:
     http://www.motherhacker.me/kgcs/ontology/attack#T1007
  4. Create shield:mapToAttack relationship
  5. Associate relationshipType from {detects, mitigates, enables, tests, engages_with}
  6. Validate relationshipType is valid enum value
  7. Link attackTactic for additional context (optional)

Output: Bidirectional mappings linking SHIELD defensive entities to ATT&CK offensive framework

Stage 4: Build RDF Graph

RDF Triple Generation:

For Tactics:
  <shield:DTA0001> rdf:type shield:DefensiveTactic ;
    rdfs:label "Channel" ;
    rdfs:comment "Guide adversary down specific path..." ;
    shield:contains_technique <shield:DTE0001>, <shield:DTE0010>, ... ;
    shield:tacticId "DTA0001" .

For Techniques:
  <shield:DTE0001> rdf:type shield:DefensiveTechnique ;
    rdfs:label "Decoy Account" ;
    shield:enables_opportunity <shield:DOS0027>, <shield:DOS0040>, ... ;
    shield:belongs_to_tactic <shield:DTA0001> .

For Opportunities (CRITICAL - enforce uses_case references):
  <shield:DOS0027> rdf:type shield:Opportunity ;
    rdfs:comment "Create detection with moderately high probability" ;
    shield:has_usecase <shield:DUC0040>, <shield:DUC0041>, <shield:DUC0123> ;
    shield:supported_by_technique <shield:DTE0001> .

For UseCases:
  <shield:DUC0040> rdf:type shield:UseCase ;
    rdfs:comment "Defender can use decoy system to access..." ;
    shield:realizes_opportunity <shield:DOS0027> ;
    shield:implements_procedure <shield:DPR0001>, <shield:DPR0005> .

For Procedures:
  <shield:DPR0001> rdf:type shield:Procedure ;
    rdfs:comment "Remove admin access to reveal escalation..." ;
    shield:used_by_usecase <shield:DUC0040>, <shield:DUC0050> .

For ATT&CK Mappings:
  <shield:mapping-1> rdf:type shield:AttackMapping ;
    shield:shieldId "DTE0001" ;
    shield:shieldType "technique" ;
    shield:attackTechniqueId "T1039" ;
    shield:attackTacticId "TA0009" ;
    shield:relationshipType "detects" ;
    shield:defensiveCoverage "High" .

Stage 5: Index and Enable Queries

Build Efficient Query Indices:

Primary Indices:
  - Opportunities by technique support
  - Use cases by opportunity realization
  - Procedures by use case implementation
  - Techniques by tactic membership
  - Tactics by name/strategic role

Cross-Framework Indices:
  - ATT&CK coverage analysis (defensive-offensive alignment)
  - Bidirectional relationship navigation
  - Gap analysis (opportunities with 0 use cases - INVALID)

SPARQL Query Examples

• Query 1: Find all techniques in a specific tactic

SELECT ?technique ?name ?description WHERE {
  ?tactic shield:tacticId "DTA0001" ;
          shield:contains_technique ?technique .
  ?technique rdfs:label ?name ;
             rdfs:comment ?description .
}

• Query 2: Find all use cases for an opportunity (CRITICAL relationship)

SELECT ?usecase ?description WHERE {
  ?opportunity shield:opportunityId "DOS0027" ;
               shield:has_usecase ?usecase .
  ?usecase rdfs:comment ?description .
  FILTER(BOUND(?usecase))  # Validation: ensures opportunity has use cases
}

• Query 3: Find all SHIELD techniques that detect an ATT&CK technique

SELECT ?shield_id ?shield_name ?coverage WHERE {
  ?mapping shield:attackTechniqueId "T1007" ;
           shield:relationshipType "detects" ;
           shield:shieldId ?shield_id ;
           shield:defensiveCoverage ?coverage .
  ?shield_entity rdfs:about ?shield_id ;
                 rdfs:label ?shield_name .
}

• Query 4: Find procedures implementing a use case

SELECT ?procedure ?description WHERE {
  ?usecase shield:useCaseId "DUC0001" ;
           shield:implements_procedure ?procedure .
  ?procedure rdfs:comment ?description .
}

• Query 5: Find all ATT&CK tactics engaged by a SHIELD tactic

SELECT DISTINCT ?attack_tactic ?tactic_name WHERE {
  ?shield_tactic shield:tacticId "DTA0001" ;
                 shield:contains_technique ?technique .
  ?technique shield:enables_opportunity ?opportunity .
  ?mapping shield:shieldId ?shield_id ;
           shield:attackTacticId ?attack_tactic .
  ?attack_tactic rdfs:label ?tactic_name .
}

• Query 6: Validate data integrity (find opportunities WITHOUT use cases)

SELECT ?opportunity ?id WHERE {
  ?opportunity rdf:type shield:Opportunity ;
               shield:opportunityId ?id .
  FILTER NOT EXISTS { ?opportunity shield:has_usecase ?usecase . }
}
# Should return EMPTY SET (violations of CRITICAL cardinality constraint)

Summary

This mapping specification defines the complete transformation of MITRE SHIELD active defense framework from JSON format to KGCS OWL ontology, enabling:

1. Hierarchical Federation: Defensive tactics organize techniques, which enable opportunities, implemented by use cases with supporting procedures

2. Critical Cardinality Enforcement: Opportunities must have ≥1 use cases, ensuring complete defensive coverage mapping

3. ATT&CK Defensive-Offensive Alignment: 5 relationship types (detects, mitigates, enables, tests, engages_with) enable bidirectional threat modeling

4. Comprehensive Validation: Multi-stage ETL with pattern matching, enumeration checking, and cross-reference validation

5. SPARQL Queryability: Rich query patterns supporting defensive coverage analysis and threat-defense alignment

6. Extensibility: Support for future technique, opportunity, and procedure expansion while maintaining semantic integrity