Top tips for CISOs running red teams – Source: www.csoonline.com

Red team is the de facto standard in offensive security testing when you want to know how all security investments — from technological controls to user training to response procedures — work together when subjected to a targeted attack. Unlike penetration testing, which aims to comprehensively assess a system, or purple team, which assesses detection and response capabilities, the purpose of a red team is to find attack paths from an initial beachhead to your crown jewels.

Though red team exercises have matured greatly over the past decade, many executives have a hard time extracting as much value out of the red team as they’d like. Here are some of the guiding principles I advise security leaders to follow through the process, from planning to remediation, to get the most out of their red team engagements.

Be generous with scope

The number one thing that I see go wrong with red teams is an overly restrictive scope. This problem emerges during the planning phase when the person in charge of defining which systems, users, and networks are out of scope ends up restricting the attack path the red team can use. This leads to an unrealistic engagement, skewed results, and an underleveraged team. While there are many reasons why this happens, there tend to be two primary ones: distrust in the red team or fear. Both lead to the desire to control the situation, which usually manifests itself as reducing scope to exclude all things that could potentially be viewed as risky.

Instead, leaders should default to a completely open scope and remove only the systems that would cause significant harm to the organization in the unlikely event that they were to go offline because of testing. Things like manufacturing systems, systems related to SWIFT for financial institutions, or high-frequency trading infrastructure all fall into this category.

To allow for restrictive systems to be removed from scope without artificially hindering the engagement, one of the things that I’ve seen work extremely well is using checkpoints that prove that the red team could access the sensitive systems without requiring them to directly touch them. An example of this would be if the red team could compromise a user account that can authenticate to the sensitive system and prove that the credentials were valid.

Remember, adversaries don’t care about your scope.

Embrace creativity

This one may be a bit controversial, but if you are constraining your red team to rigidly emulate a specific threat actor or campaign, you are almost certainly not getting the most value out of your engagements. On paper, adversary emulation (i.e., making your engagement reflect the TTPs leveraged by a threat actor of concern) makes a ton of sense as you’re focusing your efforts on what you know has been observed in the wild. 

There are many logical flaws inherent to this approach, ranging from issues with the known-known nature of threat reporting to faulty assumption that adversaries can’t vary their tradecraft. I’d argue that situations where you want to replay a threat actor’s specific behavior are better suited by using a BAS tool. Ultimately, this has the same net effect as the problem described in the previous section, but this time restricting the techniques which can be used rather than what can be targeted. This ends up stifling your team’s creativity, leading to a less effective engagement that results in poorer understanding of your security posture than you otherwise would have been able to gain. When you impose artificial restrictions on the team, you prevent them from coming up with novel ways of chaining techniques together with their understanding of the environment and business and remove their ability to capitalize on new opportunities that may emerge during an engagement. 

If threat-centric testing is a focus of your security program, try either using other projects to emulate the specific behaviors of a threat (such as a purple team that focuses their testing on just the relevant techniques of the threat) or by using the threat report to guide the planning of the red team engagement rather than constraining them to only what was described.

One example of how the latter might be done would be to use only the macro points from the threat report. For instance, a reasonable engagement could be planned using a threat report that describes some relevant threat actor who compromised Windows workstations belonging to users in the financial department, established persistence, and then began searching for sensitive file shares and exfiltrating data to an AWS instance. This doesn’t constrain the team to what specific persistence mechanism they have to use, or which type of file share they must target, leaving them space to be creative but still tying the overall theme to a threat that you may be asked about by the board or your boss.

Assume breach

One of the biggest structural failures I saw during my time in red teams was when customers required the team to gain their own initial access as a requirement to begin assessing the internal network. This was incredibly frustrating to see, not because it was particularly difficult, but because it just isn’t a good use of anyone’s time. You must decide if you would rather spend five weeks of your six-week engagement having the team phish your users or exploring attack paths to help determine risk and close holes.

I firmly believe that red teams are best suited to answer the question of what happens after an adversary has breached the perimeter. This doesn’t mean that they are incapable of performing an initial access assessment, but rather that they’re better suited for a different task. Assessing the perimeter is virtually always better run as a separate project due to the time and resources required to effectively measure susceptibility.

A smart way I’ve seen CISOs structure their red teams where they need to assess initial access vectors is to cede access to a system so that a portion of the team can begin the path finding portion of the engagement while another contingent can perform the initial access component, rejoining the group when/if they complete that stage. I’ve seen more mature organizations break these engagements out into entirely separate projects, sometimes chaining them together to tell a story. One of my favorite examples of this was a financial organization that ran two initial access projects — phishing and external attack surface exploitation — concurrently for eight weeks. The results from these engagements, which included the users who detonated the phishing payload and the external systems on which the team had gotten code execution, became the beachheads onto which access for the red team was ceded.

Keep egos out

The debrief at completion of a red team engagement can often be very tense. The red team has likely revealed serious failures along their attack path and you have all responsible parties sitting around a table, or on a call hearing about them, often for the first time. Why didn’t your SOC detect their lateral movement? Why did your identity team turn MFA off for your enterprise admins? Why did your security engineering team fail to deploy your EDR onto all hosts in the environment? It becomes all too easy to begin pointing fingers and assigning blame, leaving everyone upset, flustered, and embarrassed. 

Remember, however, that a friendly team just found serious flaws before an adversary did and you get the opportunity to fix it. Focus on creating an environment of honesty, humility and empathy. This isn’t to say that people won’t still feel negative emotions, but the tone of the conversation from the outset will significantly improve the quality of the discussion.

Your job as a security leader is to make sure that the discussion is focused on the problems identified, not the individuals involved. If the conversation does start to become defensive or argumentative, take a moment to remind the group that you’re attacking the problem together as a team and that the red team has found the issues before something bad actually happened. Eventually, this will become ingrained in your culture and others in the group will start passing this approach down, allowing it to permeate your organization.

Foster collaboration

When a red team is isolated, they often become viewed as outsiders that only bring bad news and end up being treated as adversaries rather than partners. This is why it is paramount that your red team spend a sizable portion of their time working with other teams in the security organization and across the business. 

Successful red teams have great relationships with their stakeholders, including those who own the systems that the red team targets in their operations. The most valuable engagements that I ever worked on were ones where I got to sit with the SOC after the engagement and help them build detections for the techniques that we used. The relationships and goodwill built during the remediation process saved us during dicey situations and made us more empathetic to the team’s workload.

Red teams should be missionaries, not mercenaries, within the security organization. If your red team isn’t working directly with their engagement stakeholders already, start there. Encourage red teamers to form personal relationships with the SOC. Take them out to lunch or spend a week together every quarter working on a project, or even stand up a rotation program where the teams swap representatives for a few weeks to help foster empathy and keep things fresh.