Key takeaways
- A Red Team engagement measures detection and response, not exposure. Every operator step ends with one of three verdicts: detected, logged only, or missed.
- Logged only is the verdict to take seriously. The sensor was in place and the response path was not, and no purchase corrects that.
- The through phase decides the exercise. Credential access, lateral movement and directory changes leave traces on hosts and identity systems, not on the perimeter.
- A detection during the exercise needs a decision made in advance: let it run, deconflict, or reset the foothold. Write the three answers into the rules of engagement.
- The detection gap analysis is built by reconciling the operators' timestamped log against the SOC's tickets, with time to ticket and time to action per step.
A Red Team engagement measures the SOC, not the estate
A penetration test asks what is exposed. A Red Team engagement asks a different question: whether anyone notices when a determined operator moves from the outside to a named objective. The defenders are not told it is running. The estate is the ground the exercise is run across, and the thing being measured is what your monitoring and your people do while it happens. That is why the central document in the pack, as the UAE rules that expect a Red Team set out, is a detection gap analysis rather than a findings list.
That analysis gives each step the operators took one of three verdicts. Detected: an alert reached a person, and that person acted before the operators took the next step. Logged only: an alert or a record was raised, and nobody acted on it in time. Missed: nothing was raised at all, whether or not the event sits somewhere in raw logs. Each step is identified against MITRE ATT&CK, so this year's verdicts can be compared with last year's and with another provider's.
Two of the three verdicts are failures, and the middle one is the one to take seriously. A missed step is a sensor or a rule gap, and it is fixed by adding one. A logged-only step means the sensor is in place and the response path is not. That is a question about shifts, escalation and authority, and it is not answered by buying anything.
What each phase leaves behind, and where
The operators move through the same three phases the kill chain on this site draws: in, through and out. Each phase leaves a different kind of trace on a different sensor, and a SOC that watches the perimeter measures well in the first phase and barely at all in the second. The table sets out what should fire in each, without assuming the estate already has all of it. If it does not, the detection floor a Red Team needs comes first, and the exercise waits.
The through phase is where the exercise is decided. Credential access, lateral movement and privilege escalation all happen inside the network, on hosts and on identity infrastructure. The signals are authentication logs, endpoint telemetry and directory changes, none of which a firewall sees. NIST SP 800-137 describes continuous monitoring as a capability that spans the organisation rather than its edge, and this phase is the practical test of whether yours does.
Read the last column. It names where each signal comes from, so a missed step can be traced to a sensor that is absent or a rule that does not exist, rather than written up as a general failure of monitoring.
| Phase | Operator step (ATT&CK) | What should fire | Source of the signal |
|---|---|---|---|
| In | Phishing with a payload (T1566) | A mail gateway verdict, then an endpoint alert on the process the attachment starts | Mail security, endpoint detection |
| In | Command and control beacon (T1071) | Outbound connections to a recently registered domain on a regular interval | Proxy and DNS logs |
| Through | Credential dumping (T1003) | Access to LSASS memory from an unsigned process | Endpoint detection |
| Through | Lateral movement over SMB or WinRM (T1021) | Workstation-to-workstation logons and remote service creation | Windows event logs, identity platform |
| Through | Privileged group change (T1078) | New membership of a privileged group outside change control | Directory audit log |
| Out | Exfiltration over the C2 channel (T1041) | A large or unusual outbound transfer from a host that never sends | Proxy, data loss prevention where present |
One chain, drawn against the SOC
The figure draws a chain of the kind a Red Team runs, with the SOC as the fourth column, so the verdicts can be seen where they happen. The operators deliver the pretext, the social engineering component is one member of staff opening a file, and everything after that is a question about the estate rather than the person. The step the chain turns on is not the click. It is that nothing on the workstation stops an unsigned process starting under the user's session.
Watch the two arrows into the SOC column. The first is a low-severity endpoint alert closed as noise, which is the logged-only verdict in the shape it actually takes: the record existed, a person saw it, and closing it took less than a minute. The second is a credential access alert that opens a ticket. That step counts as detected only if the ticket is triaged before the operators finish the next one. In the drawn chain it is not, so the verdict is decided by time rather than by the rule.
That is the part a SOC dashboard hides. Alert volume and mean time to acknowledge are measured against the queue. A Red Team measures them against the operators' clock, and the reconciliation in the last section is how the two are set side by side.
- Attacker → Staff member
Sends a pretext email carrying a signed installer
The pretext is built from the intelligence phase
- Staff member → Workstation
Opens it; a loader starts under the user's session
- Workstation
Vulnerability
Nothing blocks an unsigned child process
No application control on the standard build
- Workstation → SOC
Low-severity endpoint alert, closed as noise
Logged only: a record, a glance, no action
- Attacker → Workstation
Reads cached credentials from memory
- Workstation → SOC
Credential access alert opens a ticket
Detected only if triaged before the next step
- Attacker
Objective reached
Holds a privileged account before triage
The verdict is decided by time, not by the rule
When the SOC catches the operators
A detection during the exercise is the best outcome the engagement can produce, and it needs a decision made in advance about what happens next. The SOC treats the alert as real, because to the analysts it is: they do not know the source, and the moment they are told, the measurement stops. Escalation runs up the incident process it would follow for any intrusion until it reaches someone in the control group, the small set of people who know the exercise is running and whose names are in the rules of engagement.
The control group then chooses one of three answers, and the choice is recorded with a timestamp. Let it run: the SOC's containment proceeds and the operators lose the foothold, which is the truest measurement of all. Deconflict: the SOC is told that this incident is the exercise, so real incidents are not starved of attention, and the step is still scored as detected with the time to that point. Reset: the operators are granted a fresh foothold to test the rest of the chain, in the manner of an assumed breach exercise, because a chain stopped at step two says nothing about steps three to eight.
What the decision must not do is depend on who is on shift. Write the three answers into the rules of engagement, with who is allowed to choose each, before the first email is sent.
Detection
SOC alert fires
The analysts do not know it is an exercise
Incident process runs
Ticket, triage and escalation as for any intrusion
Decision
Reaches the control group
The named people who know; nobody else is told
Let run, deconflict or reset
Chosen and timestamped, as the rules of engagement allow
Record
Scored as detected
With time to ticket and time to action
Chain continues or ends
A reset foothold tests the steps after the catch
Reconciling the operator log with the SOC's tickets
The detection gap analysis is built after the exercise from two records that were kept apart during it. The operators keep an attribution log: every action, its ATT&CK identifier, the host, the account and a timestamp to the second. The SOC keeps what it always keeps: alerts, tickets and the notes on them. Reconciliation places each line of the first against the second and asks what the SOC held at the moment the operators took their next step. NIST SP 800-115 treats that correlation as part of the analysis that follows a test rather than an optional extra, and here it is the whole product.
Written generically, as an example, two lines of a reconciliation read like the table below. The first is a step the sensor saw and the process lost. The second is a step no rule surfaced, which is the cheaper of the two to fix. The measurements that matter are in the middle columns: how long from the operator's action to a ticket, and how long from the ticket to a person acting, both set against the interval before the operators' next action.
Each logged-only and missed row becomes a detection to build, and the replay closes it: the operators repeat the step with the defenders watching until it fires, which is what a purple team session does by design. Then keep the rules working, because detection content built against one chain decays, as the piece on detection decay sets out.
| Operator action (ATT&CK) | SOC record | Time to ticket | Time to action | Verdict |
|---|---|---|---|---|
| Read cached credentials from memory (T1003), 10:42:15 | Endpoint alert at 10:42:20, ticket opened at 10:51 | 9 minutes | None before 11:30, by which point the operators held a privileged account | Logged only |
| Added an account to a privileged group (T1078), 11:14:03 | No alert. The change appears in the directory audit log and nothing surfaced it | None | None | Missed |
Where the SOC sits in Dubai and Abu Dhabi, and why it changes the rules of engagement
Whether the SOC is in-house or contracted changes who an alert reaches, and in the UAE that is a question for the contract as much as for the runbook. If a managed provider runs your monitoring, the control group needs a named person on their side as well as yours, or the provider's escalation ends at a phone nobody in your organisation answers at two in the morning. For an institution supervised by CBUAE, the detection gap analysis is the part of the pack that speaks to the monitoring expectation, and it does so in Dubai and Abu Dhabi alike, because the licence follows the institution rather than the office.
In Dubai, entities held to the DESC Information Security Regulation, and the suppliers holding their data, have monitoring controls that a logged-only column evidences as present and unattended. That is a more useful finding for an assessor than a missed column, because it points at the process rather than at procurement. In Abu Dhabi, healthcare providers under ADHICS and federal entities under the UAE Information Assurance Standards are answering a controls framework, and the same reconciliation evidences the monitoring family directly, step by step. Free-zone or mainland status changes your licensing and contracting, not the expectation attached to the data you hold. For UAE buyers in either emirate, the practical step is the same: put the control group, the provider's escalation contact and the three answers into the rules of engagement before the exercise starts.
Frequently asked questions
Should the SOC be told about a Red Team engagement?
The analysts should not. The exercise measures what they do when they believe an intrusion is real, and telling them stops the measurement. A small control group does know: named people in the rules of engagement who can receive an escalation, confirm the activity is the exercise, and decide whether to let containment run, deconflict, or reset the operators' foothold.
What happens if the SOC detects the Red Team?
The alert is handled as a real incident and escalated until it reaches the control group. The control group chooses one of three answers agreed in advance: let containment run and the operators lose the foothold, deconflict so the SOC can return to real work, or grant a fresh foothold so the rest of the chain can still be tested. The step is scored as detected, with the time to ticket and the time to action recorded.
What is a detection gap analysis in a Red Team report?
It is the document that sets the operators' attack path beside the SOC's own record and gives each step a verdict: detected, logged only, or missed. Each step is identified against MITRE ATT&CK so verdicts can be compared across years. It is built by reconciling the operators' timestamped log against the SOC's alerts and tickets, and it is the part of the pack that evidences whether monitoring produces something a person acts on.
What is the difference between detected and logged only?
Detected means an alert reached a person who acted before the operators took their next step. Logged only means an alert or a record was raised and nobody acted on it in time, so the sensor worked and the response path did not. Missed means nothing was raised at all. Logged-only steps are the ones to prioritise, because they are not fixed by adding a sensor.






