Red teaming

What is red teaming?

Red teaming is a covert, objective-driven attack simulation. The red team gets a goal (“obtain domain admin”, “read the recipe database”, “send a command to a field device”) and a time frame of several weeks, then uses whatever a real adversary would: phishing, physical access, stolen credentials, vulnerabilities in exposed systems, lateral movement inside the network. Only a small control group (the white team) knows the exercise is running. The defenders, the blue team or SOC, are measured on whether and how fast they detect and contain it.

NIST defines a red team as a group authorised and organised to emulate a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture. The emphasis is on emulation and posture: the question is not “which vulnerabilities exist” but “would we notice and stop an attacker”.

Where is it defined?

The most concrete definitions come from the financial sector. TIBER-EU, published by the European Central Bank, describes threat-intelligence-based ethical red teaming with its phases (preparation, testing, closure), its roles (white team, threat intelligence provider, red team provider) and its deliverables. DORA, Regulation (EU) 2022/2554, makes threat-led penetration testing mandatory for designated financial entities at least every three years (Article 26), and the technical standards for it build on TIBER-EU. MITRE ATT&CK is the shared vocabulary for the tactics and techniques that are used and detected.

Outside finance, NIS2 does not mention red teaming by name. Article 21(2)(f) asks for procedures to assess the effectiveness of the security measures, and a red team exercise does that better than any audit.

What it means in practice

A red team exercise pays off when you already have detection in place. Three observations from engagements:

• It measures the SOC, not the firewall. The deliverable is a timeline: when the red team did what, what the blue team saw, how long until containment. If nobody is watching, the result is known in advance and a penetration test is the better use of the budget.
• The objective shapes everything. “Reach the engineering network” leads to a very different exercise than “exfiltrate customer data”. Choose objectives from your own risk analysis, not from a template.
• Rules of engagement are the safety net. Which systems are out of bounds, when to stop, how to deconflict with a real incident, who can abort. In OT environments the rules are strict: the red team shows that it could reach the controller, it does not write to it.

Zyberum runs red team exercises for IT environments and, with adapted rules, for production networks and vehicle fleets. Every exercise needs written authorisation from the management body, not just from the IT department.

Common misunderstandings

Red teaming is not a bigger penetration test. A pentest covers a scope broadly and reports all findings; a red team takes the one path that works and stays quiet. Doing a red team exercise before the first pentest wastes money: the team will walk in through a bug a pentest would have found in a day. It is also not purple teaming, where red and blue work together openly to tune detections; that is a useful follow-up, not the same thing.