Deep packet inspection benefits for industrial automation and control systems

Deep packet inspection (DPI) of traffic is needed to secure an industrial automation and control system (IACS) to understand specific protocols and apply filters to fields and values that matter to control systems.

By Sunil Maryala November 30, 2017

An industrial automation and control system (IACS) operates on proprietary technologies designed to run autonomously for a long service life. The software and hardware on 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. This poor security design situation, coupled with a lack of awareness within industrial control systems (ICS), still persists.

As the need for more connectivity arises, IACS devices such as programmable logic controllers (PLCs) and supervisory control and data acquisition (SCADA) systems are connecting to the network.

Traditional serial based protocols such as Modbus and DNP are 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.

Firewalls based on access control will not help secure an IACS. 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.

Deep packet inspection (DPI) of traffic is needed to secure the IACS. 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 apply filters to fields and values that matter to control systems.

Master-slave protocols

In a typical SCADA system, 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. When a master device issues commands, the slave devices obey these commands.

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. That means the slave has to satisfy the command without knowing the command’s origin. Almost all SCADA protocols have a packet structure similar to Modbus and do not have a way to authenticate the originator.

This scenario creates an issue where anyone able to reach a SCADA device can send a command. A malicious hacker, for example, 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 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 plant’s safety.

Regular firewalls that inspect traffic based on IP addresses can prevent unauthorized hosts from sending commands. They cannot stop a scenario where IP spoofing is employed. IP spoofing is where firewalls that should be in place 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.

Overall security

Security-related events need not always be the result of external attacks with malicious intentions. ICSs are often disrupted by human error inside the plant by personnel who are unfamiliar on the system’s full functionality or on the ramifications of certain activities. 

With DPI-based firewalls, rules can be implemented that look at the commands and coordinates issued to a robot and allow directives that meet safe movement limitations. 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 performing a sanity check on the protocol if it is deviating from the behavior or packet construction’s standard.

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 a plant’s network security as well as the physical safety of employees.

Sunil Maryala is a technical marketing engineer at Cisco focused on IoT Security. This content originally appeared on ISSSource.com. ISSSource is a CFE Media content partner. Edited by Chris Vavra, production editor, CFE Media, cvavra@cfemedia.com.

ONLINE extra

See related stories from ISSSource linked below.