“Red Team Journal still serves as the best open-source repository for helpful hints and emerging practices in the field.”
— MIcah Zenko, Red Team (2015)
Don't Leave Hungry! Plan a Full Red Teaming Meal

Don't Leave Hungry! Plan a Full Red Teaming Meal

Nothing focuses the mind quite like having to sell something.

Since the start of the year, I’ve been working on Reciprocal Strategies, my new company. One of the biggest challenges has been to characterize what I do. My time with Red Team Journal branded me as a “red teamer,” but what exactly does that mean? Ironically, it was probably clearer to me (and others) over two decades ago when I launched RTJ.

Muddying the waters today is the growing gap between cybersecurity red teamers and red teamers of other kinds. (Yes, I appreciate the longstanding resistance to the term “cyber,” and I get it; I also bow to the overwhelming currency of the term.) I’ve done my best to define the differences (here, here, and here, for example), but it wasn’t until this week that I finally realized explicitly that the confusion isn’t just about types of red teaming, it’s also about red teaming roles.

Cybersecurity red teamers tend to focus on one type (Gegenspiel) and one role (technical), and since they’re presently securing the bulk of red teaming dollars (and euros, pounds, yen, and rubles), they’re dominating the conversation dollar-by-dollar. I think that’s a mistake, however—a mistake that limits not just other types and roles, but one that limits cybersecurity red teaming as well.

At RTJ, we defined two broad types of red teaming:

  • Gegenspiel, or thinking like an opponent; and

  • Kontraspiel, or thinking like a contrarian or devil’s advocate.

The security world focuses on Gegenspiel, while Kontraspiel characterizes the “challenge your assumptions” flavor of red teaming that we sometimes see in the business and military worlds.

Thus, most cybersecurity red teamers (read pentesters for the most part) practice Gegenspiel. Their role is primarily technical and involves probing and testing technical systems. Some exceptions do exist, and I salute those red teamers who embrace broader mandates and roles.

This past week I ran one of my Red Teaming 101 webinars. I talked about the different types of red teaming and some of the challenges I believe red teamers face. I was surprised when one of the participants asked, “When are you going to talk about red teaming?” My first thought was “That’s exactly what I’ve been talking about!” but then I realized we were experiencing the “Curse of Knowledge,” as defined by Chip and Dan Heath in their excellent book Made to Stick:

Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has ‘cursed’ us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listeners’ state of mind. (p. 70.)

While (I assume) he was thinking about the technical role of cybersecurity red teaming, I’d been talking about what we might call the project, analytical, and operational roles. As important as the technical role is (and it is, and not just in the cybersecurity domain), these other roles are equally important, if not—taken as a whole—more important.

And what exactly are these additional roles? Here's a set of preliminary definitions:

  • The project role involves setting the requirements, interfacing with the customer, defining and enforcing the rules of engagement, managing the engagement model, and overseeing the deliverables. This role should be filled by someone with experience (obviously enough) in project and security management.

  • The analytical role involves attack modeling, risk analysis, and managing the context or scenario. The analytical role should be filled by individuals with experience in systems thinking and risk analysis.

  • The operational role involves adversary modeling, intelligence analysis, and perception analysis. This role should be filled by individuals with operational experience relevant to both the adversaries and the systems of interest.

One person, of course, can fill multiple roles, but the superior red team will take care to address each of these roles explicitly. Remember that we're talking about red teaming, not pentesting, and we should, as a community, take care not to conflate the two practices. I suspect that just such conflation explains a lot of the ongoing confusion. Red teaming is more than pentesting, but more than a few pentesting teams, perhaps lured by the present cachet of the red teaming concept, appear to have adopted the label without adopting the full practice. It's a shame. Full-scope, systems-oriented red teaming—what we can now call "all-role" red teaming—offers potential insights available no other way.

All of which returns me full circle to what we do at Reciprocal Strategies: a big slice of Gegenspiel project management with a side of analysis and operations. In other words, we offer a hearty complement to your technical hors d'oeuvres, which, after all, are often more of a snack than a meal. In fact, I think I've finally figured out what I want to be when I grow up! A red team meal planner. Hungry?


Chip and Dan Heath, Made to Stick: Why Some Ideas Survive and Others Die (2007).

Same Words, New Meaning

Same Words, New Meaning

Read More Borges

Read More Borges