Purple Teaming Services

A purple team exercise runs as a short series of sessions in which our operators execute agreed attack techniques while your defenders watch with their tooling open, stopping after each one to tune detection until it fires reliably. Nothing is concealed, and both teams are on the same call for the whole exercise.

Before

We agree a technique list from MITRE ATT&CK, weighted toward your sector and what your tooling claims to cover. Your team records which log sources are live and what coverage it believes it has, so that belief can be compared with what the session finds.

During

Each technique is run in turn. Your analysts watch their own console and report what they see, in their own words. Where nothing fired, or the alert was too noisy to action, the rule is written or adjusted there and then and the technique is re-run.

After

You keep the detection content, log source recommendations and the coverage record, in the format your team works in. The exercise is designed to be run again as your estate changes.

Purple teaming hides nothing and builds the capability to notice an attack, and a red team engagement hides everything and measures whether you notice. The first produces detection content, the second produces a measurement. Most organisations need both, in that order, once.

The tradecraft is the same. Our operators run the techniques in a purple session that they would run in a covert engagement, because a sanitised demonstration teaches your team to catch a demonstration. What changes is the visibility, not the technique.

A red team engagement is the right choice when you need to know, for a board or a regulator, whether the controls you have paid for would catch a real intrusion. A purple team exercise is the right choice when you already suspect the answer and want to change it.

Purple teaming tests whether your defenders can see an attacker, and a penetration test tests whether an attacker can get in. A penetration test looks for vulnerabilities in a defined system and proves them. A purple team session assumes the attacker is already inside and asks what your EDR and SIEM do about it.

The outputs are different too. A penetration test ends in a findings list with owners, severities and a retest. A purple team exercise ends in detection rules, log sources switched on, and a coverage record against ATT&CK, all of which live in your tooling rather than in a document.

They complement each other. The penetration test tells you what to fix, and the purple team exercise tells you what you would see if somebody exploited what you have not fixed yet.

Techniques for a purple teaming session are chosen from MITRE ATT&CK, weighted toward what is relevant to your sector and what your tooling claims to cover. You see the list before the session and can add, remove or reorder anything on it.

The list usually spans the chain: initial access through phishing payloads and document handling, execution and evasion through script interpreters and living-off-the-land binaries, credential access including AD CS certificate abuse, lateral movement, persistence, and exfiltration over trusted channels. Each is a technique your SOC will then have seen with its own eyes.

We favour techniques where estates are most often surprised, such as the direct memory read that an EDR misses while blocking the obvious tool, or C2 over a service your proxy trusts. A technique your tooling already catches well is run once, confirmed, and moved past.

Purple teaming ends in detections you keep because every technique run produces working detection content in your own tooling, tuned against your own telemetry, that fires reliably before we move on. A detection that stays is one that fires on the pattern rather than the tool name, that is quiet enough to be actioned, and that reaches somebody.

Three things are handed over. Detection rules and queries, in the format your SIEM or EDR uses. A coverage record marking every technique detected, logged only or invisible, with the reason. And a list of log sources that need to be collected before certain techniques can ever be caught.

A rule that alerts so often that analysts have learned to close it has not stayed, and neither has one with no owner. So the tuning includes the triage path, and the re-run confirms the alert lands with a person, not just in a queue.

The people who should attend a purple teaming session are the analysts who triage alerts and at least one person who can change a detection rule during the session. Without the second, the exercise produces a list of things to fix later, which is a report rather than a detection.

Whoever owns the telemetry pipeline should be reachable, because the techniques that come up invisible are usually a missing log source rather than a missing rule, and switching one on mid-session turns an invisible technique into a detected one the same day.

Nobody needs to be senior and nobody needs to have seen the technique before. Analysts watch their own console and report what they see, in their own words, and that is where the skill transfers.

No, purple teaming does not need a mature SOC, and this is the common misconception. It is the fastest way to find out what your tooling actually does, which is more valuable when you are unsure than when you already know.

What you do need is somebody who can change a detection rule during the session, and the tooling to change it in. If your monitoring is outsourced, the provider's engineer needs to be on the call with the same access.

A young SOC gains the most, because the baseline it believes in is usually furthest from reality and the first session closes the largest gaps. A mature SOC uses the same exercise to test what it already claims, technique by technique.

Purple teaming uses your EDR, your SIEM and your analysts, and we bring only the offensive side. The point is to improve detection in the environment you actually run, and a rule tuned against our lab is worthless in your estate.

The tooling does not need to be a particular product. What the session needs is that your team can see raw telemetry, write or edit a rule, and re-run the technique to confirm it fires. Any EDR and SIEM that allow that will do.

Where the EDR blocks the obvious tool, we record it and run the variant it does not block, because the direct memory read behind a blocked binary is the finding, not the block itself.

Purple teaming measures MITRE ATT&CK coverage technique by technique, marking each one detected, logged only or invisible, with the reason. Your team records at the start which log sources are live and what coverage it believes it has, and the record shows where that belief held.

Detected

An alert fired, an analyst saw it, and it was quiet enough to be actioned. A technique that alerts so often the queue ignores it is tuned until it belongs here.

Logged only

The telemetry exists but no rule reads it. This is the fastest category to fix, because the rule is written in the session and the technique is re-run.

Invisible

Nothing was recorded, usually because the log source was never collected. The CA logs behind AD CS abuse are the common case. The fix is ingestion first, and the rule follows.

The record is what lets you answer which parts of the matrix you can actually see, and compare next year's session with this one.

A purple team engagement typically takes three to five days of sessions, plus preparation and handover. It is deliberately short, and designed to be repeated as your estate and the threat landscape change.

Preparation is the technique selection and the baseline, which take a call or two. The sessions themselves are paced by tuning rather than by the technique list, because no technique is left behind until the detection for it fires reliably.

Handover is at the end of the last session, not weeks later, because the content already lives in your tooling. What follows is a short written record rather than a long report.

Purple teaming is often the best fit for evidencing UAE IAS controls, because several IAS control families can only be evidenced by showing that monitoring produces something a human acts on. A configuration screenshot does not demonstrate that. A technique that fires an alert somebody triages does.

The IAS is published by NESA, now the SIA, and a tender that still says NESA means the IAS. The coverage record and the tuned rules are the evidence, and both carry the date and the technique.

The same evidence serves the monitoring expectations of CBUAE, the DESC ISR and ADHICS, where the question is whether detection and response work rather than whether they are documented. A penetration test cannot evidence that, because your team is told it is happening.

Yes, a purple team exercise can be run remotely, and most sessions are. Everyone needs to be on the same call with screens shared, but nobody needs to be in the same building.

Our operators need a position inside your environment to run techniques from, which is usually a workstation or server you provision for the session, reached over your normal remote access. Physical presence is rarely in scope for purple, and only where a scenario genuinely needs it.

Remote sessions work across the UAE and the wider GCC in your timezone, and they keep each analyst in front of their own console, which is where the learning happens.