An intelligent electronic device (IED) is any device commonly used within a control system—such as a sensor, actuator, motor, transformers, circuit breakers, and pumps—that is equipped with a small microprocessor that enables it to communicate digitally. These devices communicate almost exclusively using fieldbus protocols, operating as slave nodes, and are controlled via an upstream RTU or PLC. As with all technology, IEDs are growing more and more sophisticated over time, and an IED may perform other tasks, blurring the line between device types. However, to simplify things for the purposes of this book, an IED can be considered to support a specific function (i.e., a motor can spin at different frequencies) within the control system, typically within a specific control loop, whereas RTUs and PLCs are designed for general use (i.e., they can be programmed to control the speed of a motor, to engage a lock, to activate a pump, etc.).

A Remote Terminal Unit (RTU) typically resides in a substation or other remote location. RTUs monitor field parameters and transmit that data back to a central monitoring station—typically either a Master Terminal Unit (MTU), or a centrally located PLC, or directly to an HMI system. RTUs, therefore, include remote communications capabilities, consisting of a modem, cellular data connection, radio, or other wide area communication capability. They will typically use industrial network protocols such as DNP3 to communicate between master and remote units, and either DNP3 or Modbus, Profibus or some other common fieldbus protocol to communicate with IEDs (see Chapter 4, “Industrial Network Protocols”).

RTUs and PLCs continue to overlap in capability and functionality, with many RTUs integrating programmable logic and control functions, to the point where an RTU can be thought of as a remote PLC.

A programmable logic controller (PLC) is a specialized computer used to automate functions within industrial networks. Unlike desktop computers, PLCs are typically materially hardened (making them suitable for deployment on a production floor) and may be specialized for specific industrial uses with multiple specialized inputs and outputs. PLCs also differ from desktop computers in that they do not typically use a commercially available operating system (OS); instead they rely on blocks of logic code that allow the PLC to function automatically to specific inputs (e.g., from sensors) with as little overhead as possible. PLCs were originally designed to replace relays, and very simple PLCs may be referred to as programmable logic relays (PLRs).

PLCs typically control real-time processes, and so they are designed for simple efficiency. For example, in plastic manufacturing, a catalyst may need to be injected into a vat when the temperature reaches a very specific value; if processing overhead or other latency introduces delay in the execution of the PLC’s logic, it would be very difficult to precisely time the injections, which could result in quality issues. For this reason, the logic used on PLCs is typically very simple and usually based on ladder logic (although almost any programming language could theoretically be supported).

Again, as technology evolves, the line blurs between RTU, PLC, and IED, as can be seen in Emerson Process Management’s ROC800L liquid hydrocarbon remote controller shown in Figure 5.1. This device performs measurement, diagnostics, and remote control in a single device that supports several programmable languages.

Human machine interfaces (HMIs) are used as an operator control panel to PLCs, RTUs, and in some cases directly to IEDs. HMIs replace manually activated switches, dials, and other controls with graphical representations of the control process and digital controls to influence that process. HMIs allow operators to start and stop cycles, adjust set points, and perform other functions required to adjust and interact with a control process. Because the HMI is software based, they replace physical wires and controls with software parameters, allowing them to be adapted and adjusted very easily.

HMIs are modern software applications running on modern operating systems, and as such they are capable of performing many functions. They act as a bridge between the human operator and the complex logic of one or more PLCs, allowing the operator to function on the process rather than on the underlying logic that performs the function and to control many functions across distributed and potentially complex processes from a centralized location. To accomplish this, the user interface will graphically represent the process being controlled, including sensor values and other measurements, and visible representation of output states (which motors are on, which pumps are activated, etc.).

Humans interact with the HMI through a computer console, and as such must authenticate to the HMI system using password protection. Because HMIs provide supervisory data (visual representation of a control process’s current state and values) as well as control (i.e., set point changes), user access may lock out specific functions to specific users. The security of the industrial process therefore relies heavily on access control and host security of the HMI.

The HMI, in turn, interacts with one or more PLCs and/or RTUs, typically using industrial protocols such as OLE for Process Control (OPC) or fieldbus protocols such as Modbus (see Chapter 4, “Industrial Network Protocols”).

