It was a Trojan program inserted into SCADA system software that caused a massive natural gas explosion along the Trans-Siberian pipeline in 1982. A newspaper reported the resulting fireball yielded “the most monumental non-nuclear explosion and fire ever seen from space.”
Malicious hackers have discovered supervisory control and data acquisition (SCADA) and distributed control systems (DCS) since reports of successful attacks began to emerge after 2001. A former hacker interviewed by PBS Frontline advised that “Penetrating a SCADA system that is running a Microsoft operating system takes less than two minutes.”
DCS, SCADA, programmable logic controllers (PLCs) and other legacy control systems have been used for decades in power plants and grids, oil and gas refineries, air traffic control, railroad management, pipeline pumping stations, pharmaceutical plants, chemical plants, automated food and beverage lines, industrial processes, automotive assembly lines, and water treatment plants.
There are a wide range of security technologies that can be used to protect the corporate network, but these are less successful within a production network. Software-based solutions (personal firewalls, anti-virus software) cannot run on some proprietary operating systems, due to lack of compatibility, and often can’t be integrated into systems which use older processor technology – because these lack the necessary performance.
A table nearby illustrates a chronological history of publicly reported hacking incidents that provide a chilling insight into the problems and their potential for disruption and disaster. Some of these damaging exploits were kept secret for years.
The threat comes in many forms. It does not need to be an intelligently directed attack. The non-intelligent Slammer worm, which covered the globe in 30 minutes, infected business and Pentagon computers in the first eight minutes and caused $3 billion in damage to Wall Street.
Oil and Gas Distribution
The 3-kiloton Trans-Siberian natural gas pipeline explosion mentioned in the opening paragraph occurred during the Reagan administration. The event was initially acknowledged by a Russian general, and then subsequently denied by the Russian press, and kept secret within the CIA until 2004, when details were released upon publication of the Cold War memoirs of a retired insider. The events and methodology were explained and later presented in security testimony before the U.S. House of Representatives. The story was reviewed by the Washington Post. Details are available for research in the full copy of the White Paper on which this article is based.
Beyond the dangers of deliberate, destructive sabotage, are the financial and economic business risks. These need not involve terrorist attacks or the intervention of foreign powers.
Pipeline data is collected continuously from custody transfer meters and consortium pumping stations along hundreds and thousands of miles of distribution pipeline. There are millions of dollars involved in the simple reporting of quality data as recorded electronically from the gathering field and delivery point. And there are millions of dollars potentially disputed by the receiving refinery when they report that the delivery contained four-tenths of a percent of water rather than the two-tenths percent water content for which they were being billed.
The discrepancy could occur at either end, whether upon supply or receipt. Volume could be over or under-reported by error, or by fiddling with temperature compensation. Because pipelines are shared and products blended from multiple sources and then delivered to multiple clients, the exact quality is a software-based engineering calculation. The lab test results are also reported via software. All software can be manipulated, and data tampering is easier when the data for the ledger books is all based on software, as was the case with, for example, Enron.
Now imagine the worst case (non-destructive) scenario. What if the pipeline data stream is simply interrupted? This could occur from a random virus, accidentally inserted via a thumb drive, electronic picture frame, the laptop of a visiting consultant or a subcontractor’s website linked to the company website. Or it could be a Trojan program deliberately inserted by a competitor, disgruntled employee, state supported terrorist or foreign power.
In the latter examples the breach would be virtually untraceable. What now is the financial damage? The answer is millions of dollars an hour. What is the economic damage of widespread or recurrent interruptions? Loss of investor confidence and stock losses would be measured in the billions of dollars. Add to that the very human cost of jobs lost as a result of the time-honored practice of assigning blame – down the ladder of responsibility.
Refineries and petrochemical plants have become increasingly reliant on SCADA systems, DCS and PLCs. And, as elsewhere, Windows –based software and Ethernet predominate in the front office, and are migrating into production areas. SCADA systems were typically not designed for security. These older legacy systems remain highly vulnerable to intelligent remote attacks, as well as non-intelligent viruses, because these systems are no longer isolated from the Internet. They are accessible via company websites, wireless access points, USB drives, modems, radio transmission, satellite, microwave, wiretap and remote maintenance access.
While mechanical safety switches are designed to provide fail-safe protection, independent of the control electronics, the opportunity and occurrences of uncontrolled process accidents remains common. Therefore, inadvertent software glitches and deliberate software tampering are possible.
A common example demonstrated by security Red Teams is altering or masking the information being viewed by process operators and engineers. Electro-mechanical safeties can be overwhelmed by unregulated feeds of combustible products to sources of combustion. If the process information being monitored is erroneous, there is no real way to know what is going on, or what action to take.
Harmful programs, capable of paralyzing automation systems, have many sources. External service technicians, contractors, employees and visiting consultants with laptops can inadvertently (or deliberately) introduce malicious software behind the external firewall. Surveys reveal that roughly 40 percent of security incidents involved insiders.
Establishing production network security bears a close relationship to the logic of adhering to fire codes.
The ideal solution would provide several unique features. It would provide distributed “defense-in-depth” as a second or third layer of protection. These offer greater security, flexibility and lower cost. It would be capable of providing various levels of security. It would be easy to implement, by technicians rather than network administrators, without modification to the network’s configuration.
Templates for devices should be configurable for single units or very large groups from a central location. They should be available in various formats, provide hardware and software based security, and be applicable to various network configurations.
The solution should monitor incoming and outgoing data packets, offering secure communication via Virtual Private Network (VPN) tunnels. Ideally, the solution and firewall should be invisible to intruders attempting to map the network. Network Address Translation (NAT) should be used to provide protection by IP address masquerading.
For remote maintenance and diagnostics, the ideal solution would be one that denies access, even by the original manufacturer of the production equipment. This denial was continue except when the equipment operations people request it be removed and when the connection is strictly authenticated via digital certificates of authority.
Specific industrial-based solutions are already available. They may be lesser known in the IT world because they exist in the industrial space, and they may be lesser known in the security world, where there is a tendency to concentrate on physical security and physical access.
The products include Phoenix Contact FL mGuard™, Byers Tofino, Siemens Scalance, Weidmuller IE, Hirschmann Eagle mGuard™, and Innominate mGuard™. It was Innominate Security Technologies AG, the developer of mGuard, that won the Frost & Sullivan “2008 Global Ethernet Security Product Value Leadership of the Year Award,” for their mGuard product family. Some of the products listed above are derived from the Innominate product set or licensed and rebranded OEM products based on earlier Innominate software releases.
Now that inexpensive solutions are available, the security of industrial networks can no longer be ignored. With threats to industrial networks increasing in complexity and scope, decision makers need to take action before it is too late.
A comprehensive and unedited copy of the 18-page White Paper from which this article was extracted, including footnotes, clickable Internet links and detailed research references can be downloaded at www.innominate.com.
About the Author
Frank Dickman has a bachelor of science degree in mechanical and aerospace engineering (BSMAE) and is a registered communications distribution designer (RCDD). He has served as a technical consultant to data communications firms and is a recognized expert on U.S. and international physical infrastructure network standards. Beyond telecommunications, he cites experience in consulting engineering work for petroleum refineries, chemical plants, conventional and nuclear power plants, auto manufacturers and the aerospace industry. firstname.lastname@example.org.