Are you reluctant to apply red teaming? Don't you know what it is and what its value is for the cybersecurity of your organization?
We built this blog post from the book Tribe of Hackers Red Team by Carey and Jin (2019). We wanted to take as a fundamental pillar just one of the many questions asked there to several red teaming experts: "How do you explain the value of red teaming to a reluctant or nontechnical client or organization?" Having already written blog posts on the opinions of five professionals appearing in that book (i.e., Carey, Donnelly, Weidman, Secor, and Perez), we discarded their answers to that question here. And we did the same with others that we didn't find sufficiently meaty or relevant. Ultimately, we used the responses of 33 experts. We hope that what we have put together here will help you change your mind or broaden your horizons on red teaming, especially if your answers to the questions we posed at the beginning were affirmative.
Is your organization ready?
Convincing an organization of the value of red teaming and persuading it to implement it in its cybersecurity programs can be a burdensome challenge for a service provider. It may be best not to try to achieve this, at least not directly. Ideally, organizations should look for and turn to the red teams. But if there is still reluctance or negligence with basic prevention measures, what could we expect in relation to a more advanced strategy like this? A security-conscious organization would become informed about it, mainly while it is in a deliberate process of maturing. Being mature in security, it would call upon a red team and its services without ado. However, one of the common setbacks is stagnation.
An organization may be unready and therefore unwilling for red teaming when the peak of its maturity has so far been vulnerability assessment or vulnerability management. Some even reach that point by relying exclusively on automated tools. Haven't they considered approaches like risk management and attack resistance management yet? Perhaps what the expert Chris Gates says is true: "It's most effective to not waste your time. In all honesty, if you have to really push [...] and convince, then the organization isn't going to be in the right [mindset] to receive or implement [a red team]."
However, it is indeed possible to contribute to the cybersecurity education of organizations. And this should not be seen as a waste of time. In fact, it is something that, for instance, we at Fluid Attacks like to do through this and other media. As the acquisition of red teaming ends up being a business decision, it is primarily the leaders or directors of organizations who need to be reached with messages that are clear enough to them about the importance of this solution. Even more so when there are no cybersecurity experts among them (something that should change; the SEC has already suggested it).
As Christopher Campbell puts it, "The problem is that most people don't understand what the core mission of a red team is and instead compare it to other types of testing and assessment." (If you are among those who are just starting to learn about the subject, we invite you to read our post "What Is Red Team in Cyber Security?") This method is not meant to replace vulnerability scanning or penetration testing but to complement them at an advanced stage of an organization's security maturity process. The executives of an organization can be apprised of the different features and benefits of each of these solutions (see, for example, this post). We can contribute to modifying that vision that, as Jake Williams comments, is often present in some potential but reluctant customers: "The red team is seen as an overpriced vulnerability scan or penetration test."
Trying to figure out the differences?
From the early stages of an organization's software development lifecycle (SDLC), development teams can significantly benefit from scanning and pentesting. With different techniques, these methods target diverse objectives. Well-known and zero-day vulnerabilities are identified in the software's source code and operations, especially in pre-production. Red teaming, on the other hand, is aimed more at a technology that is, arguably, ready for its end users and even at a set of systems or a network in which humans are involved. However, it is true that red teaming focuses more on goals to be achieved than on specific scopes. Those who benefit here are all security-related teams, such as prevention, defense and response teams.
In keeping with the above, as Brandon McCrillis says, "Red teaming requires the ability to combine many aspects of traditional security audits into an engagement that crosses the bounds of simply 'checking the compliance box.'" And as Campbell rightly points out, "Red teams test how all of your policies and procedures work together in the actual production environment, where there are real people."
In that quote above, there is a key element of the value of red teaming: the approach to reality. Which reality? The one relative to cyber threats and bad actors. A red team is tasked with emulating cybercriminals, using their resources, techniques, tactics and procedures, which could do harm to an organization. As Paul Brager specifies, "Red teaming allows for an organization to find potentially damaging or risky holes in their security posture before bad actors exploit them, minimizing the potential impact to company reputation, customers, and shareholders." This is part of the much-touted-by-us preventive posture. In the words of Tim MalcomVetter, the job of a red team "is to prepare the business for the reality that an attacker may play unfairly without their knowledge or consent."
With this methodology, through a trained and supervised team and with prior approval from the target organization's leadership, the aim is to evaluate the effectiveness of the organization's entire security program (prevention, detection, defense and response) against attacks as close to reality as possible. As David Kennedy expresses, "This is about as real as it gets without having an actual adversary compromise you." Ideally, it is about experiencing one or more hits but not waiting for them to occur from those "actual adversaries." Drawing on the sparring analogy used by Chris Nickerson, with red teaming, an organization joins a "fight club to see what it really feels like to be in a fight [...]. The entire sentiment of red teaming is to challenge the status quo —not through some type of theoretical or mathematical model but to learn and evolve through experience."
In a controlled manner, without putting the target organization at risk, it can be confronted with simulated adversaries who act as its real opponents (no hypothetical attackers). The organization's teams can then learn from them and, with that experience, be more prepared for genuine threats and blows. Going back to Nickerson: "It will prepare you for the inevitable fight ahead and give you trust in your skills. It will also point out opportunities in your game plan that may have never been tested." Also familiar with the sparring analogy, Robin Wood tops it off with the following: "A boxer who spends many hours in the ring trading punches with a willing sparring partner will be far better prepared for a fight than one who has only ever hit a punch bag."
Does it fit your organization's needs?
So, the red team's purpose is to assess the true reactions of an organization's technological and human systems to attacks that border on reality. Thus, in order to be realistic, the red team must know and understand the types of threats that the industry to which the target organization belongs typically faces. It must also get a grasp on what previous attacks and incidents have been or could ever be experienced by that organization. Since prioritization is a vital issue in cybersecurity, the red team can find out what the organization's leaders are most concerned about and what assets they deem most important. As McCrillis says, "The value in red teaming is understanding and exploiting the business's worst fears." Already in its offensive exercise, the red team may even compromise things that were initially wrongly undervalued by the organization.
The red team focuses on adapting to the context of the target organization and on identifying those multiple security issues that, if exploited by criminals, would have significant and compromising impacts on the organization. Therefore, the red team must show flexibility. As Stephanie Carruthers shares, "Typically, companies get penetration tests conducted by a single consultant who usually has a general skill set. A red team brings a group of individuals whose specific skill sets are aligned with the company's infrastructure." The background of each member of the red team should determine their involvement or at least the degree of participation (for they can also learn) in a specific project with an organization. A well-rounded group of experts with different knowledge and experience can help to discover even new threats and suggest which and how various systems and strategies of the organization could be improved.
You're worried about money, huh?
Quite understandably so. Many organizations may be disinclined to try red teaming purely because of the cost issue. They may have already invested in good development practices, security tools and testing, and vulnerability management programs. But, we could ask them a couple of questions: Have your investments been sufficient? Are your prevention, detection, defense and response capabilities of enough quality? Bradley Schaufenbuel suggests that red teaming can be viewed as "a relatively inexpensive way of determining whether your past investments in people, process, and technology are providing the results you expected and what areas of future investment will provide the organization with the biggest bang for its buck."
On this money issue, successful red team exercises can help the organization realize what the costs would be in the event of specific incidents. (Note that good red teaming that is not "successful" at achieving precise goals also counts as a benefit, revealing that the target organization's security controls and processes are of high quality). Large amounts of money can be at stake. As Kevin Figueroa says, "showing the cost if the organization is compromised versus the cost of conducting a red team engagement may change how they approach security in their organization." Don't wait until you experience money loss to come to your senses. Keep in mind what Robert Willis shares: "Organizations need to be able to justify the spending that goes into anything cybersecurity related, which is why many organizations have a horrible security posture."
We're here to help you!
At Fluid Attacks, where apart from red teaming, we offer other cybersecurity solutions, we take it as our responsibility to contribute to eliminating the misconception that a red team is there to break infrastructures, blame people for security issues, provide lengthy reports and get the hell out of there. A trustworthy, certified red team is not only there to compromise systems and expose holes and flaws. Its work should also include feedback and assistance to the different sections of the target organization to help them enhance their security programs.
Don't let your organization get bogged down in cybersecurity maturation. Don't join those people who, as Mary Sawyer refers to, "are only ever going to be concerned about security when they face the consequences of doing something insecurely." It's better that your organization, with the help of a red team, such as Fluid Attacks', air out the dirty laundry as soon as possible. Follow Oddvar Moe's advice: "It would not be a lot of fun to find out that an attacker can easily hack into our environment undetected and isn't stopped just because we did not test the security of our organization properly." Contact us and start mitigating your organization's risk exposure right now.
Caution: Don't forget that you can access the full interviews with each of the 47 red teaming experts in Carey and Jin's book.
Recommended blog posts
You might be interested in the following related posts.
Watch out for keylogging/keyloggers
There's not an only way but here's a good one
Benefits and risks of these increasingly used programs
A hacker's view of the performance of Researcher CNAs
Why so many are switching to Rust
Description and critique of CEH certifications
An OffSec Experienced Pentester review
Or what makes the ethical hacker