ICS vs IT: A Different Set of Priorities

The Priority Order That Changes Everything

Most people who have studied IT security learned a three-letter model early on: CIA, which stands for confidentiality, integrity, and availability. The order is not accidental. It reflects what IT security is chiefly trying to protect, which is data. In industrial control systems, that priority order is almost exactly reversed. This is the most important single difference between the two worlds, and it is easy to misread. Newcomers from IT sometimes conclude that the engineers who built industrial systems simply did not know about security, or did not care about it. Neither is true. The different order is an engineering choice, made deliberately by people who understood that the system they were building could hurt someone if it failed in the wrong way. Once you see why the order is different, a great many things about industrial systems that look odd or even careless from the outside start to make sense: why equipment is kept running for decades, why updates are rare, why a control room reacts with alarm to the suggestion of a quick restart. This chapter explains the two priority orders, the five practical differences that follow from them, and the physical reasons, from processes that cannot stop to separate safety systems, that make availability in an industrial plant a safety issue rather than a business preference.

How IT Thinks About Risk

In IT, the nightmare scenario is a data breach: customer records stolen, financial details exposed, confidential plans leaked. So confidentiality, keeping information away from anyone not authorized to see it, comes first. Integrity, making sure data is accurate and has not been altered, comes second, because a tampered record can be as damaging as a stolen one. Availability, keeping systems up and reachable, comes last. That does not mean IT ignores downtime. An outage costs productivity and money, and users notice quickly. But a server can be taken offline for a patch, rebooted overnight, or restored from backup, and a few hours of downtime, while annoying, is not dangerous. The reason this order works in IT is that the asset being protected is data, and data is remarkably tolerant of interruption. It sits on a disk whether the server is running or not. Switch the machine off and on again and the data is still there, unchanged. A breach, by contrast, cannot be undone: once information has been copied by someone who should not have it, no restart brings it back. So IT logically spends its strongest protection on keeping data private and accurate, and accepts that systems will sometimes have to go down to stay secure.

How ICS Thinks About Risk

In industrial control systems, the order is safety first, then availability, then integrity, and confidentiality last. Each position has a reason. Safety comes first because industrial systems are engineered so that when something fails, the process reaches a safe state, a condition in which it cannot harm people, equipment, or the environment. That requirement overrides every other one, and any measure that would weaken it is unacceptable no matter what else it achieves. Availability is second because the physical process, whether a chemical reaction or a power generation cycle, cannot simply stop when the computer does. The system controlling it has to keep running. Integrity is third. Wrong data is dangerous in a control system, because a false reading can lead to a wrong action, but it is ranked below availability because shutting a process down unnecessarily to protect data integrity carries physical risks of its own. Confidentiality is last. That is not because it does not matter. Process designs and recipes are valuable, and nobody wants them exposed. It is last because a data leak has never directly collapsed a refinery. A process that stops unexpectedly, or runs outside its safe limits, can. The table below sets the two orders side by side.

Five Ways ICS and IT Are Not the Same

The reversed priority order shows up in five practical differences that you will meet again and again in industrial environments. The first is timing. A control loop reads a sensor, applies its logic, and sends a correction back to the process, and in an industrial system that whole cycle may need to complete within milliseconds, every time. IT systems run on a best-effort basis, where a response that arrives a little late is merely slow. Chapter 10 shows what that timing requirement does to network design. The second is hardware lifecycle. IT equipment is typically replaced every three to five years. Industrial hardware commonly runs for twenty years or more, so a plant can be controlled by equipment designed long before the laptop on your desk. The third is the kind of consequence. An IT failure loses records; an ICS failure can injure or kill. The fourth is patching. IT applies security updates frequently, while industrial systems are patched during planned maintenance windows that may be months apart, for reasons this chapter returns to shortly. The fifth is the people. Operators know one process deeply, while IT professionals apply general principles across many systems, a contrast Chapter 4 explores from inside the control room. Each difference follows from the same root: the thing being protected is a running physical process, not a store of data.

What Failure Actually Looks Like

The clearest way to understand the priority order is to compare what failure costs on each side. In IT, a system failure typically means lost productivity, or data that has to be restored from a backup. Those are real costs. A day without a key business system can be expensive, and a lost database can take weeks to rebuild. But the damage stays in the world of information and money, and in most cases it can be repaired. In an industrial control system, failure can mean a refinery explosion. It can mean a city without power for days. It can mean contaminated water reaching hundreds of thousands of people. Those outcomes do not stay inside a computer, and many of them cannot be reversed once they have happened. Damaged equipment has to be rebuilt, a polluted river cannot be restored from backup, and an injured worker cannot be rolled back to yesterday. That is the dividing line between the two worlds. The priority order is not a matter of theory or of professional culture. It is driven by consequence. When the worst realistic outcome of a failure is physical, irreversible harm, it is entirely rational to rank keeping the process safe and running above keeping its data private.

A Deliberate Choice, Not a Gap

It is worth stating plainly, because it is so often misunderstood: the ICS priority order is not a security gap left by engineers who did not know better. It is a design decision made by engineers who understood the physical stakes very well. When an IT system fails, data is at risk. When an industrial control system fails in the wrong way, the physical consequences can be immediate and irreversible, and the engineers who designed these systems built them around preventing exactly that. Seen this way, the priority order does not mean industrial organizations value security less. It means they design for what failure actually costs. This matters for anyone arriving from IT, because the instinct to apply familiar IT practices directly, patch quickly, restart freely, lock things down first and ask questions later, runs straight into the reasoning behind the plant's design. A security measure that is excellent in an office can be harmful in a control room if it interrupts the process or gets in the way of safety. The rest of this chapter looks at the physical facts that make the order necessary, beginning with the question from the opening scenario: why you cannot just reboot.

