Information Security Today Home

New Books

Critical Infrastructure: Understanding Its Component Parts, Vulnerabilities, Operating Risks, and Interdependencies by Tyson Macaulay, ISBN 9781420068351
Smart Grid Security: An End-to-End View of Security in the New Electrical Grid by Gilbert N. Sorebo and Michael C. Echols, ISBN 9781439855874
Risk Analysis and Security Countermeasure Selection by Thomas L. Norman, ISBN 9781420078701
Critical Infrastructure: Homeland Security and Emergency Preparedness, Second Edition by Robert S. Radvanovsky, ISBN 9781420095272

SCADA Security: What Is an Industrial Control System?

Tyson Macaulay and Bryan L. Singer

Process control system (PCS), distributed control system (DCS), and supervisory control and data acquisition (SCADA) are names frequently applied to the systems that control, monitor, and manage large production systems. The systems are often in critical infrastructures industries, such as electric power generators, transportation systems, dams, chemical facilities, petrochemical operations, pipelines, and others, giving the security of PCS, DCS, and SCADA systems evaluated importance in the increasingly networked world we live in.

SCADA especially is a term that has fairly recently been deprecated. In 2002 the International Society of Automation (ISA) started work on security standards for what it called industrial automation and control systems (IACS), under the aegis of its 99 standard. IACS included SCADA services and reflected the wider and broader industrial infrastructures that were based on IP and interfaced with IT systems. IACS was further shortened in 2006 when the Department of Homeland Security (DHS) published Mitigations for Vulnerabilities Found in Control System (CS) Networks. Finally, in 2008, the National Institute of Standards and Technology applied the current compromise name, industry control systems (ICS), in its landmark publication of NIST 800-82: Guide to Industrial Control System Security.

In this chapter we distinguish between PCS, DCS, and SCADA systems as a matter of formal detail, but for the most part we intend all three systems when using the term industrial control systems (ICS). As a preliminary summary, ICS gathers information from a variety of endpoint devices about the current status of a production process, which may be fully or partially automated. Historians, typical IT systems within process control environments, gather information concerning the production process. PCS, DCS, SCADA, and so forth, read values and interact based upon automated logic alarms and events requiring operators interaction, or report automated system state changes.

A process control system allows operators to make control decisions, which might then be relayed upstream, downstream, or to parallel processes for execution by the same system. These systems could be within the four walls of one building, or could be spread throughout a potentially massive geographical region (in the case for items such as pipelines, power distribution, water and wastewater management.) For example, an ICS might gather information from endpoint devices that allow operators to assess that a leak may have opened in a pipeline. The system aggregates this information at a central site, which contains intelligence and analytics alerting a control station and operators that the leak has occurred. Operators then carry out necessary analysis to determine if and how the leak may impact operations, safety, and regulations (environmental, health, and safety).

ICS displays the information gathered from endpoint devices in a logical and organized fashion, and keeps a history of the parameters received from the endpoint device. If the leak under investigation required that pressure in the pipeline be reduced or even that the pipeline be shut down, then these operational instructions may be issued from the control station through the ICS. Another possibility is that the ICS is intended for monitoring but not active intervention, in which case the operators would dispatch maintenance teams according to the coordinates provided by the process control system.

This example starts to reveal the fact that control systems can be relatively simple or incredibly complex. More often than not, the systems are more complex than is readily apparent on the surface, which in part distinguishes them from IT systems. For instance, where the traditional IT space deals with a fairly limited set of operating systems, communications protocols, and Open System Interconnection (OSI) model layer 1 (physical) and layer 2 (data link) device vendors (as illustrated in Figure 1.3), a typical process environment can represent hundreds of devices from different vendors with different specifications, protocols, and physical deployment requirements.

Figure 1.3. OSI layers versus TCP model. (From Gilbert Held, A Practical Guide to Content Delivery Networks, Auerbach, New York, 2006.)

Systems may be solely intended for the purpose of collecting, displaying, and archiving information from endpoint devices. For instance, urban traffic flow information from various intersections around a large city is used for both day-to-day governance and long-term urban planning. Alternately, ICS in a nuclear power plant or a municipal water system may have the ability to apply either automatic, semiautomatic, or operator-controlled changes. It is important to note at this point that ICS are not necessarily the same as safety systems, and in some cases are completely distinct. More on the difference between ICS and safety systems will follow in this section.

Is Industrial Control System Security Different Than Regular IT Security?

Comparing techniques, tools, and terminology, ICS security is not entirely different from current IT security. There are differences, however. These differences largely center around the following principles:

  • Almost all ICS security failures have physical consequences, impacts that are frequently more severe and immediate.
  • ICS security issues often manifest initially as traditional maintenance failures or other nuisance trips and process stoppages, making them difficult to diagnose and remedy. Anomalies are more prevalent.
  • ICS security can be more difficult to manage: old systems that can't be patched or upgraded, no luxury of development and test environments, massively dispersed assets with mandatory requirements for frequent remote access, and conventional protections such as antivirus or firewall that may not be able to be utilized.
  • Cyber threats to an ICS include myriad additional threat vectors, including non-typical network protocols, commands that cannot be blocked due to safety or production issues (alarm and event traffic, for example), and otherwise valid communications used by an attacker in invalid ways.

What is more, most legacy and even many contemporary ICS assets were not planned and budgeted with IT-like security as part of cost of goods calculations; therefore the business margins simply do not support additional security, especially in regulated industries where tariffs are approved by regulators. Many of these industries are already heavily regulated, and operators are naturally reluctant to add any additional complexity into a process if it complicates compliance. Given that convergence between IT and ICS networks is a relatively new discipline, ICS security as a domain has much it may productively learn from the far more mature, larger IT security domain.

