Red Teaming Fundamentals
Learn ethical red-team planning through rules of engagement, threat emulation, evidence, safety controls, reporting, and retesting.
What is red teaming?
Red teaming is an authorized security exercise that uses an adversarial mindset to test whether an organization can prevent, detect, investigate, and recover from a realistic path to a business objective. The goal is not to collect the most vulnerabilities or prove that an operator can "win." The goal is to produce evidence about risk and defensive behavior so owners can make and verify improvements.
Red teaming differs from a conventional penetration test in emphasis. A penetration test commonly examines a defined system for exploitable weaknesses. A red-team exercise usually follows a threat-informed hypothesis across people, process, and technology while measuring the organization's response. Both require explicit written authorization and bounded rules of engagement.
The core invariant is: no technique runs outside a documented authorization, operating envelope, stop condition, and recovery plan.
Start with a testable security hypothesis
An engagement should begin with a claim that matters to the organization, not a list of tools. A useful hypothesis names the protected outcome, plausible adversary behavior, expected control, and evidence that would confirm or refute the claim.
Protect
Business outcome
Name the service, decision, data set, or safety function whose compromise would create material harm. Avoid a target as broad as "the corporate network."
Emulate
Threat behavior
Use current threat intelligence and ATT&CK as a shared vocabulary for relevant behavior. A technique ID is context, not an instruction to run every possible action.
Predict
Defensive claim
State which preventive, detective, and response controls should act, what evidence they should emit, and who owns the decision.
Decide
Learning result
Define what evidence will create a finding, trigger an immediate escalation, justify a retest, or support closure after remediation.
MITRE distinguishes adversary emulation, which applies threat intelligence about a specific adversary, from broader red teaming, which applies an adversarial mindset to an objective. ATT&CK helps teams describe behavior consistently; it does not replace authorization, environment knowledge, safety engineering, or evidence design.
Build an enforceable engagement envelope
Loading authorization scenarios and safeguards.
Write rules of engagement as an enforceable contract
NIST defines rules of engagement as detailed constraints established before a security test. They give the team authority for defined activities without granting open-ended permission. The signed plan should be readable by operators, system owners, legal and privacy reviewers, incident responders, and the white cell that controls the exercise.
At minimum, record:
- Authorization and accountability
- approving authority, engagement owner, operator identities, and white-cell contact;
- start and expiry times, time zone, communication channels, and escalation path.
- Scope and exclusions
- named systems, tenants, identities, facilities, data classes, and permitted test sources;
- third parties, shared infrastructure, safety-critical functions, and other explicit exclusions.
- Permitted behavior
- bounded techniques, payload properties, rate limits, persistence limits, and cleanup requirements;
- whether defenders are informed, partially informed, or operating blind.
- Safety and recovery
- measurable stop conditions, who may call a stop, and how automation is disabled;
- restoration owner, backups or rollback path, and treatment of an overlapping real incident.
- Evidence handling
- stable exercise IDs, logging requirements, classification, access, retention, and deletion;
- rules for credentials, personal data, regulated data, and proof that avoids unnecessary collection.
Authorization must fail closed. If the target, time window, technique, data handling rule, or stop authority is ambiguous, pause and ask the approving owner. Operator judgment cannot silently expand a signed boundary.
Execute the smallest action that can answer the question
Realism does not require uncontrolled impact. Choose the least harmful action that can produce the required evidence, then increase fidelity only when the prior step cannot test the hypothesis.
1 Authorize
Preflight the boundary
Verify the signed version, target identity, time window, white-cell channel, stop mechanism, evidence location, and rollback owner immediately before execution.
2 Emulate
Run a bounded action
Use a stable exercise ID and the minimum permitted behavior. Preserve timestamps and avoid collecting sensitive content when metadata or a synthetic record proves access.
3 Measure
Observe the response
Trace prevention, telemetry, alerting, analyst ownership, investigation, containment, and recovery. Record what actually happened rather than inferring it from one alert.
4 Control
Stop and restore
Halt on a stop condition or real incident, notify the white cell, preserve evidence, remove test artifacts, restore state, and confirm the environment is stable.
Stop immediately when an exercise creates unapproved availability loss, reaches an excluded system or data class, cannot distinguish itself from a real incident, loses white-cell communication, or cannot prove cleanup and recovery. A safety event is an engagement finding even when the defensive hypothesis was otherwise answered.
Build an evidence chain, not an activity log
An operator's successful action proves only that the action occurred. It does not prove that a control failed, a responder missed an alert, or a remediation worked. Preserve separate evidence at each boundary:
- Authorization evidence: signed plan version, approver, scope, window, and exercise ID.
- Execution evidence: action identifier, source, target, timestamp, and sanitized result.
- Control evidence: prevention result, telemetry record, analytic version, alert, or case ID.
- Response evidence: owner, decision, timeline, containment action, and recovery result.
- Remediation evidence: accountable owner, changed configuration or code version, and deployment proof.
- Retest evidence: same bounded hypothesis, new control version, expected outcome, observed outcome, and date.
Missing telemetry and a weak analytic are different findings. So are an alert that no one owns and a containment action that causes unacceptable impact. Report the failed boundary directly instead of blending it into a "red-team score."
Decide what the evidence actually supports
Loading finding, evidence, and remediation states.
Turn findings into owned, verifiable change
A useful report lets a system owner reproduce the claim and choose a response. Separate facts from interpretation and keep sensitive operational details in a restricted appendix.
Finding
State the path and impact
Connect the authorized starting condition to the protected outcome. Include affected assets, preconditions, evidence IDs, business impact, and the controls that did or did not act.
Remediation
Assign the decision
Name the risk owner, technical owner, chosen treatment, due date, and deployment artifact. Distinguish a compensating control from a durable correction.
Retest
Replay the hypothesis
Use the same bounded preconditions and expected result against the changed control. Close only when evidence proves the gap is fixed without unacceptable regression.
Track program outcomes that support decisions:
- percentage of engagements with complete authorization and zero scope violations;
- evidence completeness by boundary, not a single blended coverage percentage;
- time from observation to triage, owner assignment, containment, and remediation;
- open finding age, retest completion rate, failed retests, and regressions;
- cleanup exceptions, safety events, and emergency-stop performance;
- repeated paths that reveal a systemic identity, segmentation, telemetry, or response weakness.
Do not present technique count, time spent undetected, or data volume accessed as proof of security value. Those numbers can reward unnecessary exposure and teach teams to optimize the exercise instead of the defense.
Enforce the boundary in code
The first example validates a request against a signed engagement envelope. It refuses an expired window, an unnamed target, a restricted behavior, or an active stop.
The second example makes closure a deterministic evidence decision. A deployed change still requires a passed retest against the same hypothesis.