◇ OpenCyber Academy
Engineering · Chapter 39 · English

Chapter 39 — OT, IoT and cyber-physical security: maintainability

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 39 — OT, IoT and cyber-physical security: maintainability

Lesson map

Lesson 39 published. Map, example, EX115.

flowchart TD
  N0["Learning outcomes"]
  N1["39.1 Churn"]
  N2["39.2 Thin adapters"]
  N3["39.3 Ownership"]
  N4["Practice note"]
  N5["39.1b Deprecation and deletion plans"]
  N6["Field note — vacation blocker"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX115"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["39.1 Churn"]
  N2["39.2 Thin adapters"]
  N3["39.3 Ownership"]
  N4["Practice note"]
  N5["39.1b Deprecation and deletion plans"]
  N6["Field note — vacation blocker"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]

[Learning outcomes]
    |
    v
[39.1 Churn]
    |
    v
[39.2 Thin adapters]
    |
    v
[39.3 Ownership]
    |
    v
[Practice note]
    |
    v
[39.1b Deprecation and deletion plans]
    |
    v
[Field note — vacation blocker]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX115]

Learning outcomes

You will (1) budget for policy and dependency updates; (2) keep adapters thin; (3) document ownership including vacation coverage.

39.1 Churn

ATT&CK for ICS techniques, PLC firmwares and vendor HMI support matrices change. Budget calendar time for updates; pin versions and watch advisories.

At ABP, Lena keeps a dependency page listing the ATT&CK for ICS release used by the mapper, the firmware revisions of PLC-A and SIS-B, and the HMI vendor's supported versions. A subscription to vendor advisories feeds a weekly review, and each pinned version has a review date. When the technique list changes, the coverage plan is rebuilt from the new release before the next assessment, so the 44 planned techniques never silently refer to an outdated catalogue.

39.2 Thin adapters

Isolate third-party SDKs behind interfaces so upgrades do not rewrite the finding store core.

Lena's team learned this from the screen-scraping alarm adapter, which broke with each HMI update and touched code far beyond its purpose. CNHP now places every vendor library behind a small interface owned by the team, with contract tests that use recorded vendor output. When a vendor changes its library, only the adapter and its tests change; the permit function, finding store and dossier code stay untouched, and the release notes can say exactly which part moved.

39.3 Ownership

Every service has a named owning squad and a backup. CODEOWNERS enforces review. Missing vacation coverage is a release blocker.

Synthetic case — Ashford Batch Plant. The ATT&CK for ICS mapper is an adapter; upgrading the technique list is a data PR, not a rewrite.

At ABP each CNHP service page names an owner and a backup by person, not by team alias. Before a release, the pages are checked against the leave calendar, and a release with no cover during the next window is held until someone is trained.

39.4 Errors and limits

Orphan tools rot into fail-open museums.

The screen-scraping alarm adapter at ABP is the example Lena uses: one engineer understood it, it needed eleven fixes in a year, and it failed silently whenever the HMI changed. A tool with no owner stops being patched, and when it breaks nobody notices whether it is failing closed or open. Lena's rule is that a tool without an owner and backup is either adopted by a named person within a month or retired with a published deletion date.

Practice note

Write a bus-factor note: who can release, who understands permit(), who can restore the sealed store. If the answer is one person, schedule cross-training before the next season.

39.1b Deprecation and deletion plans

Announce API deprecations with dates; keep dual-run periods. Maintainability includes knowing how to retire a tool: export dossiers, revoke credentials, archive code. The CNHP calendar reserves a dependency upgrade month each year, outside the plant's turnaround, so CVE pins do not wait for an emergency.

Cross-training sessions use the same synthetic fixtures as Lab I, so a backup practises on the inputs the release will be judged on; after one session, the trained backup ran Lab I alone and the held release went out.

Lena applies this plan to every CNHP tool, including the replaced adapter. Its retirement was announced in advance.

Field note — vacation blocker

A release was blocked because the only person who understood permit() was on leave without a trained backup. Cross-training on Lab I fixtures the next week cleared the blocker. Maintainability is mostly about people allowed to be on holiday.

Deprecated reason codes stay readable by consumers for one full release after producers stop emitting them.

The deletion date is announced on the service page at least one release ahead.

39.5 Worked example — removing a fragile adapter (synthetic ABP)

CNHP had a custom adapter that parsed the HMI vendor's alarm export by screen-scraping. Each HMI update broke it, and only one engineer understood it. Lena's maintainability review measures churn (11 fixes in a year), ownership (one person) and blast radius (alarm statistics for the whole plant). She replaces it with the vendor's supported OPC UA alarm interface, keeps the adapter read-only for one release as a fallback, publishes a deletion date, and writes the runbook so a second engineer can operate the new path. Fewer bespoke parts mean fewer silent failures in security evidence.

Exercises

Synthesis

Pins, adapters and named owners keep tools alive safely.

Continue studying — chapter 39 of 50

← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →