Even efforts to protect the networks can lead to unintended consequences. Regulations such as the Critical Infrastructure Protection (CIP) standards from the North American Electric Reliability Corporation (NERC) drive integration, as electric ISOs seek access to production data in real-time to demonstrate compliance. Ironically, the pursuit of security itself can lead to exposure! Protective measures such as centralizing access control to minimize tampering, or extending closed circuit TV (CCTV) monitoring or voice over Internet (VoIP) to remote stations, require increased accessibility.

Looking into the future, what happens when smart meters are integrated into the grid, offering the capability to not only monitor but also remotely disconnect customer facilities? How can we be certain that access to these devices is available only to authorized parties? Cyber security is an issue that will not go away, but will only increase in importance over time.

Challenges of Interconnectivity

Clearly, interconnectivity is the wave of the future – but many control system components were conceived in the past. Control devices, and the PCs that manage them, are very vulnerable – not only to malicious attacks using malformed network data, but in many cases even to high levels of correctly-formed network traffic. PLCs and remote terminal units (RTUs) are typically optimized for high-performance real-time I/O, rather than for robust networking. In addition, SCADA systems run continuously for weeks or months at a time – disabling some of these systems even for only a few minutes can result in significant financial, service or even safety impacts. As a result, the PCs in these networks are often not up to date with security patches or anti-virus definitions.

Figure 1: Relationships between common components of a SCADA network
 

In the early days, SCADA systems were implemented as very simple ‘islands’ of automation, but they have steadily grown in size and complexity over time. As a result, many SCADA networks are poorly segmented, with little or no separation between subsystems or even across physical locations. If a problem occurs in one area of the network, it can spread rapidly to other unrelated systems elsewhere in the network. Poor segmentation also makes it very difficult to locate the origin of a problem and resolve it at the source.

The third common issue is the existence of multiple paths of entry into these networks. Many control network managers will swear up and down that their control systems are not connected to the enterprise network or the Internet, but authorized penetration testing often shows otherwise. Here is what the U.S. Department of Homeland Security has found:

“In our experience in conducting hundreds of vulnerability assessments in the private sector, in no case have we ever found the operations network, the SCADA system or energy management system separated from the enterprise network. On average, we see eleven direct connections between those networks. In some extreme cases, we have identified up to 250 connections between the actual producing network and the enterprise network.”

In addition, there are often other transient paths of entry that don’t even show up on a network diagram: VPN connections, laptops or even USB memory sticks traveling in and out of the plant can easily carry viruses right into the heart of the SCADA network.

Theoretical vulnerabilities lead to real-world incidents with far-reaching consequences including loss of productivity, revenue, and even loss of life. In 2003, the Davis-Besse nuclear power plant in Oak Harbor, Ohio, was infected with the MS SQL ‘Slammer’ worm that originated in a network connection from a contractor, resulting in the plant process computer being inaccessible for over 6 hours. Then, in August of 2006, the failure of two water recirculation pumps due to excessive traffic on the control system network forced the manual shutdown of the reactor at the Browns Ferry Nuclear Plant. And a year later, the National Transportation Safety Board found that an unresponsive SCADA system at Olympic Pipe Line Company contributed to a pipeline rupture and subsequent fire that killed three young men in Bellingham, WA. There are also many less serious incidents that have gone unreported in the press.

Taking Control of the Network

Most IT managers have significant experience addressing cyber security issues in enterprise networks, so why can’t managers of control and SCADA networks simply apply the same technologies in their systems? Control systems have unique requirements that until recently have not been addressed by available security solutions. These requirements include harsh physical and electrical environments; support for the unique communication protocols that are common in control networks; and the ability to install, configure and test these security solutions in a ‘live’ operating network without putting the plant at risk. As a result, most SCADA and control networks today run with little or no security measures in place.

The first step in securing a network is to document a clear security policy for network access. This policy will typically establish some criteria to allow initial access to the network, as well as further criteria that define acceptable endpoint behavior after access has been granted.

A typical security access policy might look like this:

• Access to the network is granted only to certain authorized users – the identity of each PC user must be validated.
   
• Access is granted to endpoints (PC and otherwise) that can demonstrate that they are ‘healthy’ and will not present a risk to the network. For example, PCs must be up to date with their security patches, have approved anti-virus software installed, etc.
   
• Once granted access, endpoints must continue to demonstrate behavior that is appropriate to their assigned role. For example, a laser printer should not be creating connections to an RTU– if it does so, then it is probably not really a laser printer!

Once the security policy has been defined, a set of tools and procedures can be put in place to implement the policy.

