Imagine one morning you get that call, the call that every data center manager dreads, a breathless call that informs you that there has been a major equipment failure at your data center. You sprint to your car and make the best possible time to your critical facility. As you approach the site, your heart sinks when you see a thick stream of black smoke rising from the generator yard into the morning sky.
A few minutes later, you are standing next to smoldering wreckage of your standby generators. Your perplexed facility manager informs you that there was no scheduled automatic generator run and no electrical system maintenance going on that evening. He explains that the generator cranked up “out of the blue” and immediately started smoking and shaking violently. Before he could hit the generator EPO switch, arcing currents flashed from inside the alternator, smoke poured from the engine, and the generator died a sudden death.
The BMS and SCADA system event loggers say that there was no interruption of utility power to trigger the generator start. Further adding to the mystery, the generator mode selector switch is still in the auto position, indicating that the generator could not have been started manually. In short, there is no readily discernible reason that the generator started and certainly no apparent explanation for its dramatic failure.
A new high-priority email catches your eye as you reach for your smart phone to call your generator service provider. It reads, “EXTORTION! We control your data center infrastructure. The catastrophic failure of your diesel generator at 05:00 EST was a demonstration of our capability. Deliver $4 million to the account below before 17:00 EST today, or we will shut down your facility. We have altered your switch gear PLC programming. Any breaker operation or control system tampering prior to 17:00 EST will initiate an open-all-breakers command.”
Your heart sinks as you realize that your mission-critical infrastructure has been hacked. You are the latest victim of a cyber warfare weapon known as a supervisory control and data acquisition, or SCADA, worm.
EVOLUTION OF THE THREAT
Until recently, the idea that SCADA systems were vulnerable to a cyber attack was just a theory. System manufacturers and operators relied confidently on system complexity and esoteric communication protocols to provide security from cyber attacks. They reasoned that industrial controls systems (ICS) such as SCADA are simply too different from traditional IT systems to present a valid target for hackers. Differences that seemed to rule out ICSs as valid cyber attack targets include:
-
ICSs utilize components like PLCs and field devices such as breakers and motor controllers that are well outside the experience of typical hackers.
-
ICS components are arranged into sprawling networks of devices and tend toward a degree of complexity that only experienced control engineers understand.
-
ICS communication protocols such as Modbus and BACNet are completely foreign to the typical hacker. For example, a typical data packet in a SCADA system might read: 0a 07 d9 08 3b 92 0b af 00 0b. Without specific experience in ICS, most hackers would fail to recognize this string as a “trip breaker” command.
-
Without detailed knowledge of specific system architecture, even understanding system data would be of little practical use.
- ICSs contain no sensitive financial or personal data that are targets for traditional hackers.
Unfortunately, from a cyber security standpoint, a security strategy that depends on system complexity and unique system architectures amounts to hiding in plain sight. Security engineers refer to this type of flawed strategy with the pejorative term, security through obscurity. Because of the perceived obscurity of ICS system, traditional ICS cyber security measures consist of limiting the number of personnel with supervisory computer or SCADA controller passwords and keeping the SCADA network independent of the Internet.
In recent years, a few professional organizations such as Institute of Electrical and Electronics Engineers (IEEE) and government agencies like The National Institute of Standards and Technology (NIST) have effectively blurred the line between facilities systems and IT systems. These organizations claimed that reliance on obscurity was no longer an effective cyber security strategy for ICSs. They pointed out that legacy ICSs had utilized purpose-built hardware, proprietary communication protocols, and dedicated communication networks. However, modern ICS systems utilize off-the-shelf PCs or servers for their supervisory computer systems, have adopted internet protocol (IP) communications, and often share network infrastructure with other end-user network resources. Technology advances such as these have led to a number of benefits to the ICS industry including;
-
Reduced hardware costs
-
Improved the flexibility and ease of use of ICS systems
-
Allowed manufacturers to develop their software for handy and ubiquitous Window or UNIX operating systems
- Allowed ICS systems to share data and report to other networked corporate resources
Unfortunately, embracing the technology and solutions of IT systems opened the door for control systems to be affected by the malware and cyber attacks faced by IT systems. In 2008 NIST noted in its Guide to Industrial Control System Security, “Widely available, low-cost Internet Protocol (IP) devices are now replacing proprietary solutions, which increases the possibility of cyber security vulnerabilities and incidents.”
The occasional facility manager who engaged IT resources to harden their control systems discovered that it is not an easy task. ICS technology does not easily lend itself to standard information security practices. One of the key stumbling blocks is that field bus communication protocols (such as Modbus) used to communicate between devices were not designed with security in mind. These protocols were developed for serial communications and as a result lack any built in authentication.
This lack of authentication means that Modbus devices will accept communications from any connected source. As a June 2008, IEEE report noted, “Systems relying on the Modbus protocol for distributed control render their facilities vulnerable because of no security consideration in the protocol. An intruder, without being authenticated, may harm the system by issuing malicious commands.”
The perception that ICS systems do not require antivirus (AV) protection further complicates any effort to establish meaningful protection. Fueling this misconception is the fact that ICS systems do not ordinarily connect to the internet. Thus, daily updates required to make AV protection meaningful are impossible. Furthermore, AV must be very carefully implemented in an ICS system as to not consume valuable computing resources and interfere with the system’s proper operation. A study of the use of AV protection by the ICS industry funded and guided by the US Department of Energy (DOE) and the National SCADA Test Bed (NSTB) found the following prevailing conditions as recently as 2003:
-
Widespread fear that antivirus software would cause an ICS to fail
-
Minimal support from ICS vendors on the use of antivirus software with their products
-
Worry that antivirus software would use critical computing capacity required by the ICS to meet performance requirements
- Perception that AV software updates and maintenance would be too much trouble and be time consuming
The NSTB report noted some improvement regarding AV software but confirmed the widespread belief that AV and internet security applications can potentially disrupt the proper operation of an ICS system.
As a result of advances in ICS technology and the difficulty in applying meaningful cyber security, many ICS systems today run on vulnerable computer hardware, are extensively networked, and remain almost completely undefended from cyber attack.
AURORA
In the spring of 2007, DOE engineers at the Idaho National Engineering Lab conducted a dramatic test known as the Aurora Project that demonstrated the validity of its warnings about the growing vulnerability of control systems to cyber attack. In cooperation with white-hat hackers from the Department of Homeland Security (DHS), these engineers set out to destroy a large diesel generator using the internet. Video of this electronic attack was featured in November 2009 episode of CBS’ 60 Minutes. The video centers on a large diesel generator running normally. The cyber attack causes the generator to suddenly start to shudder and jerk. As the cyber attack progresses, the massive 27-ton generator starts bouncing off of its mounting bolts and bits of broken hardware begin to fly around the room. Within seconds of the start of the attack, clouds of black smoke pour from the diesel engine, white smoke billows from the generator end, and the device comes to what is undoubtedly a very final rest.
The Aurora cyber attack vividly demonstrated that a hacker who could gain access to the control system of a generator could cause catastrophic physical damage to it. Unfortunately, generators are not the only potential for damage targets. The hackers had exploited vulnerabilities in the control system of the generator that are common in nearly every modern ICS. Suddenly, the security of any facility that relies on an ICS was questionable. Facilities that are potentially susceptible to an Aurora-type attack include nuclear power stations, electrical grids, chemical mixing plants, petroleum refineries, gas pipeline networks, drinking water treatment facilities, and data centers.
The U.S. Congress and the DHS immediately saw the national security implications of Aurora. Many of the vulnerable facilities are clearly vital parts of the national infrastructure. Their vulnerability to cyber attack represents a profound risk to national security and human life. In a speech regarding cyber warfare on critical infrastructure, President Barack Obama stated, "It is now clear this cyber threat is one [of] the most serious economic and national security challenges we face as a nation." Fortunately, the U.S. government is funding programs and developing protocols to prevent cyber attacks from damage our vital national infrastructure.
STUXNET
In spring of 2010, the cyber threat to ICS became even more pronounced. VirusBlokAda, a computer security firm based in Belarus, discovered a cyber weapon designed to exploit the vulnerabilities of mission-critical control systems. Cunningly hidden in the operating code of an ICS owned by an Iranian client, they found an incredibly sophisticated bit of malware called Stuxnet. Analysis of Stuxnet by security software giant Symantec revealed it to be a shockingly advanced and profoundly dangerous example of a variety of malware known as a computer worm. Computer worms are similar to viruses except that worms have the ability to move from computer to computer (self-replicate) without requiring an action by a human being. Some worms, like Stuxnet, even have the ability to infect computer systems that have no connection to the internet. Symantec’s comprehensive dossier on Stuxnet describes the worm as, “one of the most complex threats we have analyzed.”
Stuxnet’s complexity and degree of sophistication alone are enough to set it apart from the vast majority of computer malware. However, it is the engineered target of Stuxnet that makes it truly unique. Unlike all other previously discovered malware, Stuxnet is the first discovered that was designed to locate and attack a SCADA system. The worm utilized self-propagation techniques to move from computer to computer until an unsuspecting employee or contractor eventually carried it into its target facility on a USB flash drive or laptop computer. Once Stuxnet infects a suitable system, it conceals itself within the system and installs a “backdoor” that allows unauthorized personnel to access and remotely control the infected system. This access also allows intruders to download vital system schematics and operating parameters from the infected SCADA system. In addition, Stuxnet has the unprecedented ability to covertly rewrite the PLC code that governs certain automated features of the ICS. All of the code needed to accomplish this rewrite is carried within Stuxnet and it requires no external communications in order to achieve this objective. These abilities grant the Stuxnet worm the power to hijack control of an ICS and potentially cause irreparable damage in mission critical facilities.
To date, no one has claimed official responsibility for creating Stuxnet. However, their probable intended target has been narrowed down to a SCADA system at the highly secure Natanz nuclear power facility in Iran. A number of facts point to this facility. First, as computers infected by Stuxnet were identified, the distribution of infected systems compiled in the Symantec dossier indicated that the target facility was in Iran. Second, the sophistication of Stuxnet indicated that the malware was the work of a well-funded nation-state and that the intended target was of significant strategic value. Finally, as Stuxnet was decrypted it became clear that the target device was a high-speed centrifuge controller. SCADA systems at Natanz are used to control the operation of uranium refinement centrifuges. By infecting the supervisory control computer and system PLCs at Natanz, Stuxnet could periodically alter the rotational speed of these centrifuges and compromise the purity of the uranium. The Natanz theory is supported by statistics released by the Federation of American Scientists (FAS) that show the number of operating centrifuges at Natanz mysteriously declined from 4,756 to 3,936 around the time Symantec estimates Stuxnet was deployed.
From a physical security standpoint, a nuclear facility in Iran is an extremely ambitious target for a cyber attack. It is doubtful that many U.S. civilian facilities will have similar security protocols. Yet, the Stuxnet was apparently able to penetrate the facility and achieve its objective. Stuxnet was engineered to attack a specific device within a very specific SCADA system at a specific location. However, there was nothing uniquely vulnerable about that system. The hardware and software attack vectors utilized by Stuxnet are common to all major control system manufacturers. Nearly all manufacturers offer equipment that feature USB communications ports and utilize field PCs for PLC programming and maintenance, and all operate on Windows or Unix systems. Because of these common attributes, Stuxnet could have been developed to attack devices by virtually any manufacturer and any type of ICS. In other words, a Stuxnet type weapon could be developed to deliver a variety of payloads into a variety of SCADA systems.
CURRENT THREAT STATUS
Now that SCADA worm has been deployed, it is increasingly likely that the underlying technology will find its way into the hands of international criminal organizations. In November 2010, UK-based Sky News reported, “A super virus that was used to disrupt Iran's nuclear programme has been traded on the black market and could be used by terrorists.” Sky News went on to report, “the Stuxnet worm-the first to have been used to damage targets in the real world-could be used to attack any physical target which relies on computers.”
Unlike the nation-states that likely implemented Stuxnet, criminal organizations will look for unprotected control systems in well-funded facilities such as data centers. These criminals could tailor the worm to reprogram SCADA system PLCs to cause Aurora-type physical damage or trigger a clear-house signal in SCADA controlled switch gear.
Ralph Langner of Langner Communications has this warning, “The next cyber weapon will be considerably cheaper, since much of the attack vector and the specifics of how to use automation equipment will simply be copied. Sabotage with the motivation of extortion will get a commonplace scenario. At this time targets are no longer limited to critical infrastructure but will especially cover the private sector-a TARGET-RICH AREA (author’s emphasis) where it cannot be assumed that organizations will install countermeasures, large scale in a reasonable amount of time.”
It is imperative that mission-critical facility managers recognize that the gap between facilities systems and IT systems is rapidly closing. Facilities personnel can no longer safely ignore computer security issues that previously affected only IT resources. Cyber weapons and tactics that specifically target physical infrastructure control systems have already been developed and deployed. The proliferation of these weapons will continue to escalate and yesterday’s strategies for securing infrastructure control systems are no longer effective.
The event takes place March 25th at 2:00 pm ET.
