Ethical Hacking Scope and Rules of Engagement

"If you're going to break things, do it with permission, precision, and a paper trail your future self would be proud of."

You’ve already met the cast of characters in Threat Actors and Hacker Classes (remember our chaotic-neutral friends?), and you know the AAA basics: who gets in, what they can do, and how we log their shenanigans. Now we’re putting guardrails on the rollercoaster: defining the scope and rules of engagement (RoE) for ethical hacking. This is the difference between a legally sanctioned security assessment and “your laptop just became Exhibit A.”

---

What Are Scope and Rules of Engagement (RoE)?

• Scope: A precise list of what you can test, how far you can go, and where you must stop. Think of it as the treasure map with bright neon “Do Not Dig Here” zones.
• Rules of Engagement (RoE): The playbook for how testing happens—timing, communication, safety boundaries, data handling, and acceptable techniques.

Why this matters: without scope and RoE, your “ethical” hacking is just hacking with vibes. Also: contracts, laws, and reputations exist. Remember AAA? Scope and RoE are where authentication, authorization, and accounting get operationalized. No roaming into prod with wildcard admin creds at 2 a.m. because YOLO.

---

Scope: Draw the Box, Label the Monsters

In-Scope vs Out-of-Scope (aka “Touch This, Not That”)

• Assets: Domains, subdomains, IP ranges, APIs, mobile apps, cloud accounts, data stores, CI/CD pipelines.

• People and Places: Social engineering? Physical security? If yes, specify who/where/how. If no—say it loudly, with emojis if necessary.

• AI Systems (New Boss, Same Rules):

  • Model endpoints (LLM/chat APIs, inference servers)
  • Prompt/response pipelines, vector databases, retrieval plugins
  • Training/eval datasets, fine-tuning jobs, model cards
  • Guardrails/policy layers

• Third Parties: Payment processors, analytics, hosted auth, cloud providers—usually out-of-scope unless you have written permission. “But the app calls Stripe” is not a legal defense.

Depth of Testing

• Allowed: Non-destructive vulnerability discovery, safe proof-of-concept, privilege boundary validation, logic flaws, AI prompting behavior audits.
• Not Allowed (unless explicitly approved): Denial of service, data exfiltration of real PII, destructive payloads, persistence/backdoors, lateral movement into unincluded tenants.

AAA in Scope

• AuthN/AuthZ: Use designated test accounts with specified roles. Do not “borrow” prod admin.
• Accounting: All actions must be traceable. If it isn’t logged, it didn’t happen. If it is logged poorly, congrats: you found a finding.

Pro tip: Scope is geometry. Draw cleaner lines than a minimalist architect on espresso.

---

Rules of Engagement: How We Break Things Responsibly

Timing and Coordination

• Clear test windows (e.g., 01:00–05:00 UTC), with freeze periods for business events.
• Real-time comms channel (Slack/Teams) with on-call contacts.
• A literal safe word for emergency stop. Example: “RED-STOP” shuts everything down.

Safety and Rate Limits

• Max request rates, API call budgets, and concurrency caps—especially for AI endpoints that autoscale into bill-shock.
• Data handling rules: no downloading real PII; use synthetic data where possible.
• Change control coordination: no tests during production deploys unless planned.

Techniques and Tools

• Allowed tool categories: scanners, intercept proxies, SAST/DAST, cloud config analyzers, AI red-teaming harnesses.
• Banned: traffic floods, credential stuffing against real users, password spraying on live IdPs, or any tooling that violates provider AUPs.
• Social engineering: only if explicitly in scope, with target lists and pretexts approved.

Evidence, Reporting, and SLAs

• Proof-of-concept should demonstrate impact without causing impact. Screenshots > database dumps.
• Severity ratings (e.g., CVSS or agreed rubric) and remediation guidance.
• Reporting schedule: daily updates for high/critical, final report within X business days.
• Chain of custody for artifacts—especially important when findings involve data, keys, or model parameters.

Legal and Compliance

• Written authorization (letter of engagement) naming you, the client, and the assets.
• Safe-harbor language protecting good-faith testing.
• Regulatory flags: GDPR/CCPA/PCI/HIPAA—call them out in the RoE.

---

AI-Driven Twist: Special Rules for Testing AI Systems

Remember our threat actors? Now some of them have machine brains—or at least machine interns. Your RoE needs AI-specific clauses:

