OpenCyber Academy
Bachelor's · Chapter 30 · English
Course code: OCA-114Chapter 30: OCA-114-C030

Chapter 30 — Laboratory II

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 30 published. Map, example, EX088.

flowchart TD
  N0["Learning outcomes"]
  N1["30.1 The baseline"]
  N2["30.2 Reading the fleet result"]
  N3["30.3 Prioritising"]
  N4["30.5 Reproducing and extending the lab"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 The baseline"]
  N2["30.2 Reading the fleet result"]
  N3["30.3 Prioritising"]
  N4["30.5 Reproducing and extending the lab"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 The baseline]
    |
    v
[30.2 Reading the fleet result]
    |
    v
[30.3 Prioritising]
    |
    v
[30.5 Reproducing and extending the lab]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) assess a synthetic IoT fleet against selected ETSI EN 303 645 provisions; (2) report per-device and fleet-wide gaps; (3) relate the provisions to the NIST IR 8259 manufacturer activities; and (4) prioritise remediation.

30.1 The baseline

ETSI EN 303 645 V2.1.1 sets 13 cyber security provisions for consumer IoT, plus data-protection provisions. This lab checks four: 5.1 (no universal default passwords), 5.2 (implement a means to manage reports of vulnerabilities), 5.3 (keep software updated) and 5.5 (communicate securely). NIST IR 8259 covers similar ground from the manufacturer's process side — for example planning for updates and communicating with customers.

"""Lab 30: score a synthetic IoT meter fleet against selected ETSI EN 303 645 provisions."""
fleet = {"MTR-A": {"unique_pw": True, "vuln_policy": True, "update": True, "tls": True},
         "MTR-B": {"unique_pw": False, "vuln_policy": True, "update": True, "tls": True},
         "MTR-C": {"unique_pw": True, "vuln_policy": False, "update": False, "tls": False}}
PROV = {"unique_pw": "5.1 no universal default passwords", "vuln_policy": "5.2 vulnerability disclosure",
        "update": "5.3 software updatable", "tls": "5.5 secure communication"}
for dev, f in fleet.items():
    miss = [PROV[k] for k, v in f.items() if not v]
    print(f"{dev}: {4-len(miss)}/4 met; missing: {miss or 'none'}")
print("fleet-wide gaps:", sorted({k for f in fleet.values() for k, v in f.items() if not v}))

Run with python3 lab_fleet.py. Verified output:

MTR-A: 4/4 met; missing: none
MTR-B: 3/4 met; missing: ['5.1 no universal default passwords']
MTR-C: 1/4 met; missing: ['5.2 vulnerability disclosure', '5.3 software updatable', '5.5 secure communication']
fleet-wide gaps: ['tls', 'unique_pw', 'update', 'vuln_policy']

The lab's three meter models answer a short questionnaire for those four provisions; the script reports which each meets and what the fleet lacks.

30.2 Reading the fleet result

MTR-A meets all four. MTR-B fails 5.1 only — fixable by forcing unique credentials at installation. MTR-C fails three provisions: no disclosure policy, no update mechanism and no secure communication. The fleet-wide gap list contains all four provisions, which looks alarming but is driven by just two models; report both views.

The per-device view tells Maya what to fix on each meter model, while the fleet view tells LDHP's manager which provisions are missing somewhere in the estate. Reading only the fleet list would suggest four separate problems across every meter, when MTR-A is clean and three of the four gaps sit on MTR-C alone.

30.3 Prioritising

Severity depends on consequence and fixability. MTR-C's lack of update capability is structural — it cannot be patched — so replacement planning starts now. MTR-B's default password is the classic Mirai vector (Chapter 20) and is urgent but cheap.

Maya's remediation table follows that order. MTR-B is fixed within two weeks, at the next meter-read visit. MTR-C gets compensating controls at once, isolation behind the gateway with TLS terminated there, and a replacement scheduled within 12 months, because 5.3 cannot be met by any configuration change. MTR-A needs nothing now but is re-checked whenever its firmware changes, since a passing result describes one version only.

30.4 Limits of checklist assessment

"Meets 5.3" in this lab is a boolean from a questionnaire. A real assessment checks evidence: does the update mechanism verify signatures, and are updates actually published?

For LDHP's meters that means asking each vendor for evidence rather than answers. For MTR-A's "meets 5.3", it means a signed update package and the date of the last published update. For 5.1, it means a factory reset that still yields a unique password. For 5.5, it means the TLS version and certificate handling observed on the bench. Only MTR-A's claims would need checking this way first, because its four "yes" answers are the ones that currently drive a no-action decision.

Worked example (synthetic LDHP)

Maya's remediation table: MTR-B — reset unique passwords during next meter read visit, 2 weeks. MTR-C — isolate behind gateway with TLS termination as a compensating control for 5.5, request vendor disclosure contact, schedule replacement within 12 months because 5.3 cannot be met. MTR-A — no action, re-check on firmware change.

Synthetic case — Lakeside District Heating Plant. Device models and answers are invented.

30.5 Reproducing and extending the lab

Change one device's dictionary at a time and rerun, recording the output beside the edit. If two students get different results from the same dictionaries, compare Python versions and the exact file; the script is deterministic and should never differ.

A useful first edit is to set MTR-B's unique_pw to true and confirm its line becomes 4/4 while the fleet-wide gap list drops unique_pw and keeps MTR-C's three gaps; a second is to give MTR-C a disclosure policy and check that only 5.2 disappears from its missing list. If the fleet-wide list does not change the way you predicted, read the script's aggregation before trusting your edit.

Errors and limits

ETSI EN 303 645 targets consumer devices; district meters may fall under other regimes. The four provisions checked are a subset.

Exercises

Synthesis

Baseline assessments are useful when reported per device and fleet, backed by evidence, and turned into a dated remediation plan.

Continue studying — chapter 30 of 40

← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →

Worked answers

EX088. The loop uses 4-len(miss), so it would print MTR-C: 0/4 met unless the 4 is changed; after changing it to len(f)-len(miss), MTR-C prints 1/5 met with 5.2, 5.3, 5.4 and 5.5 missing. Spotting the hard-coded 4 is part of the answer.

EX089. Every provision appears as a fleet gap, but MTR-A passes all of them and MTR-B fails only one; the manager might fund a full-fleet replacement when the real problem is concentrated in MTR-C plus a cheap password reset for MTR-B.

EX090. A description of how updates are cryptographically signed and verified on the device, the vendor's published update history and declared support period, and a bench demonstration of applying an update and rejecting a tampered one.