Phase 00 — Engagement Foundations: Authorization, ROE, OPSEC & Deconfliction

What this is. The phase that makes the authorization boundary reflexive before any offensive technique is taught. A red team consultant is a person a company pays to attack it — and the only thing that separates that work from a crime is a signed contract, a scope, stop conditions, and a deconfliction channel back to the defender. This phase turns those four words into operating discipline: you learn to scope an engagement, write Rules of Engagement (ROE), plan OPSEC (what your activity will emit and to whom), and deconflict with the client's Security Operations Center (SOC) so the blue team can tell your beacon from a real intruder's.

Why it exists (the gap it closes). Every other phase teaches a technique. This phase teaches the frame around every technique — the part that, when skipped, ends careers and engagements. A penetration tester who attacks a host because it was reachable, a red teamer who runs ransomware-like impact outside the window, an operator who can't tell the SOC "yes, that 3 a.m. alert was us" — each has failed the only test that is non-negotiable. Phase 00 makes the boundary mechanical: a deny-by-default authorization guard and an OPSEC/deconfliction planner you run before you act.

The ethical frame (read this first — it is not optional). Consistent with the track overview's authorization boundary:

• The labs are planners and guards over synthetic ROE and action metadata — there is no exploitation, no live target, no payload, no clock, no network.
• The difference between a red teamer and a criminal is authorization and intent, not knowledge. This phase is the authorization, made explicit and testable.
• If you cannot name the owner, the scope, the stop conditions, and the deconfliction contact for an action, you do not take the action. This phase makes that check a function you can run, not a feeling you hope you have.

In Operation Cedar Lattice (the track-wide engagement against fictional client Meridian Freight International), Phase 00 is where you scope the engagement: the in-scope CIDRs, domains, and emulation accounts; the explicitly out-of-scope carve-outs (payments, production data, third parties); the permitted methods and the forbidden ones; the time window and rate limits; the stop conditions; and the deconfliction contact at Meridian's SOC. Every later phase inherits this boundary.

Prerequisites. None beyond being a competent software engineer. The labs are pure Python (stdlib + pytest), offline, deterministic. Read the track README and LAB-STANDARD.md first.

Learning Objectives

By the end you can, without notes:

1. Explain why authorization — not knowledge — is the boundary, and name the four things you must be able to state before any action: owner, scope, stop conditions, deconfliction contact.
2. Write Rules of Engagement that are unambiguous: in/out-of-scope assets, permitted/forbidden methods, time window, rate limits, data handling, stop conditions, and deconfliction — and explain why ambiguity defaults to out-of-scope.
3. Implement deny-by-default authorization: anything not explicitly in scope is denied, and out-of-scope overrides in-scope — with real CIDR math and a subdomain matcher that is not fooled by substrings.
4. Reason about OPSEC as a risk you can score: the noise, novelty, blast radius, timing, and reversibility of an action, and the indicators it emits on the host, network, and identity planes.
5. Run deconfliction: decide which actions the SOC must be told about in advance, and keep the log that lets the SOC answer "was that you?" for any time window — without launching a real incident response.
6. Build the engagement operating manual and an isolated, deny-by-default range so practice never touches anything you do not own.

Core concepts

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), complete solution.py, adversarial test_lab.py, README.md, requirements.txt.

cd lab-01-engagement-roe-guard
LAB_MODULE=solution pytest -q   # reference passes
pytest -q                        # your implementation after the TODOs

Deliverables

• An engagement operating manual: a filled-in ROE for Operation Cedar Lattice, an OPSEC plan (the indicators you expect to emit and the deconfliction contacts), and a range diagram of your isolated lab.
• A deny-by-default authorization guard (Lab 01) you can run against any proposed action and get ALLOW/DENY with reasons — the machine form of the boundary.
• An OPSEC scorer + deconfliction log (Lab 02) that scores risk, enumerates indicators per plane, flags actions that need pre-deconfliction, and answers the SOC's "was that you?".
• The ability to defend your OPSEC and authorization choices in an interview, and to scope a safe engagement from a blank page.

Readings

Primary sources first; narrowed to what this phase needs.

• Red Team Development and Operations — Vest & Tubberville: the ROE, deconfliction, and operating cadence of a real engagement.
• PTES (Penetration Testing Execution Standard) — Pre-engagement Interactions: scope, rules, and the get-out-of-jail letter.
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment: rules of engagement, handling of sensitive data, coordination.
• MITRE ATT&CK Data Sources — to read indicators back to the telemetry that detects them (used directly by Lab 02; revisited in Phase 07).
• OSSTMM and CREST engagement-management guidance — the consulting-side discipline.
• The track templates: rules-of-engagement.md, evidence-manifest.md, lab-acceptance-checklist.md.

Common mistakes (and the failure they cause)

• Allowlist by substring. Matching corp.meridian-freight.test with in target lets evil-meridian-freight.test through — an out-of-scope hit. Use exact-or-subdomain matching (Lab 01).
• In-scope superset hides a carve-out. A broad /16 that contains a protected /24 must let out-of-scope override in-scope, or you attack a production subnet.
• Forgetting the window is half-open. Acting at exactly window_end is outside the window.
• Acting before deconfliction. A loud, novel action that trips an alert with no prior heads-up burns the SOC's night and may trigger containment that ends the engagement.
• No indicator list. "I can't say exactly what that emits" means the SOC cannot deconflict it and the blue team learns nothing — the action was offensive theater, not a red team exercise.
• Practicing on something reachable. Reachability is never authorization. If you cannot name the owner, you do not touch it.

Interview questions (full answers in the WARMUP)

1. What separates a red team engagement from a crime, and what four things must you be able to state before any action?
2. Why must an authorization guard be deny-by-default, and why does out-of-scope override in-scope?
3. How do you stop a scope check from being fooled by a look-alike domain?
4. What is OPSEC, and how would you score the risk of a planned action?
5. What is deconfliction, what is the deconfliction log for, and what goes wrong without it?
6. The SOC calls at 3 a.m. about an alert — walk me through how you answer "was that you?".

Portfolio artifact

The sanitized 00-operating-rules/ package: the Operation Cedar Lattice ROE, the OPSEC plan, the deconfliction procedure, the range diagram, and the two tools (the ROE guard and the OPSEC/ deconfliction planner) with their tests and expected output. This is the artifact that proves — before any technique — that you operate inside a boundary you can defend.

Safety

Authorized-lab-only and entirely offline; the labs reason over synthetic ROE and action metadata. No exploitation, no live targets, no payloads, no persistence/stealth tooling. This phase builds the judgment and discipline that makes every later offensive capability a defensible, hireable asset rather than a liability.