Frankly speaking 9/20/22 - External red teams suck!

That's why you should have an internal one!

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

I am still looking to hire a senior engineering manager for my security team. If you know anyone who is interested, please reach out!

LET’S BE FRANK

Given the recent hacks, such as the Uber hack, there has been a lot of talk about offensive security and red teams. The reason for this is honestly quite straightforward — most hacks aren’t that sophisticated. We spend all of our time on sophisticated security tools only to miss soft spots in our access and authentication. Honestly, you can’t argue with the data that says most hacks start with stolen credentials.

The problem is that most of the time, it’s the unknown unknowns that cause issues. Sometimes, you’re too close to the problem or get tunnel vision from doing security defense that you forget how attackers think. That’s why it’s important to use red teams. First, it’s important to find soft spots in somewhat obvious areas that you might have overlooked. Second, it’s useful for figuring out the signs of attacks. Sometimes, your tools have gaps that overlook obvious attack signals, and it’s better that you learn this from a simulated attack than an actual one. Enter the red team!

In this newsletter, I’m going to talk about why I dislike external red teams and prefer internal red teams, and how you can have a red team with somewhat limited resources.

The problem with external red teams

Many companies use external security consulting firms to do a red team. The common argument is that there’s not enough work or resources to have a standing red team internally. However, although this logic makes sense from a financial and resource allocation standpoint, anyone who has a security background knows that it’s problematic for a few reasons.

First, external red teams take time to learn the environment and gather context. When they first show up, they tend to ask a lot of questions about the environment. They will not be as familiar with the application and infrastructure as the company’s engineers. Although this might be similar to an attacker’s view, an attacker technically has unlimited time whereas red teams are time-bounded by the contract. Most of the time, these exploits are subtle, and an attacker can search for months and has the ability to do whereas a red team doesn’t. On top of that, the red team has many engagements, and your company probably won’t get the same one next time. Even if they do, context will need to be developed again. At the point where you hire the red team for at least 3-4 months, it makes sense to have your own.

Second, running red team exercises take resources away from your security and engineering teams. Like what I said in the first point, your teams need to spend time with the red team to answer their questions. Most red teams require 1-2 dedicated security and/or engineers to be dedicated to the red team during the exercise to ensure that they are doing attacks that are in scope and realistic. Moreover, you also need dedicated resources to ensure that the red team is set up with the proper access to the environment so that they can test the various scenarios, and you need to explain the various scenarios. This has to happen for every red team exercise because although the setup might carry over, your environment might change, so you need to regularly update this.

The case for internal red teams

The most common argument against internal red teams is resources. It’s too expensive to maintain an internal red, but what I showed above is that many resources are already dedicated to the yearly red team exercise anyway. It’s not that much more effort to have your red team. The benefits of having your own red team can be the following:

• Familiarity with the application and infrastructure so that they can better find soft spots

• They retain context and become more familiar over time to know how changes might affect previous findings

• They aren’t on a “clock,” so this behavior is closer to an actual attacker, who has unlimited time to break in

• Resources are already being spent on setting up and executing the red team exercise

• You can perform more comprehensive and regular red team exercises

• They have more time to provide useful remediation and process fixes. They don’t leave after the contract time is up. They can work with engineering teams to fix insecure code and processes as well as provide training, which you would otherwise have to contract separately

It’s also not as big of a lift as many think to hire a red team. You can seed it with a couple of red teamers who provide the foundation for your team, which were dedicated resources that were already needed for red team exercises anyway. Then, you can have engineers and some people from your security team rotate in and out. This provides fresh eyes on problems as well as gives engineers a sense of how attackers think so that they can design software better when they go back to their team. These skills will further improve the security mentality of the engineering team which can have intangible benefits.

Finally, you can take a hybrid approach of hiring some external red teamers to come work with your current red teamers to further harden your security depending on the overall security risk of the company.

Having your own red team can be helpful, especially in finding some spots in your application and infrastructure in a continuous manner. They can also help assess risk and work with teams on remediation. They can add a ton of value and cost much fewer resources than people usually think.