When you move from securing data to securing physical processes, the entire game changes. In industrial control systems (ICS), your security decisions can stop a turbine, overflow a tank, or impact human safety. That’s why simply “copy‑pasting” IT security controls into OT environments fails—and sometimes creates more risk than it removes.
This post is for the people who live in that tension every day: control engineers, ICS security teams, and the leaders accountable for both uptime and safety.
OT vs IT: Same threats, different consequences
On paper, IT and OT networks can look similar—servers, workstations, switches, firewalls, remote access. In reality, they serve fundamentally different purposes:
– IT exists to store, process, and move information.
– OT/ICS exists to monitor and control physical processes.
In IT, the worst‑case scenario you’re usually optimizing for is data loss, data theft, or business disruption. In OT, the worst‑case scenario involves physical damage, environmental impact, and safety incidents. That difference is why the familiar CIA triad flips in importance the moment you cross into a control network.
The CIA vs AIC triad: what changes in ICS
Most security professionals grow up on the CIA triad:
– Confidentiality – keep data secret
– Integrity – keep data correct
– Availability – keep systems and data accessible
In enterprise IT, the implicit order of priority is often: Confidentiality → Integrity → Availability.
In OT/ICS, the effective order becomes:
– Availability – the process must keep running safely
– Integrity – data and commands must be trustworthy
– Confidentiality – still important, but rarely the first driver
You can think of it as the AIC triad.
A concrete example:
– In IT, a 2‑hour outage of the CRM is bad, but a large data breach is career‑defining.
– In OT, a 2‑hour outage at a power plant, or a corrupted level reading that leads to a spill, can be catastrophic—even if no sensitive data ever leaves the site.
Once you accept that AIC, not CIA, is the north star for ICS, a lot of other “strange” decisions start to make sense.
Availability: why downtime is existential in ICS
In an ICS, availability is not a KPI—it’s a safety and business requirement.
A control system outage can cause:
– Unplanned production stoppages across entire plants or lines
– Stress and damage to equipment from uncontrolled shutdowns and restarts
– Environmental releases if materials aren’t managed correctly
– Safety incidents for operators and the public
That’s why “just unplug it” or “block everything until we’re sure” is not a reasonable default in OT. Any action that disrupts communications or control has to be weighed against its physical and operational impact.
For leaders, this is the first major mindset shift:
In ICS, the cost of downtime often dwarfs the cost of a typical IT security incident.
Integrity: the hidden pillar that makes or breaks safety
An ICS that is “up” but lying to you is worse than one that is obviously down.
If an attacker—or an unintentional fault—tamers:
– Sensor readings (level, pressure, temperature, flow)
– Control logic or setpoints
– What operators see on HMIs or in the historian
then highly skilled operators can make the wrong decisions for the right reasons.
Examples:
– A tank level that appears safe but is actually climbing
– A pump that appears off but is in fact running dry
– A protection relay that appears healthy but has altered settings
That’s why integrity sits right behind availability in the ICS world. A safe operation requires both: the system must be running, and the information and commands must be trustworthy.
The landscape has shifted: more connectivity, more pressure
Historically, ICS risk was “managed” with isolation: air gaps, serial links, and proprietary protocols few people understood. Today, that’s not the reality:
– Plants and utilities connect to enterprise IT for analytics, planning, and maintenance.
– Vendors and integrators need remote access to support and maintain systems.
– IIoT sensors stream data to the cloud.
– Boards and regulators demand better visibility, reporting, and resilience.
The threats have converged, but the constraints have not. Trying to force pure IT patterns (always‑on IPS, heavy endpoint agents, “patch immediately”, “pull the plug” IR) into OT can badly misalign with AIC priorities.
The right approach is to adopt modern controls that respect OT constraints, not to ignore OT or exempt it from serious security.
IDS vs IPS in ICS: see everything, break nothing
Deep inspection is essential in modern ICS security—but how you deploy it matters.
Why IDS is usually the first choice
An intrusion detection system (IDS), especially one that understands OT protocols and runs passively, is a natural fit for control environments:
– It monitors traffic without sitting inline.
– It decodes industrial protocols and flags suspicious commands or behaviors.
– If it fails, your process keeps running; you lose visibility, not control.
This aligns with AIC:
– Availability is protected because IDS doesn’t block traffic.
– Integrity is enhanced by detecting abnormal or malicious traffic affecting process data and commands.
Why IPS can be dangerous deep in the control network
An intrusion prevention system (IPS) sits inline and can automatically block traffic it considers malicious. This is powerful in IT. In OT, it introduces new failure modes:
– A false positive can block legitimate control traffic between HMIs, PLCs, and safety systems.
– A device failure can sever critical communications entirely.
– A new rule deployed carelessly becomes an operational risk, not just a security change.
This doesn’t mean IPS has no place around OT. It means:
– Use IPS carefully at the edges—for example, between IT and OT, or at the site perimeter—where blocking traffic won’t immediately compromise real‑time control.
– Deeper in the ICS, favor detection + segmentation + allow‑listing over automatic blocking.
For executives, the decision frame is simple:
“Where will an incorrect block rule hurt us more than the attack we’re trying to stop?”
Why traditional anti‑malware doesn’t simply “lift and shift”
Endpoint protection is another area where IT muscle memory can collide with OT reality.
Standard enterprise anti‑malware assumes:
– Modern, supported operating systems
– Powerful CPUs and plenty of RAM
– Regular reboots and maintenance windows
– Frequent signature updates over reliable networks
– No impact from occasional CPU or disk spikes
ICS environments frequently offer the opposite:
– Legacy OS versions that can’t be upgraded easily
– Vendor‑locked images where adding software may void support
– Systems that run 24/7 with extremely limited downtime
– Real‑time applications sensitive to latency and I/O contention
– Restricted networks where internet updates aren’t possible or allowed
When you install traditional AV on these systems, you risk:
– Scans freezing HMIs or engineering workstations at critical moments
– Agents conflicting with vendor drivers or custom runtimes
– Updates requiring reboots you cannot perform during normal operations
A more ICS‑aligned pattern looks like this:
– Use purpose‑built OT endpoint security where possible: very lightweight agents or application allow‑listing tuned for control systems.
– Avoid installing agents on hard real‑time devices like PLCs and safety controllers; protect them with segmentation, access control, and network monitoring instead.
– Treat any change to a control endpoint (including security software) as a controlled engineering change, not a quick fix.
For leaders, the key takeaway:
“More agents” is not the same as “more security” in OT. The wrong agent in the wrong place can reduce availability and trust in the system.
Patch management in ICS: security changes become engineering changes
In the enterprise, patching is straightforward: deploy quickly, accept some disruption, roll back if needed. In ICS, patching looks more like changing out components on a live production line.
Each patch can:
– Change timing or performance characteristics.
– Affect vendor‑validated configurations.
– Require reboots or failovers that directly affect the process.
A mature ICS patch strategy treats updates as engineering changes, not just IT tasks.
A practical ICS patching approach
1. Prioritize by risk and criticality
– Not every vulnerability is exposed in your architecture.
– Not every asset is equally critical to safety or production.
– Focus first on exposed, high‑impact issues on critical assets.
2. Test in a representative environment
– Maintain a lab or staging environment that mirrors production as closely as practical.
– Test not just “does it boot?” but “does it perform correctly under real workloads?”
– Validate vendor support and interoperability after patching.
3. Roll out in controlled phases
– Patch low‑risk or redundant systems first and monitor.
– Schedule maintenance windows for critical systems with clear rollback plans.
– Coordinate with operations so everyone understands what’s changing and what to watch.
4. Use compensating controls when you cannot patch
– Tighten access, segmentation, and monitoring around unpatched assets.
– Limit who can reach them, from where, and how.
– Build a long‑term plan to replace or redesign truly unpatchable systems.
From the C‑suite perspective, this often requires resisting the simplistic directive “patch everything immediately” and instead asking, “How do we reduce risk without compromising safety and continuity?”
Incident response: why “pull the plug” can be the wrong answer
Most IT incident response training assumes one primary objective: contain quickly.
That often translates to:
– Disconnect affected systems from the network.
– Block large swaths of traffic.
– Power down or reimage systems.
In ICS, these same actions can:
– Stop pumps, compressors, or turbines without proper shutdown procedures.
– Break safety‑critical communications.
– Violate regulatory and operational constraints.
The first priority: keep the process safe
An ICS incident response plan must start from a different premise:
– The primary objective is safe and stable operation of the process.
– Containment actions must be evaluated for their operational impact before execution.
– Security, engineering, and operations must act as a joint team, not silos.
Practically, this means:
– Pre‑defined safe states and shutdown procedures for critical processes.
– Clear rules on what security can and cannot touch without operations sign‑off.
– The willingness to run in a controlled but degraded state temporarily while you gather information and prepare a safe transition.
– Playbooks that integrate OT forensics with plant procedures, not just log collection and disk imaging.
For executives, the litmus test is simple:
“If our SOC follows its standard IT playbook during an ICS incident, would we be comfortable with the operational consequences?”
If the answer is “not really,” you have work to do on OT‑aware IR.
What this means for leaders and practitioners
If you interact with or secure ICS networks, or you’re accountable for their risk at the executive level, there are a few clear action points:
– Anchor on AIC, not CIA, for OT
ensure your risk discussions, control choices, and KPIs reflect the reality that availability and integrity are the primary drivers for ICS.
– Stop copy‑pasting IT controls into OT
, evaluate IDS/IPS, endpoint security, patching, and IR through the lens of process impact. A good IT control applied the wrong way in OT is not a win.
– Invest in visibility and
Prioritize high‑fidelity asset inventory, passive monitoring, and OT‑aware IDS. You can’t defend what you can’t see, and you shouldn’t block what you don’t fully understand.
– Treat security changes as engineering changes
whether it’s a patch, an AV rollout, or a new firewall rule, build a culture where security changes in OT go through the same rigor as changes to control logic.
– Build joint OT–IT governance and response
, OT security is not “just IT down in the plant.” It’s a partnership with engineering and operations that needs clear ownership, shared language, and aligned incentives.
Done right, ICS security is not about choosing between safety, uptime, and cyber resilience. It’s about designing a program where those goals reinforce each other. That’s the standard your teams—and your regulators and customers—will increasingly expect.
