In offensive security, the line between a highly successful adversary simulation and a legal or operational disaster comes down to a single document: the Rules of Engagement (RoE). A well-drafted RoE provides red teamers with the flexibility to realistically emulate real-world threats while establishing strict guardrails to protect the business from actual downtime. Here we will explore what makes a good and bad RoE and provide a checklist to follow when developing your own.
Rules of Engagement (RoE) for performing red teaming or any offensive security engagement, for that matter, are an essential part of establishing the work to be done by the offensive security (offsec) team against a customer’s assets. This provides legal protections, peace of mind, and helps customers work with the offsec team to identify any test measures that could potentially impact or disrupt business operations ahead of time.
RoE establishes the explicit responsibilities, relationships, and operational guidelines between the offsec team, the asset owner, and any required stakeholders such as third-party partners or different business units. By thoroughly documenting these parameters, the RoE ensures that offsec professionals can perform their tasks safely while mitigating unintended disruptions to the customer organization or other involved parties. Due to this breadth, an RoE can be thought of as a legally binding document to outline work to be performed and protect both the offsec team and the customer during an engagement.
While closely related, red teaming and penetration testing (pentest) have variable differences in approach, objectives, and methodologies, requiring different approaches to scoping and defining the RoE. Both find and exploit vulnerabilities in an attempt to enhance a customer's security posture, sure, but pentesting is focused more on direct system vulnerability testing, not only identifying vulnerabilities, but attempting to exploit them (of course, if that’s allowed per the RoE, as some vulnerabilities might be too aggressive on the affected system and a full PoC may not be required).
Conversely, red teaming is an objective-oriented test designed to stress-test an organization's overall security posture from a more black-box perspective, where the defensive (blue team) side has little or no insight into operations being performed. This is, of course, something to consider as part of the RoE, and where we can start to trend toward purple-team territory regarding how much the blue team should be involved in the test.
Compared to a pentest RoE, a red team RoE governs a more dynamic and nuanced campaign where the organizational objectives are defined (e.g., accessing sensitive customer data, approaching the test like a specific advanced persistent threat (APT), or performing specific tactics, techniques and procedures (TTPs), but the specific attack path is deliberately left more opaque as red team operators will take different approaches depending on the environment and requirements in play.
Failure to implement a robust and legally approved RoE leaves both the red team operators and customers exposed to operational risks and potential legal repercussions. For example, customers having sensitive or compliance-governed datasets (e.g., PCI DSS, HIPAA, GDPR) included in the red team engagement could face legal consequences themselves if the handling of said data isn’t properly defined in the RoE. At the same time, if it is properly defined in the RoE and the red team doesn’t follow the RoE when handling said data, the red team itself is liable. Of course, that is one example, and in extreme cases, failure to follow the RoE by red team operators could lead to a multitude of issues, such as:
Typically, it is frowned upon to nuke a customer's environment or asset, so having a strong RoE protects both parties from such an event happening, keeping everyone involved safe and legally happy.
To ensure legal adherence, a secure engagement, and happiness for all parties, an RoE should keep the following in mind:
RoE acts as an approval and agreement from both parties to ensure agreement on scope, objectives, and provide legal protection to the customer and the red team itself. As such, on the customer side, signing and agreement of the RoE should be done by those who have legal authority over all in scope systems, facilities, and personnel, and on the red team side, should be signed by someone who is in a position to accept and manage these requirements/responsibilities among their team.
Scope is a paramount part of any offsec engagement, not just red teaming. It ensures that exactly what is listed is what offsec operators are allowed to test against. You can think of this as the “authorized target space,” which can include everything from IP ranges, cloud tenants, physical buildings, or even specific people (and no offsec operators aren’t going to mobstyle abduct and interrogate these folks, but it could extend into who is included/excluded from direct communication with the red team through social engineering).
Just as vital is to identify explicitly what is out of scope, which mandates boundaries that red team operators must never cross. Typical out-of-scope assets include production datasets with real customer data, critical infrastructure, systems managing life, or other high-impact assets within a customer environment. Open communication between the red team and customer stakeholders should be heavily considered to ensure no downtime, and assets identified as neither being in nor out of scope can be discussed.
Explicitly defining TTPs is important to do in a way that protects the business without being overly limiting for the red team. While common exclusions include denial-of-service (DoS), remote code execution (RCE), and SQL injection (SQLi) attacks that could bring down systems, it is important to think through the objectives to ensure you aren’t limiting operators from completing them.
Establishing deconfliction and emergency stop procedures is an extra step beyond just the bare RoE components established above. Typically, the customer will assign a “Trusted Agent” (senior stakeholder) to manage the engagement from the customer side, ensuring resources aren’t wasted and deconflicting red team activities from genuine threats.
While a purple team is more of an open discussion between the red and blue teams, a red team engagement is typically more siloed, making this trusted agent role all the more important. Defining that point of contact (or two) and a kill switch to halt testing should things go askew is another level of protection for both the red team and customer while still providing space to achieve the set objectives.
The following is a checklist of what, at a bare minimum, is required for creating an RoE:
If you are looking to build or refine your organization's internal documentation, the following industry resources provide excellent structural templates and regulatory guidance that adhere to the methodology outlined above:
As with all things, a good RoE is a work in progress. The following list will help you identify what to and what not to do when putting together an RoE for a red team engagement:
Healthy, high-impact collaboration between offsec operators and defending organizations is dependent upon a mutually agreed-upon, standardized format for engagement. A comprehensive RoE document ensures that red team or any other offsec engagement produces actionable, high-fidelity findings without compromising the integrity of the customer’s infrastructure. To learn more about how to securely execute adversary simulations or red team engagements within your environment, explore our specialized Cobalt Red Team Services.