Malware threats to Industrial Control Systems

Managers keen to avoid business interruption are delaying crucial software updates to industrial control systems. But with viruses like Stuxnet at large, this leaves organisations vulnerable says Del Rodillas.

One major reason why many industrial control systems (ICS) are highly susceptible to cyberattacks is that their software patching and anti-malware update cycles are infrequent – if they’re even happening at all.

Adding to this weakness is the growing presence of widely used Commercial Off-the-Shelf (COTS) systems whose universe of vulnerabilities and malware is constantly and rapidly expanding.  As seen in examples such as the Stuxnet and Energetic Bear attacks, these payloads can be leveraged in sophisticated cyberattacks that, if successful, could severely impact not only process availability but also safety. Let’s examine some of the ways to stay secure even in this difficult environment.

In my experience, it’s not that ICS security professionals don’t understand that patching is necessary and that systems are at risk of being compromised. Rather, it’s how the cumbersome process of ICS patching affects their main priority, which is high uptime.

Keeping the system available and running properly is critical whether the organisation is producing oil, transporting electricity or some other intensive process.

Patching in ICS to install software updates that fix vulnerabilities or to install the latest exploit/malware signatures usually requires stopping that process. With so much pressure on administrators to keep system uptime high, they often delay patching for months, or longer, to maximize production. 

“It’s not that ICS security professionals don’t understand that patching is necessary and that systems are at risk of being compromised. Rather, it’s how the cumbersome process of ICS patching affects their main priority, which is high uptime.”

In some cases, the nature of the physical process dictates the patching cycles, some of which can span years. There is also a risk that the patches may cause a system to behave in undesired ways, adding even more hesitancy to patch.  It’s for these reasons that ICS patching must be done methodically. But during this window of being unpatched, the systems are highly vulnerable to known threats as well as zero-day threats that have not yet been discovered in the wild.

While security vendors do their best to ensure that new software updates do not cause any issues to systems, they may not have tested all scenarios – some of which may cause performance issues or system crashes once deployed in production. 

These disruptions cause big problems in industrial automation environments where even temporary loss of visibility and control at the Human Machine Interface or automation server level could lead to substantial production losses and even compromise worker or consumer safety.   

The quality assurance process is made more difficult by the fact that personnel don’t always see exploitable software vulnerabilities or new software feature as compelling enough events to “mess” with a system that is working just fine. The old adage of “if it ain’t broke don’t fix it” often reigns supreme in this environment. Too often operational technology personnel believe that they sufficiently isolated for these vulnerabilities to be exploitable. But Stuxnet, which attacked an air-gapped ICS environment, is just one example of this fallacy.

There are still other challenges. Variants of older malware such as Conficker or Slammer could be accidentally released into the ICS causing various levels of loss of visibility and/or control to the process from account lockout, HMI software non-responsiveness, or the debilitating “blue-screen of death” in which machines are rendered useless.

It’s important to note that in some cases, the ICS software may not be patchable at all. For example, there are some ICSes in the middle of their lifecycle that use operating systems such as Windows XP and Windows Server, neither of which is still actively supported. Given that the average lifecycle for an ICS is more than a decade, it could be years before asset owners can deploy newer, supported operating systems. An older system is therefore susceptible to both known and unknown threats – and the known threats won’t be patched.

A good cybersecurity strategy in ICS must include both a systematic approach to patch management and compensating cybersecurity controls when patching is not an option.  Patch management increases cybersecurity through the installation of patches that resolve bugs, operability, reliability, and cybersecurity vulnerabilities.  The ISA-TR62443‑2‑3 technical report, developed by the ISA 99 Working Group 6 in collaboration with IEC 62443 standards body, addresses the patch management aspect of ICS cyber security. 

Here are five factors to consider when choosing ICS security:

• Reduce the attack surface – Make sure that the technology you select gives you granular controls at the application, user, and content levels.  Also ensure these controls are contextually tied versus residing on separate disjointed network security devices.  This leads not only to better administrative efficiency but also accuracy of the policies that you implement.
• Stop the propagation of known threats – Select a segmentation gateway that has native threat prevention capabilities to stop known malware and exploits from propagating in your network.  This serves as your first level of defense for protecting unpatched systems from threats whether specific to ICS-products or more general business software and operating systems.  Having this capability natively in the gateway instead of implemented as a separate, add-on device is important to ensure once again that there is shared context with the application/protocol and user information collected by the gateway. 
• Deploy sandboxing technology to stop zero-day threats – Advanced attackers will use zero-day malware to compromise your network.  Network sandboxing technologies that isolate suspicious payloads into a cloud-based environment, analyze them to determine their nature (malicious/benign), and send protections back to the user, are invaluable in terms of preventing zero day threats from propagating into networks. Make sure that this capability is native to the access control device so that there is a closed loop for protection, versus just serving as a detection-only device.
• Prevent zero-day attacks to the endpoint – If the threat manages to bypass network security or is implemented locally at the endpoint, it is important that any attempts to compromise the system, whether using exploits or malware, are stopped.  Detection-only technologies are not enough; these attacks must be prevented. The risks are too high in critical infrastructure applications to allow threats to successfully execute.  They must be prevented.  Newer technologies are available which rather than trying to stop exploits and malware using known threat signatures (hashes, strings, behaviors), stops the underlying techniques employed by these threats – halting even zero-day attacks to unpatched systems.
• Select a platform vs. point solutions – Integrating point solutions for network security, sandboxing and endpoint security leads to information silos, slow forensics, high administrative overhead and security gaps. When selecting a security architecture, make sure the components you pick work together as a platform. Application/Content firewalls, IPS, and URL filter functionality should be integrated into the access control device.  Furthermore, the access control device should make use of the output of the cloud sandboxing technology to ensure a closed loop in terms of stopping zero-day threats. The endpoint security should also take advantage of the threat intelligence provided by the cloud to ensure even stronger security posture than if the endpoint security was working in isolation.