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"]
  N1["5.1 Approved scope"]
  N2["5.2 Collecting evidence"]
  N3["5.3 Checkable records"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX017"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Approved scope"]
  N2["5.2 Collecting evidence"]
  N3["5.3 Checkable records"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX017"]

[Learning outcomes]
    |
    v
[5.1 Approved scope]
    |
    v
[5.2 Collecting evidence]
    |
    v
[5.3 Checkable records]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX017]

Learning outcomes

You will (1) work within an approved scope; (2) collect evidence properly; (3) keep records that others can check.

5.1 Approved scope

Before any security task, Aiko confirms the scope in writing with Mr Kowal and the library manager: which systems, which activities, which times and which data. Her scope covers the library's servers, its test ledger, read-only access to the live ledger and synthetic data. It excludes borrowers' devices, the cloud provider's infrastructure and any public blockchain. If she notices something outside scope she reports it rather than investigating. Scope protects the library, the borrowers and Aiko herself, and it keeps security work lawful and predictable for everyone involved.

5.2 Collecting evidence

When Aiko checks something, she keeps evidence: command outputs, exported data, screenshots where nothing better exists and notes of what she did. Each item records the time, source and method. She stores a SHA-256 hash of each exported file so later changes can be detected. Evidence should come directly from systems where possible, not from memory. Mr Kowal explains that evidence allows others to verify findings and supports decisions, and that unrecorded checks are, for practical purposes, checks that never happened at all.

5.3 Checkable records

Aiko keeps a simple work log: date, task, scope reference, steps, evidence locations and results. When she reports that node backups are current, the log shows exactly how she checked. Another technician can repeat her steps and reach the same result. This repeatability is what makes records trustworthy. She also notes mistakes and corrections, rather than hiding them. Clear, honest records protect technicians when questions arise later and help the library show auditors or its board that its systems are properly looked after.

Worked example

Aiko works under written scope excluding borrowers' devices, hashes every export and keeps a repeatable work log including corrections.

Synthetic case. The scope, evidence and log are synthetic.

Errors and limits

Investigating beyond written scope, even helpfully, can be unlawful and erode trust.

Exercises

• EX017 — Scope exclusion. Name one item outside Aiko's scope. Rubric: 3 = borrowers' devices;; 2 = public blockchains;; 1 = library servers;; 0 = none.
• EX018 — Evidence integrity. How does she make export changes detectable? Rubric: 3 = storing a SHA-256 hash of each file;; 2 = hashing;; 1 = renaming files;; 0 = none.
• EX019 — Record quality. What makes a record trustworthy? Rubric: 3 = another technician can repeat the steps;; 2 = repeatability;; 1 = length;; 0 = none.
• EX020 — Mistake handling. How are mistakes handled in the log? Rubric: 3 = noted with corrections, not hidden;; 2 = recorded;; 1 = deleted;; 0 = none.

Synthesis

Written scope, proper evidence and checkable records make technical security work reliable.

Continue studying — chapter 05 of 18

← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →