Monday, December 27, 2010

Stuxnet Updates

I hope everyone had a good holiday. I did take a short break from writing about chemical security issues, but not from reading about them. Over the extended weekend I came across two new Stuxnet reports. The first was an update of a previous Stuxnet report, “Stuxnet Under the Microscope, v.1.3”; the second is an analysis of the effectiveness of Stuxnet in attacking centrifuges in Iran, “Did Stuxnet Take Out 1,000 Centrifuges at the Natanz Enrichment Plant?

I was pointed at the second report by a Christmas day blog by Ralph Langner which was appropriate since Ralph was one of the early proponents of Stuxnet being a specific attack on Iranian nuclear facilities. Ralph’s blog specifically points us at the concluding paragraph from that report. The last couple of sentences from that paragraph, reproduced below, provide an important segue to Ralph’s second blog of the holiday weekend.

“It is important for governments to approach the question of whether using a tool like Stuxnet could open the door to future national security risks or adversely and unintentionally affect U.S. allies. Countries hostile to the United States may feel justified in launching their own attacks against U.S. facilities, perhaps even using a modified Stuxnet code. Such an attack could shut down large portions of national power grids or other critical infrastructure using malware designed to target critical components inside a major system, causing a national emergency.”
Ralph and a number of other commentors have noted that the effectiveness of Stuxnet against a specific target is due in large part to knowledge about the specific equipment and programming protocols found at that target location. This requires, in addition to programming skills, some fundamental intelligence information and a detailed understanding of the process being attacked. Many have argued that the requirement for this level of information means that most process owners are, practically speaking, immune to such attack.

Ralph’s “Dirty Digital Bombs”

Ralph has come up with a descriptive new term for a concept that I have previously discussed here; the ‘Dirty Digital Bomb’. As I have noted before, random changes in PLC coding will be disruptive to modern manufacturing, including chemical manufacturing, processes. While they are unlikely to cause catastrophic failures, they are very likely to upset schedules or adversely impact product quality.

While I have looked at this type of attack as a method for industrial extortion, Ralph has taken a larger industrial view. He notes that: “The dirty digital bomb is a cyber weapon that inflicts low to medium damage to a large number of random targets.” He then goes on to explain that “small damage in many power plants may be worse than big damage in one specific power plant”. It would seem to me to be particularly true in a situation where there is a carefully crafted, interconnected power grid. A number of nearly simultaneous small failures could have a catastrophic effect on the grid as a whole.

He also points out that many modern industries are interconnected in a similar manner. Specifically he points at the German automotive industry with their interconnected web of suppliers. Again he points out that “small damage at many automotive suppliers may be worse than big damage at one specific car maker”.

I would further suggest that attacks of this sort, executed in fragile economic situations like we are currently undergoing, would have a further cumulative effect. The additional economic strain of having to recover from this type of attack could be catastrophic. Even in good times, having an entire industrial sector shut down for the weeks or months necessary to cleanse their control systems at the PLC level would have a cascading effect on the economy.

Chemical System ‘Dirty Digital Bombs’

To understand how easy it would be to adversely affect a wide variety of chemical processes with a single chem-stuxnet weapon all one has to do is to consider the ubiquitous valve in the chemical industry. Valves are used to control the flow of liquids, solids, and gasses and there are only a limited number of different PLCs that are used to control these devices. The timing of the opening and closing of valves is critical to the quality of chemical product manufacturing and, in many cases, the safe operation of chemical process facilities.

If the programming for one of the valve-control PLCs were changed by a chem-stuxnet worm to add even a 30 second delay in the execution of a ‘close’ command for that PLC there would be a wide variety of potential consequences ranging from improper raw material ratios (product quality impact), to overfilled containers (chemical spills), application of too much heat (or cooling, or vacuum or pressure) leading to a difficult to control process which could lead, in turn, to any number of quality and/or safety issues.

None of these would necessarily have dangerous consequences (though there certainly could be catastrophic consequences in some applications), but even the most benign result, an off-spec batch, can have significant economic consequences particularly if identifying the root-cause of the problem is complicated by the man-in-the-middle attack methodology used in Stuxnet.

Since the same type controller may be used in dozens, or hundreds of locations within a single facility, it would be inevitable that this single programming change would result in a complete stoppage of production at the facility while the problem was diagnosed. Once the problem was identified as being a programming issue, the process of completely removing the worm from the control system could entail weeks or months of work. If the worm was spread through a significant number of facilities, the shortage of trained experts to effect the removal and system restoration would cause additional delays in bringing all of the facilities back on line. Furthermore, once a multi-facility attack was identified, all facilities using the same controller would be taken off-line to ensure that they had not also been infected.

Such an attack would not require any specific process knowledge or any other kind of facility specific intelligence collection. All it would take is the knowledge of what type of PLC’s are used in valve control situations and an understanding of the programming of that particular PLC. All of that information is readily available.

Furthermore, valves are just one of a number of possible attack vectors that are found throughout a variety of chemical processes. Modules for the control of key process variables of weight, flow, temperature, and pressure could be similarly affected.

Cyber Security

To date the bulk of interest in the political community with cyber security has been focused on the information control side of things. This is because most people are at least partially affected by information systems in their everyday lives. It is easy to understand why it is necessary to protect personal, commercial or governmental information; we see the consequences of the failure to protect that information frequently in the news.

With the advent of the Stuxnet worms and its inevitable future variants and cousins, it is becoming increasingly clear that the protection of industrial control systems will be even more important to our industrial and economic safety. A systemic attack on the chemical process industry would have far reaching economic impacts on all other industries and our country as a whole.

When Congress returns in January, they are going to need to expand their interest legislating minimum standards for industrial control system security measures. To be effective those measures are going to have to span the entire gamut of the industrial control system community, from software and hardware vendors, to manufacturers that use such systems, and to the enforcement organizations that are going to become responsible for tracking down the perpetrators of attacks on these systems.

Effective legislation and regulatory action takes time to craft. The sooner that work is started the sooner our vulnerability to these types of attacks will become manageable.

1 comment:

bizconnmedia said...

This new type of virus has a boot file built-in and now that the code is in the hands of any malware writer it could mutate very quickly

/* Use this with templates/template-twocol.html */