By Sunil Maryala
It is well-known the most popular industrial automation and control systems (IACS) operate on proprietary technologies designed to run autonomously, and for a very long service life.
The software and hardware on many of these older systems were often designed without security considerations because these systems were isolated within the factory. This isolation created a false sense of security despite numerous vulnerabilities that would make these devices a potential target for cyber-attacks. Unfortunately, this situation of poor security design coupled with lack of awareness within ICS persists to this very day.
As the need for more connectivity arises, IACS devices such as PLCs and SCADA systems are connecting to the network.
Also, traditional serial based protocols such as Modbus and DNP are now riding on open standards such as TCP/IP, which multiplies the security risk by having more devices and protocols running across a network. Recent attacks on critical infrastructure and industrial control systems have proven that hackers are trying to exploit vulnerabilities that exist in industrial protocols.
Traditional firewalls based on access control will not help in securing IACS as their rules look at IP address and port numbers and mainly these policies are static. Transactional information in industrial protocols exists in the application layer. An example is Modbus/TCP where Modbus function information is carried in the application payload.
To secure the IACS, deep packet inspection (DPI) of traffic is needed. DPI can look at exact transactions to differentiate a “read” from a “firmware update” message, for example. DPI is used to understand specifics of IACS protocols and then apply filters to fields and values that matter to control systems.
Let’s take an example of a simple Modbus communication in a typical SCADA system. Usually, there are two components in the communication — a master and a slave. In a standard Modbus network, there is one master and up to 247 slaves, each with a unique slave address from 1 to 247. The master can also write information to the slaves.
When a master device issues commands, the slave devices obey these commands, such as a command to open or close a breaker.
A Modbus packet command has all the data: MBAP header = destination Modbus unit, function code = read/write and data to be written or read to fulfill and command by the slave device. What is missing is the information on where this command originated. So that means the slave has to satisfy the command without knowing the origin of the command.
Almost all of the SCADA protocols have the packet structure similar to Modbus in which they do not have a way to authenticate the originator of the destination.
This scenario creates an issue in which anyone who can reach a SCADA device can send a command. A malicious hacker can send a command to the SCADA device to change a parameter such as cooling threshold in a power generation plant to a setting higher than the average temperature. This action means the cooling system does not activate even if the temperature in a power plant goes beyond the typical operating conditions and thus leads to an overheating of the system and damaged machinery. If hackers can disable the cooling system, this might lead to more catastrophic damage such as an explosion in the plant.
Two things must be done to avoid attacks which exploit weaknesses in SCADA protocols. First, verify that a command is coming from a valid master/source. Second, ensure all requests are correct and do not endanger the safety of the plant.
Regular firewalls which inspect traffic based on IP addresses can prevent unauthorized hosts from sending commands, but cannot stop a scenario where IP spoofing is employed and a command is sent to disrupt the industrial control system. An IP spoofing scenario is where firewalls should be in place that can go beyond just the IP address, look at the application payloads, and understand the command and data to know the exact transaction between a master and slave device.
Security-related events need not always be the result of external attacks with malicious intentions. Industrial control systems more often get disrupted by human error inside the plant by personnel who are unfamiliar on the full functionality of these systems, or the ramifications of certain activities. For example, a new technician on the plant floor might program a robot to move in a specific direction or a range which can hit other machines, or hit other people on a plant floor. This oversight could result in damage to the equipment or a clear safety problem.
By having DPI-based firewalls, rules can be implemented that look at the commands and coordinates issued to a robot and allow only directives that meet the limitations of safe movement. Effectively establishing these rules create a safety policy and align to a security policy on the DPI-based firewall. DPI firewalls can also help prevent Zero Day attacks by doing the sanity check on the protocol if it is deviating from the standard on the behavior or packet construction.
Whether a security-related event is caused by an external attack with malicious intent or human error by plant personnel, it’s important to utilize DPI. Doing so helps ensure the network security of the plant as well as physical safety of employees as protection of valuable equipment.
Sunil Maryala is a technical marketing engineer at Cisco focused on IoT Security. He has over 17 years of experience in the computer science industry. He is responsible for developing products, architectures and solutions to enable security for IoT. Prior to joining Cisco, Sunil wrote software for Automatic Trains at Bombardier Transportation as well as for firewalls in India. He holds an active CCIE certification.