Where Cybersecurity Meets Process Safety: IT/OT/Safety Convergence
- functional safety, ICS cyber security, ot cyber security, process safety, risk assessment
OT Cybersecurity Fundamentals — Estimated reading time: 12–14 minutes
Introduction
Let us take a look at the following statement:
“A cyber incident begins in the digital domain. A process-safety incident occurs in the physical domain. In an industrial facility, those domains are connected. A malicious command can move a valve. A manipulated setpoint can change pressure. A false sensor value can mislead an operator. Modified controller logic can change equipment behavior. Compromised protection logic may prevent a system from responding when a hazardous condition occurs.”
The important question is therefore not simply:
“Can the attacker compromise the controller?”
It is:
“What physical consequence becomes possible if the attacker succeeds?”
That question is where cybersecurity and process safety meet.
From Digital Action to Physical Consequence
A useful model is:
Cyber Action -> Control-System Effect -> Process Deviation -> Safeguard Response or Failure -> Physical Consequence
Consider a tank-transfer system. An attacker changes the pump logic. That is the cyber action.
The pump continues operating. That is the control-system effect.
Tank level rises above the intended range. That is the process deviation.
The process may then depend on:
- Operator action
- Independent alarm
- Shutdown function/SIS
- Mechanical safety protection (PRV)
- Containment
Whether the event becomes an accident depends on those protections.
This is why cyber risk assessment in OT should not end with statements such as:
“PLC compromise = high risk”
The process consequence needs to be understood.
Several Paths from Cyber to Safety
Cyber compromise can affect process safety in several ways.
1. Manipulating the Process Directly
An attacker may modify:
- Setpoints
- Controller logic
- Equipment commands
- Valve positions
- Motor states
- Sequence logic
Examples include causing:
- High pressure
- High temperature
- Low flow
- Overflow
- Loss of cooling
- Equipment overspeed
- Loss of lubrication
The cyber activity is digital, but the consequence is governed by process physics.
2. Manipulating What Operators See
Operators depend on accurate information.
An attacker may attempt to alter:
- HMI displays
- Alarm indications
- Historian data
- Sensor values
- Equipment status
This creates a different problem
The physical process may already be moving toward an unsafe condition while the operator sees apparently normal values. Integrity therefore becomes particularly important in OT.
3. Inhibiting Protection
The attacker may interfere with the mechanism designed to respond to an abnormal condition.
MITRE ATT&CK for ICS calls this Inhibit Response Function—behavior intended to prevent safety, protection, quality, or operator-intervention functions from responding properly. Examples might include:
- Suppressing alarms
- Modifying shutdown logic
- Disabling protective functions
- Preventing command execution
- Manipulating logic used during abnormal conditions
This is where cybersecurity and functional safety intersect most directly.
4. Removing Visibility or Support
An attacker may not manipulate the process directly. Instead, the incident may remove something operations depends on:
- Historian
- Engineering workstation
- Operator interface
- Communications
- Authentication
- Supporting servers
- Business systems
- Remote engineering capability
The resulting uncertainty may force operations to reduce production or shut the process down.
Again, Colonial Pipeline demonstrates that operational impact does not require malware directly controlling the physical process.
TRITON: When the Protection Layer Becomes the Target
TRITON/TRISIS deserves special attention because it targeted the safety-system environment.
CISA states that actors gained access to and manipulated safety devices at a Middle East energy-sector organization in 2017. The malware interacted with Triconex safety controllers used to monitor industrial processes and prevent hazardous conditions
This creates a fundamentally different concern from ordinary IT compromise.
Imagine an attacker who can:
- Manipulate the process through the BPCS, and
- Interfere with the independent safety function expected to stop the resulting hazardous condition
The combination is much more serious than compromising one workstation.
TRITON therefore reinforces an important principle:
Safety systems are not automatically protected merely because they are safety systems.
- Their cybersecurity architecture matters
- Their access paths matter
- Their engineering workstations matter
- Their configuration management matters
- Their independence matters
Cybersecurity and Process Safety Have Different Failure Assumptions
Traditional process-safety engineering often focuses heavily on:
- Random equipment failure
- Systematic design failure
- Human error
- Process deviation
- Mechanical failure
Cybersecurity introduces something different:
“Intentional manipulation by an intelligent adversary”
An accidental failure does not study the plant. An adversary can.
An accidental failure does not deliberately choose the weakest common dependency. An adversary may.
An accidental failure does not intentionally hide itself from the operator. An adversary can attempt to.
This does not invalidate process-safety methods. It means those methods may need to consider cyber-enabled initiating causes and common-cause vulnerabilities.
Enter Cyber-Informed Engineering
This is where Cyber-Informed Engineering, or CIE, becomes valuable.
Idaho National Laboratory describes CIE as an approach that integrates engineering and cybersecurity throughout the lifecycle of critical systems so that digital compromise is less able to translate into physical harm.
The idea is powerful because it changes the question.
Traditional cybersecurity often asks:
How do we prevent the attacker from getting in?
CIE also asks:
If the attacker does get in, how do we prevent digital access from producing the unacceptable physical consequence?
INL highlights engineered measures such as:
- Manual overrides
- Analog redundancy
- Resilience mechanisms
- Functional isolation
as examples of approaches that can constrain physical harm even when digital systems are compromised.
Assume Some Digital Defenses Will Eventually Fail
A mature engineering approach should avoid depending on the assumption:
“The firewall will stop it.”
The firewall is important.
So are:
- Network segmentation
- Endpoint protection
- Secure remote access
- Monitoring
But a determined adversary may eventually bypass or defeat some digital controls.
Consequence-driven and cyber-informed approaches therefore ask:
What is the unacceptable consequence?
Then:
Which digital pathways are required to create it?
Then:
Can we eliminate, constrain, monitor, or engineer around those pathways?
INL’s Consequence-driven Cyber-informed Engineering methodology explicitly starts from critical consequences and considers ways to remove or disrupt digital attack vectors to critical operations.
“Safety Cannot Be Patched — It Must Be Engineered”
This phrase needs careful interpretation.
It does not mean:
- Never patch an SIS
- Software maintenance is unimportant
- Cybersecurity controls do not matter
It means:
A safe process cannot be created simply by adding cybersecurity controls after the engineering design is complete.
Suppose a process has a hazardous condition that can be created remotely through one controller.
Suppose the same engineering workstation can also modify the protective logic.
Adding another antivirus agent does not resolve the fundamental architectural dependency.
The stronger solution may involve:
- Independent protection
- Different access paths
- Physical or functional separation
- Restricted engineering capability
- Manual recovery capability
- Hardwired protection
- Diverse technology
- Controlled states
- Mechanical protection
Security becomes part of engineering rather than an overlay around engineering.
Cybersecurity Controls Can Also Affect Safety
The relationship works in both directions. Cybersecurity is intended to reduce risk. But a poorly designed cybersecurity control can create operational risk.
Examples:
Authentication
Stronger authentication may reduce unauthorized access.
But what happens if the authentication infrastructure is unavailable during an emergency?
Firewall Changes
A rule may correctly block unnecessary communication.
But what happens if it also blocks a required safety-related diagnostic or operational dependency?
Endpoint Protection
Security software may reduce malware exposure.
But what happens if it consumes resources or causes false positives or false negatives on its protected system?
Incident Response
Disconnecting a compromised system may make sense from an IT perspective.
But what happens if that system provides operators with essential process visibility?
This is why OT cybersecurity changes require engineering validation.
Management of Change Becomes a Cybersecurity Issue
Process industries already understand Management of Change, or MOC.
Cybersecurity should connect to that discipline when a security modification can affect:
- Process behavior
- Control logic
- SIS
- Network architecture
- Engineering access
- Safety-related communications
- Operating procedures
A firewall change affecting an SIS is not merely a firewall change.
A new authentication mechanism on an engineering workstation is not merely an identity-management project.
A firmware upgrade is not merely vulnerability remediation.
The operational and safety effects must also be considered.
One Event, Several Owners
Imagine suspicious SIS engineering activity is detected.
Cybersecurity may own:
- Log analysis
- Account investigation
- Network evidence
- Threat containment
OT engineering may own:
- Controller configuration
- Logic review
- Architecture
- Restoration
Operations may own:
- Current process state
- Production decisions
- Local verification
Process safety may own:
- Functional-safety implications
- MOC
- Confirmation that safety requirements remain satisfied
Management may own:
- Risk acceptance
- Shutdown decisions
- Business consequences
No one discipline can manage the entire event alone.
Convergence Does Not Mean Organizational Merger
“IT/OT/safety convergence” should not be interpreted as:
Everyone becomes one department.
The disciplines remain different.
They have different expertise.
They may have different accountable owners.
Convergence means their decisions increasingly affect one another.
The goal is therefore:
Shared understanding + Defined interfaces + Clear ownership
Key Takeaway
- Cybersecurity protects digital systems.
- Process safety protects the process from hazardous events.
- Functional safety ensures safety-related functions perform correctly when required.
- In modern industrial environments, those responsibilities intersect.
A mature organization therefore asks:
If this digital system is compromised, what can happen physically?
and:
Which independent engineering protections prevent that cyber compromise from becoming an unacceptable consequence?
That is the foundation of cyber-informed engineering.
But it creates another question.
Cybersecurity controls cannot be designed around security alone. They must preserve the characteristics that make industrial systems operable.