• Prompt Injection and Jailbreaks: Allowed within a harness that sanitizes outputs. No uploading sensitive proprietary data to “test something real.”
• Data Exfil Attempts: You may validate whether the model leaks secrets, but must not exfiltrate actual customer data. Use seeded canary tokens and synthetic records.
• Tool/Plugin Use: If the LLM can call tools (search, code, DB), restrict these to sandboxes. Document max tokens/minutes to avoid accidental DoS.
• Model Cards and Safety Layers: Treat safety policy bypass as a finding; don’t publish the bypass recipe publicly.
• Model Theft and Extraction: Attempting to fully replicate a model is typically out-of-scope unless you have explicit license permissions. Yes, even if you “just want to see.”
• Cost and Quotas: Token storms are real. Set daily spend caps and alert thresholds.

LLMs are like gifted toddlers: brilliant, unpredictable, and very expensive if left alone with your cloud credits.

---

Compare: Pentest vs Red Team vs Bug Bounty

Engagement Type	Goal	Scope Tightness	RoE Vibes
Pentest	Find and verify vulnerabilities	Tight, asset-based	Structured, time-boxed
Red Team	Simulate real adversary (often stealthy)	Objectives-based	Emphasis on OPSEC, detection testing
Bug Bounty	Crowdsource findings continuously	Looser but policy-driven	Public policy, strict disallow list

If you’re coming from Threat Actors 101: pentests mimic opportunistic/targeted attacks; red teams emulate advanced actors; bounties lure Internet gremlins with snacks and rules.

---

Mini Case Study: The GPT-Helpdesk E‑Commerce App

• In scope: api.shop.example, web and mobile apps, staging cloud account, the HelpBot LLM endpoint, RAG vector DB with synthetic data.
• Out of scope: third-party payment gateway, corporate HR systems, prod customer PII, the CEO’s smart fridge.
• Allowed: test prompt injection against HelpBot; validate that the bot can’t reveal API keys; attempt to access disallowed knowledge bases using canary data.
• RoE specifics: 50 requests/min cap to LLM; tool calls limited to a sandbox DB; safe word RED-STOP; test accounts with roles: user, support, manager.
• What AAA adds: we provision you scoped API keys and log all LLM tool calls. Your actions are attributable, reversible, and auditable.

Outcome? You discover the bot will summarize private tickets if baited with “for internal use.” No breach, but a high-severity policy bypass—clean repro, zero drama.

---

Common Pitfalls (and How to Not Star in an Incident Postmortem)

• “We assumed third-party assets were okay.” They’re not. Get permission.
• “We proved data exfil by exfiltrating data.” No. Use synthetic or canary data.
• “We tested during Black Friday because traffic looked realistic.” Please don’t.
• “We used prod admin accounts for convenience.” AAA weeps.
• “We jailbroke the model and tweeted it.” Findings first to the client. Internet later, maybe.

---

Template: ROE Essentials (Copy, Paste, Breathe)

Engagement: <Name>  Dates: <Start–End>  Primary Contact: <Name>

Scope:
- Assets In-Scope: <IPs, domains, APIs, cloud accounts, AI endpoints>
- Assets Out-of-Scope: <Third parties, prod PII, corporate network, etc.>
- Depth: <Safe PoC only / No DoS / No persistence>

Credentials & AAA:
- Test Accounts: <list roles>
- Logging: <where and how actions are recorded>

AI Testing:
- Allowed: <prompt injection testing, safety eval, RAG boundary checks>
- Constraints: <synthetic data only, cost caps, sandboxed tools>

Operational Rules:
- Windows: <UTC times>  Rate Limits: <values>
- Comms: <channel>  Emergency Stop: <phrase>

Legal:
- Authorization: <attached letter>  Safe Harbor: <clause>
- Compliance: <GDPR/PCI/etc>

Reporting:
- Severity Model: <CVSS/rubric>  Updates: <cadence>  Final Report: <due date>

---

Quick FAQ (Because Someone Will Ask)

• Can I test in production? Only if explicitly allowed—and with stricter limits.
• Can I phish employees? Only with signed approval, target lists, and pretexts.
• Can I “test” LLM data leakage by asking for customer SSNs? No. Use seeded fake records.
• Can I pivot from one cloud account to another if I find creds? Not unless both are in scope.

---

Key Takeaways

• Scope says what’s in the sandbox; RoE says how to play in it without eating sand.
• Tie everything to AAA: scoped identities, least privilege, comprehensive logging.
• AI systems need special treatment: token budgets, sandboxed tools, synthetic data, and clear rules for prompt testing.
• Consent and safe harbor aren’t vibes; they’re paperwork. Get it signed.
• Your best findings are impactful, reproducible, and achieved without collateral damage.

Final thought: Ethical hacking is professional curiosity under contract. Draw the lines, color inside them, and leave the system stronger than you found it.