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.
What Are Red Team Rules of Engagement?
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.
Red Team Rules of Engagement vs. Penetration Testing Scope
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.
Why a Weak RoE Is a Liability (for Both Sides)
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:
- Physical safety hazards
- Catastrophic business downtime (huge profit loss, anyone?)
- Disruption of critical operational technology
- Really, anything that applies to the customer assets in question
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.
Core Components of a Red Team Rules of Engagement
To ensure legal adherence, a secure engagement, and happiness for all parties, an RoE should keep the following in mind:
Approval & Authorization Requirements
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.
Defining Scope: In-Scope vs. Out-of-Scope Assets
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.
Permitted Tactics, Techniques & Procedures (TTPs)
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.
Deconfliction & Emergency Stop Procedures
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.
Red Team Rules of Engagement Checklist
The following is a checklist of what, at a bare minimum, is required for creating an RoE:
- Executive Summary: A high-level overview should summarize the engagement, scope, dates, and deliverables expected from the red team exercise. Having a legal disclaimer here that signing constitutes formal knowledge can draw action to encourage leadership to review the entire document.
- Objective & Success Criteria: Defined goals to help guide success/failure metrics and evaluations. This helps with scope as well in terms of what the operators should be targeting or looking for, saving effort and focusing operators on the objective-oriented approach vs a purely vulnerability diagnostic one, as you’d get from a pentest. Common examples of this could be replicating known APT goals targeting the customer sector, such as data exfiltration, system manipulation, or monetary stealing or extortion.
- Scope Definitions:
- In-Scope - Explicitly authorized networks, domains, physical locations, and personnel.
- Out-of-Scope - Strictly prohibited systems, data types, and individuals.
- Undefined - What to do when customer assets neither in nor out of scope are identified by the red team.
- Authorized & Prohibited TTPs: Detailed list of permitted exploitation methods and forbidden actions that the customer could perceive as destructive or do not want to risk them potentially being. This could be anything from RCEs, and cause DoS or social engineering in ways that degrade or could affect individual employees. When putting together an RoE, it is important not to limit it in a way that affects the red team’s ability to perform the intended objectives while still protecting business needs and interests.
- Communication & Deconfliction Plan: Ensuring trusted agent(s) contact information, reporting cadence for operations (if required), and working to avoid hindering customer blue team operations are paramount to a successful engagement. If required, this can be taken a step further by also defining roles and responsibilities to help guide communication during the engagement.
- Emergency Stop Protocol: Identifying how and when this triggers helps protect the red team and customer from legal action and business downtime. While most of the core components include coverage here, such as which assets are in or out of scope, it helps curve this. Unexpected events can occur during an engagement, making this an extremely important section of any RoE.
- Data Handling, Sanitization, & Evidence Preservation: Requirements here for how to handle customer data include encrypted storage, evidence preservation, and post-engagement artifact destruction. Ensuring data is properly handled during and after an engagement limits risk to both the customer and the red team itself.
- Reporting, Replay & Remediation: The RoE should outline the expected deliverables. This could include an executive brief for leadership, a technical brief detailing attack paths, and, potentially, provisions for a joint "Replay Exercise" (Purple Teaming) in which the red and blue teams walk through the engagement chronologically to map detection failures. Essentially, you’re establishing the deliverables here. While sometimes in the RoE, this may also fall into a statement of work (SoW) between the red team and the customer.
- Legal Authorization & Signatures: As with any good contract, things must be signed. Having signatures on paper ensures responsibility to those signing, and this section can even be expanded to define liability limitations. Ensure legal reviews from both sides are agreed upon when finalizing an RoE, and that those signing have legal authority over the assets in scope.
Examples and Further Information
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:
- Red Team Guide - Rules of Engagement Template: A highly comprehensive, fillable template specifically designed for adversary emulation, complete with appendices for threat profiles and methodology.
- FedRAMP Penetration Test Guidance (Appendix C): A rigorous structural guide designed for federal and highly regulated cloud environments, emphasizing data handling, incident response integration, and strict compliance boundaries.
- Red Teaming vs Pentesting - Explore key differences between the two disciplines — primarily that pentesting focuses on finding vulnerabilities with the blue team's knowledge, while red teaming simulates a real-world attack without warning to test an organization's threat detection and incident response capabilities. Learn more about Red Team Services from Cobalt.
Rules of Engagement: Best Practices & Common Mistakes to Avoid
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:
Do’s:
- Precisely identify scope by explicitly listing all allowed IP ranges, domains, physical locations, and personnel.
- Define specific objectives
- Designate an internal point of contact who can deconflict real security alerts from simulated attacks.
- Define exactly how sensitive data captured during the engagement will be encrypted, stored, and destroyed.
- Limit TTPs based on objectives and accepted business risk
Dont’s:
- Define scopes too broadly, such as “all corporate systems”
- We can caveat this somewhat, as it depends on the engagement objectives
- Not establish a deconfliction process
- Over-limit TTPs and attack vectors
- Not having a scope expansion procedure
- Not defining data handling procedures
- Focus objectives on vulnerability count vs engagement outcomes
Conclusion
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.