A supervisory workstation collects information from assets used within a control system and presents that information for supervisory purposes. Unlike an HMI, a supervisory workstation is primarily read-only; that is, there is no control element to interact directly with the control process, only the presentation of information about that process.

Typically, a supervisory workstation will consist of either an HMI system (with read-only or supervisory access restrictions) or a Data Historian—a device specifically designed to collect a running audit trail of control system operational data. Supervisory workstations can reside within the Supervisory Control and Data Acquisition demilitarized zone (SCADA DMZ) or within the business network—up to and including Internet-facing web portals, Intranets, etc. (see “Control Processes” on page 102).

A Data Historian is a specialized software system that collects point values and other information from industrial devices and stores them in a purpose-built database. Most industrial asset vendors—including ABB, Arreva, Emerson, GE, Invensys, Rockwell, Siemens, and others—provide their own proprietary Data Historian systems. In addition, there are third-party industrial Data Historian vendors, such as Canary Labs (www.canarylabs.com), Modiüs (www.modius.com), and OSIsoft (www.osisoft.com), which interoperate with third-party assets and even integrate with third-party Data Historians in order to provide a common, centralized platform for data historization and analysis.

Data points that are historized and stored within a Data Historian are referred to as “tags” and can represent almost anything—the current frequency of a motor or turbine, the rate of airflow through an heating, ventilation, and air-conditioning (HVAC) system, the total volume in a mixing tank, the specific volumes of injected chemical catalysts in a tank, etc. Tags can even represent human-generated values, such as production targets and acceptable loss margins.

Because the information stored within a Data Historian is used by both industrial operations and business management, Data Historians are often replicated across an industrial network. This can represent a security risk, as a Data Historian in a less secure zone (i.e., the business network) could be used as a vector into more secure zones (i.e., the SCADA DMZ). As such, Data Historians should be isolated, secured within their own enclaves, and should be patched regularly to minimize vulnerability.

At the time of this writing, OSIsoft holds a dominant position in the Historian market, with 65% market penetration in global industrial automated systems. ⁵ The OSIsoft PI System integrates with many IT and OT systems including other Data Historians, and as such is a premium target for attack. Again, applying the latest updates and patches can minimize vulnerabilities, while properly isolating and securing PI within its own enclave can minimize accessibility. For more information about the role of Data Historians within control system operations, see “Control Processes: Feedback Loops” and “Control Processes: Business Information Management” later in the chapter.

Business Information Consoles are extensions of supervisor workstations designed to deliver business intelligence information to upper management. They typically consist of read-only representations of the same data obtained from HMI or Data Historian systems. In some cases, a Business Information Console is a physical console: a computer display connected to an HMI or Historian within the SCADA DMZ, but physically located elsewhere (such as an executive office or trading floor). In these cases, the physical display is remotely connected using a remote display or secure remote Keyboard Video Mouse (KVM) switching system. Business information may also be obtained by replicating HMI or Data Historian systems within the business network or by publishing exported information from these systems using an intermediary system, for example, exporting Data Historian information to a spreadsheet and then publishing that spreadsheet to a corporate information portal or intranet. Depending upon the sophistication of the Data Historian, this publishing model may be streamlined and automated. In any case, any published data should be access controlled, and any open communication path from SCADA systems to more openly accessible workstations or portals should be very carefully controlled, isolated, and monitored.

There are many other assets that may be connected to an industrial network other than PLCs, RTUs, HMIs, Historians, and various workstations. Devices such as printers and print servers may be connected to corporate networks, or they may connect directly to a control loop. Physical access control systems such as badge scanners and biometric readers may be used, and these devices may be networked (probably over Transmission Control Protocol/Internet Protocol [TCP/IP]).

Although this book does not attempt to cover every aspect of every device that may be present within an industrial network, it is important to recognize that every device has a potential impact to security and should be assessed if:

Even the most harmless seeming devices should be assessed. Check the documentation of devices to make sure that they do not have wireless capabilities, and if they do, secure or disable those features. Many commercially produced devices contain multipurpose microprocessors, which may contain radio or Wi-Fi antennae receivers or transmitters even if the device is not intended for wireless communication. This is because it is sometimes more cost-effective to use a commercial, off-the-shelf (COTS) microprocessor with unneeded capabilities; those capabilities may never be enabled by the manufacturer, but if the hardware exists it can be used as an attack vector by hackers. ⁶

