Cybersecurity / Safety Instrumented Systems

Building cybersecurity firewalls

Why and how to secure industrial control and safety systems at every conduit.

By William Mostia, Jr., P.E.

Cybersecurity is all the rage now with everyone wondering if someone is peeking under their petticoats or will hack their control system and take over their process, a la Stuxnet, leading to a disaster. This is an important issue that requires a careful approach of engineering analysis and design to keep the barbarians at the gate and out of our kingdom. IT networks are being subjected to an increased level of cyber threats, and all the pundits are predicting that industrial control systems (ICS) are next, with a good dose of doom and gloom. When the corporate or enterprise IT network is connected (directly or indirectly through the plant network) to ICS network and/or potential sneak-path connections to the Internet, cyber threats have doorways to attempt to open and possibly penetrate the ICS to do no good.

Firewalls play an important role in blocking and containing external and internal cyber threats that could impact process control system availability, reliability and productivity, and potentially impact safety. The selection of firewalls, their locations and the protection they provide should be part of a holistic cybersecurity assessment and protection plan based on a risk-based assessment and good engineering practice.

The topic of firewalls is surprisingly complex, and requires a good amount of study to be competent in their application and support. The intent of this article is to discuss some of the basics of applying firewalls in ICS systems by looking at them from the perspective of the functional data flow in the industrial control system, without too much technical IT geek-speak.

The world of the industrial control system is a substantially different world than your standard IT environment, and has given birth to a brand-new buzzword and acronym—operational technology (OT). ICS and firewalls fall into the OT realm. The types of digital transactions in an ICS are substantially limited when compared to general-purpose IT computer networks. The ICS is purpose-built to transfer a limited range of data types and functions, such as measurements, setpoints, status, alarms, calculated values, control signals, etc. Some configuration and programming is also done across the ICS network via engineering workstations. While there is typically an Internet connection to the plant network, or possibly indirectly through the enterprise network, there should not be any direct, continuous connection of the ICS network to the Internet, even through a firewall. However, there may have to be temporary connections to the Internet to download software updates and patches, which should be always be done through a firewall, and special care must be taken when doing so to control the transfer to ensure that a cyber threat does not sneak in.

Standards and layers

ISA is aware of the issues and hazards of cyber threats to ICSs, and commissioned the ISA 99 committee in 2002 to address the issue of cybersecurity in industrial automation and control systems (IACS/ICS). This committee’s goal was to develop a series of standards and technical reports to address the issue of cybersecurity in IACSs/ICSs. This standard committee’s work later became known as the ANSI/ISA-99 standards, and in 2010 was harmonized with the International Electrotechnical Commission and became ISA/IEC-62443, “Network and system security for industrial-process measurement and control.”

One of the methods in the technical report ANSI/ISA/TR99-2007 to fight cybersecurity intrusions is through the use of zones and conduits. The basic idea is to divide the ICS and connected systems into smaller functional chunks, e.g. zones, to provide isolation from each other, and to provide defense-in-depth capability. A communication “conduit” would be provided between zones, which allows a zone to communicate to another connected zone. At each conduit, there is essentially a doorway that controls the digital transactions in and out of a zone. This transaction control is commonly performed by a firewall or a data diode (hardware-enforced unidirectional gateway). The concept of protection by zones and conduits is illustrated in Figure 1 for a chemical plant-type environment. Also note that the ICS in Level 2 is divided into the basic process control system (BPCS), which includes the human-machine interface (HMI), and the safety instrumented system (SIS). Level 1 consists of the field instruments for the SIS and BPCS.

From Figure 1, we can see that the enterprise or corporate system zone (Level 4) is connected to the plant computer network system (called the plant DMZ, Level 3), which is usually a general-purpose computer network, and is typically connected through a stateful-type IT firewall to the enterprise system. The plant DMZ (Level 3) is connected to the ICS (BPCS, Level 2) typically through a specialized firewall or security appliance (a term used by some manufacturers to differentiate their product), which is later connected to the SIS (Level 2), again through a specialized firewall or security appliance. If the ICS is large enough or has separate functional areas (e.g. PLCs or process areas), there may be more defined zones with specialized firewall or security appliances.

