Data and Command Encryption for SCADA

Transcription

1 Data and Command Encryption for SCADA Kevin Mackie Smart Infrastructure Oil and Gas Division Schneider Electric Calgary, Canada Abstract This paper discusses the encryption of data and commands in oil and gas pipeline SCADA systems. It presents a typical SCADA architecture and the different functions of each site, the applications within them, and how they communicate between and among themselves. It then considers some of the challenges of protecting information in the context of pipeline SCADA, and the encryption approaches available to overcome some of these challenges. Keywords SCADA; cyber-security; encryption; networks; pipeline I. INTRODUCTION SCADA is a mix of vendor-specific, purpose-built technologies, COTS components, and diverse network types and connectivity requirements. The geographically dispersed nature of pipeline SCADA, and the need for connectivity with so many diverse external systems, opens up many communication paths that are vulnerable to unauthorized access. Figure 1 shows an example pipeline SCADA system divided into different zones. II. SCADA TELECOMMUNICATIONS The critical data and command paths in a SCADA system are within and between SCADA (control room and servers) and the field sites. The operator monitors the state of the pipeline on his or her workstation, viewing current values, data quality, alarms, events, and trends. This information is received from the operational SCADA servers, that in turn poll the information continuously from field computers (i.e. RTUs, PLCs, and flow computers) located along the pipeline. These field computers are located at stations used for pumping or compression, measurement, storage, valve control, or pipeline telemetry. Operator commands to (for example) open and close valves and start and stop pumps and compressors are first relayed to the servers using a protocol specific to the SCADA system, and from the servers to the remote devices via an industrial protocol. Figure 2 shows the typical communication paths that data and commands pass through between SCADA system and field. These communication paths present various challenges for encrypting SCADA data. We consider these challenges in two groups: 1) within the SCADA system i.e. between the client and server, and 2) between SCADA and the field. A. Intra-SCADA communication SCADA workstations and servers have traditionally been on the same physical LAN (or VLAN). There is a trend however to locate the SCADA servers in a data center apart 1 Figure 1 Typical pipeline SCADA architecture

2 Figure 2 - Typical telemetry path from the operational control center, which is in a different location entirely. The control room can sometimes connect to both the primary and secondary SCADA server sites, so that maintenance on servers at one site can be undertaken without displacing operators from their control center. And there may occasionally be satellite connections into the SCADA system, for things such as maintenance laptops in the field that connect to SCADA so technicians can see the same data and displays as the control center operators. Additionally, in a distributed SCADA system, the site that receives the command from the controller may not be the site responsible for polling the relevant devices. In this case, the command must further be replicated to another SCADA server for transmission to the field. This means that between SCADA client and SCADA server, data and commands may have to pass through several intermediate network segments. B. Encryption of data and commands Encryption protects the confidentiality of data; authentication and integrity ensure that data comes from the correct source and hasn t been tampered with. In this article we refer to these cryptographic approaches collectively as encryption. Encryption can occur at different layers but we differentiate application encryption from network encryption. Application encryption occurs within the processes that are exchanging information across a network or WAN, at the extreme endpoints of the communication path. It guarantees that data from a specific application is encrypted regardless of the path taken from source to destination. Network encryption occurs below the application layer, at or beneath the network layer. It guarantees that regardless of the application, data that passes over the encrypted segment is protected. Connections between sites carrying SCADA traffic should be encrypted using a VPN connection such as PPTP, L2TP, or an IPsec tunnel (API, 2004). Defense in depth suggests that application-level encryption (including the substitution of unsecure with secure transport protocols e.g. regular sockets vs. TLS, regular FTP vs. FTPS) should be used, where feasible. It is not recommended that home brew encryption be used. Rather, established frameworks and well-documented strong encryption algorithms should be employed (Department of Energy, 2011). C. Secure Data Access Layer One approach to application encryption between remote sites is to use a Data Access Layer (DAL, see Fig. 3) that employs a secure transport protocol between the SCADA client applications and the network. The function of the DAL is to ensure that regardless of the middleware used (SQL, Remote Procedure Call, etc.), and regardless of the security of the networks between them, critical communications between SCADA client and the SCADA server site remain protected. The DAL uses a Transport Layer Security (TLS) connection and well-proven facilities in the operating system to authenticate users and encrypt information. 2

3 A. Field communication encryption standards AGA Report 12 Part 2 dealt specifically with Retrofit Link Encryption for Asynchronous Serial Communications. It was in effect replaced by the equivalent IEEE P , published in 2011 and indicated for trial use. These standards define the SSPP (Substation Serial Protection Protocol) for authenticating and optionally encrypting both SCADA transmissions and RTU programming and maintenance traffic over existing serial connections (AGA, 2004), (IEEE, 2011). The approach is known as a Bump in the Wire (BITW), where devices are placed at either end of the serial connection to encrypt and decrypt data. The process is transparent to the end devices i.e. the SCADA master and the PLC, RTU, or flow computer, other than delays because of added latency. Latency of SSPP was measured by Pacific Northwest National Laboratories and determined to most adversely affect lowbandwidth connections and timing based protocols like MODBUS vs. length-based protocols such as DNP3 (Department of Energy, 2007). The AGA 12 approach is designed to be used with legacy protocols like MODBUS, Allen-Bradley DF1, etc. Figure 3 - Secure Data Access Layer D. LAN encryption and IPsec Between machines on the same LAN, IPsec may be considered. On IPv4 networks, IPsec is an optional Bump in the Stack, being inserted just above the data-link layer. IPv6 has IPsec built in (i.e. it is mandatory in IPv6), but the adoption of IPv6 will be very slow with so much existing IPv4 infrastructure in place. The requirement for IPv6 in SCADA is likely to come first in polling large numbers of IPv6-based IED devices for utilities. One issue with IPsec is that the redundancy models on SCADA systems may require transparent network failover on clustered servers. In some implementations (Microsoft s IPsec, for example) the reconnection and recovery of SCADA connectivity after failover can be much slower than normal. The adoption of IPsec technology on IPv4 SCADA LANs has to be done with caution. III. SCADA TO FIELD COMMUNICATION A greater challenge in securing critical data and command traffic is between the SCADA master site and the field. Communication between control centers and data centers can be routed through standard TCP/IP networks over secure tunnels on relatively high-bandwidth connections, using secure protocols built for this purpose. From SCADA to field, however, there are a large number of legacy devices over slow serial connections (dial-up, leased line, satellite, radio, etc.) The devices were never designed for security, or for the computational loads that encryption would add. These issues, and the need to secure legacy devices and a specification of the technology to do so, have been documented in AGA Report 12 (Part 2) and IEEE P TABLE I. MOST COMMON OIL&GAS PIPELINE PROTOCOLS Protocol MODBUS (RTU/ASCII/TCP) BSAP Fisher ROC/ROC+ Allen Bradley DF1/CSP CIP Mercury DNP3 IEC-104 (mostly in Europe) OPC ABB Totalflow There are now industrial protocol standards that include security explicitly. The two most relevant for oil and gas SCADA are DNP3 and IEC /104. DNP3 itself is now compatible with IEC , and is documented in IEEE This latest version of the standard includes DNP3 authentication with a challenge-response between SCADA and the remote whenever a critical communication such as a command must be transmitted. DNP3 does not include encryption, so data confidentiality is not protected unless combined with something like retrofit link encryption. 3

