The disconnection between senior management in charge of Operations from senior management in charge of security is leading to vendors being tasked to build new technology for reliability, not security purposes. The mantra of “from the plant floor to the Boardroom” is being followed without seriously asking the question of why an executive in the Boardroom would want to control a valve in a plant or open a breaker in a substation. Several years ago, a heat wave caused failures of a large number of electric transformers. In order to address this, the vendor installed temperature sensing and decided that getting information out to the largest possible audience was the best way to proceed. Consequently, the new transformer was built with a Microsoft IIS webserver integrally built into the transformer (Figure 3). Cyber vulnerable technologies such as Bluetooth and wireless modems are being built-in to ICS field devices. As one vendor claims: “They now have a Bluetooth connection for their new distribution recloser. If your line folks and/or engineers would like to sit in the truck on those rainy days checking on the recloser...” This means it is possible to get onto the SCADA network far downstream of the corporate firewall. In many cases, it is not possible to bypass the vulnerable remote access without disabling the ICS devices.
Figure 3 Distribution Transformer with Built-in Webserver
A great concern is the integration of ICS systems with other systems such as Geographical Information Systems (GIS) or customer information systems. The unintended consequences of incompatible software or inappropriate communications have caused significant cyber incidents. This is an insidious problem because the individual systems work as designed, while the vulnerability is the interconnection of individually secure systems. In one case, the rebooting of a control system workstation that was not even on the control system network directly led to the automatic shutdown of a nuclear power plant. In this case, both the workstation and the PLC worked exactly as designed – two rights made a wrong. In another instance, incompatible software turned a fossil power plant into a “yo-yo” causing it to swing from maximum load to minimum load and back, within configured parameters, for three hours causing extreme stress to the turbine rotor.
There are currently very few forensics to detect or prevent these types of events, thus pointing to the need for additional or improved monitoring and logging. This lack of ICS cyber forensics has two aspects. The first is for performing forensics on COTS operating systems (e.g., Windows). The second and more challenging issue is how to perform cyber forensics on an antique 1200 baud modem to determine if a cyber event has occurred. Technologies exist, but will removing a hard drive actually impact the restart and operation of an ICS?
One final concern almost seems trivial but isn’t. In most tabletop exercises, the ultimate fix is to “pull the plug” (isolate the ICS from all others). Unfortunately, in complex ICS implementations, it may not be possible to know if the ICS really has been isolated. Consequently, a very important issue is to determine how an organization can tell if the ICS has been isolated and also if any Trojans have been left that can affect restart.
Why do we care
It is often, but mistakenly, assumed that a cyber security incident is always a premeditated targeted attack. However, NIST defines a Cyber Incident6 as: “An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability (CIA) of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. Incidents may be intentional or unintentional.” Unintentional compromises of CIA are significantly more prevalent and can have severe consequences, but this does not seem to be part of many current discussions of ICS cyber security. The direct cause of many ICS cyber incidents are unintentional human error. This phenomenon must be addressed by cyber security standards if they are to be effective. It is important to note that protecting ICS from these unintentional compromises also protects them from intentional compromise and outside threat.
Contacts throughout industry have shared details and adverse affects of more than 125 confirmed ICS cyber security incidents to date. The incidents are international in scope (North America, South America, Europe, and Asia) and span multiple industrial infrastructures including electric power, water, oil/gas, chemical, manufacturing, and transportation. With respect to the electric power industry, cyber incidents have occurred in transmission, distribution, and generation including fossil, hydro, combustion turbine, and nuclear power plants. Many of the ICS cyber incidents have resulted from the interconnectivity of systems, not from lack of traditional IT security approaches such as complex passwords or effective firewalls. Impacts, whether intentional or unintentional, range from trivial to significant environmental discharges, serious equipment damage, and even deaths.
Figure 4 shows the result of a Bellingham, WA, pipe rupture which an investigation concluded was not caused by an intentional act. Because of the detailed evaluation by NTSB, this is arguably the most documented ICS cyber incident. According to the NTSB Final Report, the SCADA system was the proximate cause of the event. Because of the availability of that information, a detailed post-event analysis was performed which provided a detailed time line, examination of the event, actions taken and actions that SHOULD HAVE been taken7.