MITRE ATT&CK Coverage

Overview

The MITRE ATT&CK Coverage module gives SOC teams a visual, interactive view of which adversary tactics and techniques the ThreatOps detection rule library currently covers. In a managed security operations service, customers and analysts need to answer a single critical question: which attack paths can we detect today? Without this visibility, coverage gaps remain invisible until an attacker exploits them.

This module maps every active detection rule's mitre_tactic and mitre_technique_id fields against all 12 MITRE ATT&CK Enterprise tactics (TA0001–TA0040) and their representative techniques, producing a real-time heat-map matrix, per-tactic progress bars, an overall coverage score, and a prioritized gap analysis with actionable recommendations. It is directly driven by the 372 detection rules in platform/api/app/rules/.

What Was Proposed

• Visual ATT&CK matrix heat-map showing detection coverage across all enterprise tactics and techniques
• Automatic computation of coverage percentage derived from the live detection rule library
• Technique drill-down showing which specific detection rules are mapped to each ATT&CK technique
• Gap analysis identifying uncovered or partially-covered techniques ranked by risk severity
• Actionable remediation recommendations per identified gap
• Recalculate-on-demand to reflect newly deployed detection rules immediately
• Integration with the Detection Rules module so rule MITRE tags are the single source of truth
• Framework export capability for customer compliance reporting

What's Built

Architecture

Coverage Computation Pipeline

The coverage calculation runs client-side in src/app/mitre-coverage/page.tsx inside the fetchData useCallback hook, executing three steps on every recalculation:

1. Rule Fetch — Calls GET /api/v1/detection-rules/?limit=1000 via the shared api client (src/lib/api-client.ts). Handles three API response shapes: plain array, { items: [...] }, and { data: [...] }.
2. Coverage Mapping — For each of the 12 MITRE tactics, filters rules where rule.mitre_tactic (case-insensitive) matches the tactic name. Techniques are then scored: more than 2 matching rules marks a technique as full; 1–2 rules as partial; zero rules as none.
3. Score Calculation — Overall coverage percent uses the weighted formula ((full_count + partial_count × 0.5) / total_techniques) × 100. Identical formula is applied per-tactic for the progress bars.

When the API call fails or returns zero rules, the page falls back to generateMockCoverage() and generateMockGaps(), displaying an amber warning banner. This ensures the UI remains fully functional during development or connectivity issues.

Detection Rule Backend Integration

Detection rules exist in two stores, both surfaced by the same API endpoint:

• Rule library — 372 hand-authored rules in platform/api/app/rules/ (20+ modules), loaded via get_all_rules(). Each rule carries mitre_tactics: [...] and mitre_techniques: [...] arrays. The router normalizes mitre_tactics[0] to the singular mitre_tactic response field.
• Database — Tenant-created rules in the detection_rules PostgreSQL table, with mitre_tactic (string) and mitre_technique_id (string) columns directly.

The coverage page queries both sources through the same endpoint, so library rules and tenant-specific rules both contribute to the ATT&CK heat-map.

Gap Analysis

The gap analysis section uses a curated static list of eight high-signal technique gaps representing the most commonly exploited and under-detected attack patterns in enterprise environments:

• T1566 Phishing (Critical) — Deploy email gateway rules and user-reported phishing playbook
• T1059 Command & Scripting Interpreter (Critical) — Enable PowerShell script block logging and Sigma rules for encoded commands
• T1003 OS Credential Dumping (Critical) — Monitor for LSASS access patterns and deploy credential guard
• T1486 Data Encrypted for Impact (High) — Create canary file detection rules and monitor mass file modification events
• T1021 Remote Services (High) — Monitor anomalous RDP/SSH sessions with baseline deviation rules
• T1071 Application Layer Protocol (High) — Deploy DNS analytics and HTTP anomaly detection rules
• T1543 Create or Modify System Process (Medium) — Monitor new service installations and systemd unit file creation
• T1082 System Information Discovery (Low) — Baseline normal discovery activity per host to detect anomalies

Tactics & Techniques Covered

The module covers all 12 MITRE ATT&CK Enterprise tactics. Each tactic maps to a technique bank of 4–7 representative techniques drawn from the most prevalent sub-techniques in each category:

API Endpoints

The MITRE Coverage module does not have a dedicated backend router. It relies entirely on the Detection Rules API, which exposes MITRE tactic and technique metadata on every rule record.

Detection Rules API (consumed by this module)

Router file: platform/api/app/routers/detection_rules.py — Prefix: /api/v1/detection-rules

GET  /api/v1/detection-rules/?limit=1000

Query parameters used by coverage page:
  limit=1000   # Fetch all rules in a single request

Response fields consumed by coverage computation:
  id                  string   Rule UUID
  name                string   Human-readable rule name
  severity            string   critical / high / medium / low
  mitre_tactic        string?  ATT&CK tactic name (e.g. "Initial Access")
  mitre_technique_id  string?  ATT&CK technique ID (e.g. "T1566")
  enabled             boolean  Whether the rule is active

Response Shape Handling

The frontend handles multiple API response shapes to accommodate both the library and DB-backed rules endpoints:

// All three shapes are supported:
rulesRes               // Plain array
rulesRes.items         // Paginated response { items: [...] }
rulesRes.data          // Alternative envelope { data: [...] }

Frontend Routes

Frontend Page File

File: platform/frontend/src/app/mitre-coverage/page.tsx

The page is a single React client component ('use client') with two primary state objects: tacticCoverage (a Record<string, TacticCoverage> keyed by tactic ID) and gaps (the prioritized gap list). A single fetchData callback populates both on mount and on manual recalculation. The selectedTechnique state drives the detail modal visibility.

Data Model

The MITRE Coverage module is stateless on the backend — there is no dedicated database table. All coverage data is computed in-memory on the frontend from the detection rule records. The relevant TypeScript types are defined at the top of page.tsx:

TacticCoverage

TechniqueCoverage

GapItem

Detection Rule (MITRE fields — from backend)

Model: platform/api/app/models/detection_rule.py — Table: detection_rules

UI Layout

Prerequisites

• Detection Rules Endpoint — GET /api/v1/detection-rules/?limit=1000 must be reachable. The page degrades gracefully to deterministic mock data if unavailable, with an amber warning banner.
• Rule MITRE Tags — Detection rules must have mitre_tactic populated with exact MITRE tactic names (case-insensitive match). Rules without mitre_tactic do not contribute to coverage scores.
• API Client — src/lib/api-client.ts must be configured with NEXT_PUBLIC_API_URL pointing to the FastAPI backend (e.g., https://api.threatops.roconpaas.io).
• Detection Rules Router Registered — platform/api/app/routers/detection_rules.py must be included in app/main.py under the /api/v1/detection-rules prefix.
• Rules Module — platform/api/app/rules/ must be importable and get_all_rules() must succeed. This supplies the 372 library rules with their MITRE metadata arrays.
• No dedicated backend service required — Coverage computation is fully client-side. No additional database tables, background workers, or scheduled jobs are needed for this module.