Notifications
Clear all
Topic starter
18/08/2026 2:37 pm
TL;DR: Continuous purple teaming only works when validation is automated, procedure-level tracking is precise, and detection engineering is treated like software, according to Sprocket Security’s interview with Northwestern Mutual’s Gary Lobermier. The operational lesson is that manual exercises and static coverage claims quickly decay as environments, tools, and attacker techniques change.
NHIMG editorial — based on content published by Sprocket Security: Ahead of the Breach episode on scaling purple team validation
Questions worth separating out
Q: How should security teams run purple team exercises continuously instead of as one-off tests?
A: Security teams should automate repeatable ATT&CK-based executions, store results in a structured format, and compare outcomes after every meaningful change to infrastructure, detections, or cloud policy.
Q: Why do one-time purple team exercises create false confidence?
A: One-time exercises validate a point in time, not a living environment.
Q: What do security teams get wrong about ATT&CK coverage?
A: They often treat technique coverage as if it equals real detection coverage.
Practitioner guidance
- Build a continuous validation pipeline Schedule ATT&CK technique execution on a recurring basis, store results as structured data, and compare them after every major environment or policy change.
- Track procedure variants separately Record the specific ATT&CK procedure used, not just the technique ID, so detection gaps can be tied to the exact behaviour tested.
- Include identity and cloud paths in coverage Add tests that exercise privileged execution, cloud instances, and access-driven attack paths alongside endpoint checks, because real intrusions often move through credentials and workload access as much as through binaries.
What's in the full article
Sprocket Security's full episode covers the operational detail this post intentionally leaves for the source:
- Hands-on discussion of how the automation platform schedules and tracks hundreds of ATT&CK techniques across multiple operating systems and AWS EC2.
- The custom YAML procedure-tracking approach used to distinguish technique coverage from real procedure fidelity.
- Practical examples of how continuous validation changed blue-team alert quality and detection engineering workflows.
- Gary Lobermier's perspective on where AI can accelerate offensive testing without replacing human judgment.
👉 Read Sprocket Security's episode on scaling purple team validation and detection engineering →
Purple team automation at scale: are your detections keeping up?
Explore further
18/08/2026 3:22 pm
Continuous validation is now the real unit of purple team maturity. The article shows why annual or ad hoc testing produces a false sense of control, especially when infrastructure changes continuously. A mature programme needs repeatable evidence that detections still fire after drift, not just a report that they once did. For practitioners, the lesson is to manage purple teaming as an operational control with measurable freshness.
A question worth separating out:
Q: How can organisations know whether their detections still work after platform changes?
A: They need to re-run the relevant tests after EDR updates, asset changes, policy modifications, or cloud expansion. A detection that worked before a change may fail silently afterwards. Continuous validation provides the feedback loop needed to separate documented intent from actual control performance.
👉 Read our full editorial: Continuous purple team validation is becoming an engineering discipline