Industrial networks are typically very distributed and vary considerably in all aspects, including the link layer and network protocols used, as well as the topology. In the business networks, however, Ethernet and TCP/IP networks are ubiquitous, using a variety of star, tree, and even full-mesh topologies. The ubiquity of Ethernet and TCP/IP make it the “glue” that connects other SCADA and industrial control systems together. SCADA and industrial control system networks may utilize bus, ring, star, and tree topologies depending upon the specific type of control process that is in operation and the specific protocols that are used. For example, an automated control process to sanitize water may use a bus topology with the Modbus protocol, while another control process may use Profibus in a ring topology to control pumping or filtration systems (see Figure 5.6 for examples of topology use within and across an industrial network). The SCADA DMZ must communicate to both sides: on one side a number of industrial network protocols and on the other corporate Ethernet TCP/IP networks. As such, the SCADA DMZ will require protocol gateways to translate between the two environments (see Chapter 4, “Industrial Network Protocols”). These gateways can be standalone network devices, or they may be a built-in function of MTUs, HMIs, PLCs, or other industrial assets.

The specific topology used has little impact on the security of any particular network. More important is the boundary of a network area (which will help to determine how an attacker can migrate between systems) and the protocol(s) used within a network area (which will help to determine how a specific network area may be vulnerable). Although these areas are shown at a very high level in Figure 5.5, each network area that can be differentiated from its neighbors—ICCP interconnects versus OPC SCADA systems versus different control groups using DNP3, Modbus, etc.—can and should be isolated behind a secure periphery (see Chapter 7, “Establishing Secure Enclaves”).

Industrial networks are made up of many specific automated processes, called control loops. The term “loop” derives from the ladder logic that is widely used in these systems: a controller device such as a PLC is programmed with specific logic; the PLC then cycles through its various inputs, applying the logic to adjust outputs or controls, in order to perform a specific function. This cycle or “loop” automates that function.

In a closed loop, the output of the process affects the inputs, fully automating the process. For example, a water heater is programmed to heat water to 90°C. An electric heater coil is then engaged to heat the water, and the water temperature is measured and fed back into the process; when 90°C is reached, the heater will turn off inputs from outside of the specific process. In an open loop, the output of the process does not affect the inputs, such as when the coil of a water heater is manually engaged, independent of the current water temperature. In other words, closed loops provide automated control whereas open loops provide manual control.

Control loops can be very simple, checking a single input, as illustrated in Figure 5.8 and Figure 5.9. For example, a simple loop in an automated lighting process might check a single input (e.g., a light sensor to measure ambient light) and adjust a single output (e.g., the dimmer switch on a lamp). Very complex loops might use multiple inputs (e.g., pressure, volume, flow, and temperature sensors) and adjust multiple outputs (e.g., valves, pumps, heaters) to perform a function that is inherently more complex—in this case, maintaining a constant pressure in a dynamic fluid system.

Multiple control loops may be required to perform even more complex control processes. They may be controlled by a central HMI, or they may themselves be part of a larger control loop, acting as inputs or outputs into another level of logic, controlled by a master or central PLC.

A “control process” is a general term used to define larger automated processes within an industrial operation. Many control processes may be required to manufacture a product or to generate electricity, and each control process may consist of one or many control loops. For example, one process might be to inject an ingredient into a mixer, and that process may consist of a control loop that opens a valve in response to volume measurements within the mixer, temperature, and other conditions. Several such processes can automate the correct timing and combination of several ingredients, which in turn complete a larger process (to make a batter). The mixed batter might then be transported to other entirely separate control processes for baking, packaging, and labeling.

Each process is typically managed using an HMI, which is used to interact with that process. Typically, an HMI will provide relevant readings from one or more control loops, requiring communication to all daughter systems, typically PLCs or RTUs. Some HMIs may include readouts of sensors and other feedback mechanisms, as well as the activity of the PLCs, while others may issue direct control operations and provide controls to adjust the set points of the ongoing control process.

