Chapter 5 — Security scope and evidence

Chapter 5 — Security scope and evidence

Lesson map

Lesson 05 published. Map, example, EX017.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["5.1 Scope is a safety control"]
  N2["5.2 Passive first"]
  N3["5.3 What makes technical evidence usable"]
  N4["5.4 Four labels"]
  N5["5.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX017"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["5.1 Scope is a safety control"]
  N2["5.2 Passive first"]
  N3["5.3 What makes technical evidence usable"]
  N4["5.4 Four labels"]
  N5["5.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX017"]

[Learning outcomes and connection]
    |
    v
[5.1 Scope is a safety control]
    |
    v
[5.2 Passive first]
    |
    v
[5.3 What makes technical evidence usable]
    |
    v
[5.4 Four labels]
    |
    v
[5.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX017]

Learning outcomes and connection

After this chapter you should be able to:

• write a technical scope for a task in a critical environment: systems, actions allowed, time window, contacts and stop conditions;
• explain why, in operational technology, a passive observation is preferred and an active one needs explicit approval;
• collect technical evidence so that someone else can verify it: what, from where, when (UTC), by whom, how, and its hash;
• separate observed, inferred, done and open in every working note.

Chapters 1–4 gave you tools. Before you point any of them at a real system, this chapter defines what you are allowed to touch and how you will prove what you saw.

5.1 Scope is a safety control

In an office network, an over-eager scan wastes time. In a control network it can stop a process: some controllers and older network stacks behave badly when probed, and a "read" can trigger vendor diagnostics or fill a session table. NIST's OT guide recommends caution with active scanning in operational environments and prefers passive methods where possible (SP 800-82 Rev. 3); NIST's testing guide describes rules of engagement for any assessment (SP 800-115).

A technical scope answers, in writing, before work starts:

• Purpose — what question the work answers.
• Systems in scope — named hosts and addresses; everything else is out.
• Allowed actions — for example "read running configuration", "passive capture on SPAN port", "one TCP connect test to port 502 with no Modbus request".
• Window — date and times, with the operator's agreement.
• People — who authorized it (the system owner), who is on site, who in the control room is informed.
• Stop conditions — any unexpected device behaviour, alarm or request from operations.
• Evidence handling — where results are stored and who may read them.

5.2 Passive first

Many questions can be answered without sending a packet: configuration exports, firewall logs, switch MAC tables, a passive capture from a mirror (SPAN) port, the historian's own records. Prefer these. When an active test is genuinely needed — for example to verify a deny rule in Chapter 11 — make it the smallest test that answers the question, from a named source, at an agreed time.

Prefer a SPAN capture or a configuration export before any connect test. When an active test is needed, use a marked source address, the smallest action that answers the question, and an agreed window with operations informed at start and end.

5.3 What makes technical evidence usable

A screenshot of a terminal proves little. Usable evidence records:

1. What — the raw output or file, not a summary.
2. Source — host and tool, with version.
3. Time — in UTC with the host's clock offset if known (Chapter 7).
4. Collector — who ran it.
5. Method — the exact command or query.
6. Integrity — a SHA-256 hash recorded at collection time, so later copies can be checked (FIPS 180-4); Chapter 18 seals a whole package.

NIST's guide to integrating forensic techniques into incident response discusses collection and preservation order (SP 800-86). At technician level the rule is simple: preserve before you change. If you are about to fix something that may be evidence of misuse, collect it first.

5.4 Four labels

Every note you write in this course uses four labels. Observed: what a tool or person recorded, with source and time. Inferred: what you conclude, and why. Done: what you changed, under which change record. Open: what remains unknown, and who owns it. Mixing them — "the RTU was compromised" when you observed only a configuration session — is how wrong conclusions spread.

A note that says only "RTU compromised" fails the test: it mixes inference with observation. Write the four labels on every working note in this course, including the KW-04 reachability check, so a reader can see what was measured and what remains open.

5.5 Worked example: scoping the KW-04 check (synthetic)

After Lab 2 showed writes from a corporate desk, L. Ferreira (KVROC security lead) asks you to confirm whether the corporate zone can reach station port 502. A sound scope:

The working note after the test reads: Observed — connect from 10.30.99.9 to 10.10.4.2:502 did not complete at 08:04:11Z; fw-01 logged it as blocked by the default deny. Inferred — fw-01 does not let corporate desks reach station Modbus, so the writes from 10.30.3.7 captured in Chapter 2 must have used another path (Chapters 10 and 13). Done — nothing changed. Open — which path carried those writes (owner: L. Ferreira).

5.6 Practical activity

Write a scope for a passive capture on the control-centre switch's SPAN port for 24 hours. Include storage limits and who may read the capture, since it will contain process values and possibly credentials sent in clear text.

State a maximum file size and a retention period, because a day of process values and clear-text credentials is both large and sensitive. Name who may read the capture and where it is stored, and say that the capture stops if the switch's mirror port affects forwarding. Mark the activity as passive and list stop conditions that include any operator request.

5.7 Common errors and limits

• Collecting evidence without UTC times or hashes.

• Treating scope as paperwork: it is what stops a test becoming an incident.

• Starting from a verbal go-ahead and writing the scope afterwards.

• Scanning a subnet in a control network to discover devices.
• Fixing a finding before collecting the evidence that showed it. A scope written after the work cannot protect the process during it.
• Carrying on past the end time in the scope because the last check "only takes a minute", instead of stopping and asking for an extension.

Exercises — chapter 5

EX017 — Repair a scope. Objective: find missing elements. Inputs: "Run a scan of 10.10.0.0/16 on Tuesday to find open ports. Approved by IT." Steps: list each defect and rewrite. Expected evidence: defect list and rewritten scope. Rubric: 3 = identifies wrong authorizer (system owner needed), unbounded range, active scanning in OT, no window, no stop conditions, no evidence handling; rewrite prefers passive inventory sources; 2 = most defects; 1 = cosmetic; 0 = none.

EX018 — Label the note. Objective: separate observation and inference. Inputs: "The vendor hacked KW-09 last night — the RTU config changed and data stopped, so I reset it." Steps: rewrite with the four labels. Expected evidence: labelled note. Rubric: 3 = observed (config session time, data gap), inferred (possible unapproved change; attribution unknown), done (reset — and the loss of evidence it caused), open (who, why; owner); 2 = labels without noticing the evidence loss; 1 = partial; 0 = none.

EX019 — Evidence record. Objective: produce verifiable evidence. Inputs: you export fw-01's rule set to fw-01-rules-20261013.txt. Steps: write the evidence record fields and the command that produces its hash on Linux. Expected evidence: record and sha256sum fw-01-rules-20261013.txt. Rubric: 3 = all six elements, UTC time with clock source, hash stored separately from the file; 2 = one missing; 1 = hash only; 0 = none.

EX020 — Passive alternatives. Objective: avoid unnecessary active tests. Inputs: three questions: which hosts talk to KW-07; what firmware KW-07 runs; whether KW-07 accepts telnet. Steps: propose a passive or read-only method for each and say when an active test would still be justified. Expected evidence: three rows. Rubric: 3 = flow logs or SPAN capture; asset records or the vendor tool during an approved engineering session; configuration export or the vendor's documentation, with an active check only in a scoped window with operations present; 2 = one weak; 1 = all active; 0 = none.

Chapter synthesis

In critical environments, scope protects the process as much as the tester. Write it before you start, prefer passive methods, and make every piece of evidence verifiable by someone else: raw, sourced, timed in UTC, attributed and hashed. Preserve before you change, and keep observed, inferred, done and open apart.

Continue studying — chapter 05 of 18

← Chapter 04 · Course chapter index · Chapter 06 →

Continue to the next authored lesson.