When I launched Red Team Journal in 1997, I did so because I saw a need to define the practice of red teaming in new and broader ways. My vision emerged over time, but from the start it relied heavily on notions of convergence and cross-pollination. I think we’ve done a pretty good job over the years carrying new ideas, tools, and concepts to the red teaming community from a range of other domains.
I remain convinced that the best red teamers are those who know many different things. Yes, domain knowledge and skills are essential, but the best red teamers I’ve met—almost without exception—are those who actively hunt down concepts from other domains and then apply them to their red teaming activities. I’ve even encountered a couple of organizations that do this well, although I increasingly worry that they are the exception, not the rule.
Parallel with the site’s mission, I’ve worked hard over the years to broaden my own cross-domain skill set, adding skills in systems analysis, systems engineering, risk analysis, knowledge management, information assurance, and others. When I decided earlier this year to steer my career more toward commercial cybersecurity and strategy, I naïvely assumed the value of this skill set would be self-evident. After talking to more people in the past few months than I care to count, I realize that it’s not.
At first I heard variations of this theme: “Yeah, most firms understand the value of red teaming (read ‘pen-testing’), but few consider security from a strategic perspective. You just need to find one of those firms, and it’s probably going to be one of the big ones.” Only recently did someone finally warn me “You’re not going to find anyone doing that. Everyone’s focused on the tactical, even the big firms.” I still don’t know if it’s universally true, but it sure lines up with my experience to date.
All of this has caused me to think more about red teaming requirements in the cybersecurity domain. I realize now that if I can’t find the job I want, I have to create it or persuade someone to create it. With this in mind, I’m coining two new terms: point red teaming and pattern red teaming.
Point red teaming is tactical, short-term, and focused on immediate needs. It helps enterprises find and plug existing holes. It’s roughly equivalent to pen-testing but can include other techniques as well. Point red teaming efforts tend to be one-off, and even when coordinated at a project level, they still maintain the point focus. Because they’re one-off, it’s hard to connect the dots, find the patterns, and project those patterns into the future. What’s more, running lots of point red teams doesn’t mean you see the big picture; in fact, it may obscure the big picture while leading you to believe you’ve mastered it.
Pattern red teaming includes point red teaming but embeds it within the broader system. Pattern red teaming is strategic and lifecycle-oriented. It emphasizes enterprise-wide requirements; dynamics; and long-term, sustainable strategies. In short, pattern red teaming is all about looking at the system for broader patterns and tradeoffs. One of the limitations of point red teaming is that it naturally encourages point responses. Pattern red teaming encourages system-wide tradeoffs, and you can’t do this well without understanding your enterprise as a whole system.
While technical skills are the sine qua non of point red teaming, the pattern red teamer’s toolkit is much broader. The superior pattern red teamer knows security; strategy; systems engineering; systems analysis; systems and enterprise architecting; risk analysis; knowledge management; and a bit of psychology, history, and biology thrown in for good measure. Since 1997, this is precisely the kind of red teamer we’ve encouraged organizations and enterprises to grow. Looking back, we may have failed to sufficiently articulate the need, but defining the difference between point and pattern red teaming should help.
Having said all this, I want to emphasize that your enterprise’s requirement to conduct pattern red teaming isn’t answered by simply hiring a pattern red teamer. Pattern red teaming also requires a discrete and adequately empowered pattern red teaming function, situated not necessarily within the security office but perhaps alternatively in a risk or strategy office. Yes, you still need point red teamers in your security office, but think carefully about where your pattern red teamers fit best given your unique situation.