OpenCyber Academy
Rapid course · Chapter 2 · English
Course code: OCA-019Chapter 02: OCA-019-C002

Chapter 2 — Scope, permission and safe practice

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 02 published. Map, example, EX014.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 What the paper must say"]
  N2["2.2 Checking a target list"]
  N3["2.3 Stop conditions and out of bounds"]
  N4["2.4 When someone asks you to break the rules"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX014"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 What the paper must say"]
  N2["2.2 Checking a target list"]
  N3["2.3 Stop conditions and out of bounds"]
  N4["2.4 When someone asks you to break the rules"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX014"]

[Learning outcomes]
    |
    v
[2.1 What the paper must say]
    |
    v
[2.2 Checking a target list]
    |
    v
[2.3 Stop conditions and out of bounds]
    |
    v
[2.4 When someone asks you to break the rules]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX014]

Learning outcomes

You will (1) list what a written authorization must contain; (2) check proposed targets against a scope with a short script; (3) explain stop conditions and out-of-bounds rules; and (4) handle a request that would break the rules.

2.1 What the paper must say

Before any testing, a written agreement — sometimes called rules of engagement — must name the systems and people in scope, what is out of scope, which methods are allowed, the start and end times, who to call in an emergency, how findings will be reported, and how data will be handled afterwards. NIST SP 800-115 and PTES both treat scoping as a first-class stage, not a formality.

If any of these items is missing, testing waits until the agreement is corrected and signed again. Maya's classroom pack covers 192.0.2.0/25, excludes the payroll server at 192.0.2.10 and allows only a configuration and policy review.

2.2 Checking a target list

Testers compare every proposed address or hostname with the written scope. Excluded systems — payroll, medical devices, safety systems — must never be touched even if they share a network. A simple local check catches mistakes before anyone sends a packet.

"""Lab 2: check synthetic targets against a written scope (no network traffic is sent)."""
import ipaddress
in_scope = [ipaddress.ip_network("192.0.2.0/25")]          # documentation range, synthetic
excluded = {ipaddress.ip_address("192.0.2.10")}             # payroll server: owner excluded it
requested = ["192.0.2.5", "192.0.2.10", "192.0.2.130", "198.51.100.7"]
for t in requested:
    ip = ipaddress.ip_address(t)
    if ip in excluded:
        verdict = "EXCLUDED - do not test"
    elif any(ip in n for n in in_scope):
        verdict = "in scope"
    else:
        verdict = "OUT OF SCOPE - do not test"
    print(f"{t:14} {verdict}")

Run with python3 lab_scope.py. Verified output:

192.0.2.5      in scope
192.0.2.10     EXCLUDED - do not test
192.0.2.130    OUT OF SCOPE - do not test
198.51.100.7   OUT OF SCOPE - do not test

The lab script compares four addresses with one allowed range and one excluded address, and sends no traffic. Only 192.0.2.5 is in scope: 192.0.2.10 is the excluded payroll server, and 192.0.2.130 and 198.51.100.7 fall outside 192.0.2.0/25. Run it whenever the list changes, and keep the output with the plan as a record that the check happened before any work began.

2.3 Stop conditions and out of bounds

Stop conditions are events that end or pause testing at once: the owner asks to stop, an unexpected outage appears, safety systems are involved, or sensitive data is exposed beyond the test's purpose. Out-of-bounds rules list methods that are never allowed, such as denial-of-service or social engineering of students, unless the paper explicitly permits them.

When a stop condition occurs, pause at once, contact the emergency contact named in the agreement and write down the time and what you were doing. Testing resumes only when the authorizing contact says so. For Maya's classroom exercise, a slow staff portal test page is enough reason to pause and call.

2.4 When someone asks you to break the rules

Colleagues sometimes ask for a "quick check" of a system that is not in scope. The answer is always no until the authorization is changed in writing. Being helpful does not create permission.

If the request is genuine, the person should ask the system's owner to change the agreement in writing. In Maya's exercise, a classmate asks her to add a personal blog, and she refuses: the college's authorization covers only agreed college systems, and pressure or friendship does not change that. Record each refused request, so your manager can see that the rules held.

Worked example (synthetic RCC)

Maya is given a draft target list for a classroom exercise that uses documentation addresses only: 192.0.2.5, 192.0.2.10 (payroll, excluded), 192.0.2.130 and 198.51.100.7. She runs the check script. Only 192.0.2.5 is in scope; the others are excluded or outside the agreed network. She removes them from the list before any further work.

Synthetic case — RCC. The addresses come from documentation ranges (RFC 5737); the college and exclusions are invented.

Errors and limits

A script only checks the list you give it; it cannot discover whether the real network matches the paper. Live scanning needs separate, explicit authorization.

Exercises

Synthesis

Written scope, exclusions and stop conditions decide every action; anything unclear is out of bounds.

Continue studying — chapter 02 of 04

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →

Worked answers

EX014. In-scope systems, out-of-scope systems, allowed methods, start and end times, emergency contacts, how findings will be reported, and how data will be handled.

EX015. The owner explicitly excluded the payroll server; being inside the network range does not override a written exclusion.

EX016. 198.51.100.7 OUT OF SCOPE - do not test — she removes it from the plan and never sends traffic to it.

EX017. 192.0.2.20 in scope because it lies in 192.0.2.0/25 and is not on the excluded list.

EX018. Refuse: the college's authorization and tools cover only agreed college systems; testing a personal blog with them would be unauthorized.

EX019. Stop if the owner or emergency contact asks; stop if a service outage appears that may be caused by testing; stop if sensitive personal data appears in a place it should not.

EX020. The emergency contact named in the rules of engagement, and she stops testing until told otherwise.

EX021. No. Changing the window needs a written change to the authorization before any out-of-hours testing.

EX022. It is retained only for the period and purposes written in the agreement, then deleted or returned as that document requires.

EX023. They are reserved documentation addresses (RFC 5737), so examples cannot be mistaken for a real attack on someone's network.

EX024. Pause testing of that target, request a written scope change from the authorizing contact, and continue only if approval is recorded.

EX025. Scoping is an early, first-class stage; technical testing follows only after scope and rules are agreed.

EX026. If it is not clearly in the written scope, do not test it.