Skip to content
Attack Surface Validation LabProject Nightwatch · Synthetic

Phase 01 · Authorization & scope

Scope & Rules of Engagement

Nothing in a legitimate assessment starts before this document is agreed and signed. The rules of engagement below are synthetic and illustrative, but they follow the structure a real engagement requires: what may be touched, what may never be touched, how evidence is handled, and when testing stops.

Engagement metadata

Synthetic engagement record for the portfolio lab.

Assessment name
Project Nightwatch
Client
Synthetic Mid-Market SaaS Organization
Engagement type
External + web application + identity review
Testing window
Illustrative only — no real testing window exists
Methodology basis
OWASP WSTG concepts, NIST CSF 2.0 functions, and attack-path reasoning
Report version
v1.0 (portfolio demonstration)

Authorization statement

Written authorization from the asset owner is required before any real testing activity begins. That authorization must name the in-scope assets, the testing window, the approved techniques, the emergency contacts, and the stop conditions. No assessment activity in this lab was performed against any real system: the engagement described here does not exist, and the authorization statement is presented to demonstrate the control, not to imply one was granted.

Scope boundaries

Authorized assets are explicit; anything not listed is out of scope by default.

Authorized assets (synthetic)

  • portal.lab.invalid — synthetic customer portal (WEB-01)
  • api.lab.invalid — synthetic public API gateway (API-01)
  • id.lab.invalid — synthetic identity service (IAM-01)
  • 198.51.100.0/24 — documentation range representing the lab perimeter
  • 10.20.0.0/16 — synthetic internal lab range (authenticated review only)

Explicitly excluded

  • Any real production system, domain, or IP address
  • Third-party SaaS, payment processors, and hosting provider control planes
  • Employee endpoints, personal accounts, and physical facilities
  • Any asset not explicitly listed in the authorized scope table

Techniques and prohibitions

Stated at a high level. Techniques are described, never operationalized.

Allowed techniques

  • Passive attack-surface inventory of synthetic lab assets
  • Authenticated and unauthenticated review of lab application workflows
  • Configuration and access-control review against documented expectations
  • Non-destructive validation sufficient to confirm a finding exists
  • Attack-path modelling and trust-boundary analysis on paper

Prohibited actions

  • Denial-of-service or availability-degrading testing
  • Destructive testing, data deletion, or modification of records
  • Persistence, implants, backdoors, or malware of any kind
  • Real credential harvesting, phishing of real people, or social engineering
  • Targeting third parties, shared infrastructure, or out-of-scope assets
  • Exfiltration of data beyond the minimum needed to evidence a finding

Evidence, stop conditions, and escalation

Evidence handling

  • Evidence is described in narrative form; no live payloads are published.
  • Synthetic screenshots and logs are redacted by default.
  • Evidence is stored in an access-controlled engagement workspace.
  • Evidence is retained only for the reporting and retest period, then destroyed.

Stop conditions

  • Indication that an out-of-scope or third-party system is affected
  • Discovery of apparent real personal data in a lab environment
  • Unexpected service instability or availability impact
  • Evidence of a pre-existing compromise

Escalation path

  • Tester pauses activity and records the time and last action taken.
  • Immediate notification to the engagement lead and client security contact.
  • Joint decision recorded in writing before any activity resumes.

Responsible testing