Purple teaming: testing with your defenders, not against them
Purple teaming is not a third team and buying a purple team as a product is usually a mistake. It is a working arrangement in which someone executes a known attacker technique while the defenders watch their own tooling, and the session is only finished when a detection exists and has been re-run successfully. For organisations that have monitoring but do not know its coverage, this returns more per pound than a covert engagement, and it does so within days rather than months.
What is purple teaming, and what is it not?
It is offensive and defensive people working the same technique in the same room, or the same call. One side executes, the other watches the logs and the alert queue, and both agree in advance what telemetry ought to appear. The output is a detection rule, a documented gap with an owner, or a decision that the technique is not worth detecting, and all three are useful results.
It is not a covert exercise, so it measures nothing about whether your team would have noticed unprompted. That is the trade. You give up the realism of surprise and get in return a specific, repeatable, technique-level map of what your tooling sees, which a covert engagement cannot produce because it only exercises the handful of techniques it needed.
The name matters less than the arrangement. Some organisations run it as a formal programme with a facilitator, others as a standing fortnightly session between two engineers, and the results are comparable because the mechanism is the same: execute, observe, fix, re-run. What does not work is a purple team consisting of a red team report emailed to the monitoring team, which is the arrangement most often described using the word.
It is also not a product. Vendors sell continuous validation platforms that automate the execution half, and they can be worth having later. Starting with one commonly produces a dashboard of pass and fail states that nobody converts into detection engineering work, which is the actual bottleneck.
When does it beat a covert red team?
When you already know you will fail. If nobody has ever tested whether your tooling alerts on credential dumping, you do not need six weeks of stealth to find out. Execute it, watch, and either write the rule or record why you cannot. The information arrives in an hour instead of a quarter, and you keep the budget.
It also wins when the estate is changing quickly. Detection coverage decays: an agent stops reporting, a log source changes format after an upgrade, a cloud service is replaced, a rule is disabled during an incident and never re-enabled. Covert engagements sample that decay once a year. A purple team cadence catches it continuously, which matters more in a container platform where the workload inventory turns over weekly.
It wins on the cost of failure too. A covert engagement that reaches its objective on day three has consumed most of the budget and produced one path. A purple team session that fails produces the same information about that technique for the price of an afternoon, so the programme can afford to test the techniques you expect to fail on, which are the ones worth knowing about.
The third case is political. A covert engagement produces a report that reads as a judgement on the security team, which makes defenders adversarial towards the exercise. Purple teaming puts them in charge of the outcome, and the same people who resist an audit will happily spend a Friday proving their tooling sees a technique.
How does a purple team session actually run?
Pick one technique. Write down the hypothesis before anyone executes: which log source should record it, which rule should fire, and roughly how long it should take. Execute in a controlled environment with the defenders watching live. Then compare what happened against the hypothesis, and classify the result as detected, telemetry present but no alert, or no telemetry at all.
The third category is the expensive one and the most common. Telemetry present without an alert is an afternoon of rule writing. No telemetry at all means a configuration change, an agent deployment or a new log pipeline, which is a project. Knowing which of the two you are facing, per technique, is what turns a vague sense of coverage into a budgeted plan.
Two habits improve every session. Record the exact command or manifest that was executed, so the re-run is identical rather than approximate, and record the query that found the evidence, so the next person does not have to rediscover which field holds the container name. Both belong in the same repository as the detection rule, and together they are what makes coverage survive staff turnover.
Then re-run. This is the step teams skip and it is the point of the exercise: a detection that has never been re-tested after being written is a hypothesis, not a control. Re-run the same technique a week later, and again after any platform upgrade, and treat a rule that stops firing as a broken build rather than a security event.
Which techniques should you start with?
Start where an intruder actually ends up, which for most estates means identity, endpoint execution and the container platform. The table below is a workable first fortnight, and the container rows are the ones that most often come back with no telemetry at all.
| Technique | How it is executed | Telemetry that should exist | Common gap |
|---|---|---|---|
| Command execution inside a running container | Exec into a pod and run a shell | Control plane audit event plus process events from a node sensor | Audit logging off, or shipped nowhere queryable |
| Deploy a privileged or host-mounted pod | Apply a manifest with a permissive security context | Admission decision and an audit record of the create | No admission policy, and nobody alerts on the audit event |
| Service account token abuse | Read the mounted token, call the API from the pod | API requests attributed to that service account, from an unusual pattern | Every workload uses one broad role, so nothing looks unusual |
| Cloud metadata access from a workload | Request instance credentials from inside a pod | Egress or host telemetry, then cloud audit use of the node role | Node role used by workloads routinely, so no baseline exists |
| Credential access on an endpoint | Read process memory of the credential store | Endpoint detection alert | Usually covered, which makes it a good control test |
| Unusual egress from a workload | Long-lived outbound connection to an unfamiliar host | Network flow logs with workload identity attached | Flows recorded per node, so no attribution to a pod |
What tooling do you need to start?
Less than vendors suggest. An open library of documented atomic tests gives you execution with known expected behaviour, which matters because a home-rolled test that fails to detect might simply not have done what you thought. An open adversary emulation framework covers chained sequences later. For the container rows above, a runtime sensor on nodes and audit logging switched on and shipped somewhere queryable are prerequisites rather than tooling choices.
The part worth investing in is detection as code. Rules in version control, reviewed like software, with the test that proves each one fires. That is what makes the re-run cheap, and it is what stops the coverage you built this quarter quietly disappearing next quarter. Vendor consoles where rules are edited by hand in a web form make the discipline impossible to sustain.
Map results to a shared technique taxonomy so the coverage picture accumulates rather than living in session notes. Use it as an inventory, not a score. A heatmap showing most techniques green is easy to produce and means very little, because the techniques an adversary would use against you are a small and specific subset.
How do you keep it running after the first month?
Give it an owner, a fixed cadence and a backlog. Half a day a fortnight with a named person choosing the next two techniques survives; an initiative depending on both teams having spare capacity does not. Keep a visible list of techniques not yet tested, because that list is the honest statement of your coverage and it makes the case for the next hire better than any maturity model.
Feed the backlog from three sources: techniques observed in incidents at organisations like yours, techniques a previous engagement used successfully, and every platform change that could have broken an existing detection. The third is the one that keeps paying, because most lost coverage is caused by your own upgrades rather than by adversary innovation.
Watch for the failure mode where purple teaming becomes a reporting exercise. The signal is sessions that always succeed. If every technique tested produces a detection, the backlog is being filled with techniques already known to be covered, which is comfortable and useless. A healthy programme fails often enough to keep generating work for the log pipeline.
Finally, publish the failures internally. A team that reports honestly that six techniques produced no telemetry is a team that gets the log pipeline funded. A team that reports a green dashboard gets nothing, and deserves the covert engagement that follows.
Common questions
- What is purple teaming in cyber security?
- A working arrangement rather than a team. Someone executes a known attacker technique while the defenders watch their own logs and alert queue, with both sides agreeing in advance what telemetry should appear. The session ends when a detection exists and has been re-run successfully, or when the gap is documented with an owner. It measures coverage per technique, which a covert engagement cannot.
- Is purple teaming better than red teaming?
- It is better value when you do not yet know your detection coverage, which is most organisations. It gives up the realism of surprise, so it says nothing about whether your team would notice unprompted, and returns a repeatable technique-level map of what your tooling sees. A covert red team only exercises the few techniques it needed to reach its objective.
- How do you run a purple team exercise?
- Choose one technique, write the hypothesis down first, execute with defenders watching live, then classify the result as detected, telemetry present but unalerted, or no telemetry at all. Write or fix the detection, then re-run the same technique a week later and after any platform upgrade. A detection that has never been re-tested is a hypothesis rather than a control.
- Why do container techniques fail purple team testing?
- Because the telemetry is commonly absent rather than unalerted. Control plane audit logging is often off or shipped nowhere queryable, nodes have no runtime sensor so process execution inside containers is invisible, and network flows are recorded per node without workload attribution. Those are pipeline projects rather than rule-writing afternoons, which is why finding out early changes the budget conversation.
- Do you need a continuous validation platform for purple teaming?
- Not to start. An open library of documented atomic tests provides execution with known expected behaviour, which matters because a hand-rolled test that produces no alert may simply not have done what you assumed. The bottleneck is converting results into maintained detections, so invest in rules held in version control with tests before buying a console that reports pass and fail states.
