If you purchased, borrowed or otherwise picked up this book, there is a good chance you are concerned about Industrial Controls System or ICS security in some way. Along with regular cyber security, ICS security is a hot topic these days. Not a day goes by without some company getting compromised, critical infrastructure controls systems getting infiltrated or our personal information getting splattered all over the internet. As a matter of fact, while writing this book, the following major security events occurred, some even influenced the material of this book:
- In May of 2017 the WannaCry ransomware severely impacted the National Health Service (NHS) and locked hospital workers out of critical healthcare patient data:
- In June of 2017 it is discovered that a sophisticated piece of malware, named Crash Override, targeted infrastructure companies in the United States and Europe in 2014 and brought down the Ukraine electric utilities in 2015. At first it was believed the attacks were random acts of aggression with limited intelligence. Research, performed by Dragos unveiled malicious code that sets a new level of sophistication in ICS targeted malware:
- In July of 2017 the NotPetya WiperWorm causes major downtime and revenue loss for companies like companies the Oreo cookie maker Mondelez, drug maker Merck and car manufacturer Honda:
- Not directly related to ICS security but well worth mentioning here as the Equifax breach of September 2017 is a great example of how flawed security can lead to a devastating compromise of customer's personal information. With some due diligence and common security practices this disaster could have been prevented:
By writing this book I am embarking in educating the reader in the process of securing an Industrial control system by applying industry-wide adopted best practice methods and technologies. The book will use a fictive company as a silver lining throughout the learning process. The company isn't directly based on any real-time business but more a cumulative set of experiences of security postures and situations I have encountered over time.
Before we can dive into any security discussions, with this first chapter, we will discuss exactly what an Industrial control system (ICS), is and what it does. We will look at the different parts that make up an Industrial control system. From an architectural perspective, we will examine the individual parts that can be found in modern day ICSes and look at how they work together to accomplish a common task. We will end the chapter with an examination of the various industrial communication protocols that are used to connect all the parts, systems, and devices in an ICS. This includes a high-level explanation of the Purdue model, a reference model commonly used to explain Industrial control system.
From the traffic lights on your drive to work, or the collision avoidance system of the train or metro, to the delivery of electricity that powers the light you use to read this book, to the processing and packaging that went into creating the jug of milk in your fridge, to the coffee grinds for that cup of joe that fuels your day; what all these things have in common are the Industrial control systems driving the measurements, decisions, corrections, and actions that result in the end products and services that we take for granted each day.
The following diagram shows the architecture of a properly designed, modern ICS. The intent of this book is to educate you on the methodologies and considerations that went into the design of an architecture, such as the one shown here:
Technically speaking, the Industrial control system lives in the area marked Industrial Zone of the preceding diagram. However, as we will discuss later in this book, because most ICSes interact with the Enterprise Zone, in order to effectively secure the system as a whole, consideration must also be given to the systems in the Enterprise Zone.
An ICS is a variety of control systems and associated instrumentation used in industrial production technology to achieve a common goal, such as creating a product or delivering a service. From a high-level perspective, ICSes can be categorized by their function. They can have one or several of the functions discussed in the following sections.
The view function encompasses the ability to watch the current state of the automation system in real time. This data can be used by operators, supervisors, maintenance engineers, or other personnel to make business decisions or perform corrective actions. For example, when the operator sees that the temperature of cooker 1 is getting low, they might decide to increase the steam supply of the cooker to compensate this. The view process is passive in nature, merely providing the information or view for a human to react on:
From a security perspective, if an attacker can manipulate the operator's view of the status of the control system or, in other words, can change the values the operator bases their decisions on, the attacker effectively controls the reaction and, therefore, the complete process. For example, by manipulating the displayed value for the temperature of cooker 1, an attacker can make the operator think the temperature is too low or too high and have him or her act upon the manipulated data.
The monitor function is often part of a control loop, such as the automation behind keeping a steady level in a tank. The monitor function will keep an eye on a critical value, such as pressure, temperature, level, and so on, and compare the current value against predefined threshold values, and alarm or interact depending on the setup of the monitoring function. The key difference between the view function and the monitor function is in the determination of deviation. With monitoring functions, this determination is an automated process, whereas with a view function, this determination is made by a human looking at the values. The reaction of the monitor function can range from a pop-up alarm screen to a fully automated system shutdown procedure.
From a security perspective, if an attacker can control the value that the monitor function is looking at, the reaction of the function can be triggered or prevented; for example, a case where a monitoring system is looking at the temperature of cooker 1, preventing the temperature from exceeding 300 degrees Fahrenheit. If an attacker feeds a value of less than 300°F into the system, that system would be tricked into believing all is well, while in actuality, the system could be in meltdown.
The following diagram illustrates the control function:
The control function is where things are controlled, moved, activated, and initiated. The control system is what makes actuators engage, valves open, and motors run. The control actions can either be initiated by an operator pushing a button or changing a set point on an HMI screen, or it can be an automated response as part of the process control.
From a security perspective, if an attacker can manipulate the values (the input) the control system reacts to or if the attacker can change or manipulate the control function itself (the control program), the system can be tricked into doing things it wasn't designed to do or intended for.
Now I can hear you all say that manipulating values is all nice and dandy, but surely that cannot be done with modern switched networks and encrypted network protocols. That would be true if those technologies were implemented and used. The sad state of affairs is that on most, if not all, ICS networks, the confidentiality and integrity parts of the CIA security triage are of less importance than availability. Even worse, for most Industrial control systems, availability ends up being the only design consideration when architecting the system. Combine that with the fact that the ICS communication protocols that run on these networks were never designed with security in mind, and one can start to see the feasibility of the scenarios mentioned.
More about all this will be discussed in later chapters, when we dive deeper into the vulnerabilities mentioned and look at how they can be exploited.
Industrial control system is an all-encompassing term used for various automation systems and its devices, such as Programmable Logic Controllers (PLC), Human Machine Interface (HMI), Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), Safety Instrumented Systems (SIS), and many others:
Programmable logic controllers, or PLCs, are at the heart of just about every Industrial control system. These are the devices that take data from sensors via input channels and control actuators via output channels. A typical PLC consists of a microcontroller (the brains) and an array of input and output channels. Input and output channels can be analog, digital, or network-exposed values. These I/O channels often come as add-on cards that attach to the backplane of a PLC. This way, a PLC can be customized to fit many different functions and implementations.
The programming of a PLC can be done via a dedicated USB or serial interface on the device or via the network communications bus that is built into the device or comes as an add-on card. Common networking types in use are Modbus, Ethernet, ControlNet, PROFINET, and others.
PLCs can be deployed as standalone devices, controlling a certain part of the manufacturing process, such as a single machine, or they can be deployed as distributed systems, spanning multiple plants in disperse locations with thousands of I/O points and numerous interconnecting parts.
The HMI is the window into the control system. It visualizes the running process, allowing inspection and manipulation of process values, the showing of alarms, and trending of control values. At its simplest form, an HMI is a standalone touch-enabled device that communicates via a serial or Ethernet encapsulated protocol. More advanced HMI systems can use distributed servers to offer a redundant supply of HMI screens and data:
The Supervisory Control and Data Acquisition system is a term used to describe a combined use of ICS types and devices, all working together on a common task. The following diagram illustrates an example SCADA network. Here, the SCADA network is comprised of all the equipment and components that together form the overall system. SCADA systems are often spread out over a wide geographical area as a result of being applied to power grids, water utilities, pipeline operations, and other control systems that use remote operational stations:
Closely related to the SCADA system is the distributed control system. The differences between a SCADA system and a DCS are very small and the two have become almost indistinguishable over time. Traditionally, though SCADA systems were used for automation tasks that cover a larger geographical area, meaning that parts of the SCADA system are located in separate buildings or facilities as where a DCS is more often confined to a single plant of facility. A DCS is often a large-scale, highly engineered system with a very specific task. It uses a centralized supervisory unit that can control thousands of I/O points. The system is built to last with redundancy applied to all levels of the installation, from redundant networks and network interface attached to redundant server sets to redundant controllers and sensors, all with creating a rigid and solid automation platform in mind.
DCS systems are most commonly found in water management systems, paper and pulp mills, sugar refinery plants, and so on:
Safety instrumented systems, or SIS, are dedicated safety monitoring systems. They are there to safely and gracefully shut down the monitored system or bring that system to a predefined safe state in case of a hardware malfunction. An SIS uses a set of voting systems to determine whether a system is performing normally:
