Protecting SCADA devices from threats and hackers

Supervisory Control and Data Acquisition (SCADA) systems control many of the crucial services our modern society depends upon such as electric power distribution, water treatment, natural gas and oil pipelines, hydroelectric dams, traffic lights, train switching systems, building controls, and many others. 

Because of its critical role in controlling these systems, security for SCADA systems is a high priority, but many legacy SCADA devices that were designed without security measures are now being connected to the Internet.  These devices also lack the ability to detect and report traffic abnormalities, probes or attacks, or to manage and control security policies.   While newer systems may include improved security, many SCADA devices remain deployed for 10 years or more, often in remote areas, resulting in very slow migration to newer, more secure devices.

In addition to system level security issues, SCADA protocols themselves are often inherently insecure. They may lack basic security measures. Instead they often rely on “security by obscurity” or on isolation from public networks for security. Without security measures such as authentication and encryption, the underlying protocols provide an easy avenue for hackers wishing to attack SCADA devices.

SCADA networks 

SCADA systems are often complex networks with multiple components.  These systems may be fully automated, where all control is performed by computers, fully manual, where control is performed by human operators, or a hybrid system, where some control is performed automatically and some is performed by human operators.  To perform all of these functions, many SCADA systems include:

Field interface devices  –  Sensors detecting and reporting power levels, flow rates, temperature, pressure, and local control devices such as motor controls, valve actuators, and control switchboxes.

Operating equipment  –  Motors, pumps, automated factory systems, and valves controlled by the SCADA network.

Control computers  –  Embedded computers or dedicated PCs receiving information from the sensor networks, reporting this information to the management systems and controlling the associated operating equipment.  These computers may make decisions automatically based on the information derived from sensors, or may relay commands received from management computers. 

Management computers  –  Computer terminals with an HMI (Human Machine Interface) connected to the SCADA network. These computers provide an interface for operators to monitor and control the devices on the SCADA network.

Networked communication (local and remote)  –  SCADA networks use a variety of communication technologies.  Serial communication, USB or proprietary wired networks are used for short range communication. Ethernet, TCP/IP, Wi-Fi, dial-up networking, cellular packet data and other methods are used for long range communication.  Increasingly, SCADA networks utilize the Internet for long range communications and remote access.

Interconnection to business process systems  –  Frequently, SCADA networks are connected to corporate networks to allow them to interconnect with business process systems.

SCADA networks may contain a mix of PCs and special-purpose embedded systems running  real-time operating systems such as VxWorks, INTEGRITY, or MQX.  Many of the PCs used in SCADA networks were installed when the SCADA system was first deployed and have not been updated with newer operating system versions or software patches.  As a result they are often vulnerable to attack. Most embedded computers in SCADA networks were designed before security was a major concern and contain few, if any, security measures.

In most cases, the PCs within the SCADA network can be protected by ensuring they are running a current operating system with the latest security patches and security software.  In some cases, the PCs are running SCADA specific software that is only supported on an older OS version preventing the PC from being upgraded, creating a security issue.   In the case of these legacy PC systems, and for embedded SCADA computers, another solution is required. 

Attacks on SCADA networks

There is little dispute that additional protection is needed for SCADA networks.  The FBI recently acknowledged that hackers gained access to SCADA systems in three different cities. Other reported attacks on SCADA systems include:

• Train system delays
• Sewage system spillage caused by a disgruntled former employee
• Automotive manufacturing plant shutdown

Given the large number of deployed SCADA devices and the slow migration to modern, secure SCADA devices, the SCADA marketplace needs the ability to add security to both existing legacy devices and new designs in a cost-effective manner for both remote SCADA devices located outside of a corporate network and for local SCADA devices such as those residing on the factory floor. 

This can be achieved by augmenting current SCADA devices with the ability to control their communication, detect and report attacks or suspicious traffic patterns, and to allow centralized control of security policies.  These capabilities would provide SCADA devices with a much higher level of security and protect them from the majority of cyber-attacks. 

A low-cost SCADA aware firewall device (Figure 1) can provide these capabilities. Unlike enterprise firewalls that protect all of the computers on a corporate network, a SCADA firewall protects just a single SCADA device. Since the firewall is filtering traffic for a single SCADA device only, it does not need to perform any routing functions and can be customized specifically for the requirements of protecting a specific SCADA device.  It only requires two Ethernet ports and can be implemented on low cost hardware, providing a customized yet cost-effective solution.  The device is simply plugged into the network in front of the SCADA device, inserting a layer of protection.

Figure 1:  A firewall to protect SCADA devices from Internet delivered threats can be embedded into an external device that protects the device.

 The SCADA firewall can be used to protect devices located at remote locations without making any modifications to the SCADA device itself.  It can also be used to protect SCADA devices located on a factory floor or other non-remote location.  For new SCADA devices, the firewall software can be integrated into the device to ensure protection.

The SCADA firewall must provide:

• Control of the packets processed by the device
• Protection from hackers and cyber-attacks that may be launched from the Internet, inside the corporate network, or WiFi networks
• Protection from DoS attacks and packet floods
• Ability to detect and report traffic abnormalities, probes, or attacks.
• Ability to manage and control changes to filtering policies

 

Blocking attacks with a SCADA Firewall using a virtual closed network

As stated above, many SCADA devices with limited security are now connected to the Internet, exposing their security vulnerabilities.  This can be remedied by using a SCADA firewall to create a virtual closed network (VCN).

To create a VCN, the designer needs to define communications polices for the device restricting communication to only what is required.  The communication policies define who the device is allowed to talk to, what protocols are allowed, and what ports are open. The defined communications policies are then encoded as firewall rules.  The firewall filters messages before the device processes the messages.  By enforcing the rules, the firewall limits communication to the device, creating a virtual closed network. 

In a system without a firewall, a hacker may attempt to remotely access the device using default passwords, dictionary attacks, or stolen passwords.  Such attacks are often automated, allowing a huge number of attempts to break the system’s password.  The same system, protected by a firewall configured with a whitelist of trusted hosts, will be able to block the attack. The firewall’s filters will block the login attempts from the hacker before a login is even attempted because the IP or MAC address is not in the whitelist of trusted hosts. 

SCADA firewall design

The main requirement of a SCADA firewall is that it control who the SCADA device talks to and what communication is allowed. The firewall can control who the device talks to (IP and MAC address filtering) and what traffic is allowed (port and protocol filtering) by filtering network traffic.  Ideally, the firewall should also provide protection from Denial of Service and other cyber-attacks, event reporting, and integration with a management system.  Event report and integration with a management system provide visibility into abnormal network traffic, alerts in the event of a cyber-attack, and centralized control of security policies. 

The firewall must provide the ability to configure a set of rules specifying which packets are processed and which are blocked. Rules can be set up to block or allow packets by IP address, port, protocol, or other criteria.  Some firewalls support advanced rules allowing additional fine-grained control over the filtering process.    

A SCADA firewall may also provide Stateful Packet Inspection (SPI) and threshold-based filtering.  SPI filtering maintains information on the state of the connection and uses that information to distinguish legitimate from malicious packets. Threshold-based filtering maintains statistics on the number of packets received to detect and block DoS attacks.

Since each packet received by the device passes through the firewall for filtering before being processed, many attacks are blocked before a connection is even established.  This provides a simple yet effective layer of protection missing from most devices.  

 

Figure 2: A multi-stage filtering engine provides fine-grained control over the packets processed by an embedded device.

Filtering options

Many SCADA protocols now have variations that run over Ethernet or TCP/IP.  Modbus can run over TCP/IP and ProfiNET is a standard for Profibus over Ethernet. To protect these devices the SCADA firewall must provide filtering of Ethernet and TCP/IP traffic.

There are three main types of filtering a firewall can perform. 

• Static filtering or rules-based filtering:  Compares each packet to a set of rules to determine if the packet should be blocked or allowed.  All decisions are made based on the information in the packet.
• Stateful packet inspection or dynamic filtering:  Maintains information on the state of each connection (dynamic information) and uses the information to make filtering decisions. 
• Threshold-based filtering: Keeps statistics on packets received and monitors for threshold crossings to detect packet floods and Denial of Service (DoS) attacks.

Rules-based filtering 

Rules-based filtering (Figure 3) provides a simple and effective tool to enforce closed communication, and is generally the only filtering needed for some devices.  Any communication from a non-trusted IP or MAC address will be blocked, isolating the device from attack.

 

Figure 3. Rules-based filtering is generally the only filtering needed to enforce closed communications, during which any non-trusted IP or MAC address will be blocked, isolating the device from attack.

Rules-based filtering provides an important layer of defense.  Since virtually all embedded devices are closed for at least some protocols, rules should be configured to enforce any communication not allowed with the device. 

If rules-based filtering does not provide sufficient protection, then Stateful Packet Inspection (SPI) or threshold-based filtering may be added for additional protection.  Stateful packet inspection provides protection against packets received with invalid TCP state information, a common Internet-based attack. 

Threshold-based filtering is complex and requires significant system processing time and memory, but provides a powerful tool for detecting packet floods and DoS attacks.

Static Filtering

Static filtering works by allowing a set of rules to be configured specifying the filtering field (IP or MAC address, protocol number, port value, etc.), the filtering type (whitelist vs. blacklist), and the values to be matched.  A whitelist is a list of allowed values.  If a packet is received and the value is on the list, it is allowed.  If not, it is blocked.  A blacklist is the opposite, any values on the list are blocked and all other values are allowed.   

For example, a rule set could look like the following:

            Rule 1, WHITELIST, IP source address, {192.168.0.0 – 192.168.0.255}

            Rule 2, WHITELIST, IP protocol, {1,2,6,17}

            Rule 3, BLACKLIST, UDP destination port, {700-799}

Static filtering requires the ability to specify the rules set and a filtering engine to evaluate each packet against the configured rules.  With the rules show in this example, the filtering engine first checks the IP address of each packet.  If the IP source address is not in the range of 192.168.0.1 – 192.168.0.255, the packet will be blocked. Otherwise the filtering engine will proceed to the next rule.

The second rule specifies that the IP protocols of ICMP, IGMP, TCP and UDP (protocol numbers 1, 2, 6 and 17) are allowed.  Packets received with any other protocol value will be blocked, even if it is from a whitelisted IP address.  The third rule specifies that UDP ports 700-799 are blacklisted.  Any UDP packets received for these ports are blocked.

Stateful Packet Inspection (SPI) maintains information on the state of each connection and uses it to make filtering decisions.  Connection-oriented protocols such as TCP use the protocol connection state. In contrast, for connectionless protocols such as UDP, the connection state is either CLOSED or ESTABLISHED based on how recently a packet was sent or received for a given IP address and UDP port.   This requires a state table that is updated as connections are established, proceed through the connection states, and closed.  As packets are received, the firewall validates them based on the current state of the connection and then updates the state table as needed.  SPI is protocol specific and therefore the SPI engine must implement a state transition and state validation routine for each supported protocol. 

Threshold-based filtering

Threshold-based filtering (Figure 4) works by keeping statistics on the packets received and monitoring for threshold crossings based on configured time intervals and threshold levels.  If the number of packets received from a specific IP address during any time interval exceeds the configured high-water threshold, future packets from that IP address will be blocked.  Once the traffic from that IP address falls below the configured low-water threshold, the filter is disabled and packets from that IP address are again allowed.  Implementing threshold-based filtering requires a database to maintain packet counts and a monitoring module to detect and enforce threshold crossings.

 

Figure 4. Threshold-based filtering works by keeping statistics on the packets receive. If the number of packets received from a specific IP address exceeds the configured high-water threshold, future packets will be blocked.

SCADA firewalls vs. desktop firewalls

Firewall technology is standard in home and corporate networks and is a proven and reliable technology.  So why not just use one of these existing solutions to create a SCADA firewall?  First, for the same reasons desktop operating systems are not used in embedded devices; they are slow, big, and are not easily ported to a low cost, special purpose device. To build a SCADA firewall requires a small, low-cost solution that will work on inexpensive hardware.  The solution must also be customizable to support filtering of SCADA protocols.  An embedded firewall (see video) can run on devices as small as an 8-bit MCU, provide customizable filtering, and support user configurable filtering rules, allowing the firewall to be configured for any SCADA network deployment.  

Other features of a SCADA firewall

In addition to providing filtering, there are a number of important requirements for a SCADA firewall. It is crucial to provide users with a flexible and easy to use, yet secure, configuration interface.  If the firewall configuration can be compromised, then the firewall can be reconfigured and bypassed, or possibly even disabled.

The firewall should also provide statistics, logging, and reporting capability to allow security audits to determine if the device has been attacked, what IP address the attack originated from, and other relevant details.  Integration with a management system to allow centralized policy management and configuration is also critical for large scale deployments.

Summary

Firewalls provide a simple and effective layer of security and have long been used to protect home and enterprise networks. A cost-effective SCADA aware firewall can provide a critical layer of defense for SCADA devices, protecting them devices from a wide range of cyber attacks.  By controlling who/what the SCADA device talks to, most attacks can be blocked before a connection is even established. 

Alan Grau is President and co-founder of Icon Labs www.iconlabs.com, a provider of security software for embedded devices and  the architect of the company’s Floodgate Firewall.  Alan has 20 years of embedded software experience.  Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola.  Alan has an MS in computer science from Northwestern University.

References:

1. Source: John Gantz, The Embedded Internet: Methodology and Findings, IDC, January 2009.
2. Source: Cui, Song, Phatap and Stolfo, Brave New World: Pervasive Insecurity of Embedded Network Devices, Intrusion Detection Systems Lab, Columbia University

Source