Interview: Alan Grau On What You Should Know About Industrial Cyber-Attacks
We are increasingly reliant upon industrial systems, many of which were designed before cyber-attacks against industrial systems were even considered. Our aging industrial control systems are vulnerable to a wide range of attacks and many new systems are being deployed with insufficient security. It is imperative that security for industrial systems be addressed. Doing so requires an understanding of the problems and challenges relating to securing industrial control devices. I recently talked with Alan Grau, president and founder of Icon Labs, about these issues.
Wong: What is the danger of cyber-attack for industrial systems?
Grau: Industrial systems are increasingly automated, and the greater the automation, the larger the impact of a cyber-attack on these systems. The potential impact is huge. The cost of downtime for a production line can easily be in the hundreds of thousands of dollars per hour or more. In addition to downtime costs, a compromised control system could result in physical damage to the plant or the product. A sewage spill caused by a compromised control system resulted in 800,000 liters of raw sewage being dumped into parks, rivers and the grounds of a hotel. The cost of this sabotage is hard to estimate. It is an interesting attack because not only did the perpetrator cause pumps to not run when they should have been running, he also was able to prevent alarms from being reported, further complicating the problem. In another attack a pump was cycled on and off repeatedly until the pump motor burned out.
Related Articles
Wong: How do most industrial facilities prevent attack? Why is that not working?
Grau: Most industrial systems rely on security at the perimeter. They install standard enterprise security (firewall, Intrusion Detection and Intrusion Prevention systems) at the entry point to the network, and then install the SCADA devices within the secure boundary. There are three flaws with this approach:
1. Threats may originate from within the network. Cyber-attacks can penetrate the corporate security perimeter, or can originate from within the network itself. Insider attacks or even accidental, but unauthorized commands from a valid user can result in serious breaches of security. One large industrial control company recently said that a major concern is employees accidently issuing control commands that they are not authorized to make. Adding security to authenticate these commands is one of their top priorities.
2. Security parameters for the enterprise as a whole may not be appropriate for industrial devices. Industrial devices may only need to communicate to a few other machines, and only communicate using a few, specialized protocols. The filtering rules used by enterprise firewalls are generally not appropriate for industrial devices, which may require more restrictive filtering rules. In addition, the enterprise security systems will not recognize the protocols used by industrial systems and therefore cannot do any protocols specific filtering for these devices.
3. Some devices may not be installed within the corporate security boundary. Devices installed at remote locations clearly require their own security solution.
Wong: What is an embedded firewall? How does that differ from the typical firewall found in most IT and enterprise networks?
Grau: The main difference is the firewall resides on the device itself, as opposed to running as an appliance on the network. It is integrated into the device’s communication stack with the communication requirements of the device encoded into a set of policies defining allowable communication. The firewall enforces these polices, limiting communication to the required IP address, ports and protocols. In some cases, the firewall can also support protocol specific filtering for the relevant industrial protocols such as Modbus.
Since each packet or message received by the device is filtered by the firewall before being passed from the protocol stack to the application, many attacks are blocked before a connection is even established, thereby providing a simple, yet effective layer of protection missing from most devices.
Wong: How does an embedded firewall work? What does it block?
Grau: An embedded firewall works by controlling the communication with the device. The firewall will limit communication to known, trusted hosts. It will also close any unused ports and protocols, further limiting communication.
For example, 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, with an embedded firewall configured with a whitelist of trusted hosts, blocks the attack. The firewall blocks packets from the hacker before the packet is passed to the application to attempt to login.
If the firewall supports filtering of application specific protocols (i.e., Modbus, etc.) then attacks that exploit weaknesses in those protocols can also be blocked.
Rules-based filtering provides a simple and effective tool enforcing communication polices, blocking communication from a non-trusted IP address and isolating the device from attack.
Wong: How do I integrate an embedded firewall into my design? Chip, Board or Assembly level projects
Grau: Typically, the firewall will be integrated with the communication stack just above the device driver level. This allows filtering to occur as early as possible in the processing of the packet. Filtering may also be inserted in the device driver layer. For example, to filter packets by MAC address, filtering would need to be inserted into the Ethernet layer itself to ensure visibility into the sender’s MAC address. The drawback of this approach is that it adds processing to the device driver.
For most applications, filtering can be performed at the IP layer. By filtering at a lower layer in the stack, packets are dropped before the embedded device utilizes additional processing resources. When filtering at the IP layer, the firewall can first perform filtering based on IP packet header information, then on protocol-specific criteria such as TCP port, UDP port, etc.
Wong: How do I configure and control the firewall?
Grau: The firewall works by enforcing communication policies. How these policies are configured will depend upon the device implementation. Some policy rules may be hard coded into the device by the engineering team. For example, if the device does not support web services, a rule to block all traffic to port 80 may be hard coded into the device in the factory. Other rules will need to be configured by the user of the device.
The device engineers will need to provide an interface for configuring filtering rules. This can be achieved through a local command line interface or web interface, or by integration with an enterprise security management system such as McAfee’s ePolicy Orchestrator.
Wong: What kinds of monitoring and reporting services are available?
Grau: Security event monitoring and reporting are a critical piece of the security solution. If a device cannot report security events, a hacker may continue to probe indefinitely until a password is found or security vulnerability is discovered.
At a minimum, the firewall should log filtering rule violations, invalid login attempts, and other security related events. Some systems, such as Icon Labs Floodgate Firewall, provide integration with corporate level security systems such as the McAfee Enterprise Security Manager.
Security must be made a priority for industrial control systems. Solutions are available for building secure systems and security by obscurity is no longer acceptable. Security must be considered early in the design phase. Since many embedded devices are deployed outside of the standard enterprise security perimeter, it is critical that security be included in the device itself.