Protecting ICSs from Electronic Threats, Part 1

By Joe Weiss, PE, CISM Applied Control Solutions

The following is the first section of a three-part "Security Spotlight" series, which consists of portions of Joe Weiss' Protecting Industrial Control Systems from Electronic Threats, Momentum Press, 2010. Parts 2 and 3 will run in the August and October issues of Control.

The fundamental reason for securing industrial control systems (ICSs) is to maintain the mission of their overall production systems, whether they generate or deliver power, produce or distribute oil and gasoline, provide clean water or operate any other process application or facility.

I don't believe it's possible to fully electronically secure ICSs. However, we can make them more secure and also minimize the possibilities of unintentional incidents that have already cost hundreds of millions of dollars and a number of lives.

From a cybersecurity perspective, ICSs are very brittle and attacking them isn't rocket science. On the other hand, it can be rocket science to protect them and maintain their missions at the same time.

Unfortunately, while the first two legs of the three-legged security stool—physical and IT security—are well understood, the third leg, ICS security, is much less understood, has few experts and is often not considered critical. Those working in this area are generally from the IT security community and have little knowledge of ICSs, or are ICS experts who know operations, but not security. Operations alone can't secure ICSs. It takes a team of experts in IT security, telecom, networking, ICS and IT vendor support, and senior management, most of all.

Presently, many issues are coming together that are making ICS electronic security of paramount importance. These include growing smart grids for electricity distribution and generation, government stimulus money, cybersecurity funding, terrorism threats, chronically sick economies and emerging green ones and the need to reduce carbon footprints. All of these can be impacted by ICSs' electronic security or lack of it.
Definitions, Descriptions and Differences

From an ICS perspective, it's very important to understand what could compromise a control system. The National Institute of Standards and Technology (www.NIST.gov) defines a cyber incident is "an occurrence that actually or potentially can jeopardize the confidentiality, integrity or availability (CIA) of an information system or the data it processes, stores or transmits, or that constitutes a violation or imminent threat of violation of security policies, security procedures or acceptable use policies." What's important about this definition is that cyber incidents can be intentional or unintentional.

For the ICS community, there's a need for additional definitions of cybersecurity and cyber incidents. So, the following terms for compromised ICS modes are suggested:

Loss of view (LOV), which consists of incidents that blind operators and put them at risk of taking harmful actions due to inaccurate knowledge of ICS status.
Manipulation of view (MOV), which is intentionally manipulating HMIs by changing displayed states on intelligent electronic devices (IEDs), so an operator will unwittingly perform potentially dangerous actions.
Denial of control (DOC), which prevents operators from interacting with process control points. These include operator accidents, hardware failures, network failures or improper network capacity.
Loss of control (LOC) is a sustained event or the creation of unstable conditions in which operators can't take alternate action before a potentially catastrophic condition occurs.

Fortunately, while ICS networks and HMIs are similar to IT systems and may be subject to their usual vulnerabilities and threats, ICSs can benefit from using IT security technologies too.

Similarly, enhanced SCADA protocols, namely IEC 61850 and Distributed Network Protocol (DNP3), are being modified to run over TCP/IP, Ethernet and possibly other protocols. These improvements make them more vulnerable to security risks because they're running on utility networks and not on isolated, dedicated circuits, but they could be further enhanced to use security countermeasures developed for these networks.

In addition, there's been a blurring of the differences and similarities between ICSs and IT. For example, some of the functions of routers in IT and remote terminal units (RTUs) in ICSs have migrated toward a common area occupied by SCADA servers. This has big implications for security, as IT personnel may attempt to use inappropriate policies, technologies or testing of these systems that appear to be IT.

The use of mainstream operating system environments, such as Windows, UNIX and Linux for running ICS applications can leave them just as vulnerable as IT systems. At the same time, the application of mainstream IT security solutions and methods will help to secure more modern ICS host computers and operator consoles, also known as PCs. IT technologies use virtual private networks (VPNs) to secure communications to and from ICS networks. IT security focuses on the strength of the encryption algorithm, while IC security focuses on what goes into the VPN.

For example, one of the U.S. Dept. of Energy's National Laboratories showed how a hacker can manipulate widely used "middleware" software running on current mainstream computer systems without much difficulty. In this sobering demonstration, vulnerabilities in OPC code were used to make it appear that the system was functioning properly, even though it was not, because it displayed incorrect information or withheld correct information from system operator consoles.

General and Administrative Security Recommendations

Based on the experiences of myself and others, I provide the following general recommendations:

Develop a clear understanding of ICS cybersecurity, including associated impacts on system reliability and safety for industry, government and private citizens.
Define cyber threats in the broadest possible terms, including intentional, unintentional, natural and other electronic threats, such as electromagnetic pulses (EMPs) and electronic warfare against wireless devices. ICS cyber security threats are more than malware and botnets.
Change the culture around critical infrastructure so security is considered in the same context as performance and safety.
Get operations and IT to work together.
Establish a means for vetting ICS experts, rather than using traditional security clearances or IT certifications.

Next, on the administrative and procedural side:

Get senior management support because improving ICS cybersecurity will fail without it. Then identify division of responsibilities and reporting structure all the way to the board of directors because cybersecurity is a corporate risk.
Identify all affected stakeholders and their applications, including those beyond operations and the organization, such as contractors, vendors, regulators, first responders and even the public.
Mandate effective cybersecurity requirements so this is not simply a compliance exercise.
Determine what you really have and what you have done because the hardware, software and firmware that affect cybersecurity are often not identified in any formal system diagrams or vendor documentation. Establish a living configuration management or configuration control program that includes the ICS as well as cybersecurity-specific software, hardware and firmware.
Learn what you really need from the ICSs in terms of functions, features and communications by obtaining input from throughout your organization because cybersecurity will affect any new systems.
Decide what you want to do—and do it, which is not as easy as it sounds. This requires an understanding of what features are needed, what features can be cyber-vulnerable, and which of these need to have security enabled.
Determine what risks are present and modify risk assessments that address probability and consequence. Probability should be listed as #1 (it will happen), and consequences should be based on "design basis threat," which is the worst case the facility was designed to safely handle. Because risk assessments require a cost-benefit tradeoff between performance and safety versus security, this involves assessing the risk of security and performance features.
Develop ICS-specific policies and procedures. Recognize that complexity adds security overhead and potential performance and safety impacts. Work with IT to make sure that the ICS policies and procedures are consistent. But first, develop them for the specific equipment to be secured and how it's expected to be operated.
Make equipment suppliers and contractors your partners in securing your systems. Require documentation of what's been provided and how it's been tested and secured.
Consider lifecycle issues because ICSs can be cyber-vulnerable from initial design until they're retired.
Consider system recovery issues after an incident.

Next time: Part 2 will feature more on threats, myths, personnel status, information sharing, cybersecurity risk assessments and technical recommendations.

Joe Weiss, PE, CISM, of Applied Control Solutions (www.realtimeacs.com) is author of Control's Unfettered blog (http://www.community.controlglobal.com/unfettered).