SCADA systems can have different zones and conduits due to their geographical distribution of components and control functions. It's typical to have a stateful firewall at the central control center connection to the enterprise network. A specialized firewall or security appliance should be in place between the central control center and distributed control locations (typically RTU sites), and a specialized firewall or security appliance firewall at each control location. Firewalls are required at both ends because of the geographical distribution; a cyber threat attack may backdoor into the control center from one of the control locations. Depending on the design, there may or may not be separate SIS zones.

IT vs. ICS networks

Computers in networks perform digital transactions to accomplish tasks. Plant networks are typically Ethernet-based over fiber, and commonly connected to the outside world via a connection to the Internet. They are the realm of the IT department, but there's an overlap where they connect to the ICS. While it may go against the grain of many control engineers to associate with IT personnel, for the sake of cybersecurity, making a friend with your local (hopefully friendly) IT guy is a good idea. Maintaining these networks against cyber threats requires quite a bit of work and skill, so all the help you can get will be good in the long run.

The enterprise network (Level 4) and the plant DMZ network (Level 3) are typically IT networks, and they'll have a firewall at the system connection to the Internet as well as to each other and any other connected network. General-purpose IT firewalls are unsuitable for ICSs because they're essentially packet filters with some smarts. They generally can't distinguish at the application level which ICS data transactions/traffic packets to explicitly allow, and can let packets through without knowing if what they contain may be hazardous to our ICS. Smart hackers are always looking for and finding vulnerabilities to access these networks, which can lead to a cyber threat penetration into the ICS.

IT isn't typically the recommended department to control ICS firewalls because they typically don’t understand what goes on in the ICS. IT personnel should be knowledgeable about IT firewalls, and the control engineer can define the allowable control system transactions that should pass through the IT firewalls, but control of the ICS firewalls should be in the control engineering department with the assistance of the IT department. Physical access to the ICS firewalls should be controlled, all firewall passwords should be changed from their default, and each firewall should have a different password.

{pb}

Between the DMZ and BPCS

The first step to designing a firewall system for an ICS system is to determine your zones and define the conduits where you'll locate firewalls based on the defense-in-depth concept. You must also determine what type of data transaction that you'll allow across the firewalls (read, writes, program/configure, etc.) and what risks are associated with allowing these transactions. This requires engineering analysis and a risk assessment for allowing these transactions. A key rule for ICS firewalls is that they should be configured by default to deny all transaction traffic except that which is explicitly authorized.

There should be only one access point between the ICS network and plant DMZ network—the ICS should be analyzed for other potential access points, including thumb/memory stick drives, and these access ports should be closed. The corporate or enterprise system should not connect directly to the ICS because this would eliminate the layer of protection of the plant DMZ/enterprise firewalls.

At the interface between the plant DMZ and the BPCS, a decision must be made as to what control system transactions are going to be allowed across the firewall. The location of the data historian can affect this if the enterprise system collects data from it. Remember, we wish to only allow data transactions that are explicitly authorized (necessary), and we also need to control who is authorized to use these data transactions.

Whitelisting, which specifies who or what can talk across the firewall, should be used rather than blacklisting, which is who should not be allowed to talk. Blacklisting is limited to those who you know should not be allowed to talk across the firewall. However, blacklisting does not help you when someone who you don't know wants to talk for nefarious purposes, which is the case for many cyber threats. Whitelisting should follow the rule that if a system or user doesn’t need to communicate with a system, it should not be allowed. Blanket access should not be allowed.

Read the Guide: The Essentials of Safety Instrumented Systems

