Red team or pentest: which do you need?
A pentest finds as many weaknesses as possible. A red team tests whether you can stop a real attack.
- A pentest is broad: find as many weaknesses as possible in a defined scope.
- A red team is narrow and deep: pursue objectives undetected, to test detection and response.
- Start with pentests; move to red teaming when you have defenders to test.
- Purple teaming turns what a red team finds into working detection.
Penetration tests and red team engagements both involve skilled people attacking your systems, so they are easy to confuse. They answer different questions, and choosing the wrong one wastes money in both directions.
Different goals
A penetration test is broad. Within a defined scope, testers try to find as many vulnerabilities as they can and show the impact of each one. Success is a thorough list of findings, with evidence and fixes.
A red team engagement is narrow and deep. Testers pursue specific objectives, such as reaching customer data or a payment system, the way a real adversary would, while trying to avoid detection. It tests your people, processes and monitoring as much as your technology. Success is learning whether, when and how your defenders would notice and respond.
| Aspect | Penetration test | Red team engagement |
|---|---|---|
| Goal | Find as many weaknesses as possible | Reach objectives undetected, to test detection and response |
| Scope | Defined systems or applications | The organisation, within agreed rules of engagement |
| Who knows | Usually the security team | A small control group; defenders are not told |
| Duration | Days to a few weeks | Weeks to months |
| Output | Findings with evidence and fixes | An attack narrative, objectives reached and detection gaps |
What a red team engagement involves
Engagements vary, but most move through the same stages:
- Planning: objectives, the starting scenario, rules of engagement and authorisation
- Reconnaissance: learning about the organisation, its people and its exposed systems
- Initial access: a foothold, through phishing, an exposed service or a supplied starting point
- Moving towards the objective: escalating privileges and moving laterally, while avoiding detection
- Reaching the objective: demonstrating access to the agreed target, safely
- Reporting and debrief: the attack narrative, what was detected and when, and what to improve
An assumed breach scenario starts the engagement inside the network, as if an attacker already had a foothold. It saves weeks of initial access work and spends the budget on what matters most: whether defenders notice an attacker who is already in.
When a pentest is the right choice
- You have not had independent testing before, or not recently
- You are launching or significantly changing a system
- A customer, an auditor or a standard requires it
- You want to find and fix as many weaknesses as possible in a specific system
When a red team is the right choice
- You have a detection and response capability, such as a SOC or a managed detection service, and want to know whether it works
- Regular pentests are finding fewer serious issues, and you want to test the organisation as a whole
- Your board wants to know whether a determined attacker could reach what matters most
A red team engagement against an organisation without basic hygiene or monitoring mostly confirms what a pentest would have found for less. Start with pentests, fix what they find, and move to red teaming when there are defenders to test.
Measuring the result
A red team report should answer questions that a pentest report does not:
- Were the objectives reached, partly reached or blocked?
- Which actions were detected, by what, and how quickly?
- How did the response team react, and how long did containment take?
- Which detection gaps would a real attacker use next time?
Purple teaming
Purple teaming puts attackers and defenders in the same room. Techniques are run openly, one at a time, and the defenders tune their detection as they go. It is often the most valuable follow-up to a red team engagement, because it turns the detection gaps the red team found into alerts that work.
Planning a red team safely
Red team engagements need more preparation than a pentest:
- Objectives agreed with the sponsor, and a starting scenario, such as an external attacker or an assumed breach
- Written authorisation and rules of engagement, including what is off limits
- A control group who know the engagement is running and can stop it
- Approval points before risky steps, such as moving into production systems
Red team engagements in Cerberos Nexus
Red team engagements in Cerberos Nexus keep the objectives, starting scenario, authorisation, rules of engagement and attack plan in one record. Activity is mapped to MITRE ATT&CK techniques, risky steps wait for approval, and findings are reviewed before someone other than their author publishes them. Pentests run alongside, so a client can follow both in one portal. See how red team engagements run in the platform.