Purple teaming: connect attack, detection and defence

Purple teaming is a collaboration model in which offensive and defensive teams test, observe and improve adversary techniques in a short loop. It does not require a permanent purple team. Shared goals across red team, SOC, detection engineering and system owners matter more.

A penetration test primarily asks whether a weakness can be exploited. Purple teaming also asks whether the organisation sees the activity, classifies it correctly and responds within the required time.

Select techniques with evidence

Do not begin with a random ATT&CK list. Use risk assessment, cyber threat intelligence, previous incidents and architecture. Choose a scenario relevant to the business, such as administrator session theft, OAuth abuse or lateral movement from a service account.

For each technique, define prerequisites, target, safety constraints, expected telemetry and success criteria. Name the people authorised to stop the test.

Establish a baseline

Run the technique in controlled conditions and capture a complete timeline. Verify whether the source produced an event, the pipeline delivered it, a rule fired, priority was correct and the analyst received enough context.

A missing alert can result from absent logging, a broken parser, the wrong field, weak detection or triage. Each root cause needs a different fix.

Test, improve, retest

After each run, build or modify the control together. The change may be additional logging, correlation logic, asset context, a playbook or a preventive restriction. Then execute the same scenario again.

Retain commands, event identifiers, queries, timelines and rule versions. The scenario can then become a regression test in a detection-as-code workflow.

Meaningful measures

Useful metrics include:

• priority techniques covered by reliable telemetry;
• time from execution to alert and triage;
• scenarios detected without hints;
• false positives introduced by the rule;
• gaps closed and independently retested;
• resilience to small variations of a technique.

ATT&CK is an index, not a score to maximise. Ten proven detections protecting critical paths can outperform one hundred weak rules.

Run exercises safely

Use test accounts and synthetic data. Limit speed, network scope, persistence and payload effects. Agree on timing, monitoring and a recovery route. A test should not leave a real backdoor or bypass data-protection rules.

Connect results to the first 72 hours of breach response and control owners’ backlog. The exercise finishes only after the retest.

A minimal session

1. Define the threat and business objective.
2. Choose one to three techniques.
3. Specify evidence, constraints and stop conditions.
4. Execute and measure telemetry.
5. Find the root cause of each gap.
6. Implement the change and retest.
7. Add the scenario to regression testing.

Purple teaming works when it shortens the defender’s learning cycle. A report without an improved and verified detection only describes the problem.

---

Measuring the result of a technique

For each step, record the precondition, telemetry, expected alert and analyst response. Results are not binary: score prevention, data visibility, detection, triage and containment separately. No alert may indicate a poor rule, but also a missing log, wrong field or ingestion delay.

After changing a rule, repeat exactly the same action and preserve evidence. Then test a variation so the detection is not fitted to one command. Purple teaming does not replace an independent red team; it enables rapid learning and validation of known defensive hypotheses.

Scope needs safety conditions and a stop procedure, especially for identity, email and production tests. Mark test activity for the controller, though not necessarily for the analyst. Remove accounts, payloads and exceptions afterwards, and place new detections under regression testing.

Sources: MITRE ATT&CK, MITRE CTID — Adversary Emulation Library, NIST SP 800-61 Rev. 3.