Defence in depth: Three common cybersecurity issues in industrial control systems and how to manage them

Sept. 29, 2014 – The migration from traditionally isolated, purpose-built industrial control systems (ICS) to more modern IT infrastructures continues to be embraced by asset owners. However, modern IT can also bring previously unseen cybersecurity issues. More importantly, the operational requirements of control systems can create unintentional vulnerabilities that cannot be mitigated using contemporary security methods. All of these factors combine to create complexity in addressing cybersecurity risks in ICS environments.

Sometimes the problems are exacerbated due to the vulnerabilities that exist within the actual control system technology. Although vendors never introduce cybersecurity risk into their solutions intentionally, it is almost impossible to ensure applications for industrial automation are completely devoid of cyber vulnerabilities. To that end, asset owners and operators inherit the responsibility to create mitigations and compensating controls to reduce the cyber risk introduced by conventional IT for the control system applications themselves.

Contemporary cybersecurity best practices are useful within control system environments, but the nuances and complexity of industrial automation demand that the strategies be customized for the networks they’re protecting. This article will look at three common security practices applicable to ICS environments, and discuss realistic strategies to help manage them.

1. Interconnectivity
Historically, companies separated information systems responsible for corporate operations from their industrial automation. Sometimes this was done for security reasons, and sometimes it was done because nobody knew how (or wanted) to connect the two. This “air gap” provided some protection against unauthorized users gaining access to critical control systems, but it was also time-consuming and costly to get information from the plant over to corporate. In addition, just because the control system wasn’t connected to an external network didn’t mean it was protected from cybersecurity threats (let’s not forget the trusted insider or the accidental introduction of virus-laden removable media).

As businesses grew, the requirements to get real-time information from the plant floor accelerated and the once separate networks were joined. However, industry quickly realized that by connecting these networks, new vulnerabilities were introduced that created exposure to once isolated control system networks. Over the years, industry has rapidly come to learn that this connection needs to be protected, but the deployment of traditional IT countermeasures doesn’t always work properly. In many cases, the security countermeasures and compensating controls introduce new complexity that, if not managed properly, ends up completely defeating the value proposition offered by integrating corporate and automation environments.

Most security-savvy organizations will introduce firewalls or other perimeter security technology to protect their mission-critical control systems, and configure the security technologies to facilitate effective data transfer between automation and business systems. In many cases, however, organizations fail to recognize that without very specific and granular configuration of these perimeter devices, they’re really not much safer than if there was no firewall there at all.

Modern firewalls or perimeter security appliances have an extensive capability to be configured to do things that firewalls couldn’t do even five years ago. Organizations need to protect interconnectivity between control systems and corporate systems in a truly bidirectional manner. Many entities feel that simple protection of the automation network from the corporate domain is sufficient, and forget to configure the security perimeter to protect against outbound threats as much as inbound. Historical analysis has shown that those networks that are protected from ingress attacks have done little to defend against an adversary who has been successful in attacking a network and used lax egress filtering to create outbound communications back to rogue sites. Of all the lessons learned that relate to securing interconnected corporate/control system networks, those that advise on protecting egress connections just as much as ingress connections have proved very beneficial in protecting critical automation cyber assets.

2. Malware protection and ICS
Since Stuxnet (and more recently Havex), there has been a growing interest in control system-specific viruses and malware. Researchers, vendors and asset owners have for many years espoused the importance of having anti-malware capabilities within the control system, and evidence continues to suggest that protecting critical control system cyber assets from malicious software is mandatory.

However, antivirus and anti-malware tools can create undesirable situations on the plant floor. Critical servers and workstations, such as HMIs, can experience system latency or reduced screen refresh rates when an anti-malware application fires up to check the system. In addition, some asset owners have reported system crashes because the anti-malware system has erroneously tagged a critical file as a virus and quarantined it. Although these cases are rare, they are more than enough to convince some plant owners that using anti-malware on critical systems is a bad idea.

Fortunately, there are emerging strategies and alternatives to traditional anti-malware programs, and they are providing options for those asset owners who remain reticent to deploy technology that could influence the behaviour of their systems.

First, the problem associated with anti-malware programs improperly identifying and isolating critical application files has gotten the attention of more than one control system vendor. Most major control system vendors have worked with numerous anti-malware vendors to define configurations and exclusion lists specific to automation applications and technology. The progress in this area has been considerable.

Many vendors can provide operators with very specific and detailed instruction on how to configure anti-malware technology so that it does not influence the control system in a negative way, and greatly reduces the risk associated with mission-critical files erroneously being sent to quarantine. In addition, exhaustive laboratory testing has created additional instructions that allow the operator to configure their anti-malware so there is more granular control over how much processing power the anti-malware application will use when running.

