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.
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:
- Relay logic or trip-amp-based non-programmable SIS (SIS-TECH);
- Diverse design technology by separate manufacturers (Triconex, A-B, Rockwell Automation);
- Partially integrated, but different technology SIS (Emerson, Honeywell); and
- 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.