OT/ICS Security Foundations
The core mental model every OT security program needs: why IT and OT priorities differ, how the Purdue model organizes an industrial network, and what actually breaks when an ICS protocol is abused.
IT vs OT: Why Traditional Cybersecurity Doesn't Just Transfer
The single biggest mistake an experienced IT security professional makes on their first OT project is assuming the same instincts apply. They mostly do not, and understanding why is the foundation of every good OT security decision that follows. In IT, patching quickly is almost always the right default response to a vulnerability. In OT, patching a controller that has been running a specific firmware version for eight years, validated against a specific safety case, can introduce more operational risk than the vulnerability itself -- an untested patch that causes an unplanned outage in a live process can be far more damaging than a theoretical exploit that has never been seen against that asset. This is why OT patching decisions are usually made jointly with process engineers, on planned maintenance windows, after compatibility testing -- not pushed automatically overnight. In IT, rebooting a server to apply a fix is routine. In OT, rebooting a controller can mean a physical process stops -- a pump, a valve, a signal -- and depending on the system, that can have safety consequences, not just downtime cost. Availability requirements in OT are often measured in the ability to run continuously for years, not the ability to tolerate brief planned outages. In IT, replacing an asset every three to five years is normal. In OT, a PLC or an RTU might run for two or three decades, which means many OT environments are permanently running systems that will never receive a vendor security update again -- making network-level compensating controls (segmentation, monitoring, strict access control) far more important than patch management as a primary defense.
The Purdue Model and Network Segmentation
The Purdue Enterprise Reference Architecture (often just called 'the Purdue model') is the classic mental map for organizing an industrial network into layers, and even where a real network does not match it perfectly, it is still the fastest way to reason about where an attack would have to travel to reach something that matters. At the top, Level 5/4 is the enterprise IT network -- email, ERP, general business systems. Level 3 is operations management -- historians, MES systems, engineering workstations that coordinate across the plant but are not directly controlling equipment. Level 2 is supervisory control -- HMIs and SCADA servers that operators actually watch and interact with. Level 1 is basic control -- the PLCs and RTUs directly issuing commands to field equipment. Level 0 is the physical process itself -- sensors, actuators, motors, valves. The security logic of this model is simple: the deeper an attacker has to travel from Level 5 toward Level 0, the more segmentation boundaries, monitoring, and friction they should encounter, because the consequence of compromise increases as you get closer to the physical process. A well-segmented environment does not just have a single firewall between 'IT' and 'OT' -- it has a demilitarized zone (the famous 'Level 3.5 DMZ') that mediates all traffic between the two, with no direct path from the enterprise network straight into Level 1 or 2. Modern architectures increasingly use IEC 62443's zones and conduits alongside or instead of a strict Purdue layer count, especially for distributed environments like substations or pump stations that do not map neatly onto a single-site factory model. But the underlying principle survives either way: distance and friction between the enterprise network and the physical process is the primary defense, not a single perimeter control.
Common ICS Protocols and Their Weaknesses
Most industrial protocols were designed decades ago for reliability on isolated networks, not for security against a networked adversary -- and understanding their weaknesses is essential for reasoning about what a compromise on an OT network can actually accomplish. Modbus, one of the most widely deployed protocols in industrial environments, has no authentication and no encryption in its classic form: any device that can reach a Modbus server on the network can issue read and write commands, including commands that change output states. This is precisely why network access control matters more than protocol hardening for legacy Modbus deployments -- the protocol itself will not stop an attacker who has network reachability. DNP3, common in utility and substation environments, added optional secure authentication in later revisions, but a large installed base still runs without it, and DNP3 traffic that reaches an unsegmented WAN link (common in geographically distributed utility networks) extends the attack surface far beyond a single site. OPC (and OPC UA, its more modern successor) is used heavily for interoperability between different vendors' systems. OPC UA meaningfully improved on classic OPC by adding authentication and encryption as first-class features, but the security benefit only materializes if those features are actually configured and enforced -- OPC UA can still be deployed insecurely if default or permissive settings are left in place. The practical takeaway for a security program is not to try to 'fix' these protocols -- most cannot be meaningfully hardened at the protocol layer without vendor and lifecycle constraints -- but to treat network segmentation, strict access control, and monitoring for anomalous command patterns as the primary compensating controls.
Safety, Availability, and the Real Cost of an OT Incident
When people estimate the cost of an OT cybersecurity incident, they often default to IT-style thinking: downtime cost, incident response fees, maybe a regulatory fine. That framing consistently understates the real exposure in critical infrastructure, where the cost model includes categories that simply do not exist in most IT breaches. Safety consequence is the most serious category and the one that most differentiates OT risk from IT risk: an attack that manipulates a safety instrumented system, disables an interlock, or causes equipment to operate outside safe parameters can cause injury or loss of life. This is why safety-critical zones typically receive the strictest security controls and the most conservative change management, even when the underlying technology looks similar to less critical systems. Availability and process consequence come next: a shutdown of a power substation, a water treatment interruption, or a rail signaling outage does not just cost the operator money -- it affects the public the infrastructure serves, sometimes immediately and sometimes over prolonged recovery periods, since restarting some industrial processes safely takes far longer than simply restoring a server from backup. Recovery complexity is its own cost category: OT environments frequently mix legacy and modern equipment, run vendor-specific configurations that are poorly documented, and require physical presence to fully validate that a system is safe to bring back online -- recovery cannot be treated as a purely digital restoration process the way it often can in IT. Finally, trust and regulatory consequence matters at a different scale for critical infrastructure operators: a public-facing incident affecting essential services draws regulatory scrutiny, public attention, and sector-wide response obligations that a typical corporate data breach usually does not.