Stuxnet reveals vulnerabilities in industrial controls

Updated guidelines may help

Ongoing analysis of the Stuxnet worm, which has breached thousands of industrial control systems around the world, reveals a complex, professional and dangerous piece of malware that appears to cross the line from cyberspace to the physical world.

“Stuxnet has been called a cyberweapon,” said Jimmy Sorrells, senior vice president of Integrity Global Security. “The intent was to cause physical damage and maybe to kill people.”

Research by Symantec Security Response indicates the malware is the product of a well-funded team of professionals that probably gained access to proprietary data about the Siemens control systems the worm targets and spent months developing and testing the software.

“This is the first threat we have seen that specifically targets industrial control systems,” Symantec researcher Liam O’Murchu told reporters Friday. “It is able to change how industrial control systems work,” possibly creating a threat to physical infrastructure such as power plants, pipelines or electric distribution systems.

Although much is being learned about the malware, many of the most important questions remain unanswered: Who wrote it, what is its target and what is it intended to do? It appears intended to reprogram programmable logic controllers that control physical processes, but researchers do not know enough about the PLCs to understand the intent.

“We can’t tell what it does until we know what is connected to it,” O’Murchu said, and that will take more research.

One thing that is immediately clear is that Stuxnet is a reminder of the importance of securing industrial control systems, said Ron Ross, senior computer scientist at the National Institute of Standards and Technology. NIST already is working on a number of new and updated documents with guidelines for securing these systems.

Related coverage:

Agreement reached on security controls for IT systems

“We are working on this very hard to make sure our catalog has the set of security controls we need to protect these systems,” Ross said.

Special Publication 800-82, “Guide to Industrial Control Systems (ICS) Security,” now is undergoing final review and is expected to be released in the next month, Ross said.

Industrial control systems originally had little resemblance to or connections with traditional IT systems, the draft publication says. But that is changing as standardized technology and IP networking become more common, enabling remote access and connections with business systems.

“This integration supports new IT capabilities, but it provides significantly less isolation for ICS from the outside world than predecessor systems, creating a greater need to secure these systems,” the publication says. “While security solutions have been designed to deal with these security issues in typical IT systems, special precautions must be taken when introducing these same solutions to ICS environments. In some cases, new security solutions are needed that are tailored to the ICS environment.”

SP 800-82 grew out of work on an earlier publication, SP 800-53, “Recommended Security Controls for Federal Information Systems,” originally published in 2005.

“It was only a year later that we started to delve into industrial security controls,” Ross said, and an appendix was added in 2006 on ICS security. Although the last major revision of SP 800-53 was released in August 2009, NIST is planning another major update next year. “We have to stay on the cutting edge,” Ross said.

A third publication, SP 800-39, which is expected to be published in four to six weeks, will provide a strategic, enterprise-wide approach to risk management. “This is important for ICS because the new framework looks at control as well as business side systems,” Ross said.

Stuxnet appears to be purpose-built malware that targets Siemens systems using specific models of programmable logic controllers. Although discovered only in July, it has been around for at least a year, spreading slowly and quietly and using sophisticated tools to avoid detection. Symantec’s researchers estimated it would have taken a team of five to 10 developers six months to create the software and additional time to test it. They would not only have needed access to Siemens software, but probably also would need a hardware testbed. Driver files in the malware were digitally signed to avoid suspicion, and legitimate digital certificates from two companies were compromised for this. Both certificates have since been revoked.

Although initial infection probably was through removable media such as a USB drive, Stuxnet can spread through internal systems and communicate with a command and control server to receive updates. Most copies of the worm that actually reside in a control system probably would not have direct Internet access, however, and updates would likely come via other copies that had infected systems on the business side of an enterprise.

As of Sept. 29, Symantec had identified about 100,000 infected hosts by monitoring command and control communications, more than 60 percent of the infections in Iran. Because of this concentration, researchers speculate that Iranian systems were the worm's intended target. They also believe that its subsequent spread to more than 25 countries probably was “collateral damage,” and was not intended by the authors.

“We find that spread a little bit puzzling,” O’Murchu said. The code seems to be constructed to limit its spread. When on a USB drive it removes itself after infecting just three computers, and it appears to replicate itself for internal distribution for only 21 days, all of which seems to indicate that it was not meant to spread far from its original point of infection.

There are no confirmed cases yet in which a PLC was actually reprogrammed, O’Murchu said, but because getting that confirmation would require the owners of infected equipment to make it public, that's not surprising. We probably won’t get actual confirmation that PLCs have been reprogrammed," he said.

As to the authors of the code, “we really are not getting any closer to discovering who wrote it,” O’Murchu said. They apparently were careful to cover their tracks and leave few clues about their identity and their intent. “They would need to have a lot of money behind this.”

Some investigators theorize that the worm might contain hints that Israeli forces trying to head off Iranian aggression are its creators, but the clues are oblique. One possible clue: A file in the worm's code is named "Myrtus," which could be a reference to the Old Testament book Esther (Esther's birth name in that story is Hadassah, which means "Myrtle"), which concerns Jewish resistance to a Persian plot -- or it could simply be a word a programmer chose for some other reason.

Symantec researchers also found several internal clues in the code that appear to be references to ancient and modern Hebrew history with reference to Persia and Iran, but cautioned against drawing conclusions. “Attackers would have the natural desire to implicate another party,” they wrote.

About the Author

William Jackson is a Maryland-based freelance writer.


  • Records management: Look beyond the NARA mandates

    Pandemic tests electronic records management

    Between the rush enable more virtual collaboration, stalled digitization of archived records and managing records that reside in datasets, records management executives are sorting through new challenges.

  • boy learning at home (Travelpixs/

    Tucson’s community wireless bridges the digital divide

    The city built cell sites at government-owned facilities such as fire departments and libraries that were already connected to Tucson’s existing fiber backbone.

Stay Connected