A risk assessment, combined with a vulnerability assessment and threat scenario analysis, specifically identifies cyber vulnerabilities that may require elimination from a pipeline system. Elimination of vulnerabilities isn't always possible, however, especially with little control over the operating system and networking software used as the basis of supervisory control and data acquisition systems.
Relying on the various vendors to identify vulnerabilities and supply patches eliminating them is a never-ending process. The only solution is to place independent barriers and protections (technical countermeasures) around a SCADA system to try to keep its communication paths secure.
The first article in this series (OGJ, Sept. 28, 2009, p. 62) described a risk assessment for cyber attack before detailing a number of potential attack avenues. This concluding part will detail the application of a particular approach to vulnerability assessment.1
DNSAM
One often referenced commercial assessment methodology is DuPont Corp.'s proprietary DNSAM methodology (DuPont Network Security Assessment Methodology), deployed successfully in almost all of the company's industrial facilities worldwide. The methodology is designed to be simple and to operate independently of any particular type of automation system.
DNSAM's basic concept works on the justified assumption that a cyber attack requires a communications path between an attacker and the critical cyber assets, and only a few types of communication paths really merit worry. DNSAM breaks the critical systems into LAN segments before identifying the connections between various segments, the cyber assets present on each segment, and the communication interfaces into each of those segments. DNSAM then presumes the worst-case scenario (total loss) for all of the assets on each local segment and determines the consequences.
If a local segment has a dangerous communications interface (dial-in telephone, wireless, or Internet), DNSAM assumes an attack against the assets on that segment is highly likely. If a local segment is isolated (no interconnections or only via a protective firewall), DNSAM classifies an attack against assets on that segment as unlikely.
In between those extremes lie segments with external WAN connectivity (attacks being likely) and connectivity with internal LAN/WAN networks (attacks being somewhat likely).
Evaluating interfaces into a given network segment requires remembering the possibility of alternate communication interfaces. Fig. 1 provides a representative example of determining network segmentation. Segments end at a filtering device (a firewall or other device with user-definable access control list rules). A simple Layer 2 switch doesn't terminate a segment.
Network Segment 1 has three communication connections in Fig. 1: one for dial-in telephone access via a router, the other two internal network connections. Network Segment 2 has two communication connections: an internet connection and an internal network connection.
Network Segment 3 has two parts (connected through a Layer 2 switch) and four communication connections: two internal network connections, a connection to an internal WAN, and a wireless Ethernet (WiFi) access point. Network Segment 4 has only one communication connection: an internal network connection.
A pure DNSAM approach would rank the cyber assets on network Segments 1 and 2 as highly likely to be attacked, the cyber assets on network Segment 3 as only likely to be attacked, and those on network Segment 4 as unlikely to be attacked.
DNSAM assumes physical and operational security is being addressed separately and doesn't specifically address the evil-insider threat agent. It therefore doesn't consider the manual delivery of malware, which is either forbidden by policies (operational security) or blocked by disabling those drives, ports, and interfaces as part of baseline configuration-setting procedures (operational security).
DNSAM also ignores non TCP/IP communication interfaces, such as serial communication channels used for RTU polling. DNSAM, finally, considers only firewalls as a suitable countermeasure. Its focus on communication interfaces creates this approach, but other countermeasures could also be employed.
Variation
A variation of the DNSAM approach is probably an acceptable methodology for conducting a pipeline SCADA system risk assessment. Considering only IP-based communication interfaces fails to address the situation adequately, nor can operational security be ignored as a necessary component of overall cyber security. Addressing intolerable vulnerabilities—those enabling an attack resulting in unacceptable consequences—also requires examining the full spectrum of available countermeasures.
Hacker conferences have hosted numerous papers and presentations on industrial automation systems and the communication protocols used in them. An attacker could attack field sites by accessing the serial communications to those sites and simulating control command messages. Several suppliers offer protocol test sets simulating almost any SCADA/RTU protocol and generating a full range of RTU commands.
A pure DNSAM assessment approach usually ignores communication channels not supporting routable protocols (such as the TCP/IP suite), allowing intermediate computers to receive messages addressed to other computers and attempt to pass them along to the actual addressee.
Typical SCADA serial protocols for RTU polling and supervisory control are not routing protocols, and there is no way for an attacker to hack into a computer and access the operating system, plant malware, and alter software by sending messages back along a polling channel.
RTU serial protocols have a fixed set of predefined commands and message types and well-defined responses to each. Any variation from that well-defined structure will cause a message or response to be rejected.
But it would be possible for an attacker to send false data back to the SCADA system by sending forged poll-response messages, causing the SCADA system see what the attacker wants it to see (open valves looking closed, running pumps appearing to be stopped, pressure and flow measurements apparently stable, etc.).
An attacker with access to RTU polling channels can also send supervisory control messages out to the RTUs and cause them to start-stop and open-close field devices or issue any other supported supervisory command (such as changing set points, alarm limits, tuning constants, etc.). The degree of possible damage this could generate depends on the intelligence level of the RTU (how much local, semi-autonomous regulatory control and sequence-safety logic it performs), the types of equipment it directly operates (valves, pumps, motors, etc.), and the presence (or lack) of hard-wired safety logic capable of overriding the RTU's controls.
Installation and commissioning of a SCADA system or a new RTU often uses protocol test sets when one or the other is unavailable and something is needed to simulate the missing component, making it quite within the capabilities of a commercially available test set to simulate field conditions or act in the role of the SCADA system.
Vulnerability assessment
One typical approach used in a vulnerability assessment examines various scenarios in which an asset could be attacked, identifies the real consequences of a successful attack, and then reviews the difficulty involved in staging such an attack. A table of scenarios can document this process (Table 1).
It is important to state accurately the consequences of having a cyber asset compromised, altered, deleted, or disabled. A cyber attack can disable computers and overload communication networks. A cyber attack can delete or alter data or insert malware, providing an attacker with remote access to critical systems. But completely reformatting hard drives and reloading the affected computers (and other infected network components) from "clean" backup media, usually puts things back as they were before the attack.
This takes time (once it is actually realized an attack is in progress) and requires thoroughly tested, well-documented, and well-rehearsed procedures for performing a system restoration. SCADA systems used for supervising critical processes (such as pipeline transportation) almost always have full (or as near as is possible) redundancy. For very critical pipelines there might even be a backup operating site with another complete SCADA system sitting ready.
An assessment of attack consequences must remember these factors, although a serious attacker would probably be aware of them and take them into account. In an assessment of attack-scenario success likelihood, the more things needing happen in parallel or sequence for success, the lower the likelihood. If an attack-scenario, therefore, only results in dire consequences if the attacker can take out the primary and redundant backup SCADA system at both the main and alternate operating sites, the success likelihood is low.
Redundancy usually requires sharing a common LAN and updating communication processes between the redundant equipment and the primary and backup sites. Failure to protect these communication links adequately offers a path for an attacker to get to the full range of system components. Redundancy alone will not protect against a cyber attack.
Rating the likelihood of each of the attack scenarios is usually a qualitative process. Probability of an attack is highly likely, likely (probable), somewhat likely (possible), or unlikely, strictly based on the available communications interfaces giving an attacker access to your cyber assets (remembering DNSAM omits manual delivery of malware and non-routing communication interfaces).
Effects of a cyber attack on a pipeline SCADA system may include:
• Loss of critical data, programs.
• Alteration of critical data.
• Partial loss of operational visibility.
• Full loss of operational visibility.
• Partial loss of supervisory control.
• Full loss of supervisory control.
• Partial usurpation of supervisory control.
• Full usurpation of supervisory control.
More important, however, is the effect of these events on the pipeline and associated facilities. Altering or deleting critical applications or data could degrade the operational capabilities of a SCADA system, resulting in a loss of scheduling, batch tracking ability, pressure models, leak detection, etc.
Such an attack would imply thorough knowledge of the inner workings of the SCADA system. Brute force deletion of all system files and programs, on the other hand, would require little knowledge and could shut down the SCADA system.
Disabling selected functions, such as alarm management or RTU polling, could blind the operators to a dangerous situation for a moderate period of time. Totally depriving operators of communications with the field equipment or an attacker issuing supervisory commands to field devices represents the worse-case scenario. An attacker might be able to open or close valves, start or stop pumps-compressors, or change operational set points and actually cause physical damage to a pipeline, resulting in a release, pressure drop, product loss, environmental, contamination, explosions, fire, death, injury, or other serious consequences.
The temporary shutdown of a pipeline is conceivable. But if an attack is purely a cyber one against the pipeline's SCADA system, it will be possible eventually to restore the system to proper operation. Operators must consider how long the restoration process will take and how bad things can get along the pipeline, and associated facilities, in the meantime.
Attack
A cyber attack on a pipeline's SCADA system is probably not intended to harm the SCADA system but rather use the SCADA system to trigger actions harmful to the pipeline and associated facilities. Taking control of field equipment, moreover, can be done without breaking into and usurping control of a SCADA system, by instead getting access to the communications circuits linking the SCADA system to the field-based RTUs and control systems.
Unencrypted radio, analog telephone, and TCP/IP communication channels are attack points capable of being used to take control of field devices or remote automation systems. Customary engineering practice builds a reasonable number of safeguards into pipeline design and automation. Pipeline designers recognize the possibility of a rupture, installing automatic pressure (loss) activated valves at river crossings and equipping booster stations with overpressure shutdown logic.
SCADA systems are also generally fault-tolerant (redundant), and major pipelines may even have a physically separated, alternate-site SCADA system, intended to assume control if the primary SCADA system were disabled. A major pipeline might have field-based personnel who can take local manual control of booster stations and storage terminals, as long as voice communications are available.
A risk assessment also requires assembling previously developed scenarios and ranking them by a combination of their consequence rating and likelihood rating. Table 2 shows how this could be organized; scenarios with severe consequences and a high likelihood of occurring would be the top priority for implementing countermeasures.
Assigning priorities to each matrix element is, to a degree, a business decision and related to the risk tolerance of particular organizations.
A self-insured organization may elect to accept the risk posed by third- and fourth-priority scenarios, rather than investing in countermeasures. An organization with insurance underwriters, however, may be penalized in the form of higher rates if it chooses to ignore lower-ranked scenarios. The US Transportation Safety Administration has also mandated implementation of safety measures to protect critical cyber assets.
Any reasonably likely scenario producing severe consequences would clearly demand action to reduce or eliminate the possible outcome. The business decision comes at the moderate and low severity ratings and low likelihood rankings. A risk-averse organization would probably address risks with moderate, and maybe even low, consequences.
Reference
1. Shaw, T., "Energy Infrastructure Cyber Security: Pipelines—A Step-by-Step Guide for Keeping Pipeline Infrastructure Safe From All Cyber Attacks," Oil & Gas Journal Research Center, 2009.
More Oil & Gas Journal Current Issue Articles
More Oil & Gas Journal Archives Issue Articles
