Why I dislike the term Red team
Stop talking and start communicating
Red team. Penetration test. Adversary emulation. Adversary simulation. Purple team. [Insert color] team.
Periodically, we have community discussions entirely focused on vocabulary. It could be arguments regarding the difference between a customer hiring a Red team versus hiring for a Penetration test. Maybe it’s an argument about the difference between Adversary Emulation versus Adversary Simulation. Other times it’s introducing “a whole new color of team!”
We’ve all used these terms. We’ve all had these discussions at some point. There are no innocents.
Now that we acknowledge there is a problem, let’s talk about it. To me these discussions about language and words highlight a core failure in how we make InfoSec relevant in the business world:
We are using our own language instead of adapting to the needs of the organizations we support.
Communicating with decision makers
I spent several years in both the active and reserve United States Air Force (USAF) filling a variety of roles from traditional communications support to offensive cyber operations planning. During my time, the USAF cyber force was (and still is, to a certain extent) undergoing a major cultural shift around how cyber/IT personnel communicate with Commanders.
Commanders speak Operations - and by that I mean they communicate in the context of achieving objectives. They might lay out an objective like “Suppress the generation of enemy air sorties” which would have tasks like “damage aircraft in hardened shelters” or “crater or mine runways and taxiways.” Weapons Systems (capabilities) are then combined and layered to create the desired effects to accomplish those tasks. All of this is applied in order to achieve a higher-level objective to “Gain air superiority or supremacy.”
There is absolutely a place for general IT maintenance/communication work, but integrating Cyber into Operations is an entirely different beast. What a Commander (generally) doesn’t want, is someone to speak technical jargon related to patching computers, or deep details on how a system works, or what compliance criteria must be met. They want people who speak in Operations oriented language: “We will degrade the adversary’s capacity to laterally move in our systems. It will have X impact to our mission systems.” That languages avoids the technical complexity underlying the discussion, but it still enables the Commander to make a calculated decision to accept or reject that risk.
Once we adapt that mentality of IT/InfoSec acting as a capability to enable the larger organizations operations, you can apply the same language used in other areas. To continue with the military operations examples:
In meatspace, the Area Air Defense Commander (AADC) has a mission “to protect defended assets (DAs) that are vital to theater operations against missiles and aircraft. DAs typically include airports, seaports, critical government installations, and concentrated civilian populations. These assets are selected, often in consultation with higher authority, by the Commander of the Joint Task Force (CJTF) and are assigned to the AADC to defend in a given priority order. The resultant product is a Defended Asset List (DAL).”
We can directly use this language in Cyberspace when describing how we prioritize defending critical assets to a Commander. The creation of a cyberspace Prioritized Defended Asset List (PDAL) enables Commanders to approve resource and risk allocations upfront. It tells everyone - on behalf of the Commander - here are the assets that matter to your mission and this is the priority order in which we will apply resources to securing these assets. At a tactical level, applying this could help an IR team leader prioritize log dives, patching, etc, of one system over another.
Organizational language matters
What I really want everyone to take from this is: Speaking in the language of your organization matters. Cybersecurity for the vast majority of organizations is a supporting capability, not a supported capability. Meaning, InfoSec personnel in those organizations exist in a supporting capacity to empower the organization; the organization does NOT exist to support the needs of the InfoSec team.
So when you tell your COO “we need a red team assessment or a penetration test” or “we need to do adversary emulation NOT a red team,” you are not helping the Operations leader make an operations oriented decision. You need to articulate - in plain vocabulary relevant to that organization - how you are trying to empower the organization to achieve its core objectives and the desired effect from that capability (red team/pen test/etc).
In an outstanding post on Elevate Security titled “CEOs Want the CISO to Act more like a GM,” Robert Fly explains that “a [General Manager] is responsible for clearly identifying, building strategy, and articulating the projects in support of the business.” This is exactly what I mean. A Red Team/Adversary Emulation/Penetration Test means nothing to the vast majority of people and, more importantly, usually means very little to those empowered to make decisions in an organization. Those leaders are certainly familiar with language relative to their industry and as InfoSec professionals in a supporting role, we should be using their language - not ours.
All of this is essentially to say, it really doesn’t matter if you think something is a Red team or a Penetration test or Adversary emulation or [insert whatever word you want]. What matters is the outcome and how that outcome ties back to the organization’s core mission and what they are trying to accomplish.