Air Gaps won’t Stop Stuxnet’s Children

As someone working in the field of industrial cyber security I never thought I would see the day when a cyber attack would be the topic of a prime time television show.

Recently the U.S. program “60 Minutes” aired a segment called “Stuxnet: Computer worm opens new era of warfare,” If you have not seen it, I recommend viewing it.  It does a good job of explaining a complex malware and it is interesting to learn about it from the people who were directly involved in deciphering and tracking it.

Recent well-designed ICS worms and cyber attacks such as Night Dragon, Duqu and Nitro have been revealed. Each of them has focused on stealing intellectual property such as oil field bids, SCADA operations data, design documents and other information that could cause business harm.  This focus on industrial data compromise is new, and signals a new era of industrial malware.


Eric Byres is in the background of Ralph Langner’s talk at the S4 Symposium. Taken from the 60 Minutes video on Stuxnet.

Why do they do it?

When most people consider the motivation of worm creators and hackers, they think of the destructive focus of early cyber events like the Slammer worm or Mafia-Boy attacks. Both Nitro and Duqu show a different focus – subtle and persistent attempts to steal valuable information. This information could then be used to make a competitive or counterfeit product, out-bid a rival for an oil or mineral exploration lease, or coordinate a marketing campaign against a competitor’s new product.

Theft of process information for commercial espionage is nothing new. It has been around long before networks and cyber-security showed up - check out the article "The Pizza Plot" for an example of how Schwan's used production information from a Kraft plant in Sussex, WI to reshape the store-bought pizza market.

Today the profit potential for IP theft can be enormous. One consumer products company estimates that IP theft from its operations results in a nearly a billion dollars of counterfeit product being produced and sold every year. This is money that the company will never see.

These worms could also be precursors to later destructive attacks against automation systems. Clearly the Stuxnet designers collected detailed process information on their victim prior to actually creating their worm. Could the Duqu worm be a forerunner to a more destructive attack? Symantec certainly thinks so.

It is worth noting that the goal of Stuxnet was to impact production (of enriched uranium) rather than cause an explosion and kill people. So it is possible that the goal of this next generation of malware is to quietly stop production at a plant or utility somewhere in the world. Impacting the production of a competitor, short selling the shares of a company or extorting money under the threat of a disruption are all profitable activities for a criminal or nation-state group.

Why we can’t keep Son-of-Stuxnet out of our Factories

Many security experts suggest the only solution is to go back to the days of completely isolated automation systems. Unfortunately, walling off a control system just isn’t feasible today. As I explain in the article “#1 ICS and SCADA Security Myth: Protection by Air Gap,” modern industry and the technologies it depends on need a steady diet of electronic information from the outside world to operate. Cut off one source of data into the plant floor and another (potentially riskier) “sneaker-net” source replaces it.

 Figure 1: Possible Pathways into the Control System

Now industry and government can try to battle this trend by banning technologies and mandating complex and onerous procedures. We see this sort of strategy every time we try to board a plane and wait in long lines to take our shoes off and get our hair shampoo confiscated. Frankly, I don’t think it is effective or efficient security for air travel. It is even worse for companies that ultimately need to be profitable if they are going to stay in business.

The Way Forward

Is the situation hopeless? No, but ICS/SCADA security practices must improve significantly. First, the industry needs to accept the idea that complete prevention of control system infection is probably impossible. Determined worm developers have so many pathways available to them that over the life of a system some assets will suffer compromise. The owners and operators need to adjust their security programs accordingly. In particular, security programs need to:

  • Start with a Risk Assessment to quantify and prioritize the threats that pose a danger to your business (see the White Paper at the end of this article for guidance on how to do this),
  • Consider all possible infection pathways and have strategies for mitigating those pathways, rather than focusing on a single pathway such as USB keys,
  • Recognize no protective security posture is perfect, and take steps to aggressively segment control networks to limit the consequences of compromise,
  • Install ICS-appropriate intrusion detection technologies to detect attacks and raise an alarm when equipment suffers compromise or is at risk of compromise,
  • Look beyond traditional network layer firewalls, toward firewalls capable of deep packet inspection of key SCADA and ICS protocols,
  • Focus on securing last-line-of-defense critical systems, particularly safety integrated systems (SIS),
  • Include security assessments and testing as part of the system development and periodic maintenance processes. Identify and correct potential vulnerabilities, thereby decreasing the likelihood of a successful attack,
  • Demand secure control products from automation systems vendors, and
  • Work to improve the culture of industrial security amongst management and technical teams.

Implementing these changes will improve the “defense in depth” posture for all industrial control systems. They are needed urgently; if not your operation might show up on TV, as the lead story in the news about a successful cyber attack.

Related Content to Download 

White Paper - "7 Steps to ICS and SCADA Security"


Download this White Paper and find out:

  • The 7 Steps to start improving your organization’s cyber security posture
  • Tips for optimizing your spending and resource allocation on cyber security
  • Real-world advice from security experts Eric Byres and John Cusimano


Related Links


RSS Feed Subscribe to the "Practical SCADA Security" news feed

Author Eric Byres




Did you ever hear of a write-once (read-only) preprogrammed memory for a PLC? That would block malware.

Interesting idea - a few PLCs have Write-Once EPROM/Flash memory for loading logic to RAM memory at start-up, but none that I am aware of have the ability to actually run from flash. Thus I doubt that they would really do much to help the security issue. For example, the changes that Stuxnet performed on the 315 PLCs didn't require a restart and thus the correct logic in the the EPROM would have no affect on the modified logic. It may have made clean up easier though.

In my experience, there are many small but critical logic changes made to most standard control systems during their life time. Locking these out would not be well received by the engineers and technicians that actually have to maintain these systems. So perhaps the most effective use of your idea would be for the actual operating system firmware for the PLC or for logic in safety integrated systems (SIS). Of course, that would preclude even installing patches in the controller for bugs or vulnerabilities that are discovered after sale. This may or may not be an acceptable trade off.

I should also mention that a number of operating systems struggle to run from read-only memory. Not a show stopper, but it is a problem.

My preferred solution would be proper signing of controller logic - a few SIS already do something like this. Unfortunately the ones I have seen were designed to detect errors or version issues and are not hardened against an intelligent attacker. However I think they are going in the right direction.

Fully support what you're saying here Eric, I also think though that we need to be driving the same level of awareness into the Instrumentation (not just Control)community, especially given the increasing intelligence of the instrumentation (e.g through Foundation Fieldbus devices) and controls (variable speed drives), all of which are capable of being compromised through either programming devices, controllers or (especially in the case of FF) connections to the Corporate networks for Asset management software interfaces.

Any thoughts?

I couldn't agree more - as intelligence moves deeper into the plant floor, so do the risks. Check out Rob's excellent blog on this exact concern:

Add new comment