RedTeam
Red Teaming for Cybersecurity
Understanding Red Teaming
Red teaming is the process of providing a fact-driven adversary perspective as an input to solving or addressing a problem.1 For instance, red teaming in the financial control space can be seen as an exercise in which yearly spending projections are challenged based on the costs accrued in the first two quarters of the year. In the cybersecurity context, red teaming has emerged as a best practice wherein the cyberresilience of an organization is challenged by an adversary’s or a threat actor’s perspective.
This is a powerful means of providing the CISO a fact-based assessment of an organization’s security ecosystem. Such an assessment is performed by a specialized and carefully constituted team and covers people, process and technology areas. As a result, CISOs can get a clear understanding of how much of the organization’s security budget is actually translated into a concrete cyberdefense and what areas need more attention. A practical approach on how to set up and benefit from a red team in an enterprise context is explored herein.
Why Invest in Red Teaming?
An organization invests in cybersecurity to keep its business safe from malicious threat agents. These threat agents find ways to get past the enterprise’s security defense and achieve their goals. A successful attack of this sort is usually classified as a security incident, and damage or loss to an organization’s information assets is classified as a security breach. While most security budgets of modern-day enterprises are focused on preventive and detective measures to manage incidents and avoid breaches, the effectiveness of such investments is not always clearly measured. Security governance translated into policies may or may not have the same intended effect on the organization’s cybersecurity posture when practically implemented using operational people, process and technology means. In most large organizations, the personnel who lay down policies and standards are not the ones who bring them into effect using processes and technology. This contributes to an inherent gap between the intended baseline and the actual effect policies and standards have on the enterprise’s security posture. Cyberthreats are constantly evolving, and threat agents are finding new ways to manifest new security breaches. This dynamic clearly establishes that the threat agents are either exploiting a gap in the implementation of the enterprise’s intended security baseline or taking advantage of the fact that the enterprise’s intended security baseline itself is either outdated or ineffective. This leads to the question: How can one get the required level of assurance if the enterprise’s security baseline insufficiently addresses the evolving threat landscape? Also, once addressed, are there any gaps in its practical implementation? This is where red teaming provides a CISO with fact-based assurance in the context of the active cyberthreat landscape in which they operate. Compared to the huge investments enterprises make in standard preventive and detective measures, a red team can help get more out of such investments with a fraction of the same budget spent on these assessments.
Scoping the Red Team
The most critical aspect of scoping a red team is targeting an ecosystem and not an individual system. Hence, there is no predefined scope other than pursuing a goal. The goal here refers to the end objective, which, when achieved, would translate into a critical security breach for the organization. People, process and technology aspects are all covered as a part of this pursuit. How the scope will be approached is something the red team will work out in the scenario analysis phase. It is imperative that the board is aware of both the scope and anticipated impact.
At this stage, it is also advisable to give the project a code name so that the activities can stay classified while still being discussable. Agreeing on a small group who will know about this activity is a good practice. The intent here is not to inadvertently alert the blue team and ensure that the simulated threat is as close as possible to a real-life incident. The blue team includes all personnel that either directly or indirectly respond to a security incident or support an organization’s security defenses. In the present cybersecurity context, all personnel of an organization are targets and, therefore, are also responsible for defending against threats. The secrecy around the upcoming red team exercise helps maintain the element of surprise and also tests the organization’s capability to handle such surprises. Having said that, it is a good practice to include one or two blue team personnel in the red team to promote learning and sharing of knowledge on both sides.
Developing Red Team Scenarios
Simply put, this step is stimulating blue team colleagues to think like hackers. The quality of the scenarios will decide the direction the team will take during the execution. In other words, scenarios will allow the team to bring sanity into the chaotic backdrop of the simulated security breach attempt within the organization. It also clarifies how the team will get to the end goal and what resources the enterprise would need to get there. That said, there needs to be a delicate balance between the macro-level view and articulating the detailed steps that the team may need to undertake. In most cases, the scenario that was decided upon at the start is not the eventual scenario executed. This is a good sign and shows that the red team experienced real-time defense from the blue team’s perspective and was also creative enough to find new avenues. This also shows that the threat the enterprise wants to simulate is close to reality and takes the existing defense into context.
While brainstorming to come up with the latest scenarios is highly encouraged, attack trees are also a good mechanism to structure both discussions and the outcome of the scenario analysis process. To do this, the team may draw inspiration from the methods that have been used in the last 10 publicly known security breaches in the enterprise’s industry or beyond. Figure 1 is an example attack tree that is inspired by the Carbanak malware, which was made public in 2015 and is allegedly one of the biggest security breaches in banking history.
Execution Phase of a Red Team
This is perhaps the only phase that one cannot predict or prepare for in terms of events that will unfold once the team starts with the execution. By now, the enterprise has the required sponsorship, the target ecosystem is known, a team is set up, and the scenarios are defined and agreed upon. This is all the input that goes into the execution phase and, if the team did the steps leading up to execution correctly, it will be able to find its way through to the actual hack. The skill and experience of the people chosen for the team will decide how the surprises they encounter are navigated. Before the team begins, it is advisable that a “get out of jail card” is created for the testers. This artifact ensures the safety of the testers if encountered by resistance or legal prosecution by someone on the blue team. The get out of jail card is produced by the undercover attacker only as a last resort to prevent a counterproductive escalation.
Reporting Red Team Findings
Unlike a penetration test, the end report is not the central deliverable of a red team exercise. The report, which compiles the facts and evidence backing each fact, is certainly important; however, the storyline within which each fact is presented adds the required context to both the identified problem and suggested solution. A perfect way to find this balance would be to create three sets of reports.
The Storyline
The storyline describes how the scenarios played out. This includes the moments in time where the red team was stopped by an existing control, where an existing control was not effective and where the attacker had a free pass due to a nonexistent control. This is a highly visual document that shows the facts using pictures or videos so that executives are able to understand the context that would otherwise be diluted in the text of a document. The visual approach to such storytelling can also be used to create additional scenarios as a demonstration (demo) that would not have made sense when testing the potentially adverse business impact. An example of such a demo would be the fact that a person is able to run a whoami command on a server and confirm that he or she has an elevated privilege level on a mission-critical server. However, it would create a much bigger impact on the board if the team can demonstrate a potential, but fake, visual where, instead of whoami, the team accesses the root directory and wipes out all data with one command. This will create a lasting impression on decision makers and shorten the time it takes to agree on an actual business impact of the finding.
Standard Report With Findings and Recommendations
The second report is a standard report very similar to a penetration testing report that records the findings, risk and recommendations in a structured format. This report is built for internal auditors, risk managers and colleagues who will be directly engaged in mitigating the identified findings.
Purple Teaming Report With Event and Technical Logs
The third report is the one that records all technical logs and event logs that can be used to reconstruct the attack pattern as it manifested. This report is a great input for a purple teaming exercise. Purple teaming is the process in which both the red team and blue team go through the sequence of events as they happened and try to document how both parties viewed the attack. This is a great opportunity to improve skills on both sides and also improve the cyberdefense of the organization.
Learn, Improve and Red Team Again
To learn and improve, it is important that both detection and response are measured from the blue team. Once that is done, a clear distinction between what is nonexistent and what needs to be improved further can be observed. This matrix can be used as a reference for future red teaming exercises to assess how the cyberresilience of the organization is improving. As an example, a matrix can be captured that measures the time it took for an employee to report a spear-phishing attack or the time taken by the computer emergency response team (CERT) to seize the asset from the user, establish the actual impact, contain the threat and execute all mitigating actions. These matrices can then be used to prove if the enterprise’s investments in certain areas are paying off better than others based on the scores in subsequent red team exercises. Figure 2 can be used as a quick reference card to visualize all phases and key activities of a red team.
