The detection you need before a Red Team is worth buying

Noticing is five conditions, not one

The question a Red Team engagement answers is whether an intrusion would be seen and stopped. That single question hides five conditions stacked in series, and a failure at any one of them produces the same outcome: silence.

The event has to be generated by the system. It has to be collected off that system and shipped somewhere. It has to still be there when someone looks. Something has to raise it to a human. And that human has to be able to act on it, at the hour it fires.

Estates that fail an exercise usually fail on the first two conditions or on the last one. Detection rules are rarely the weak link, which is why buying a rule pack rarely changes the result. Work through the five in order. Anything else is tuning alerts on data you do not have.

The telemetry floor

Process creation with the full command line is the highest-value source on a Windows estate, because most post-exploitation activity is a process with an unusual parent and a revealing argument list. Windows Security event 4688 carries the command line only when command line auditing is explicitly enabled, which it is not by default. Sysmon event 1 carries it as installed. If you turn on one new thing this quarter, turn on this.

Identity events come next: successful and failed authentication, Kerberos ticket requests, account creation, changes to group membership. Lateral movement and privilege escalation appear here first, in ordinary-looking events whose value comes from sequence and volume rather than from any single entry looking suspicious.

Then egress. DNS queries and proxy or firewall records tell you where the estate is talking, which is the practical way to see command and control traffic that is otherwise shaped to look like everything else. Cloud control plane audit logs belong in the same tier, because in a hybrid estate the interesting privilege escalation increasingly happens through an API call rather than a login.

One coverage gap is worth naming on its own: endpoint agents rolled out to laptops but not to servers. Domain controllers, jump hosts and build servers are exactly where an operator goes, and exactly where the agent is most often missing because of a change freeze that was never revisited.

Retention is a detection control

Real intrusions are discovered late. When the alert finally fires, or a third party tells you, the useful question is what happened before it, and the answer lives in logs whose retention window you set months ago without thinking of it as a security decision.

If process and authentication telemetry is kept for a week, an investigation that starts on day ten cannot establish initial access, cannot scope the compromise, and cannot state with any confidence that it is over. The output is not a finding. It is a shrug, delivered to a board. That is expensive to discover during an incident and cheap to discover now.

Set retention against the time you would plausibly take to notice, not against the storage quote. Tiering makes the number affordable: keep the high-volume sources searchable for weeks and archived for a year, rather than dropping them at the point of collection where they cannot be recovered at all.

Pick coverage by technique, not by product

Vendors describe coverage in terms of their own features. That framing cannot be used for planning, because it never tells you which attacker behaviour remains invisible. Map against a public technique catalogue such as MITRE ATT&CK instead, and record three honest states per technique: alerted, logged but not alerted, and not collected at all.

You do not need all of it. A small set of behaviours sits on the path of almost every intrusion: credential material read out of LSASS, remote service creation and remote execution, persistence through scheduled tasks and services, built-in administration tooling used from places it has no business running, and one account touching file shares at a rate no person would. Cover those properly before widening the map.

The middle state deserves its own column, because it is the cheapest thing on the list to improve. The data is already collected and already paid for. What is missing is a rule and a name against it.

An alert nobody acts on is not a detection

Detection ends at a decision, not at a dashboard. That requires a named route from alert to human, a stated expectation of how quickly that human looks, and clear authority to isolate a host or disable an account without first convening a meeting.

Test the route rather than assuming it. Ask who receives a high severity alert at three in the morning on a Friday, what they are permitted to do on their own signature, and how long it takes them to reach somebody who can approve the rest. Ask what happens when the alert concerns a system owned by a team outside the security function. The gap is almost always authority and out of hours cover, not tooling.

None of this costs money to specify, and it moves the result of an exercise further than any rule change will.

How to check before you buy anything

Everything above can be measured without an engagement. Take a handful of the techniques in the coverage list, run them on a host you control, in daylight, with the security team told in advance, and follow each one through the five conditions: generated, collected, retained, alerted, actioned. Write down where it stopped. Open source atomic test libraries exist for this and are safe to run on a lab host.

What comes back is a short list of gaps that configuration and rule writing can close, rather than a budget request. Repeat the pass after each fix. The exercise is worth running quarterly whether or not you ever hire anyone, because coverage decays quietly as systems are rebuilt and agents fall off them.

When that list stops producing surprises, an external exercise starts being worth its price, because the answer is no longer known before it begins. Purple teaming is the efficient next step if you want the remaining detections built alongside your team rather than described to it. An assumed breach exercise is the cheapest way to see how far an intruder actually reaches once the obvious gaps are shut. A full Red Team engagement is worth buying at the point where you have a defensible answer to whether you would notice, and you want it tested rather than assumed.

Why this matters for the UAE market

Four regulatory regimes in the UAE name security testing, and they do not ask for the same thing. CBUAE binds licensed financial institutions wherever they sit. DESC binds Dubai government entities and the suppliers who serve them. ADHICS binds healthcare in Abu Dhabi. The UAE Information Assurance Standard, published by NESA, sits federally over critical national infrastructure. An organisation in Dubai and an organisation in Abu Dhabi can therefore be told to do adversarial testing by completely different authorities, on different timetables, with different evidence expectations.

The practical effect is that engagements get bought to satisfy a clause rather than to answer a question. A Dubai entity reads a requirement for a Red Team exercise and buys one, with no telemetry in place to measure it against, and receives a report confirming that an attacker got in and nobody noticed. That was knowable in advance and the budget is gone.

Testing the floor first is what changes that. If more buyers in Dubai and Abu Dhabi asked the four questions in this article before signing, the market would shift spend from exercises that document a gap to work that closes one, and the reports landing on regulators' desks would start describing capability instead of absence. That is a better outcome for the buyer, for the examiner, and for the standard of security work sold in the Emirates.

Frequently asked questions