purple-ops

name	purple-ops
description	Purple-team operations — structured detection validation against MITRE ATT&CK through planned emulation, measured coverage gaps, joint red+blue debrief, and tracked closure via D3FEND mapping. Bridge between the pentest bundle and the blue bundle.

Purple Team Ops

Bridge skill: this is a both-blue-and-pentest category. The actual work is collaboration — red simulates a TTP, blue tries to detect it, both learn at the same time. No surprise engagements ("see if we catch them without warning"); that is red team. Purple is planned, measured, and aimed at gap closure.

When to use

A SOC can write endless rules without ever knowing if they cover the right TTPs. A red team can run endless engagements without the defensive side learning more than "we got owned again". Purple ops is the discipline between the two: ATT&CK-mapped, repeatable, measured.

Triggers on:

• A question like "set up a purple-team cycle", "which TTPs are we not detecting", "ATT&CK coverage measurement", "validate detection rule X against real emulation", "post-pentest debrief with the SOC".
• A handoff from pentest-reporter (post-engagement feedback feeding into a detection-gap approach), detection-engineer (rule validation), alert-tuning (coverage gap identified after rule retirement).
• A periodic (quarterly to half-yearly) maturity measurement of the detection stack.
• Compliance context (NIS2 Art 21 effectiveness evaluation, DORA Art 25 testing) — a purple cycle delivers evidence of "we test our controls".

When NOT (handoff)

• Surprise red-team engagement without blue informed in advance → pentest skills (recon-agent, c2-hygiene, post-exploit, pentest-reporter).
• Writing detection rules → detection-engineer.
• Alert tuning on existing rules → alert-tuning.
• Threat hunt for the unknown-unknown → threat-hunt (command).
• IOC feed work → ioc-hunter.
• Forensics after an incident → forensics-assist.
• IR itself → ir-runbook.

Approach

Six phases as a cycle, not a one-off project. Each run covers a sub-set of ATT&CK; over quarters you work toward broader coverage.

1. Plan: scope, threat-actor emulation, success criteria

• Threat-actor choice: emulate a specific group relevant to your sector (FIN7 for financial, APT28 for a geopolitical target, RANSOM cluster for broad impact). MITRE Adversary Emulation Plans as a template.
• TTP subset: not the whole kill chain in every cycle. Focus on one tactic or a chain of 2–3 tactics. For example, Q1 Initial Access + Execution; Q2 Persistence + Privilege Escalation.
• Target systems in scope: lab? a specific staging environment? a deliberately chosen production segment? RoE sign-off for each.
• Detection coverage goal: which ATT&CK techniques do you claim to have covered? DeTT&CT (NL Rabobank-CDC) or ATT&CK Navigator as baseline. Those are the claims you are about to test.
• Success criteria: not "we get caught" — measurable: "technique T1003.001 is detected within 5 minutes by rule X with TP confidence high; rule does not fire on baseline traffic". Qualitative AND quantitative criteria.
• Communication: the blue team knows that a cycle is running and which window. Not which specific TTPs at which moment — that fingerprint is for blue to find themselves.

2. Execute: emulation with atomic-red-team / Caldera / manual

• atomic-red-team (Red Canary, MIT) — atomic tests per ATT&CK technique. Small, scriptable, replay-able. Default for unit-style emulation.

  # Example atomic test for T1003.001 LSASS dumping
  Invoke-AtomicTest T1003.001
  

• MITRE Caldera — full-scenario emulation with an agent on endpoints. Fits multi-step chains.
• Hand-driven emulation for TTPs without an atomic equivalent or for a target-specific environment. Document exactly what you did.
• Replay discipline: document each execution (timestamp, target, parameters, result). Output goes to the evidence store.
• Cleanup discipline: atomic tests have cleanup commands; always run after. Remove Caldera agents after the cycle. Do not leave persistence behind.

3. Measure: detection vs. blind, MTTD, false-positive context

Per executed TTP:

• Detection status: detected (which rule, how fast) / partial (rule fires but at too low a severity) / blind (no alert).
• MTTD (Mean Time To Detect) for covered TTPs: time between execution and alert generation. Goal: shorter than attacker dwell time in a real incident.
• MTTR (Mean Time To Respond) for covered TTPs: time between alert and blue-team action. Part of capability measurement.
• False-positive impact in the same period: a rule that now fires, how often on baseline? Too many FPs make the rule operationally unusable even when it fires correctly on emulation.
• Coverage shift: how much % of the claimed coverage has been validated? New gaps?

Output: a per-TTP row in the coverage matrix with "validated detect" / "validated blind" / "not tested".