The data transaction choices are typically reads, writes, programming access, and remote control access. The recommended transaction is to allow only “read-only” transactions. This should limit your risk from a cyber threat to vulnerabilities of the firewall itself, such as denial of service, buffer overflow, etc. This can be done with a data diode (unidirectional data flow) or a firewall with deep packet inspection (DPI) that only allows reads.

Unfortunately, allowing access by engineers via desktop or laptop from their offices due to safety concerns (limiting personnel inside the plant battery limits) and/or convenience sometimes overrides cybersecurity concerns. Programming or remote-control access should not be allowed from the plant DMZ network to the ICS network. The consequence of a reprogramming of the control system or SIS cyber event, if it occurs, could be a potential disaster. If you must allow other types of access besides reads, a risk assessment should be done, and adequate cyber protection be added to the firewall for the access allowed. Knowing what transactions flow and where within the BPCS and SIS is important for locating and configuring the firewall, and a transaction map can be a good conceptual tool to locate and determine what authorized transactions will be allowed to be passed by the firewall.

ISA/IEC-62443, NIST 800-82R2, “Guide to Industrial Control Systems (ICS) Security,” and Industrial Control System from the Cyber Emergency Response Team (ICS-CERT, https://ics-cert.us-cert.gov) can provide guidance in this regard. ICS-CERT has recommended practices available. In particular, “Firewall Deployment for SCADA and Process Control Networks” would be a recommended practice of interest.

Many firewalls that also have network intrusion detection and prevention systems and antivirus scanning are very useful features for control system networks—so long as they don't interfere with control system availability and performance. When purchasing firewalls, in addition to a detailed technical review, you should request to look at all the firewall’s engineering change orders (ECO) to determine what vulnerabilities have been detected and fixed. A lot of fixes or patches can indicate a weak design.

Between the BPCS and SIS

The other minimum required firewall is between the BPCS and the SIS. To assure independence of the SIS from the BPCS, permitted firewall transactions should be limited and strictly enforced. The SIS engineer should be involved in configuring and supporting this firewall.

The best system from a cybersecurity perspective would be to have non-programmable SISs with read access only by the BPCS. A second option is to air-gap the SIS and have a separate HMI for the safety instrumented functions (SIF) that's not connected to main control system network, the plant DMZ or the Internet. This type of SIS typically would still require a firewall between the HMI and the SIS, but the SIS is isolated from the main control network. However, the separate HMI adds different HMI hardware and software that have to be supported, and it's not typically in line with most people’s HMI philosophy today.

Most BPCSs today will have a digital connection that will be used to interface the BPCS with the SIS logic solver. It's still good engineering practice to isolate the SIS from the BPCS as much as possible to prevent simultaneous control of these systems by a cyber threat. Had this isolation existed between the control system and the safety system during the Stuxnet event, it might have turned out quite differently.

The best digital option is to allow only reads and no programming or configuring through the firewall from the BPCS control network to the SIS. Allowing programming over the process control network to the SIS exposes the SIS to unauthorized program changes and potential defeat of the SIS safety function by a cyber threat. Changing the operating mode of the SIS logic solver or any PLC from the BPCS also should not be authorized. For example, a Modbus firewall between BPCS and SIS should be designed specifically for Modbus, and limit the acceptable commands to Modbus Function Codes 01–04 (read function codes) to gather necessary read data from the SIS logic solver (e.g. SIS transmitter measurements, valve positions, SIF status, etc.) Any required writes to the SIS should be hardwired via a BPCS digital output or analog 4-20 mA to the SIS. If writes are allowed through the firewall, as a minimum, they should be from a recognized source, go to specific registers in the SIS logic solver, and be within an acceptable range of values.

Due to evolution and competition, we have four basic SIS system designs:

  1. Relay logic or trip-amp-based non-programmable SIS (SIS-TECH);
  2. Diverse design technology by separate manufacturers (Triconex, A-B, Rockwell Automation);
  3. Partially integrated, but different technology SIS (Emerson, Honeywell); and
  4. Fully integrated SIS (ABB).

Design 1 typically is interfaced to the BPCS hardwired or via Modbus (inherently read only); Design 2 commonly uses Modbus or a recognized proprietary protocol (e.g. A-B DH+) and should have a purpose-built firewall for that protocol that allows only certain types of transactions, and should allow access only to specific registers; Designs 3 and 4 should use a firewall from the SIS manufacturer or recommended by the manufacturer. A number of manufacturers have licensed Tofino DPI technology for their firewalls (MTL, Honeywell, Triconex).

The more integrated the SIS, the more vulnerability it has to a common cyber threat penetration into the BPCS that could also get into the SIS. Connecting Ethernet directly to a SIS is not recommended, and if done, should only be done with a risk assessment, through a manufacturer-recommended firewall, and use DPI technology or equivalent. Get the manufacturers involved early, and get their insights into their systems and their cybersecurity recommendations.

Level 1 is where the field instruments interface with the process and do the actual work. Many of these are connected to the BPCS controllers and PLCs in Level 2 via analog or discrete digital signals, and don't require firewall protection, but an increasing number use fieldbus or some other digital communication protocol (e.g. motor or electrical protection relay com links). The potential vulnerabilities here must be risk-assessed and protected against.

ICS and SIS firewalls

Because the ICS will typically run a proprietary operating system and network protocol, ICS firewalls must be purpose-built for that protocol and specifically designed for ICS and SIS service. These firewalls should not have any extra ports that might be open to a cyberattack, and should not allow general computer transactions (e.g. Internet, e-mail, access to server-based programs, etc.) ICS and SIS firewalls should use DPI, similar firewall technology or a data diode to control data flow. DPI is an advanced packet filter method that examines the data or payload of the transaction in the application context as it passes into an inspection point, searching using defined criteria to decide whether the packet may pass. DPI functions at the application layer of the Open Systems Interconnect (OSI) seven-layer model. Data diodes are less common than firewalls and are different from them because they only allow hardware-enforced data transfer one way, no exceptions, and can be used to create a read-only interface.

Ethernet is a common transport protocol in ICS. In addition to normal, safe transactions, it can transport a range of hazardous payloads using general-purpose communication protocols, making it inherently more risky than proprietary protocols due its generic nature. If the ICS or SIS firewall is on an Ethernet-based control network, HTTP and other general-purpose computer traffic not specifically related the control functionality should be explicitly forbidden. This is to prevent computer malware and viruses from tunneling into the ICS and SIS. Unfortunately, the proprietary protocols are disappearing, along with purpose-built human machine interfaces (HMI). Typically to financial considerations, they're giving way to HMIs on Microsoft Windows-based PCs, which many times use some form of Ethernet, opening more potential doors for hackers to infest your control systems. These types of HMIs should be reviewed to see if it's appropriate to have additional firewall protection on them.

At the end of the day, there should only be a single controlled connection from the plant DMZ to the ICS. The key rule is that the ICS firewalls should be configured to deny all traffic except that which is explicitly authorized. The allowable data transactions across a firewall must be identified and the protection defined that will be provided by the firewall to control the data flow. In general, read-only access is best and if write access or another kind of access is given, a risk assessment should be done to see what additional cyber protection should be provided. DPI-type firewalls or a data diode should be used to control access to the ICS and to the SIS.

It's important to understand that firewalls for the ICS and SIS should be specifically designed to that service, and only data transaction be allowed. No general computer transactions should be allowed through ICS and SIS firewalls. This is to ensure that computer malware and viruses cannot tunnel into the ICS and SIS.

Access to the SIS must be severely limited because the SIS represents the last line of instrumented defense for the safe operation of the facility. Again, had the safety system been separate and independent from the control system in the Stuxnet event, the outcome might have been a bit less negative. It's all about what BPCS and SIS transactions will be allowed through a firewall, what is the risk of allowing those transactions, and what protections the firewall must provide to assure the efficient and safe operation of the ICS and the plant or facility.