◇ OpenCyber Academy
Technical · Chapter 18 · English

Chapter 18 — Supervised technical project

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

Chapter 18 — Supervised technical project

Lesson map

Lesson 18 published. Map, example, EX071.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["18.1 Choosing a project"]
  N2["18.2 Phases"]
  N3["18.3 Sealing evidence"]
  N4["18.5 Assessment rubric for the project"]
  N5["18.6 Continuing practice"]
  N6["Chapter synthesis"]
  N7["Chapter 1: EX001–EX004"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX071"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["18.1 Choosing a project"]
  N2["18.2 Phases"]
  N3["18.3 Sealing evidence"]
  N4["18.5 Assessment rubric for the project"]
  N5["18.6 Continuing practice"]
  N6["Chapter synthesis"]
  N7["Chapter 1: EX001–EX004"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX071"]

[Learning outcomes and connection]
    |
    v
[18.1 Choosing a project]
    |
    v
[18.2 Phases]
    |
    v
[18.3 Sealing evidence]
    |
    v
[18.5 Assessment rubric for the project]
    |
    v
[18.6 Continuing practice]
    |
    v
[Chapter synthesis]
    |
    v
[Chapter 1: EX001–EX004]
    |
    v
[Worked example] --> [Exercise EX071]

Learning outcomes and connection

After this chapter you should be able to:

This chapter closes the course. It uses everything before it on one realistic task, and its output is what an employer or assessor would ask to see: not a claim of competence, but evidence of it.

18.1 Choosing a project

A good supervised project is narrow, valuable and checkable. Examples drawn from this book: harden the corporate-to-control-centre conduit and verify it (Chapters 10–11); close the station-router bypass across all stations (Chapter 13); deploy drift detection on the control-centre servers (Chapter 14); build and test the detection pipeline against a replayed, sanitized capture (Chapter 17). Every project needs a supervisor (here L. Ferreira) and an authorizer who owns the affected systems (here A. Mensah for Kestrel Water).

Agree the supervisor, the owner who signs the scope and the success criteria before day one. Pick one conduit or one class of host, not the whole programme. Write the open items you expect to leave, so honesty about limits is planned rather than improvised at assessment.

18.2 Phases

  1. Scope (Chapter 5): purpose, systems, actions, window, people, stops, evidence handling — signed.
  2. Baseline: configuration exports and digests before anything changes (Chapter 14); current test results (Chapter 11).
  3. Change: under a change record with rollback (Chapter 10).
  4. Verification: positive and negative tests, every requirement verified, failed or untested.
  5. Troubleshooting log throughout, with the four labels (Chapter 13).
  6. Handover: as-built record, work instructions, open items with owners (Chapter 16).
  7. Evidence package: everything above, sealed.

Do not skip baseline digests even when the change seems small; without them you cannot prove what changed. Keep the troubleshooting log open for the whole window, including interruptions and false starts. The evidence package is last, after handover documents exist to put in it.

18.3 Sealing evidence

A manifest lists each artefact with its SHA-256 digest (FIPS 180-4). The seal is the digest of the manifest itself. Record the seal outside the package — in the change record, an email to the supervisor, the assessment form — because anyone who can edit the package can also edit a manifest stored inside it. Later, re-computing the artefacts' digests shows whether anything has changed; re-computing the manifest's digest and comparing with the externally recorded seal shows whether the manifest has been altered.

What a seal proves: the artefacts are byte-for-byte what they were when sealed. What it does not prove: that they were true, complete or created when they claim. Those depend on how they were collected (Chapter 5) and on independent records (firewall logs on the collector, change tickets in their own system). For stronger guarantees, organizations use signatures with keys held by a separate party or trusted time-stamping; the principle is the same.

18.4 Worked example: the KW-04 conduit project (synthetic)

R. Kaur's project removed the broad corporate rule R4 on fw-01 (CHG-2215), verified the result, and investigated the KW-09 event on the way. The evidence package is sealed and then, a week later, re-verified.

Lab 18 (save as lab18.py, run with python3 lab18.py):

# Lab 18 - seal and re-verify a project evidence package (offline, standard library only)
# Synthetic artefacts from the supervised project; written only inside a temporary directory.
import hashlib, pathlib, tempfile
artefacts = {
 "01-scope.md": "Scope: KW-04 conduit hardening; authorized by A. Mensah (Kestrel Water) 2026-10-05.\n",
 "02-before-fw.txt": "R4 allow 10.30.0.0/16 10.20.0.0/24 tcp any\n",
 "03-after-fw.txt": "R4 removed CHG-2215\n",
 "04-tests.csv": "test,result\nT4,pass\nT5,pass\nT9,pass\n",
 "05-troubleshooting-log.md": "07:05Z KW-09 missing; H4 consistent; RTU config preserved as E-17.\n",
}
with tempfile.TemporaryDirectory() as tmp:
    d = pathlib.Path(tmp)
    for n, t in artefacts.items(): (d / n).write_text(t)
    lines = [f"{hashlib.sha256((d / n).read_bytes()).hexdigest()}  {n}" for n in sorted(artefacts)]
    (d / "MANIFEST.sha256").write_text("\n".join(lines) + "\n")
    seal = hashlib.sha256((d / "MANIFEST.sha256").read_bytes()).hexdigest()
    print("manifest:")
    for l in lines: print(" ", l[:16] + "...", l.split("  ")[1])
    print("seal (record this outside the package):", seal[:24])
    (d / "04-tests.csv").write_text("test,result\nT4,pass\nT5,pass\nT9,pass\nT10,pass\n")   # later edit
    for l in (d / "MANIFEST.sha256").read_text().splitlines():
        h, n = l.split("  ")
        ok = hashlib.sha256((d / n).read_bytes()).hexdigest() == h
        print(f"verify {n:<26} {'OK' if ok else 'MISMATCH'}")

Expected output (Python 3.13.5):

manifest:
  72d8be01e70067c7... 01-scope.md
  8d52d15a3e02b7f8... 02-before-fw.txt
  2cd59665641b4779... 03-after-fw.txt
  d6eccc2e2ac61ecb... 04-tests.csv
  6d2525605f11521c... 05-troubleshooting-log.md
seal (record this outside the package): 062b9a1fd700dd0eac04b3a8
verify 01-scope.md                OK
verify 02-before-fw.txt           OK
verify 03-after-fw.txt            OK
verify 04-tests.csv               MISMATCH
verify 05-troubleshooting-log.md  OK

Four artefacts verify; 04-tests.csv does not. Someone added a T10 line after sealing. It may be an honest later test — but it must be added as a new, separately dated artefact with its own entry, not by editing a sealed file. The assessor asks R. Kaur to restore the sealed version from the archive (its digest must match the manifest), and to submit T10 as 06-tests-addendum.csv in a new, re-sealed package version, with both seals recorded.

18.5 Assessment rubric for the project

Criterion 3 (meets the technical outcome) 1
Scope and authorization Signed scope with owner, window and stops Verbal approval
Technical correctness Change achieves requirements; no collateral damage Partial or harmful
Verification All requirements verified or explicitly open, positive and negative tests with evidence Pass counts only
Troubleshooting Hypotheses, predictions, eliminations, preservation Narrative
Documentation Executable work instructions, as-built record, no secrets Notes from memory
Evidence Manifest, external seal, verification run Folder of screenshots
Honesty about limits Open items with owners; blind spots stated "All done"

18.6 Continuing practice

After the course, keep three habits: verify before you report, preserve before you change, and correct clocks before you order events. Keep labs contained, and never test real infrastructure without written authorization from its owner. Revisit standards and guidance when they change; every source in this book is dated October 2026.

Turn the course work into a portfolio: scoped plans, lab outputs with their Python versions, troubleshooting logs and the sealed package from this chapter, each seal recorded outside its package. When you move to a new Python version, re-run the labs and compare outputs; a difference is a finding to explain, not to hide. Seek supervised work where you can repeat the whole cycle — scope, baseline, change, verification, handover — on a real system with its owner's signature, and ask your supervisor to score it against the 18.5 rubric.

18.7 Common errors and limits

Checks that catch these errors:

Exercises — chapter 18

EX069 — Project scope. Objective: define a supervised project. Inputs: choose one project from 18.1. Steps: write the scope, requirements (testable) and the list of artefacts the evidence package will contain. Expected evidence: one-page plan. Rubric: 3 = all scope elements, at least four testable requirements with positive and negative tests, artefacts mapped to phases, supervisor and authorizer named; 2 = one gap; 1 = generic; 0 = none.

EX070 — Verify a seal. Objective: use the seal correctly. Inputs: Lab 18. Steps: modify the program to also re-compute the manifest's digest at the end and compare it with the recorded seal; then also edit MANIFEST.sha256 to match the tampered tests file and show what the seal comparison reports. Expected evidence: code and outputs for both cases. Rubric: 3 = first case: seal matches (manifest untouched) while one artefact mismatches; second case: all artefacts "OK" against the edited manifest, but the seal comparison fails — explains why the seal must be stored outside; 2 = one case; 1 = attempted; 0 = none.

EX071 — Handle the late addition. Objective: manage evidence changes. Inputs: the T10 edit. Steps: write the procedure the assessor described, step by step, including what is recorded where. Expected evidence: procedure. Rubric: 3 = restore sealed original from archive and check its digest; add addendum as new artefact with date and collector; produce a new manifest version and seal; record both seals externally with reason; never overwrite version 1; 2 = missing external record; 1 = "edit and reseal"; 0 = none.

EX072 — Self-assessment. Objective: apply the rubric honestly. Inputs: R. Kaur's project as described in this chapter and Chapters 10–13. Steps: score each rubric criterion with one sentence of evidence and list the open items. Expected evidence: scored table and open items. Rubric: 3 = scores justified from the text (for example verification limited by REQ-4 until R6 is removed; evidence criterion reduced by the post-seal edit until corrected), open items include R6, KW-04 router bypass across other stations, REQ-6 coverage, and the KW-09 incident outcome, each with owner; 2 = scores without evidence; 1 = all 3s; 0 = none.

Chapter synthesis

A supervised project shows technical competence as evidence: a signed scope, a baseline, a controlled change, verification of every requirement, a troubleshooting log, executable documentation and a sealed package. A seal proves that evidence has not changed since sealing, if it is recorded outside the package; it does not prove the evidence was true. State what is open, who owns it, and what you could not see.

Continue studying — chapter 18 of 18

← Chapter 17 · Course chapter index · Next course via chapter index →

This is the final chapter of this course; the index links the next course in the full study path.

Worked answers

EX001 — Path classification. HMI → scada-01 "start pump 2": control; worst case an unauthorized start or stop of a pump (overflow, pressure transient). KW-04 → scada-01 reading: monitoring; worst case operators act on a false level. eng-ws-15 → KW-04 project download: management (and indirectly control); worst case replaced controller logic — the most dangerous action on the list, because it changes what the controller does even when no further command is sent. jump-01 → hist-02 SSH: management; worst case altered or deleted historical records, or a foothold in Z2. hist-02 → corporate CSV: monitoring data leaving the control zone; worst case disclosure of operational data or, if implemented as a pull, a corporate credential into Z2 (Chapter 15).

EX004 — Shared platform list. Virtualization hosts — "What is the headroom if one host fails, and which guests restart where?" Directory — "Who is in the administrator groups, and can operators log in to the HMI if the directory is unreachable?" Time source — "What is the reference, is there a second one, and is offset monitored?" Monitoring collector — "What happens when its disk fills or it stops — do sources buffer, and does anyone get alerted?"

EX069 — Project scope. Example (station-router bypass): purpose — remove unauthorized paths to station Modbus via cellular routers; systems — twelve station routers (read), changes only on routers with findings; window — agreed per station with Kestrel Water; authorizer A. Mensah; supervisor L. Ferreira; stops — any communication loss or alarm. Requirements: no port-forward to tcp/502 on any router (negative: config check and VPN-client connect test); SCADA polls all stations (positive: historian count); router configs under drift detection (test: injected benign change detected); router management only from jump-01 (negative test). Artefacts: scope, baseline exports and digests, change records, test results, troubleshooting log, as-built record, manifest and seal.

EX070 — Verify a seal. After verification, compute hashlib.sha256((d / "MANIFEST.sha256").read_bytes()).hexdigest() and compare with seal: case 1 prints "seal OK" while 04-tests.csv mismatches. Case 2: rewrite the manifest line for 04-tests.csv with the new digest; every artefact now verifies "OK", but the manifest digest differs from the recorded seal, so the seal check fails. Only an externally stored seal reveals that the manifest itself was edited.

EX071 — Handle the late addition. (1) Retrieve version 1 of the package from the archive; check every artefact and the manifest against the externally recorded seal. (2) Restore 04-tests.csv to the sealed content. (3) Save T10 results as 06-tests-addendum.csv with collector and UTC time. (4) Create version 2 of the manifest including all six artefacts; compute seal 2. (5) Record seal 2 in the change record and the assessment form with the reason, keeping seal 1. (6) Never overwrite version 1.

EX072 — Self-assessment. Scope 3 (signed, owner and stops). Technical correctness 2 (R4 removed; R6 still present). Verification 2 (REQ-4 failing until R6 is removed; REQ-6 tested only after EX042). Troubleshooting 3 (KW-09 hypotheses, predictions, preservation). Documentation 2 (as-built pending for router findings). Evidence 2 until the post-seal edit is corrected, then 3. Honesty 3 if open items are listed. Open items: remove R6 (R. Kaur); router bypass check across all stations (network lead); REQ-6 regression test monthly (J. Tan); KW-09 incident outcome (L. Ferreira).