Where do the terms “red” and “blue” come from?
The red vs blue concept comes directly from military wargaming. In military simulations, the enemy is traditionally the Red Force: its role is to attack, infiltrate, and emulate the objectives of an opposing adversary. Opposing it is the Blue Force, the defending side, tasked with protecting territory, detecting Red Force activity, and neutralising attacks.
These clearly defined roles proved so effective for testing and improving military strategy that the cybersecurity field adopted them, and the same logic now underpins how organisations validate their own defences through penetration testing and structured attack simulations.
The red team: thinking like the attacker
The red team consists of offensive security experts, also known as ethical hackers, who adopt the mindset of an attacker. Their working principle is simple: a chain is only as strong as its weakest link, and their job is to find that link.
The main goal of a red team is not merely to “hack” something. It is to simulate the tactics, techniques and procedures (TTPs) of real malicious actors, in order to test and attempt to bypass an organisation’s defences. A red team engagement aims to answer questions such as: what are the possible attack vectors, and what is the likelihood of a successful attack?
What tactics does a red team use?
- Social engineering: phishing and spear-phishing simulations, vishing (voice-based social engineering), or attempts to gain physical access to a building. These simulations are often part of broader employee awareness programmes.
- OSINT (Open Source Intelligence): searching the internet, public data sources and social media for information about a company, its employees and its technology stack.
- Penetration testing, external and internal: authorised attempts to breach systems, typically starting externally (public websites or servers). If a breach succeeds, the red team then focuses on lateral movement and privilege escalation to reach an organisation’s most valuable assets, its “crown jewels”.
- System exploitation: detecting unpatched systems or unknown vulnerabilities and attempting to exploit them.
A red team engagement ends with a detailed report that does not just list vulnerabilities: it demonstrates how those weaknesses could be exploited to cause real damage.
The blue team: defending the organisation
The blue team is the defensive backbone of any cybersecurity strategy. Anyone who has worked with firewalls, antivirus solutions or security monitoring tools has already touched blue team activity.
The blue team’s mission is to protect the organisation. It hardens systems and monitors networks for suspicious activity around the clock. When a potential incident is detected, it responds quickly to limit damage and stop lateral movement.
What tactics does a blue team use?
- Detection and monitoring: managing and monitoring tools such as SIEM (Security Information and Event Management) and EDR (Endpoint Detection and Response) to spot anomalous or malicious behaviour.
- Incident response (IR): maintaining detailed playbooks for when things go wrong: who does what during a ransomware attack, how the threat is contained, and how recovery is handled.
- Hardening: ensuring systems are configured securely, patches are applied promptly, and networks are locked down.
- Threat hunting: proactively scouring logs, endpoints and network traffic for traces of intrusions or suspicious behaviour, rather than waiting passively for an alert.
Purple teaming: what happens when red and blue work together?
A blue team that is never properly tested can develop a false sense of security: it may invest in expensive tools while assuming it is protected, without knowing whether its SIEM would actually detect an advanced attack. A red team operating alone often delivers a report that ends up in a drawer: it demonstrates that the house could burn down, but nobody installs the smoke detectors or rehearses the evacuation plan.
Genuine cyber resilience is achieved when the two work together, a collaboration usually called purple teaming. It is not a separate team but a process: the red team launches an attack, the blue team attempts to detect it in real time, and immediately afterwards both sides review what happened together. The red team explains which technique gave it access; the blue team explains what it did or did not see, and adjusts its detection rules accordingly.
This direct feedback loop is one of the fastest ways to make an organisation more cyber-resilient, because it tests the technology, the processes and the people behind them at the same time.
Why Approach Cyber now delivers both
Historically, AXS Guard’s focus was on defence: building and hardening the fort. Following the merger with Approach Cyber, that fort is now also tested from the outside by ethical hackers, through penetration testing and broader offensive security services. Combining red team and blue team capability under one roof means an organisation’s defences are not only built, but continuously verified against real attacker behaviour.
If you want to understand where your organisation stands, on either side of the fence, talk to an expert about your penetration testing needs or explore how a security operations centre keeps you defended around the clock.
FAQ: red team, blue team and penetration testing
What is the difference between a red team and a blue team?
A red team simulates real attacks to find weaknesses, while a blue team defends the organisation by detecting and responding to threats. One tests; the other protects.
Is penetration testing the same as a red team engagement?
Penetration testing is one of the tactics a red team uses. A red team engagement is typically broader, combining social engineering, OSINT and system exploitation alongside penetration testing.
What is purple teaming?
Purple teaming is not a separate team but a collaborative process in which the red team and blue team work together in real time, sharing findings immediately to improve detection.
How often should an organisation run a penetration test?
This depends on the organisation’s risk profile, regulatory obligations and how frequently its systems change. Talk to our team to define a testing cadence that fits your context.