Again, an HMI may control a process consisting of many control loops; therefore, the HMI’s network connectivity is typically heterogeneous: connecting over routable protocols (TCP/IP) as well as specialized SCADA and fieldbus protocols and other industrial network protocols to the various PLCs and RTUs that make up the individual loops. Because of this, HMIs are a common attack vector between the routable SCADA and business networks.

Every automated process relies on some degree of feedback both within a control loop and between a control loop or process and a human operator. Feedback is generally provided directly from the HMI used to control a specific process, as seen in Figure 5.10. Feedback may also be centralized across multiple processes, through the collection, analysis, and display of information from many systems. For example, a refinery may have several crude oil tanks, each used in a replicated control process. Information from each process can be collected and analyzed together to determine production averages, overages, and variations.

The centralized information management of an industrial control system is typically performed by one or more Data Historian systems. The process of removing data from the real-time environment of an industrial automation process and storing it over time is called “historizing” the data. Once historized, the information can be heavily analyzed, either directly from within the Data Historian or by using an external analysis tool such as a spreadsheet.

Specific control system elements may use their own Data Historian system to historize data locally. For example, an ABB 800xA control system may use the 800xA Information Management Historian, while an Emerson Ovation control system may use the Ovation Process Historian. The need for a common Data Historian that historizes all data across systems derives from the heterogeneous nature of many industrial operations, where different processes may utilize assets manufactured by different vendors, yet all processes need to be evaluated holistically in order to manage and fine-tune overall operations. In addition, there may be value in collecting information from other devices and systems within the industrial network, such as IT systems, HVAC systems, and Physical Security and Access Control systems. The shift from process-specific data historization to operation-wide business intelligence has led to the development of specialized features and functionality within Data Historians.

Operational monitoring and analysis provides valuable information that can be used by business managers to fine-tune operations, improve efficiencies, minimize costs, and maximize profits. As such, there is a need for replication of the operational process data into the business network.

Supervisory data can be accessed using an HMI or a Data Historian, each of which presents its own security challenges. HMIs provide supervisory and control capabilities, meaning that an HMI user with the correct privileges can adjust parameters of control process (see “Control Process Management” on page 106). By placing an HMI outside of the SCADA DMZ, any firewalls, IDS/IPS, and other security monitoring devices that are in place will need to be configured to allow the communication of the HMI into and out of the SCADA DMZ, effectively reducing the strength of the security perimeter between the SCADA and business networks to user authentication only. That is, if a user account is compromised on the outside HMI system, it can be used to directly manipulate control process(es), without further validation from perimeter security devices.

The use of a Data Historian for business intelligence management presents a similar concern: the security perimeter must be configured to allow the communication between the Data Historian in the Business network and the various systems within the SCADA DMZ that need to be monitored. Unlike an HMI, a replicated Data Historian does not explicitly allow control of the process. Instead, the Data Historian provides a visual dashboard that can be configured to mimic the informational qualities and graphical representation of an HMI so that information about a process can be viewed in a familiar format.

Data is collected by a Data Historian through a variety of methods including direct communication via industrial network protocols such as Modbus, Profibus, DNP3, and OPC (see Chapter 4, “Industrial Network Protocols”); via direct insertions in the Data Historian’s database using Object Linking and Embedding Database (OLEDB), Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), etc.; or using standard data exchange protocols such as the Simple Network Management Protocol (SNMP) and Syslog. Most Data Historians support multiple methods of data collection to support a variety of industrial applications. Once the information has been collected, it is stored within a database schema along with relevant metadata that helps to apply additional context to the data, such as batch numbers, shifts, or virtually anything (depending upon the Data Historian’s available features and functionality).

Data Historian systems also provide access to historized data, typically through the same supported interfaces, with the possible addition of more ubiquitous protocols such as HTTP. Historized data can therefore be retrieved via direct SQL queries, via HTTP requests, via direct fieldbus protocol reads, or via other means. The data itself could be presented in almost any format, including binary files, XML, etc.

Historized data may be accessed directly via the Data Historian’s operator console or could be integrated at almost any level into supplementary Business Intelligence Management systems. In some cases, the Data Historian may also be integrated with Security Information and Event Management systems (SIEMs), Network Management Systems (NMSs), and other network and/or security monitoring systems.