Red teaming is the practice of asking a trusted group of individuals to launch an attack on your software or your organization so that you can test how your defenses will hold up in a real-world situation. Any organization reliant on software – including banks, healthcare providers, government institutions, or logistics companies – is potentially vulnerable to cyberattacks, such as ransomware or data exfiltration.
For software providers, red teaming is an effective way to test the security of your product or service and protect your users from attacks made via your software in the future. A red team can either be an internal team or a third-party group of ethical hackers hired explicitly for the task.
The term “Red Team” originates from the military practice of using war games to challenge operational plans by testing how defenses perform against an intelligent adversary. The “Red Team” refers to the group playing the enemy role, whose job is to get past the defenses of the “Blue Team,” who represent the home nation.
In a cybersecurity context, the red team is a group of ethical hackers tasked with launching an attack. At the same time, the Blue Team refers to the security analysts, operations team, or software developers responsible for the system(s) under attack. Typically, the red team is tasked with a particular goal, such as accessing sensitive data, disrupting a service, or planting malware that will enable future attacks.
The red team’s only information about the system is what could be gleaned by an actual attacker. The Blue Team is not informed in advance of the attack and should treat any suspicious activity as a live situation and address it accordingly. The red team responds to any defensive measure by adapting their approach and persevering until they reach their goal or are routed by the Blue Team.
Once the attack is concluded, the red team reports their activities, including any vulnerabilities they found and any defenses that worked against them. This information is then used by the security team and/or software developers to strengthen their defenses for the future. The sharing of information from the red team following the exercise is an essential part of the process, turning the simulated attack into an opportunity to improve security operations.
In some contexts, you may come across the term “purple team,” referring to an amalgamation of red and blue teams. The aim of creating a purple team is to focus on sharing the tactics, techniques, and procedures used so that the security staff can learn from them. However, to run an effective simulation, it’s essential that the red team does not have insider knowledge that an attacker would lack, and the blue team reacts as they would in a real-world scenario. Equally, to get value from red team exercises, it’s essential that the red team shares their findings to improve security.
Although closely related, red teaming is not the same as penetration testing (aka pen testing). While both types of security testing are designed to assess whether an attacker could achieve a particular goal, their scope is different.
With a pen test, your security team would typically be made aware of the test before it takes place. The pen testers will work through multiple tactics to achieve the goal, recording any observations along the way.
Red teaming takes security testing a step further. Because the role of the red team is to emulate real attackers, the security team should be unaware of the details or timing of the attack. Furthermore, the red team will operate by stealth, seeking to evade detection and cover their tracks the same way an actual cybercriminal would work.
To make the simulated attack as accurate as possible, red teams go further than pure software testing and may use social engineering techniques and attempt to breach physical security to pursue their goal, just as an actual attacker would.
A red team’s attack will depend on what you’re trying to test – your organization, your software, or a combination of the two (as in the case of software-as-a-service providers). To emulate a real cyberattack, a red team may challenge:
In practice, these areas overlap, and a red team will often use tactics that cover some or all of these areas. For example, although your remote access protocols might defend your systems from network intrusion, weak building security combined with some simple social engineering could allow your red team (or a malicious actor) to gain entry to your offices and get their hands on an unattended employee laptop or connect their own device to an available network socket.
Once inside your network, they can use privilege escalation tactics to access critical systems. Having gained access, they will demonstrate how they could exfiltrate valuable data or plant malware that could be used to encrypt your files and demand a ransom.
While red teaming and pen testing are effective ways of testing your organization’s cyber defenses, they are not designed to provide you with an exhaustive list of all your security vulnerabilities. That’s the role of a vulnerability assessment.
Before you embark on red team testing, it’s vital to lay the groundwork with a detailed vulnerability assessment to identify, prioritize and address as many security flaws as possible. Findings might range from unpatched servers and default admin passwords to use of compromised third-party libraries or failure to sanitize user inputs.
Having addressed all known issues, it’s time to use a threat assessment to identify the highest risks to focus your testing accordingly. The type of cyber-attack you’re most likely to face will depend on your organization and industry.
The lowest level of attacks are those launched by individual opportunistic hackers using known exploits and off-the-shelf tools to see what they can find, from user account credentials to servers on which to deploy cryptocurrency miners.
More high-profile organizations and those with valuable assets are at higher risk from advanced attackers that will invest time in employing underhand tactics to deploy ransomware, steal sensitive information, or craft new exploits for your product or service. Finally, there are nation-state-sponsored attackers with vast resources at their disposal to select strategic targets.
Once you have put your security measures in place and have determined the types of risk you likely face, you can test your defenses with a pen test to check for more complex vulnerabilities. Having fixed all you can, it’s time to see how they stand up against a sustained assault via red teaming.
Ideally, red teaming should be an ongoing activity that continuously assesses your security posture. As changes are made to your systems or software, and new exploits are discovered, you must keep testing your defenses against realistic attack techniques.
An effective red team will adapt their tactics in response to your defenses, looking for any opportunity to gain access to your systems, which means they are well placed to find unanticipated ways.
Organizations that regularly use red teaming to challenge their security posture can use the findings from those exercises to strengthen their defenses, improve their ability to detect attacks early on, and limit any damage. By emulating all aspects of a likely attack, red teaming tests the ecosystem as a whole rather than just one element of it.
Sharing the results of a red team attack with your employees – mainly where social engineering formed part of the approach – can help minimize complacency and foster a security culture. Showing the impact of a seemingly insignificant breach is often far more compelling than a corporate training video.
Continuous red teaming also provides real-world metrics for your SOC team to measure their performance over time and provide valuable evidence to inform and justify investment in security enhancements.
The starting point for red team activities is to set out their terms of engagement. This should include details of anything that is expressly off-limits, describe how authority is given for an activity, agree on how personal and sensitive information will be handled, and detail the conditions for ceasing a red team attack.
Although your security team (the blue team) should be largely unaware of a red team engagement (including the planned date and time), it’s vital that someone in authority is aware of upcoming activities and can provide the necessary assurances – to both law enforcement and stakeholders – that their actions have been authorized. This is true whether the attack is against your organization or a software product – in the latter case, if you integrate with third-party providers, they should be notified that red teaming may occur.
Once terms are agreed upon, and a goal has been defined, the red team process can begin. This includes:
Once the process is complete, it’s over to the security team or software developers to start addressing vulnerabilities and updating procedures, ready for the next attack.
If you’re new to red teaming, various tools can help you get the most value out of this security testing activity.
The MITRE ATT&CK framework is a valuable resource for recording and analyzing the phases of an attack. As a red team, you can use the framework to identify strategies and document your approach for reporting after the event. As a Blue Team, identifying the tactics, techniques, and procedures used in an attack will assist you in identifying mitigations better to protect your organization or your software in the future.
MITRE Caldera is an open-source project from the creators of the ATT&CK framework, which you can use to automate elements of both a red team attack and a Blue Team response.
Finally, tools such as Vectr assist with planning and reporting on red teaming activities, including collecting metrics to assist you in measuring the performance of your defenses.
Red teaming provides the most realistic test of your systems’ and your organization’s defenses against a cyber attack. If your organization is responsible for user data or relies on software systems for day-to-day running, you’re vulnerable to ransomware and data exfiltration attacks. If you’re developing software, verifying the security of your products and services is essential to protect your users from attacks that exploit your system. To get the most out of red teaming, make it an ongoing practice and ensure all findings are shared and acted upon.