Red teaming is an objective based attack simulation that tests whether people, process and technology together can detect and stop a realistic adversary, not whether a system has an exploitable flaw. A red team exercise succeeds or fails on one question: did the target notice, and how fast.
- Red teaming and penetration testing answer different questions. Most engagements sold as "red team" in the UAE are scoped and briefed like the latter.
- A red team only proves something when it is objective led against a real business impact: fund transfer fraud, data exfiltration, disruption of a core system.
- The exercise measures detection and response time, not the number of findings.
- The most common failure is treating it as a compliance artefact instead of a live test of the SOC.
Red teaming versus penetration testing versus vulnerability assessment
These three get used interchangeably in UAE procurement documents and they should not. A vulnerability assessment is broad and mostly automated: scan everything in scope, list what is exploitable in theory, prioritise by severity. A penetration test narrows to a system or app, runs inside an agreed window, and proves specific vulnerabilities are exploitable. Both are announced.
Red teaming starts from a business impact objective rather than a system boundary, uses whichever path a real adversary would use (phishing, credential reuse, an exposed VPN portal, a misconfigured cloud bucket, a weak vendor connection), and runs blind or double blind so the SOC's actual response gets tested along with the technical controls. A penetration test asks "can this be broken into." A red team asks "if this is broken into, does anyone notice, and what happens next."
Why the label gets misused
Much of what gets called red teaming in the region is an internal network penetration test with a new name on the statement of work: scope fixed to a subnet, the SOC briefed in advance as a "white team," a three to five day window set by the budget. None of that is wrong as a penetration test. It is just not a red team, and calling it one gives a board false confidence that detection has been tested.
What decides whether it functions as a red team
- Objective, not coverage. Scope should define a handful of business impact scenarios (fund transfer, a data store, an availability target) rather than a list of IP ranges to sweep.
- A realistic initial access vector is permitted. Excluding phishing, physical access, or credential reuse means the exercise cannot test how most intrusions start.
- Blind or double blind execution. A SOC that knows an exercise is live pays closer attention than during a real incident, which makes the numbers dishonest.
- Enough time to behave like a real adversary. Intrusions unfold over days or weeks. A three day sprint changes what gets caught.
- Threat intelligence shaping the plan. Techniques should reflect what targets financial services regionally: credential phishing, business email compromise, ransomware affiliates moving laterally after a foothold, and abuse of vendor connections into the core network.
Where these engagements typically fail in practice
Segmentation between the corporate network, the DMZ, and the core banking or payment environment is usually flatter than the network diagram claims. One compromised laptop with domain credentials often reaches further than the architecture review said it should, and that gap only shows up once a red team is allowed to actually pivot instead of stopping at the first finding.
The highest impact objectives, fund transfer, SWIFT connectivity, card issuing platforms, are routinely carved out of scope as too sensitive to touch. That is understandable risk management, and it also means the exercise never tests what the board cares about most. If the crown jewel cannot be touched directly, test the path to it and stop short of a live transaction.
Findings get closed on paper without a retest, and detection rules drift: one that fired during the exercise gets disabled months later during unrelated SIEM tuning, unnoticed until the next engagement. The SOC is briefed in advance often enough that "we detected it" really means "we were told what to watch for."
What good scoping and rules of engagement include
A rules of engagement document that is doing its job covers: objectives and the business impact each maps to, permitted and excluded techniques (denial of service, social engineering against named individuals, physical entry), an escalation path if production availability is at risk, legal sign off, and a data handling clause stating proof of access is sufficient evidence, not the data itself. Two details matter most: someone senior enough to authorise the test in writing, and a clear, agreed definition of "detected" before the exercise starts.
Red team, purple team, or continuous validation
These are complementary, not competing. A full red team engagement earns its cost once a SOC is established and the question is whether it holds up against a realistic adversary end to end. It is episodic: expensive and disruptive to run properly, not something to repeat every quarter.
A purple team exercise suits building or tuning detection collaboratively rather than testing it blind: attacker and defender work side by side, closing gaps faster and more cheaply, but it will not show whether the SOC would have caught the same thing alone.
Continuous attack validation platforms fill the gap periodic testing leaves open, replaying known techniques on a schedule and flagging when a control that passed last quarter has quietly stopped working. Pentera is one vendor here, and it complements rather than replaces a human led red team, since it cannot improvise around an unexpected response the way a live operator does.
What assessors and boards actually ask to see
Regulatory examiners and internal audit in the UAE increasingly ask harder questions than whether a red team was done: objectives tied to business risk, detect and contain times measured against the SOC's own targets, evidence findings were retested after remediation rather than closed in a ticket, and a signed rules of engagement on file. Tracking SOC metrics like time to detect and contain outside the exercise, not just inside it, turns a one-off report into evidence of a functioning programme.
Getting the next engagement right
- Write objectives before scope, and let the technical scope follow from two or three business impact scenarios.
- Do not brief the SOC in advance. Testing detection honestly means the people being tested cannot know the test is live.
- Allow a real initial access vector. A red team starting inside the network with no phishing or credential entry tests only half the problem.
- Budget for a retest, not just a report. A finding never replayed against the fix might still be open.
- Decide up front if this is a red team, a purple team, or both, and stop calling a pentest a red team.