4 In the years since AGA 12 Part 2 came out, vendors have produced devices to encrypt data traffic over serial connections. Also, RTUs and flow computers have been built that support AGA-12 encryption and authentication natively within the devices themselves (see Aubin, ENTELEC 2010 for an example of DNP3 combined with AGA-12). Replacing field devices is complicated by the fact that some flow computers have company-specific programming for handling gas measurement and gas quality history and refined product batch queues. There is thus a coupling between the measurement data acquisition component on the SCADA system and the structure of data in the flow computer. To say a device uses MODBUS is incomplete, since the real complexity lies in interpreting the structural measurement data superimposed on MODBUS s flat address space (see the many flavors of MODBUS for use in gas measurement). Adopting a different device with a different protocol would require reimplementing this business logic in both the flow computer and the data acquisition and measurement system, or changing business processes to accept the change. For these cases, legacy link encryption may be the only viable short-term option. As per the PNNL performance report, general benchmarks cannot be relied upon for purchase decisions on cryptographic protection for field devices. Each pipeline operation is different in its mix of devices and telemetry networks, so testing has to be done using the pipeline company s unique blend of technologies in a non-production environment before acquiring cryptographic solutions. Field encryption is likely to occur as a mix of retrofit encryption and end device replacement, occurring over years - one device and link at a time. TABLE II. Standard AGA 12 Part 2 API 1164 FIELD DATA ENCRYPTION STANDARDS Scope Retrofit field encryption SCADA serial connections SCADA security IEEE P Equivalent to AGA-12 2 IEC Security for communications in the electrical grid IEEE DNP3 with authentication, compatible with IEC IEC Sections 101 and 104 protocols for electrical grid, compatible with IEC IV. AUXILIARY SYSTEMS A. Engineering and test systems The Engineering system is where developers and administrators modify system configuration and create and edit operational displays and reports. The test system is where the modified SCADA components and configuration are validated before being put into production. While the engineering and test servers are located on a secure LAN behind the SCADA firewall, the administrative and engineering staff may be physically located at offices far from the SCADA LAN. The display and report source files are sensitive, providing pipeline schematics and mappings between what the operator sees and interacts with in the SCADA interface and the data acquisition and command tags on the SCADA servers. The display files are edited by the user on their workstation (again, possibly on the corporate network) and then distributed to the test system and the production system over the network. B. Leak detection and online simulation In addition to the core SCADA functionality, there are auxiliary systems important to pipeline safety, such as online simulation and leak detection. Leak detection systems receive current data from the SCADA system to update a mathematical model of the pipeline to track product movement and hydraulics and detect and locate leaks. Warnings and alarms are sent from the model back to the SCADA system for annunciation on operator consoles. Unlike SCADA client to server communication, SCADA to model communication is sometimes between systems from different vendors. The leak detection servers are usually on the SCADA server LAN, but may sometimes reside on a decision support site outside of SCADA. Typical interfaces between SCADA and leak detection may include: OPC Text file transfer MODBUS master/slave drivers in the SCADA or leak detection components Direct database access from a decision support server API or direct socket access (where either the SCADA vendor or the leak detection vendor provide a programming library to the other in order to develop the interface) If the SCADA and leak detection software are from the same vendor, there may be a more direct application-level connection between the systems. For securing these connections the principles outlined in the following section can be followed. V. EXTERNAL SYSTEMS One of the most difficult aspects of SCADA security is the need to communicate with disparate IT systems outside of the SCADA zone. The following list shows some of the 4

