Key takeaways
- The technique list decides what a purple team session can find. Reviewing it is the real scoping decision, not signing the statement of work.
- Build it from four sources: threat intelligence for your sector, your own incidents, your architecture, and your vendor's coverage claims. Any one of them alone inherits its own blind spot.
- Write each entry as a procedure, naming the host class and the account it runs as. Two procedures under one ATT&CK identifier leave different traces and need different rules.
- Plan for entries that need a rule written and a second run. A list that fills the booked hours end to end assumes an outcome that would have made the session unnecessary.
- Keep the list after the session. The verdicts are your coverage record, and re-running it is how you find out which detections have decayed.
The technique list is what you are buying
A purple team session is a fixed number of hours with your analysts, your tooling and an operator running attacks in front of both. What fills those hours is a list of techniques agreed before anyone starts. That list sets the ceiling on what the session can find, and a session run against a weak list still produces rules, still fills a handover document, and still leaves the things you needed to see untested.
The provider normally drafts the list and asks you to review it. That review is the scoping decision, and it deserves more of your attention than the schedule or the invoice. On a purple team engagement the technique list is agreed in advance and shown to your team precisely so that you can change it, which makes reading it properly an obligation rather than a courtesy.
Four things decide whether a list is any good: where the entries came from, whether each one is written as a procedure or as a category, how many of them fit the hours booked, and what was deliberately excluded. Each is a separate decision, and each is easy to get wrong quietly.
Four places a technique list comes from
No single source produces a usable list. Threat intelligence tells you what has been run against organisations like yours and nothing about how your estate is built. Your architecture tells you which paths exist and nothing about what attackers currently favour. A list drawn from one source inherits that source's blind spot and nobody in the room will notice, because the list is the only thing being compared against.
Public advisories are the cheapest source to work from. CISA's cybersecurity advisories map observed intrusions to ATT&CK technique identifiers, so an advisory covering activity in your sector converts fairly directly into candidate entries. Where a named threat actor is the whole reason for the exercise, adversary simulation is the engagement built around that constraint, and the technique list becomes the output of a threat intelligence step rather than of a workshop.
Your own incidents are the most undervalued of the four. A near miss that was caught by a person rather than by a rule is a technique with a known outcome and a known gap, and re-running it under controlled conditions turns an anecdote into detection content. Weight the list toward the first two sources, then use your architecture and the vendor's claims to fill it out.
| Source | What it gives you | What it cannot tell you |
|---|---|---|
| Threat intelligence for your sector | Techniques an actor group has actually used against organisations like yours | Anything about how your own estate is built |
| Your own incidents and near misses | Techniques that already reached you once, against your telemetry as it stood | Coverage of anything that has not happened yet |
| Your architecture | Paths that exist because of your own choices: certificate services, federated identity, jump hosts | What attackers currently favour |
| Vendor coverage claims | What the tooling says it detects, which is the cheapest thing in the room to falsify | Anything the vendor never claimed |
Write each entry as a procedure, not as a heading
A technique identifier is a class, not an instruction. MITRE ATT&CK describes what a technique achieves and lists procedure examples underneath it, and two procedures filed under the same identifier can leave entirely different traces. An entry reading only "credential dumping" hands the operator the choice of procedure and hands your analysts a rule that catches whichever one was picked.
Here is an illustrative example, written generically rather than taken from any engagement. The entry "scheduled task persistence" can be run three ways in an hour: a task created by an administrator at the console, a task created remotely over a management protocol, and a task created by a process spawned from a remote execution service on a server outside the build estate. The first is indistinguishable from ordinary administration. The third is the one worth writing a rule for. A list naming only the heading gets whichever the operator chose, and the rule written that afternoon is narrower than the team believes it to be.
So write each entry with the procedure, the class of host it will run on, and the account it will run as. Those three facts are what a detection keys on, and they are exactly what a Red Team engagement is free to vary because nobody has agreed them. Naming them in a purple session is not making the exercise easier. It is what makes the result reproducible when you run the same list again next quarter.
| Written as a heading | Written as a procedure | What the detection keys on |
|---|---|---|
| Credential dumping | Memory of the local security authority process read by a signed utility, renamed, run from a user-writable path | Process handle access, not the file name |
| Scheduled task persistence | Task registered on a member server by a process whose parent is a remote execution service | The registration event plus the parent relationship |
| Certificate abuse | Enrolment against a template that allows a requester-supplied subject name | Template name and requester in the certificate authority log |
| Command and control | Beacon to a cloud storage endpoint already allowed by policy, at a fixed interval with jitter | Timing regularity in egress to allowed hosts |
How many entries fit in the hours you booked
Every entry costs more than the time it takes to execute. The operator runs it, your analysts report what their own console showed, the entry is given a verdict, and where nothing fired a rule is written and the technique is run again. Plan on the assumption that any entry may need that second pass, because the entries that do are the reason the session exists at all.
That makes list length a constraint rather than an ambition. A list packed to fill the booked hours end to end assumes every entry alerts first time, which is the one outcome that would have made the session unnecessary. Order the list so the entries you most need answered run first, and accept in advance that the tail may not be reached. A short list fully resolved is worth more than a long list half run.
Check before you finalise it that the telemetry each entry depends on is actually being collected. Entries resting on a log source nobody ingests return the same verdict every time and consume the same hour doing it. That is a question to settle first, and the detection you need before an exercise is worth buying is the shape of the check.
What to leave off the list
Leave off anything that risks availability. A purple session runs against real systems with real analysts watching, and an entry that takes a service down turns the room's attention to recovery for the rest of the day. Destructive techniques can be staged in a lab, described rather than executed, or replaced by the detectable precursor step that would precede them.
Leave off entries whose answer everybody already knows. If a log source is switched off and the team can say so, running four techniques that depend on it produces four identical verdicts. Record it as a work item and spend the hour on something whose outcome is genuinely uncertain.
Leave off breadth pursued for its own sake. Covering more of the matrix is a number that improves without the estate getting safer, and a list chosen to widen a heatmap tends to be shallow everywhere at once. Published testing guidance puts planning and boundaries before execution for the same reason: NIST SP 800-115 treats the rules of engagement and the exclusions as the first phase of the work. The same discipline applies to where an exercise begins, which is the argument for an assumed breach exercise when the uncertain part is not how someone gets in.
The list outlives the session
Each entry ends with one of three verdicts: it alerted, it was logged and nothing fired, or it was never collected. Those verdicts against those entries are your coverage record, and it is a more honest one than a heatmap because it names the procedure that produced each result rather than the class it belongs to. A green square that stands for one execution should say so.
Carry unreached entries into the next session rather than dropping them, and re-run the entries that passed. Detections decay as the estate moves underneath them: an agent falls off a rebuilt host, a collection pipeline is re-pointed, a product update changes the shape of an event. The detect function of the NIST Cybersecurity Framework describes detection as a capability held over time rather than an artefact delivered once, which is the argument for keeping the list in version control beside the rules it produced.
Whether the next exercise is announced or not is a separate decision, and one covered in which exercise answers your question. The list matters either way. In an announced session it is the agenda you agreed; in an unannounced one it is the yardstick you measure the result against afterwards.
What the list has to survive in Abu Dhabi and Dubai
Four regulatory regimes in the UAE name security testing, and they do not read a technique list the same way. The Central Bank of the UAE binds licensed financial institutions wherever they are established. The Dubai Electronic Security Center binds Dubai government entities and the suppliers serving them. ADHICS applies to healthcare providers in Abu Dhabi. The UAE Information Assurance Standard, published by NESA, sits federally over critical national infrastructure. A list drafted without knowing which of these you answer to is a technical document that gets rewritten the moment somebody asks what it evidences.
In practice that changes the weighting rather than the method. A Dubai government supplier facing a control that requires monitoring to be demonstrated needs entries whose verdicts map onto the control wording, because the verdict is the evidence. A healthcare provider in Abu Dhabi under ADHICS is answering against a defined control set and gets more from entries chosen to exercise it than from breadth across the matrix. A free zone entity selling into both emirates often has to satisfy a client's regulator rather than its own, and the technique list is where that gets reconciled before anyone books a room.
So ask what the evidence is for before the list is signed off, and scope to that answer. Where the open question is technical exposure rather than detection, penetration testing answers it more cheaply and clears ground the session would otherwise spend hours on.
Frequently asked questions
How many techniques should a purple team session cover?
Fewer than the hours would allow if every entry alerted first time. Each entry has to be run, observed, given a verdict, tuned where nothing fired, and then run again, so the entries that teach you the most are also the slowest. Order the list by the questions you most need answered and treat the tail as optional. A short list fully resolved is a better purchase than a long list half run.
Should the provider write the technique list, or should we?
The provider normally drafts it and you review it, because each side holds half of what the list needs. The provider knows the procedures and how they are usually detected; you know which hosts matter, which log sources are live and which paths exist because of decisions your organisation made years ago. Sign off on the procedures rather than the headings, and change anything you would not want to spend an hour on.
Does the technique list have to follow MITRE ATT&CK?
Use ATT&CK as the shared vocabulary and as the frame for the coverage record, but do not stop at the identifier. A technique identifier names a class of behaviour, and two procedures inside one class can leave different traces and need different rules. Name the identifier so the record is comparable, then write the procedure underneath it so the detection has something specific to key on.
Can we reuse the same technique list for the next session?
Yes, and that is one of the reasons to write it carefully the first time. Re-running the same entries is how you find out which detections have decayed since they were tuned, which is why the entries have to be specific enough to reproduce. Add new entries as the estate changes and as new intelligence arrives, keep the old ones, and version the verdicts alongside the rules.