4. Close gaps: detection-engineering cycle

Per blind spot, an action:

• Quick win: existing SIEM data permits detection but there is no rule. Handoff to detection-engineer for a Sigma/SPL/KQL rule.
• Data gap: SIEM does not have the right log source. Handoff to the log-pipeline team for enablement (Sysmon config, EDR policy, audit-policy expansion).
• Tooling gap: rule building is possible but the SIEM platform has limits. Roadmap input for tooling evolution.
• Compensating control: detection remains hard, but a D3FEND defensive technique (prevention or mitigation) closes the gap. For example: T1003.001 LSASS dump is hard to detect across every variant; LSASS Credential Guard makes it irrelevant.

D3FEND mapping is core here: per ATT&CK technique, the defensive techniques that mitigate it. Not every gap must close via detection — some via prevention.

5. Re-test and track closure

A gap is only closed when you test it again and see validated detect.

• Re-test cycle: after detection-rule deployment, run the atomic test again. Confirmation: rule fires, FP rate acceptable, MTTD inside target.
• Closure tracking in the coverage matrix: update the status per TTP (validated → re-validated with date).
• Regression check periodically: are previously validated detections still firing? Schema drift in log sources, EDR-policy changes, or rule tuning can retroactively break detection coverage.

6. Verification-loop and program-level metrics

Layer 1: scope (subset of TTPs covered as planned? all blind spots addressed or explicitly accepted?), assumptions (atomic tests represent real attacker behavior, no lab-only shortcuts?), gaps (D3FEND counters considered or only the detection path?). Layer 2: ATT&CK T-IDs correct, atomic-test IDs really exist in the atomic-red-team repo, MTTD/MTTR figures from the SIEM source of truth, coverage claims supported by DeTT&CT output or an ATT&CK Navigator export.

Program-level metrics over quarters:

• Coverage trend (ATT&CK techniques validated-detect / total relevant).
• MTTD trend per severity class.
• New-blind-spots rate (regressions).
• Closure time per blind spot (time from identification to re-validation).

Output

Purple-team cycle report — <quarter/cycle name>
Period: <start → end>
Threat-actor emulation: <APT/group + source emulation plan>
Scope tactics: <T-A##: ... + T-A##: ...>

Plan:
  TTPs in scope:    <T-IDs list>
  Target systems:   <lab/staging/scope segments>
  Success criteria: <per TTP: detect window + FP acceptance>

Execute:
  Per TTP:
    Test method:    <atomic-red-team / Caldera / manual>
    Test-ID:        <T-id ref>
    Run timestamp:  <UTC>
    Target:         <system>
    Cleanup status: <ok>

Measure (coverage matrix):
  TTP | Detected? | Rule-id | MTTD | FP context | Verdict (validated/blind/partial)

Close gaps:
  Per blind spot:
    Type:           <quick-win / data-gap / tooling-gap / compensating>
    Action:         <handoff to detection-engineer / pipeline team / D3FEND control>
    Owner:          <name>
    Deadline:       <date>

Re-test:
  Per closed gap:
    Re-test date:   <...>
    Result:         <validated-detect | partial | still open>

Program-level metrics:
  Coverage trend:        <% validated-detect>
  MTTD trend:            <minutes>
  Open gaps:             N
  Closed this cycle:     N

Handoffs:
  detection-engineer: <new rules / refinements>
  alert-tuning:       <FP tuning on freshly validated rules>
  ir-runbook:         <playbook update for ATT&CK context>
  policy-drafter:     <if a D3FEND control touches a policy requirement>

Verification-loop: ...

References

• MITRE ATT&CK — https://attack.mitre.org/. Common framework.
• MITRE D3FEND — https://d3fend.mitre.org/. Defensive-technique mapping.
• MITRE ATT&CK Navigator — https://mitre-attack.github.io/attack-navigator/. Coverage visualization.
• MITRE Adversary Emulation Plans — https://github.com/center-for-threat-informed-defense/adversary_emulation_library. Per-actor plans.
• atomic-red-team — https://github.com/redcanaryco/atomic-red-team. Per-technique replay modules.
• MITRE Caldera — https://github.com/mitre/caldera. Adversary-emulation platform.
• DeTT&CT — https://github.com/rabobank-cdc/DeTTECT. NL tooling for data-source and coverage mapping.
• Center for Threat-Informed Defense — https://ctid.mitre-engenuity.org/. Research + tooling.
• SANS Purple Team Maturity Model — https://www.sans.org/. Maturity rubric.
• Detection Engineering Maturity Matrix — community resource for self-assessment.

Categories

• blue
• pentest