Why Rebooting Is Not an Option

Industrial control systems are built around two requirements that sit underneath the priority order: reliability and safety. The process must keep running, and it must keep running safely. A reboot threatens both at once, and the reason is that switching off the control system does not switch off the physics. A chemical reaction partway through its cycle, pressurized gas in a pipeline, or a water treatment plant in the middle of dosing chemicals will all carry on without the control system. They simply carry on without guidance, and a process without guidance can drift into an unsafe condition. Even when a shutdown is planned and controlled, getting back to normal is far more involved than pressing a power button. After an industrial system has been stopped, the safety interlocks have to be verified, process measurements have to be brought back into their normal ranges and allowed to settle, product quality has to be checked, and in some industries a regulator has to sign off before production resumes. All of that takes time on top of whatever caused the stop in the first place. So total downtime stretches well beyond the repair itself, and an unplanned stop in a continuous process is never a five-minute event.

Processes That Cannot Stop

Some industrial processes are continuous by physical necessity, and for them stopping is not merely inconvenient. It is a hazard. You cannot switch a nuclear reactor off and restart it like a server. A distillation column processing crude oil, the tall tower in a refinery that separates oil into its components by heating it, takes days to shut down safely and days more to bring back up. A city's water system cannot accept unplanned downtime while residents are left without clean water. In each case the process has momentum of its own, in the form of heat, pressure, chemical reactions, or the simple fact that people depend on it every hour of the day. Bringing such a process to a stop has to be done gradually, in a controlled sequence, by people who know exactly which steps come first. An abrupt stop, the kind a crash or an ill-judged restart causes, skips that sequence and can leave equipment, product, and people in a dangerous condition. This is why the control systems running these processes are expected to keep working without interruption for years, and why everyone who works on them treats any action that could stop them with great caution.

The Safety Instrumented System

Because the consequences of losing control are so serious, critical facilities do not rely on a single control system. Alongside the normal control system that runs the process day to day, sometimes called the basic process control system, they run a separate layer called a safety instrumented system (SIS). The SIS has one job: to watch for dangerous conditions and bring the process to a safe state if one appears. It does this independently of the main control system. If pressure in a vessel exceeds its safe limit, the SIS triggers an emergency shutdown automatically. It does not wait for an operator to notice. It does not check with the main controller first, and it does not care what the main controller is doing. It acts on its own. The SIS is also designed to fail safe, which means that if it loses power or a sensor develops a fault, it defaults to a known safe state rather than leaving the process uncontrolled. A useful way to think of it is as an independent guardian standing beside the process, with its own sensors, its own logic, and the authority to stop everything. How reliably a safety function performs is formally rated by its Safety Integrity Level (SIL), under the IEC 61508 standard, and the more dangerous the process, the higher the rating required, with more redundancy and more rigorous testing to match. That is exactly why a safety instrumented system is never something to change casually.

Why Patching Takes Months, Not Minutes

In IT, applying a security patch takes minutes: apply it, reboot, done. Some organizations patch as often as weekly. In an industrial control system, the same task starts months earlier, and every step exists for a reason rooted in the priorities above. First, engineers have to identify a maintenance window, a planned period when the process can be taken offline or into a safe condition. In a continuous process, that window may come only once a year. Second, the patch is tested on an identical offline system before it goes anywhere near the real one, because an update that disturbs the control logic or the timing could disturb the process itself. Third, on the day, operations confirms that the process is in a safe state before any change is made, so that if something does go wrong, nothing dangerous is happening at the time. Only then is the patch applied. Each step is a sensible answer to the question of what could go wrong, and together they mean that the patching cadence considered normal in IT is simply not possible in an industrial plant. It is also one of the reasons so much older equipment stays in service far longer than its IT equivalent would.

Availability Is Safety

All of this leads to the central idea of the chapter. In IT, a system going down costs money. In an industrial control system, a system going down can cost lives. When the control system fails, operators lose visibility of a process that is still running, so they can no longer see the temperatures, pressures, and levels they rely on to keep it safe. Safety interlocks, automatic circuits that halt equipment before damage occurs, may be disrupted. And recovering the process to a safe state can take hours. This is why keeping the system running ranks above protecting its data. It is not a business preference, and it is not a sign that security matters less. It is a safety requirement. The IT world grew up with weekly patch cycles and routine reboots. The industrial world grew up with continuous processes that never stop. For decades these two worlds rarely touched, but today they share networks and data connections, and the friction between their rules is the source of almost every major ICS security challenge, as Chapter 13 explains. For now, the lesson is simpler: safety requirements, patching constraints, and uptime demands are not obstacles to be worked around. They are the context that every decision about an industrial system has to work within.

What's Next

You now know why industrial systems put safety and availability first, and why that choice shapes everything from patching to how a plant reacts to a restart. The next question is how all of these systems are organized. Chapter 3 introduces the Purdue Model, the map that divides an industrial environment into levels, from the physical process at the bottom to the corporate network at the top, and explains why that separation is an engineering requirement rather than a matter of taste.

Reflect

• If you come from IT, which of your everyday practices, such as restarting a system to clear a fault or patching quickly, would you need to rethink before applying it to a running plant?
• For a process you know, what would actually happen in the first ten minutes if its control system stopped without warning?
• How does your organization currently decide when a change to a critical system is safe to make, and who has the final say?
• Which of the five differences between ICS and IT do you think causes the most friction when IT and operations teams work together, and why?
• What would change in a conversation between an IT security team and a plant team if both sides started from the question "what does failure actually cost here?"