A wide range of products is available to address network security for enterprise and IT networks – for example, the series of UAC (Unified Access Control) appliances from Juniper Networks. Other products such as Tofino Security from Byres Security make it simple to adapt existing IT security technologies and practices to the unique requirements of SCADA and control networks.

The Next Generation of Network Access Control

Current solutions work well and can demonstrate measureable improvements in network security. But the competitive and regulatory pressures that got us to this point are not going away. If anything, these pressures will only increase over time. SCADA networks will increase in size from dozens or hundreds of devices today to thousands or even millions of devices, but staffing levels almost certainly will not increase proportionately. New tools and technologies will be required to keep pace with the growth and evolution of these systems. New standards will be required so products from multiple vendors can interoperate seamlessly. And these systems must be flexible so customers can easily configure them to automate their unique security policies and procedures.

Open Standards for Network Security

Trusted Network Connect (TNC) is a work group of the Trusted Computing Group (TCG), an industry standards organization focused on strong security through trusted computing. TNC is completely vendor-neutral; the full set of TNC specifications is freely available for anyone to implement, and TNC-based products have been shipping for over five years.

TNC standards provide a flexible architecture and open interfaces that allow interrogation of an endpoint to determine its integrity and compliance with security policies. When an endpoint requests access to the network, a policy server queries the endpoint, determines user identity and endpoint health, and makes an access control decision based on the resulting information. The policy server sends a policy decision to an enforcement point, telling it whether to permit access, deny access, or quarantine the endpoint. TNC interfaces standardize communication between these components at the network, transport, and application layers.

Figure 2: TNC standards enable integration of best-of-breed networking and security products to ensure dynamic, intelligent access control decisions.
 

IF-MAP – TNC’s Cornerstone of Interoperability

TNC’s IF-MAP (Interface – Metadata Access Point) standard extends the TNC architecture to allow data sharing across a huge variety of security and networking systems. The Metadata Access Point, or MAP, is a central clearinghouse for endpoint metadata; MAP clients can publish, search for, and subscribe to notifications about that metadata. Any networking and security technology can be a MAP client; examples include intrusion prevention system (IPS) platforms, vulnerability scanners, dynamic host configuration protocol (DHCP) servers, physical security systems such as badge access solutions, and even application servers. These components can act as sensors adding data to the MAP and/or act upon information received from other components. 

The open interface to MAP enables customers to implement the ‘appropriate behavior’ requirements of a security policy in ways that would be difficult, if not impossible, using proprietary single-vendor solutions. As an example, one could connect Hirsch access control systems to a MAP server in order to monitor physical security of facilities. What if user ‘Joe’ is connected remotely to the SCADA network via VPN, but then the access control system reports that he just scanned his badge to gain entry to a substation? Clearly, Joe cannot be in two places at the same time. The open, multi-vendor nature of TNC and MAP enables this type of integration today, taking advantage of the best available products from multiple vendors to build customized solutions quickly and inexpensively.

Figure 3: The MAP enables integration of security products from different vendors, allowing them to share information in real-time.
 

Onward into the Future

Now, more than ever, organizations interconnecting control system networks with corporate IT networks need to be aware of potential risks. Planning, processes, and technology are required to adequately reduce exposure, mitigate the risks associated with a hyper-connected environment, and prepare the infrastructure to securely handle change.

The current trend towards higher levels of integration between enterprise and control/SCADA networks will continue to accelerate as operators seek improved productivity and return on investment (ROI). However, this ROI will not be realized without significant improvements in control system security. TNC and MAP provide an open ecosystem of interfaces, tools, and products that enable robust and flexible security architectures to be deployed quickly and cost-effectively. Moreover, integration of specialized security products demonstrate that open standards from TNC enable management of security policy for both the enterprise and control networks from a single set of tools, offering high levels of security in a very cost-effective solution.

About the Author

Scott Howard serves as a representative to the Trusted Network Connect Work Group of the Trusted Computing Group (TCG). TCG is a not-for-profit organization formed to develop, define and promote open, vendor-neutral, industry standards for trusted computing building blocks and software interfaces across multiple platforms. Scott also serves as System Architect at Byres Security Inc. and has over 30 years of experience in embedded system development, technical sales and product support with companies such as Motorola (now Freescale) Semiconductor, Embedded Support Tools and Wind River Systems.

Scott has been with Byres Security since 2007, where he was Product Development Manager during the first two releases of the Tofino Industrial Security Solution until transitioning to his current role in 2008. He is a graduate of the Electrical/Electronics Technology program at Camosun College in Victoria BC. (Scott can be reached for questions or comments via email to scott.howard@tofinosecurity.com.)