Chapter 7 — OT, IoT and cyber-physical security: organizational integration
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 The ownership problem"]
N2["7.2 A RACI for three processes"]
N3["7.3 Change management"]
N4["7.4 Metrics"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 The ownership problem"]
N2["7.2 A RACI for three processes"]
N3["7.3 Change management"]
N4["7.4 Metrics"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 The ownership problem]
|
v
[7.2 A RACI for three processes]
|
v
[7.3 Change management]
|
v
[7.4 Metrics]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) design OT security roles and responsibilities across IT, operations and engineering; (2) build a RACI for key OT security processes; (3) integrate OT security into change management; and (4) set metrics that drive the right behaviour.
7.1 The ownership problem
In many utilities IT owns the network up to a firewall, operations owns the process, engineering owns the controllers and nobody owns the space where they meet. NIST SP 800-82r3 recommends a cross-functional team for OT security, with clearly assigned authority. Integration means writing down who decides, not only who advises.
At BWRP that space includes the DMZ firewall, the vendor broker and the cellular links to lift stations. Each needs a named owner with authority to approve changes and to act in an incident. Writing it down often reveals that two teams believed the other owned it, which is exactly the gap an attacker or a fault exploits.
7.2 A RACI for three processes
For remote-access approval: the shift supervisor is Responsible for enabling sessions; the OT security lead is Accountable for the policy; the vendor manager is Consulted; IT security is Informed of each session. For PLC logic change: control engineer Responsible, engineering manager Accountable, operations Consulted, OT security Informed and alerted. For OT incident declaration: shift supervisor Responsible for raising, plant director Accountable, OT security and IT Consulted, regulator Informed when thresholds are met.
Check each row for exactly one Accountable party and at least one person who does the work. Share the table with every role it names and ask whether they agree; a role that learns from the table that it is Accountable for something has not yet accepted it. Review the RACI after organisational changes and after any incident that tested it.
7.3 Change management
Every change to an OT system passes a change board that already exists for safety and reliability. Adding three security questions to its form — does this change add a conduit, change an account, or alter firmware? — integrates security without a parallel bureaucracy.
Each yes answer then triggers a defined action: a new conduit needs a firewall rule and an owner; a changed account needs a review of who can use it; altered firmware needs a check against vendor advisories and a backup taken first. The board already understands safety and reliability questions, so the security questions should be phrased the same way.
7.4 Metrics
Measure what you want more of. "Number of vulnerabilities" rewards not looking. Better: percentage of OT assets in the inventory with known firmware versions; median days to apply high-risk OT patches within available windows; percentage of vendor sessions with recordings reviewed. Each metric names a denominator.
Each metric also needs a baseline and a target date. BWRP's dashboard starts from 14 of 23 RTUs in the inventory and 0 of 37 vendor sessions reviewed since March, so progress is visible from the first report. Review each definition with the people it measures, so that the metric changes behaviour rather than reporting.
Worked example (synthetic BWRP)
Daniel's integration plan: OT security lead reports to the plant director with a dotted line to the CISO; change-board form gains three questions; quarterly dashboard shows inventory completeness (today 14/23 RTUs plus 41/41 plant assets), vendor-session review rate (today 0/37 sessions reviewed since March) and restore-test currency.
Synthetic case — Bayside Water Reclamation Plant. Structure and figures are invented.
Errors and limits
RACI tables fail if two parties are both Accountable. Metrics can be gamed; review definitions annually.
Exercises
- EX031 — Spotting a RACI error. A draft lists both IT security and the plant director as Accountable for incident declaration. What is wrong and how to fix it? Rubric: 3 = one Accountable only; director A, IT C; 2 = problem only; 1 = accepts; 0 = none.
- EX032 — Three change-board questions. Rewrite the three security questions so a non-specialist can answer them yes/no. Rubric: 3 = three clear yes/no questions; 2 = two; 1 = jargon; 0 = none.
- EX033 — A metric that backfires. Explain how "zero open OT findings" could backfire. Rubric: 3 = discourages reporting/finding; incentivises closing without fixing; 2 = partial; 1 = vague; 0 = none.
- EX034 — Inventory completeness figure. Compute BWRP's combined inventory completeness. Rubric: 3 = 55/64 ≈ 85.9 %; 2 = right fraction; 1 = 14/23 only; 0 = none.
- EX035 — Reporting line choice. Give one advantage of the OT security lead reporting to the plant director rather than the CISO. Rubric: 3 = authority over operations decisions, process context; 2 = vague; 1 = minimal attempt; 0 = none.
Synthesis
Integration is explicit authority, embedded change questions and metrics with denominators that reward finding and fixing.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →