Scope And Rules Of Engagement

A tester at 10.10.0.10 receives a short request to assess the CORP.LOCAL internal network. Without a boundary, a discovery request can reach an unintended host, an aggressive check can destabilize a lab service, and a finding cannot be defended because nobody can show which systems were authorized. In this course, authorization is limited to the isolated 10.10.0.0/24 lab: DC01 at 10.10.0.5, SRV01 at 10.10.0.20, and WS01 at 10.10.0.30. Internet access is outside scope. Work remains confined to systems we own or are contracted in writing to test, under the governing rules of engagement and applicable law, including the Computer Fraud and Abuse Act in the United States and the Computer Misuse Act 1990 in the United Kingdom.

The first practical decision is therefore simple. Traffic from Kali may reach 10.10.0.5, 10.10.0.20, and 10.10.0.30, but it must not reach anything beyond the lab boundary. That restriction makes later evidence meaningful because each observed service, account behavior, and configuration belongs to a known target set. Let’s map the authorized boundary around the four lab systems:

This diagram shows why an IP address alone is not permission. The subnet and named hosts define where assessment activity may occur, while the no-internet boundary prevents a lab exercise from becoming an action against an uncontrolled system.

Rules that constrain each action

With the target boundary fixed, the rules of engagement are the written operating constraints that decide what activity is permitted, when it may occur, how evidence is handled, and when work stops. A rules-of-engagement document is not administrative padding. Each clause changes what we can safely claim in the final report and what a reviewer can reproduce.

For CORP.LOCAL, the rules must settle five decisions before reconnaissance begins:

• Target scope names 10.10.0.0/24 and the approved hosts DC01, SRV01, and WS01.
• The no-internet constraint excludes public addresses, external DNS lookups, and any action outside the isolated environment.
• Safety limits require measured, careful assessment because availability matters even in a lab.
• Evidence retention requires timestamps, host names, IP addresses, and captured output for every material observation.
• Stop and escalation conditions require work to pause when a service becomes unstable, unexpected data appears, or scope becomes uncertain.

The target list becomes the boundary for service inventory. Safety limits shape how we assess exposed services. Evidence rules create the artifacts behind the findings backlog, and stop conditions prevent a technical result from outranking system safety. The comparison below ties each clause to a concrete CORP.LOCAL value: