After talking recently with colleagues at IOActive as well as some heads of industry-leading red teams, I wanted to share a list of attributes that I believe are key to any effective Red Team.

For debate about the relevant terminology, I suggest my post titled The Difference Between Red, Blue, and Purple Teams.

To be clear, I think there can be significant variance in how Red Teams are built and managed, and I believe there are likely multiple routes to success. But I believe there are a few key attributes that all (or at least most) corporate Red Teams should have as part of their program. These are:

1. Organizational Independence
2. Defensive Coordination
3. Continuous Operation
4. Adversary Emulation
5. Efficacy Measurement

Let’s look at each of these.

Organizational Independence is the requirement that the Red Team be able to effectively act like a real-world attacker in terms of scope, tools, and techniques employed. Many organizations restrict their Red Teams to such a degree that they’re basically impotent, which in turn lulls the company into a false sense of security.

Defensive Coordination is the requirement that Red Teams regularly interact with their counterparts on the defensive side to ensure the organization is learning from their activities. If a Red Team is effective on its own, but doesn’t share its knowledge and successes with the defense in order to make it stronger, then the Red Team has lost sight of its purpose.

Continuous Operation is the requirement that the organization remain under constant, rolling attack by the Red Team, which is the polar opposite of short, penetration-test-style engagements. Red Teams should operate through campaigns that span weeks or months in duration, and both the defensive teams and the general user population should know that at any moment, of any day, they could be targeted by both a Red Team campaign of some sort, or by a real attacker.

Adversary Emulation is the requirement that Red Team campaigns should be regularly updated based on the actual tools, techniques, and processes employed by real-world attackers. If cyber-criminals are doing X this quarter, let’s emulate that. If we’re seeing some state actors doing Y this year, let’s emulate that. If you’re not simulating—to some significant degree—the techniques being used by actual attackers, the Red Team is providing questionable value.

Efficacy Measurement is the requirement that Red Teams know how effective they are at improving the security posture of the organization. If we can’t tell a clear story around how our defenses are improving, i.e., that it’s getting increasingly more difficult to compromise, move laterally, and achieve attacker goals, then you’re getting limited value from any work that’s being done.

Summary

Here’s a pointed capture of those points:

• If your group is significantly restricted in its scope and capabilities by the organization, you probably don’t have an effective Red Team
• If your group doesn’t regularly work hand-in-hand with the defensive side of the organization in order to improve the organization’s security posture, you probably don’t have an effective Red Team
• If your internal or external service operates based on projects that happen once in a while rather than being staggered and continuous, you probably don’t have an effective Red Team
• If you aren’t constantly updating your attack campaigns based on new intelligence on actual threat actors, you probably don’t have an effective Red Team
• If you aren’t closely monitoring the effectiveness of the attack campaigns (and the responses to them by the defense) over time, you probably don’t have an effective Red Team

There are many other components of a solid Red Team that were not mentioned—top-end malware kits, elite security talent, deep understanding of the attacker mindset, etc.—but I think these five components are both most fundamental and most lacking.

As always, I’d love to hear from other security types who might have a differing opinion. All my positions are subject to change through exposure to compelling arguments and/or data.

Notes

1. Thanks to Ryan O’Horo (@redteamwrangler) for helping me form and crystalize many of these ideas.