5 applications to be found on corporate systems that rely on a connection with SCADA: Decision support site - Provide a replica of SCADA information on a database outside of the SCADA zone for reports and queries Alarm Manager analyze SCADA alarm activity and configuration to report on alarm loads and to help determine how alarm loads can be reduced (this will involve the transfer of SCADA alarms and alarm threshold configuration to the alarm manager) Corporate decision support corporate databases requiring SCADA information PI Historian SAP RDBMS MS SQL, Oracle notification and report distribution server to notify users outside of the control room of alarms and pre-alarm conditions, or to scheduled reports Casual and home-user GUI access to provide access to SCADA displays outside of the control room Measurement and accounting to validate measurements from the SCADA system for billing Operational planning and scheduling to schedule operations based on customer nominations, demand loads Nominations interface Weather interface Of the above external systems, two stand out in their influence on daily pipeline operations: measurement system and scheduling system. A. Measurement and accounting The SCADA data acquisition sub-system acquires measurement history and product quality information from flow computers and transfers these to a measurement system on the corporate network. Measurement configuration values needed for flow calculations (AGA parameters, manually entered gas quality, meter factors) may be adjusted on the measurement system and then transferred back to SCADA to be downloaded into flow computers in the field to be used in flow calculations. B. Operational planning, scheduling, nominations Operational planning systems use nominations and other data (for example, weather information for gas load forecasting) from corporate or internet-based services. An operational plan is created and then transferred to the control room to be executed by SCADA controllers. As the operational day progresses, flow volumes are sent back to the planning system to monitor actual vs. planned operations. For gas pipelines, the schedule will indicate quantities to be received and delivered at various points in the pipeline network to meet contracted quantities and demand. For liquids pipelines it will be a batch schedule of the sequence of product batches to be delivered including product, batch size, source, and destination. Batch schedules may be downloaded to flow computers as pending batches, and may drive how SCADA or local users initiate product movement operations. C. Encryption of data outside of SCADA The challenge of encrypting data from the above applications is that they are often a heterogeneous mix of technologies from multiple vendors. As with measurement and planning applications, there can be unprotected information being transferred to SCADA and used by controllers to affect operations. The following types of interface technologies are typically used between SCADA and external systems: 1) Direct database connection. For example, SCADA will connect to the database server or a PI historian on the DMZ or corporate network to replicate historical information to it directly. 2) File transfer. For example, interfaces to SAP or to nominations and scheduling systems may be implemented with text file transfers. Data is written to (say) an XML file and dropped on a commonly accessible file share or FTP site, where it will be picked up by the SCADA system (or the external system, depending on the direction of flow). In the case of liquids lines, the schedule may also result in pending batch queues being updated on the flow computers. 3) Direct network connection. For example, SCADA may send notifications to an or SMS gateway to notify appropriate personnel of alarm or pre-alarm conditions; or SCADA may have to acquire data from an external system via a direct socket connection such as OPC or an electronic data exchange protocol like X.12. The basic encryption strategy is roughly as above i.e. to map the physical and logical connections between sites, machines, and applications and then to adopt a multi-layered approach where feasible: a. Isolate systems with encrypted tunnels between sites; b. Use encrypted transports. For example, SCADA clients connect through a secure data access layer using TLS, FTPS is used instead of plain FTP, SMTPS is used instead of SMTP, secure database connection options are enabled; c. Enable application-level encryption options if possible for example in the case of a text file transfer the file could be encrypted/zipped before being left on the file share and then decrypted on the SCADA side (but this would require modifying parts of the interface). VI. CONCLUSION SCADA is an enabling technology at the core of a pipeline company s business, so there will always be pressure to improve efficiency by connecting it to other systems. It is important to identify the many applications and connections 5

6 within SCADA and between it and other zones, and to ensure that critical data and command paths are protected from eavesdropping and misuse. The use of established and well documented encryption technologies at multiple levels can help protect these critical systems. REFERENCES [1] American Petroleum Institute (2004) API 1164, SCADA Security [2] Mahan, RE and Burnette, JR et al U.S. Department of Energy, Pacific Northwest National Laboratory Secure Data Transfer Guidance for Industrial Control and SCADA Systems, 2011 [3] American Gas Association (2004) AGA Report No. 12 Part 2. Cryptographic Protection of SCADA Communications: Retrofit Link Encryption for Asynchronous Serial Communications [4] Institute of Electrical and Electronics Engineers (2011) IEEE P Trial Use Standard for a Cryptographic Protocol for Cyber Security of Substation Serial Links [5] Aubin, Philip, SCADA Communications Security: Authentication, Encryption, Integration, 2010 (ENTELEC 2010) [6] Hadley, M.D and Huston, K.A. and Edgar, T.W. Department of Energy, Pacific Northwest National Laboratory, AGA 12 Part 2 Performance Test Results, 2007 [7] Institute of Electrical and Electronics Engineers. Dist 1815 WG (2012) IEEE IEEE Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3) 6