Chapter 22 — OT, IoT and cyber-physical security: automation
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 Reading the report"]
N3["22.3 Report, do not change"]
N4["22.4 Scheduling and logging"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 Reading the report"]
N3["22.3 Report, do not change"]
N4["22.4 Scheduling and logging"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 What to automate]
|
v
[22.2 Reading the report]
|
v
[22.3 Report, do not change]
|
v
[22.4 Scheduling and logging]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) automate routine checks such as certificate expiry; (2) design automation that reports rather than changes OT systems; (3) schedule and log automated jobs; and (4) handle failures of the automation itself.
22.1 What to automate
Good candidates are repetitive checks with clear rules: certificate expiry, backup completion, inventory drift (Chapter 11 run weekly), flow comparison (Chapter 12 run daily on new captures). Poor candidates are actions on live controllers; those stay manual and approved.
"""Lab 22: report days until expiry for synthetic IoT logger certificates."""
from datetime import date
today = date(2026, 10, 12)
certs = {"LOG-01": date(2026, 11, 2), "LOG-02": date(2027, 6, 30), "LOG-03": date(2026, 10, 5), "LOG-04": date(2026, 12, 20)}
for dev, exp in sorted(certs.items(), key=lambda kv: kv[1]):
d = (exp - today).days
flag = "EXPIRED" if d < 0 else "renew-now" if d <= 30 else "plan" if d <= 90 else "ok"
print(f"{dev} expires {exp} in {d:4} days -> {flag}")
Run with python3 lab_certs.py. Verified output:
LOG-03 expires 2026-10-05 in -7 days -> EXPIRED
LOG-01 expires 2026-11-02 in 21 days -> renew-now
LOG-04 expires 2026-12-20 in 69 days -> plan
LOG-02 expires 2027-06-30 in 261 days -> ok
Priya's checks start with the certificate expiry check above; its first run found one expired certificate and one due for renewal.
The check reads each logger's certificate expiry from the vendor's export and sorts loggers into expired, renew-now, plan and ok. Its first run gave LOG-03 expired, LOG-01 at 21 days, LOG-04 at 69 days and LOG-02 ok at 261 days.
22.2 Reading the report
LOG-03's certificate expired a week ago, so that logger is probably failing to connect and readings are missing. LOG-01 has 21 days left and needs renewal now, given vendor lead times. LOG-04 should be planned; LOG-02 is fine. Sorting by expiry date puts the urgent items first.
Priya scheduled the check at 06:00 daily. Its first run opened tickets for LOG-03 and LOG-01. The vendor confirmed LOG-03 had stopped uploading on 5 October; the quality manager recorded a seven-day gap in the cloud records for that room, covered by the PLC probe history in HIST.
22.3 Report, do not change
The script prints and could e-mail the report; it does not renew certificates by itself. Renewal goes through the vendor's process, because an automated renewal that fails halfway could leave a logger offline.
Priya's check opens tickets; it does not act. LOG-01, with 21 days left, was renewed through the vendor's process within the week, and the ticket records the new expiry date. Had the script tried to renew LOG-03 automatically and failed halfway, NCS could have lost a second logger without knowing. Keeping the script report-only also means it needs no write access to the vendor portal, so its credentials are worth less if the management host is compromised.
22.4 Scheduling and logging
Run the check daily from a scheduler on a management host in the OT management VLAN, write output to a log with timestamps, and alert if the job did not run. A silent automation failure is worse than no automation, because people stop checking manually.
At NCS the job runs on the OT management host at 06:00, logs each run with its timestamp, and the scheduler raises an alert if no log line appears by 06:15. That alert matters because the certificate check is the only reason anyone looks at logger expiry dates now.
Worked example (synthetic NCS)
Priya schedules the check at 06:00 daily. The first run triggers a ticket for LOG-03 (expired) and LOG-01 (renew now). The vendor confirms LOG-03 stopped uploading on 5 October; the quality manager records a seven-day gap in the cloud records for that room, covered by the PLC probe history in HIST.
Synthetic case — Northgate Cold Storage. Dates and devices are invented.
Errors and limits
The script uses a fixed "today" date so its output is reproducible; a production version would use the current date. Certificate dates must come from the devices or vendor, not from a manually typed table.
Exercises
- EX064 — Changing thresholds. If "renew-now" applied at ≤ 60 days, which devices change status? Rubric: 3 = no status changes, with LOG-04 still "plan" at 69 days; 2 = right conclusion, no reason; 1 = says LOG-04 becomes renew-now; 0 = none.
- EX065 — Using the real date. What line change makes the script use the current date, and what is lost? Rubric: 3 =
today = date.today(); reproducibility of documented output; 2 = one; 1 = vague; 0 = none. - EX066 — Detecting a silent failure. Describe how NCS would notice if the 06:00 job stopped running. Rubric: 3 = heartbeat/expected-log check alerts when no run recorded by deadline; 2 = partial; 1 = "someone notices"; 0 = none.
Synthesis
Automate checks that report clearly and fail loudly; keep changes to OT devices in human, approved hands.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →