Securing Industrial Controllers (Part 3)

We simplify steps into easily identified categories and then help organizations identify priorities based on their own unique environments & risk tolerance.

What Is an Industrial Controller? 

First, let’s clarify what we mean by industrial controllers. In a typical industrial environment, there will be the physical systems–things like robots, sensors, pumps, actuators, and motors to name a few. As these are the systems that actually interact with the physical world, when it comes to the priorities of cyber security in these environments–first safety and then availability, these are ultimately the systems we need to protect. However, something like a motor is not often going to be a system that can or will be directly attacked or exploited.

Instead, these physical systems are connected back to a type of specialized computer that actually controls it. It is these specialized computers that make the bridge between controlling the physical systems and receiving programming or instructions from a network. These are the industrial controllers, and they are the systems being targeted to create physical damage or disrupt a revenue generating industrial process in cyberattacks.  Industrial controllers come in different varieties, but you will hear terms such as programmable logic controllers (PLSC) and distributed control systems (DCS) used commonly to refer to different types of these.

Common Ways Controllers Can Be Attacked 

There are a few different attack vectors (ways an outside adversary or malicious insider would approach breaking into a system) we worry about when it comes to industrial controllers.

Denial-of-Service (DoS)
The first and simplest would be a denial of service attack. By overwhelming a system with a large number of frames in network traffic or malformed packets to create heavy system loads, it may be possible to create latency and downtime on a controller, which could interrupt physical systems. In some physical processes, damage may occur. Although safety is potentially a concern here, the reality is most safety systems have been built to handle these situations as well-designed safety environments wouldn't compromise safety by an increase in latency or lack of availability for a single controller.

ICS Misconfigurations and Vulnerabilities
Another attack vector is to exploit vulnerabilities or misconfigurations in the controller. By attacking an vulnerability not patched with upgraded firmware, a malicious attacker could potentially disrupt, gain access to/ take over control of a system. Similarly, although modern controllers have added security features like authentication and logging, if these are not properly configured, those checks and balances may be disabled and allow an attacker to easily modify the system without detection.

According to Tony Gore, CEO at Red Trident, “During cyber security assessments, we find there has to be a pivot-point the attacker has gained access to.  Taking advantage of weak configurations or known and exploitable vulnerabilities is one of the easiest ways to gain access to engineering workstations, HMIs, servers, third parties and other systems. Another is through stolen credentials, jointly shared credentials, or a lack of authentication methods... Once unrestricted access is gained at Level 2 devices, this becomes the adversary’s pivot-point. We don’t always see PLCs directly connected to the Internet, but will use Shodan to see what shows up for our customer’s Internet-facing systems. It’s always a surprise.”

Malware, USBs & Firmware
A third and most dangerous attack would be uploading a malicious program to the controller, overwriting the valid program that already existed on it. On some controllers, physical access to the device can be used to accomplish this (e.g., plugging a USB drive into it or making a serial connection) and on more modern ones programs are uploaded across the network–requiring various forms of authentication, which is often not setup at time of PLC deployment.

Older networked controllers may have no authentication at all required–a major issue–while newer ones almost certainly will. Even with proper authentication, a malicious insider, such as a disgruntled employee or a consultant, or an outside attacker who has stolen credentials (e.g., the password to the system) can go make these changes.

Additional ICS Attack Vectors
Additional vectors of attack can exist in the form of trusted computer systems operating on levels inside the ICS environment that have unrestricted and non-monitored access to various levels of the control environment. Malicious programs have been used in industrial attacks to create subtle or not so subtle changes to physical processes, causing physical damage. Almost equally damaging are pivot points and attackers tool-kits modifying set points in a non-monitored and poorly engineered security architecture. This allows for ample reconnaissance time as well as the trial and error to successfully compromise but ultimately maliciously modify the environment.

The next cybersecurity blog will cover ways to secure controllers in a way to help prevent attacks such as those described earlier, and what types of strategies are essential for reducing the attack surface within ICS, detecting and responding to unexpected and unplanned changes that could indicate an attack, malicious insider activity or simple human error–all sources of cyber security risk.