Threat and risk assessment and management are far more developed as are the language and tools for addressing threats and risks is a systemic fashion using standardized terminology. Conversely, off-the-shelf IT security controls and safeguards are not ready to be applied wholesale to ICS: there needs to be a reconciliation and understanding of the potential for kinetic impact and lasting physical damage to product quality, operations assets, and potentially irrecoverable downstream and upstream impacts to customers, partners, and suppliers.

Last, because of overlapping but not necessarily apparent impacts shared between IT and ICS, people may be reluctant to take action. For instance, if an industry has explicit safety regulations to apply and has built to these mandatory safety standards, then security may not even be on the table! It can take a lot in some cases to convince someone that a security issue is not addressed by a safety design that has been accepted by a regulator.

What Has Changed in ICS That Raises New Concerns?

ICS technology has been evolving since the earliest systems for remote monitoring and controlling of industrial processes were put in place in the 1960s. Prior to this period, manual operator observations and intervention were the norm, aided by networks of pipes with gauges that allowed very simple forms of process monitoring. (Think of the steam pressure gauge on a boiler, which might be available on the bridge of a ship.) The advent of transistors and modern electronics made the process control systems as we know them today possible, allowing industrial processes to be made both more efficient and more pervasive.

Of course, ICS also improved the ability to detect and respond to dangerous situations, and thereby mitigate some of the risks associated with massively scaling up industrial production processes in order to gain economies of scale. As we will discuss soon, while ICSs are not safety systems, they allow processes to be managed with a significantly greater degree of assurance that could be attained by applying pre-ICS techniques, such as manual observations by larger staffs of industrial workers.

As might be expected with any new technology, in the earlier days of ICS there were many different suppliers, each with a proprietary technology. Standards for process control communication did not exist at the birth of the process control market, so each vendor tended to develop the necessary technology to connect remote endpoint devices to the networks and transport the data to central data historians and management consoles. Gradually, the ICS market consolidated through attrition, mergers, and acquisitions to the point we are at today, with perhaps half a dozen dominant process control vendors from an original field of probably hundreds.

In addition to market consolidation, a wide variety of new requirements have emerged for process control systems relative to their initial foundations. For instance, the period in which ICS has been evolving has paralleled the evolution of business information systems, which moved from carbon paper and dictation to e-mail and Internet commerce during the same period. Similarly, a host of new regulatory requirements, from financial reporting to environmental monitoring, have come into effect while process control systems evolved. These factors mean that process control systems had an increasing need to interface with other information and reporting systems in the business.

Recent industrial history has demonstrated that the life cycle of a control system is now between 15 and 30 years. As little as even 15 years ago, network and software security was not a top priority in the control systems environment, and ICS networks were not using the same underlying protocols as the other business networks within organizations. Recall that 15 years ago technologies such as Novell and Banyan dominated the LAN market, while IEEE 802.3 Ethernet was just evolving. Internet protocol was available, but typically only as a fiddly third-party software extension.

The IT and ICS networks were conventionally and technically isolated. Control systems were stand-alone assets not connected to business networks or the outside world except perhaps for very slow modems that would be used for remote management and maintenance. Competition among process control vendors and a drive for simpler to manage networks and cost savings have driven ICS from highly proprietary, custom-built, stand-alone systems to those that use commercial off-the-shelf (COTS) hardware and software components.

With the convergence of ICS onto the same IP and operating system platforms as other generic business tools and applications comes increased risk. In the last 6 months of 2010, Symantec stated in its Internet security threat report10 that it "recorded more vulnerabilities in 2010 than in any previous year since starting this report. Furthermore, the new vendors affected by a vulnerability rose to 1,914, a 161% increase over the prior year."

The Symantec evidence makes it plain that malicious code and cyber threats continue to grow as the Internet expands and penetrates further and further into both business and personal applications, but how does this translate to threat levels related to ICS assets?

Some analysts estimated that 10% of all IP-enabled devices in existence today are ICS devices.11 This number of connected devices (versus people via PC and laptops) is expected to grow dramatically with a compound growth rate of 30% from 2012 to 2020-reaching as much 7 billion devices by that time and completely outnumbering people-oriented connections.12

Much of this connectivity will be through wireless cellular technology, but also through more traditional Ethernet LANs; but all of it will be IP-based and especially IPv6 (see the last chapter for a discussion of IPv6). Connected devices are all around us, yet their profiles and exposure to IP-based threats are hardly known relative to the discussion and effort associated with IT controls and safeguards. Granted, any IT controls and safeguards can be directly applied to ICS, but the way they are applied is always based on a risk calculation, and ICS risks are distinct from IT risks, as discussed previously.

More encouraging is that awareness of ICS security has risen dramatically in the last few years. The U.S. Department of Homeland Security recognizes the importance of ICS security education and awareness and offers funding for industrial control security research and tools for managing and even procuring secure process control systems. For instance, DHS has published the cyber security procurement language document as a means to help asset owners integrate security into their control system's security life cycle. There is also the Idaho National Labs Recommended Practices Commission, and the Control Systems Security Program (CSSP) at the U.S. Computer Emergency Readiness Team (US-CERT13).

About the Author

Cybersecurity for Industrial Control Systems: SCADA, DCS, PLC, HMI, and SIS by Mano Paul, ISBN 978-1-4398-1446-8 From Cybersecurity for Industrial Control Systems: SCADA, DCS, PLC, HMI, and SIS by Tyson Macaulay and Bryan L. Singer, ISBN 978-1-4398-0196-3. New York: Auerbach Publications, 2012.

Subscribe to
Information Security Today

Powered by VerticalResponse

Share This Article

© Copyright 2012 Auerbach Publications