In addition, technology known as “application white listing” is becoming very popular. Traditionally referred to as “kernel locking,” this technology ensures that applications or programs that are not authorized to run on the computer are prohibited from writing to system memory. The technology was specifically created for systems that, once configured to perform a task, are not expected to deviate from that task. This allows the administrator of that system to ensure that only the programs and applications allowed to run will run, and any other programs introduced (either intentionally or accidentally) will be denied. This means that unauthorized applications or data — such as viruses or other artifacts often associated with hacker methods — will not be allowed to access system memory and won’t run.  

The technology was designed to be used on systems that are purpose built and operate in deterministic and predictive environments. Although the concept of application white listing has not really been embraced on traditional IT and corporate environments, it is perfect for industrial automation because once the control system application and software have been configured for operations, it can be “locked down.”

3. Intrusion detection
In the context of IT cybersecurity, intrusion detection is used to watch for and identify possible unauthorized or malicious network traffic. Intrusion detection is passive in nature and is based on events and alarms being sent to an administrator when a certain event or threshold number of events are met.

Contemporary cybersecurity plans and activities almost always include intrusion detection systems based on signature mapping or anomalies. The intrusion detection system watches the network traffic and compares it against a known list of bad traffic. If the system identifies traffic that matches one of its signatures, it sends an alarm or event notice to the security administrator. If the system is anomaly-based, it watches traffic patterns and traffic flows, and looks for notable deviations from expected and predetermined traffic envelopes.

Over the last several years, there has been tremendous progress in the area of control system cyber intrusion detection. Asset owners have worked closely with vendors to create effective intrusion detection methods that will be usable in automation environments, while not impacting the optimization or performance of the systems it is protecting. Considering that there are two primary types of intrusion detection systems — signature-based and anomaly-based — asset owners continue to have difficulty determining what system is best for them.

Although signature-based systems are very popular and are well supported by cybersecurity technology vendors, there are issues that make using a signature-based intrusion detection system difficult. First, the number of available signatures specific to cybersecurity and control systems is considerably smaller than what’s available for traditional IT domains. In addition, the signatures that are available for control systems are not ubiquitous across all control system environments and, in many cases, offer no value to the asset owner. Operators can create their own signatures, but there is a significant cost of ownership in doing that.

Second, there is a high level of commitment to ensure that the database of signatures used by the intrusion detection system is constantly accurate and up-to-date. In most cases, operators and engineers within a facility simply do not have the time or skill to create and manage a signature update plan, nor do they have the time to write specific signatures on the devices unique to their automation environment. To that end, updating the database of signatures involves getting signature files into the intrusion detection system sitting within the control system network. This leads to an entirely new set of complex issues, as updating those signatures may involve a direct connection from the control system network out to a database to download the files.

As an alternative to using signature-based intrusion detection systems, asset owners are taking advantage of the deterministic and predictable behaviour of their control systems. Rather than creating/managing the process associated with signature-based systems, operators are creating intrusion detection rules based on what the system is supposed to do or what it is allowed to do. Relationships that involve communications and networking between control system elements — such as engineering workstations, HMIs and PLCs — are usually very well established and well known. Within these deterministic environments, there are communication pathways that exist between control elements. Some of these are normal and expected, while others are not. For example, an HMI communicates directly with the historian and PLC, but the HMI does not talk to the firewall that protects the control system from the corporate domain. It is within the understanding of these simple relationships that very effective rules can be created.

Asset owners are beginning to realize that defining granular communication rules that exist within a control system is a viable option. Operators fully understand communications within their plant operation environment, and this knowledge can be leveraged into creating rules that define communications and traffic that is explicitly allowed in the network. As opposed to comparing all the data against a known set of signatures (bad traffic), if the intrusion detection system is taught a set of rules which define the normal operational envelope, the control system will be able to “trigger” when it sees something that is not expected or allowed.

The ease of implementing these rules combined with having the intrusion detection alert when it sees something out of the normal is exceptionally valuable. In most cases, the normal operational envelope will not change, so the cost of ownership and maintaining the intrusion detection system will decrease over time.

Although there are still some requirements for managing and responding to alerts, over time this functionality becomes well understood and easily manageable for an operator or administrator. The solution is extremely flexible, can be tuned over time, and creates a significant capability for an operator to detect possibly malicious activity on the control system network.

For example, an adversary on the control system network may not be able to perform exhaustive network reconnaissance without introducing traffic onto the network that is not allowed. If the attacker had compromised one machine on the control system and tried to communicate with every other device on the network, a security alert would be triggered every time the compromised machine attempted to communicate with a device it was not allowed to.

Although contemporary information technology can be used within control system architectures, it’s important for asset owners to know that the determinism and predictability of their control systems can provide significant value in creating and managing the cybersecurity controls. Explore these solutions and alternatives, and take advantage of the fact that there is a significant amount of information available.

Mark Fabro is the president and chief security scientist for Lofty Perch, a Markham, Ont.-based security technology company focused on SCADA and control system cybersecurity.

This article originally appeared in the September 2014 issue of Manufacturing AUTOMATION.