At 03:17 the pressure starts to rise. Nobody knows why.
Why it helps to read an attack backwards, from the alarm in the control room to the first compromised PC.
At 03:17 the pressure starts to rise. Nobody knows why. The operator hears the alarm and then looks at the trends. Several of them have started to move a little strangely. Something has changed in the process, but it is not obvious what. Is it an instrument fault, a valve that is not where it should be, an error in the control logic, or something else entirely?
Behind the alarm and the trends: if the cause is a targeted cyberattack, the story hardly began at 03:17. What we see then is only the part of the attack that has finally become physical.
This hidden part of the iceberg is one of the things that makes cyberattacks hard to understand in general, and perhaps especially when the attack moves deep into industrial systems. This is where the ICS Cyber Kill Chain is useful. The model lets us work backwards from the consequence and look at what an attacker actually had to achieve before the pressure could begin to rise. The first attack is about establishing access, learning the system and getting into position. The next is about using that knowledge to develop, test and carry out an attack on the control system itself or on the industrial process.
In my view, the stepwise model is a better thing to look at than a long list of attack techniques. A compromised PC can be the start. Making a specific physical process behave the way the attacker wants is potentially many steps further ahead.
The way in can begin far from the process
The first part of a targeted OT attack can involve perfectly ordinary IT systems. An employee's laptop. The company's website or web server. The access control system for the building where the employees work. In this part of the attack, the attacker does not need to know much about the industrial process. First you have to get in, work out where you have ended up, and understand what opportunities this access can give you further in towards the company's industrial systems.
Further along, the Purdue model provides a new map. It describes functional levels from the enterprise systems at Level 4, through production management and control, down to Level 0, where the physical process actually happens. Level 1 covers the functions that measure and act on the process, while Level 2 monitors and controls it. Level 3 coordinates production operations. The model was originally developed for integrating the various control systems and functions of a company's industrial production process, and it is not in itself a recipe for how a modern OT network should be built. The real architecture, with all its connections and trust relationships, is what determines which path the attacker can actually take.
This also makes the IT/OT boundary more concrete, or perhaps more blurred and harder to oversee, than a line in a network diagram. If, for example, identities are reused across all sorts of systems on the inside, and those identities are exploited or compromised, the attacker may have solved several of their problems at once. The boundary into OT can then be far easier to cross than the architecture drawing suggests. The same applies to external connections, service PCs and other legitimate ways in. Segmentation has value when it creates a real boundary and real resistance in the attack, not because the architecture looks tidy on a drawing.
Getting into OT is not the same as understanding the process
As the attacker moves on, the ICS Cyber Kill Chain separates more clearly from models that primarily describe the compromise of IT systems. Stage 1 can provide a foothold and information about the environment. For an attack that is meant to produce a controlled physical effect, a hard question still remains: what has to be changed in the industrial production process to achieve what the attacker wants?
Suppose the attacker has gained access to an engineering environment. That does not automatically make it obvious which signals matter, or what happens if a value is changed. A valve may be part of sequences and interlocks. A pump may be protected by other logic, redundant pumps or mechanical mechanisms meant to stop problems from developing further. The control system may reject or override a command when other process conditions are not met. And behind the control system there may be safety functions and mechanical barriers that still limit what the attacker can actually achieve.
This is the kind of problem Stage 2 of the ICS Cyber Kill Chain tries to capture. Knowledge gathered earlier is used to develop and possibly test the attack itself against the specific industrial system. The difference lies between having compromised an ICS environment and having understood enough to create a desired physical effect with reasonable predictability.
Stuxnet is the obvious example of how far this can go. What is interesting is the amount of knowledge behind the attack. A targeted attack on a physical process may require an understanding of the control system, the equipment and the process being controlled. At some point the problem stops being purely cybersecurity. The attacker is in practice doing engineering, just with an entirely different purpose from those who originally designed and operate the plant.
This is also where the combination of Purdue and the kill chain becomes useful. Purdue says something about which function the attacker has reached. The kill chain says something about how far the attacker has come in turning that access into an actual effect.
Not every cyberattack needs to get that far
At the same time, an attacker does not need to complete the whole ICS Cyber Kill Chain to cause major problems for an industrial company.
Ransomware is a good example. Production may have to be stopped because systems needed for safe or responsible operation are unavailable, even though the attacker never understood the process logic or sent a malicious command to a controller. There can be serious consequences for production long before anyone has reached Level 0 and tampered with anything down there.
The ICS Cyber Kill Chain becomes particularly interesting when we try to understand targeted attacks where the attacker wants a specific physical effect and needs some control over the outcome. Then access alone is not enough. The attacker has to learn enough about the system and the process to understand what an action will actually do.
This way of thinking also affects how we should build and work with defences. If all the attention goes to stopping the very first part of the attack, we place much of our security right at the start of the chain. A stolen account, a vulnerable server or a compromised client should still not be enough to control a physical process. Every new step should meet new resistance.
That makes it easier to discuss what defence in depth means for OT. Segmentation should limit where a compromised machine can communicate. Remote access should make it harder to use one compromised identity to move on. Engineering changes should be detectable and controllable as engineering changes, not just as general network traffic. The architecture should be built so that access to one system does not automatically grant the same trust further down. There is a lot of sense in Zero Trust thinking here, even though it has to be applied with somewhat different ingredients than is usual in purer IT systems.
When cyber becomes physical
Towards the end of an attack that is actually meant to affect the process, the attacker reaches an interface that is at least as interesting as the divide between IT and OT. It is the interface between digital information and physical action.
A controller calculates a value and sends a signal. An actuator receives the signal and makes a valve move. The flow through the pipe changes, and the pressure somewhere else in the process begins to move. Only when we understand this chain can we say anything precise about what physical consequence a cyberattack can actually have.
It also affects how we design protection. A firewall can stop the traffic. Access control can stop a user. The control system can reject a command that violates its logic. But if a legitimate command still manages to push the process towards a dangerous state, we should know what protection remains, if any.
This is where cybersecurity, engineering and process safety meet. Interlocks, safety functions and physical barriers become interesting to look at together because they can limit how a digital action develops into a physical consequence. It is important that the protection mechanisms are sufficiently independent of each other, so that one fault or one compromise does not negatively affect several of them or trigger a domino effect through the system. If several layers of protection in reality depend on the same system, the same signal or the same access path, several barriers can disappear at once.
So we return to 03:17. The pressure is still rising, and the operator is trying to find the cause. The cyberattack started far higher up in the architecture and long before the first alarm. In the end, it is the physics that decides what the event becomes.
If a mechanical safety valve is the last barrier, it does not need to know whether the pressure rose because of a fault in the control system, a human action or an attacker. It opens when the pressure gets high enough.