Purple team
Detection coverage is usually described as a percentage of a framework. That number comes from reading rule names. The only way to know whether a rule fires is to do the thing it is supposed to catch, while someone watches the console, and write down what appeared.
What is included
- A technique list agreed in advance, drawn from MITRE ATT&CK and from what we see
- Execution alongside your detection team, in real time
- Per-technique result: alerted, logged without alerting, or no telemetry at all
- Tuning suggestions for the rules that nearly fired
- Re-run of the failed techniques after tuning, in the same engagement where time allows
What you get
- Technique-by-technique results table with timestamps on both sides
- The specific log sources that were missing, not just that coverage was low
- Detection logic suggestions written in the query language you actually use
- A shortlist of what to fix first, ordered by technique prevalence
- Debrief with the detection team
- Attestation letter for auditors and customers, on request
- Remediation attestation after the retest, as a standalone document
Shape of the engagement
- Scoped individuallyFixed in writing before testing starts. Two to five days on site or on callTypical window. Built around your deadline if you have one. How pricing works
What usually comes out of it
The common result is not that detection is absent. It is that the telemetry exists, the rule exists, and the two do not meet: the rule queries a table the relevant log source does not write to, or it filters on a process name that the technique does not use, or it fires into a channel nobody reads at two in the morning. Those are all cheap to fix once someone has proved they are happening.
The second common result is a technique that produces a perfectly good log entry that nothing is querying. That is the cheapest finding on this list and the easiest to miss from a documentation review.
How a session runs
We agree the technique list first, so nobody is surprised and so your team can prepare their queries. On the day we execute each technique in turn, call it out as we do it, and your team reports what they see and when. Both sides record timestamps. Where a technique produces nothing, we stop and work out whether the problem is the log source, the rule, or the routing, before moving on.
What this is not
This is a collaborative exercise, not a covert one. If you want to know whether your team catches someone who is trying not to be caught, that is a red team assessment, and it measures something different. We also do not operate, monitor, or staff your detection capability. We test it, help tune it, and hand it back to the people who own it.
Questions
You need somewhere logs land and someone who can query them. It does not have to be mature. Some of the most useful sessions have been with a team three months into a SIEM deployment who needed to know which of their assumptions held.
Agreed in advance from MITRE ATT&CK, weighted toward what we actually see used: credential access, lateral movement, certificate abuse, and persistence. If you have a specific threat model or a recent industry incident you want covered, bring it.
We suggest logic and hand over query drafts in the language you use, commonly KQL for Microsoft Sentinel. Your team owns, tests, and deploys them, because rules nobody on staff understands become the next gap.
Yes, and where the engagement window allows it we re-run failed techniques in the same session, which is the fastest feedback loop available.
Individually, on the size of the technique list and the length of the window. Fixed in writing after the call.
Scope it properly before you buy it.
Thirty minutes on the call, a fixed price in writing within 24 hours, and an honest answer if this is not the engagement you need.