5 steps to a successful red team engagement

I’m a huge fan of red teams, but they are often so good at what they do that they lose sight of their primary mission: to help the organization reduce cybersecurity risk.

Red teams are employees or contractors who hack into an organization’s computer assets to reveal weaknesses in defenses. In my over 30-year career, the most enjoyable part was when I was being paid to break into someone’s network. I don’t do it now, although I keep my hands slightly wet by creating realistic hacking demos for my presentations. I always worried that I might not be able to do it, but I was always able to break into every place I was paid to. Hacking is relatively easy once you know what tools and techniques to use. Everyone thinks hackers are uber geniuses, but it’s more like being a skilled plumber or electrician.

Every organization should have regular red teaming done against its environment and applications/services/sites. How often is up to the organization, but anything less than once or twice a year borders on negligence. If you don’t do it at all, you are likely to have multiple vulnerabilities that you are not aware of.

The red team needs to be ethical and professional, and it needs to document and communicate all found vulnerabilities. Here’s my advice for a successful red team engagement.

1. Red teams should report all critical findings to top-line management

Red teams need to be able to report directly to the top-line management, whatever that is. It’s OK if they report directly to the IT manager, CSO, CISO or CIO, but their report needs to be uninfluenced by people whose jobs rely on its outcome.

All red team findings should also go to the CEO or board of directors unfiltered without undergoing changes directed by lower-level direct reports. I’ve seen many red team reports that get the guts ripped out of it by the person directly in charge of the red team because they didn’t want embarrassing details reported up the chain. Instead, they used the red team’s report to send a fake “clean bill of health” to upper management.

Serious found vulnerabilities are often removed after they were found and fixed (and sometimes not fixed). If you are senior management, you want to know what your lower-level management missed. You don’t want them cooking the books to look perfect all the time. We all miss stuff. If you’re in upper management and the red team reports you receive look too good to be true, inquire about the reporting process in more detail.

I’ve been on a few red teams where the CSO “negotiated” what was and wasn’t on the final report, and our overall compensation or whether we were rehired again next time depended mostly on making the CSO look good, not in what was really happening. Don’t let the fox guard the henhouse.

2. You need an external red team

If you have an internal red team, you still want to hire external contractors to try to penetrate your defenses. Many companies use only an internal team do all the hacking. It’s not enough. Internal teams get stuck in ruts and concentrate on particular methods to the exclusion of others. Internal red teams, no matter how good they are, are usually hamstrung by company organization and politics. They might want to do more things, but they often are pulled into concentrating on what someone above them wants them to.

The best of all worlds is to have both internal and external red teams. The internal team goes full bore all the time. The external team comes in a few times a year and acts more like real, malicious external hackers, with free reign on how and what they hack. An external team should have a defined scope, but you want to make sure you don’t artificially and unnaturally limit them in such a way that they end up not hacking like a true malicious hacker might hack.

3. Let pen testers hack like real hackers

One of the biggest problems with red teams is they often spend more time hacking using supercool, exciting, “sexy” methods, so how they break in doesn’t come close to mirroring how real hackers would likely break in. Most red teams have one or more smart and creative hackers that are their go-to guys for breaking in successfully all the time. They are usually proven leaders who know a lot more than the rest of the team, and more importantly, more than the defenders. They often use techniques and tools that are far less popular than what most real hackers would use. In doing so, they miss the biggest reason for having red teams.

The red team’s primary goal shouldn’t be to successfully break in. That’s nice. You always want to know about any vulnerability you need to fix, but you get the most value out of a red team when they hacking like most real-world hackers hack. A red team is supposed to help you decrease cybersecurity risk by finding the low-hanging fruit that hackers actually use. All red teams should focus on helping organizations close the holes most likely to be exploited first, followed by everything else.

4. Define the scope well

Define what is and isn’t in scope for the red team. You may have heard about the penetration testers who were arrested trying to break into an Iowa courthouse a few months ago. The wording of the scope seemed unnecessarily vague, and the pen testers seem to have stretched what they were allowed to do. The red team and their company say that the hackers’ physical break-in attempts were covered by the scope. The Iowa courthouse management team and law enforcement obviously disagree with that conclusion.

Either way, if your red team penetration testers are arrested for performing something the pen testing company says was in scope, the scope was not well defined, at the very least. Scoping can be boring but it’s central to define well to make sure everyone is happy.

5. Marry red teaming with blue teaming

Make sure that blue teaming is being done whenever red teaming is going on. Blue team is the defender’s side of the equation. Blue teams watch log files and wait for alerts from the red team’s activities. If the red team successfully breaks in without the blue team getting strong indications and alerting, then the defending side needs to step up its game.

You still need external code reviews

As every organization needs external red teaming, every bit of critical code for an organization’s software/services/sites needs to be reviewed. Your internal development team should be reviewing its own code as the first step of the process, and if you have enough programmers, having programmers review the other programmer’s code for security bugs.

Having software that reviews code for security bugs is a big help, and having a full-time employee who looks for code bugs and uses the software to do the same will reduce bugs in an organization’s custom code. Just like with red teaming, you always need an external code review to catch the things the internal team or software didn’t or can’t catch.

You need a red team and one that is allowed to hack like real, external malicious hackers hack. If they do their job well, they help the organization close the biggest, most likely to be exploited holes first. Everything else is gravy.