Mattias Pilroth
OT security architecture
I arrived at security architecture through operations. That origin determines what I treat as demonstrated and what I treat as assumed.
The consequence question
A plant run by a control system can be driven by that control system, and so by whoever holds its commands, however they came to hold them.
A safety case credits a safety instrumented function on the condition that it is independent of the cause it protects against. Where one configuration authority can both create the demand on that function and defeat it, the condition does not hold against a deliberate cause, and the credit against that cause is lost, not reduced.
Whether anything stands between one compromised authority and an outcome the operator cannot accept is a question about the plant, and it has an answer. For each named outcome a bound is established, a bound is absent, or the evidence cannot settle it, and whichever it is can be shown wrong by someone holding better records.
The security programme is the correct instrument for everything a compromise can reach that the operation can recover from and may carry as ordinary loss. Beyond that range it does not establish whether a bound holds.
Demonstrated, assumed, or ruled out. No required review determines which.
The work
Argument
Keeping the commands in the right hands is one question, answered by a programme attested for presence and maintained continuously. Establishing what the plant can be driven to is another. Inside its working range compliance is the correct instrument, and it still cannot establish that an unacceptable outcome is bounded.
Where one configuration authority can create the demand and defeat a credited safety function, the function's integrity level does not entitle it to partial credit against that cause. A probability derived from the security measures in place is no substitute, because it describes a different conditional event, and where the scenario cannot be characterised to the assurance the safety case requires, removing the coupling is what closes the question.
Context
OT environments appear static because deliberate change is slow, a consequence of how they were validated, funded and operated, while their actual condition keeps moving. A security strategy that ignores those constraints is overridden by them.
OT systems drift from their commissioning state without producing any signal that demands correction. Security controls depend on operational conditions, and a control being present does not establish that the conditions it depends on still hold.
About
My background runs from field automation engineering and EPCM project delivery in oil and gas and petrochemicals, through six and a half years of operational responsibility for the full OT estate at a SEVESO-classified chlorovinyl production facility, to enterprise OT security architecture across 14 chemical manufacturing sites in 8 European countries. It includes work with control and safety instrumented systems under the IEC 61511 lifecycle, and with the network, identity and platform infrastructure that carries authority across the IT and OT boundary.
Contact: mattias@pilroth.com