Path: EDN Asia >> Design Centre >> Computing/Peripherals >> Understanding Stuxnet and embedded security
Computing/Peripherals Share print

Understanding Stuxnet and embedded security

13 Dec 2012  | Kris Ardis

Share this page with your friends

Stuxnet, a sophisticated virus that damaged Iran's nuclear capability, has been catching a lot of attention recently. And it should—it's a fascinating story that combines international political intrigue and nuclear science. However, many of the questions being raised are wrong and misleading; they don't address the root problem. This article discusses why we shouldn't fixate on Stuxnet, what questions we should be asking, and where we should go from here.

What is Stuxnet?
Stuxnet is at its root a computer virus. But it is a very sophisticated one. Most viruses are passed by email, file attachments, or USB sticks, and cause mayhem by exploiting weaknesses and flaws in modern PC operating systems. They can spread quickly, but many commonsense approaches to handling email, Internet downloads, and antivirus software can help mitigate their threat.

Normal computer viruses are indiscriminate: they attack every PC they touch. Stuxnet is different—while it spread in a similar manner as other viruses, in most systems it had no effect. Stuxnet was designed to:

1. Infiltrate a PC through the typical virus pathways. USB sticks were highly effective.

2. Confirm whether the host PC's location was Iran.

3. Establish whether there was a certain type of programmable logic controller (PLC) connected to the PC.

4. Check if there were a specific number of those PLCs attached.

5. Confirm whether those PLCs were connected in a very specific arrangement and controlling a particular piece of equipment.

6. Reprogram the PLCs to alter their behaviour, but report diagnostics that everything was fine.

This sounds pretty complex. But it is only part of the story; the number of PLCs and the configuration that Stuxnet targeted prove that the virus was clearly defined to attack a specific nuclear facility in Iran, and to slowly and permanently damage the centrifuges there to set back the Iranian uranium enrichment program. The damage was intended to be done over time to confuse operators—they would not think of a virus or even any kind of IT problem until they were deep into diagnosing the issue.

Evidence suggests that Stuxnet was successful at permanently damaging 1,000 centrifuges in the Iranian nuclear facility. There is speculation that the virus was designed by the United States, Israel, or both. Note that Stuxnet did not actually damage most systems it infected—it was a highly targeted attack. This allowed it to spread to its target before it was detected and antivirus companies were alerted to its presence.

Why we should we worry
This is a model for effective cyber warfare. It has likely inspired the IT efforts of nation states all over the world. While the United States/Israel may have achieved their targets in this opening strike, has a Pandora's box been opened where we will now see retaliatory attacks that target US or other allied interests? Will attacks in the West model Stuxnet, but broaden the focus to cause maximum damage to critical infrastructure?

There is another reason to worry: Stuxnet shows that critical infrastructure is not protected. Security is often not a design consideration in many applications, including industrial control. There is a basic rule about designing security into an application: It never happens because it is a good idea.

It only happens because (1) it is dictated by the situation (e.g., a certification that requires a level of security); or (2) in reaction to public or damaging exposure of a security flaw. Note that the first reason is pre-emptive, and the second is reactive. What situation are we in now?

In the post-Stuxnet era, are we asking ourselves the right questions to try to solve this problem? Some are asking, "How do we combat Stuxnet?" and "How do we secure a USB stick?"

Solutions resulting from these questions are bandages, similar to airport security measures that require us take our shoes off to check for bombs. Yes, inspecting our shoes will detect the attack that was nearly effective, but it doesn't check for the next type of creative attack.

Even if we believe USB memory sticks are a weakness and a path for spreading viruses, a secured USB stick won't help—It is easy enough to create a USB that looks like the secure one, and load it with the virus.

The root problem
In our shoe bomber example, the root problem is easy to identify: How do we ensure that everyone who has access to the plane (passengers, maintenance, crew) has good intentions to travel on, repair, or operate the aircraft? The question is easy to identify, but not to answer.

It is similar with Stuxnet. The question needs to be "How do we protect critical infrastructure so that it operates in the way it was intended?" The answer is accordingly complex, but at its root is a need for embedded systems to consider security in all aspects of design. Engineers typically design a system first for nominal functionality, and if they consider security at all it is generally an afterthought, applied over an existing and designed system. Everyone involved in the security industry is familiar with the notion that "security will be designed in later"... which actually means that the solution will never be secured. Security added at such a late step can only be superficial, only protecting against obvious threats.

Let's use another piece of equipment as an example: a smart meter is first designed to meet metrology accuracy requirements and implement a communication stack correctly. In that communication stack, the Advanced Encryption Standard (AES) is usually added to protect data that the meter generates and sends back to the utility, and to protect the commands sent from the utility to the meter.

The answer from many utilities, communication providers, and meter manufacturers is then that the meter is secured because it uses AES to encrypt the data going in and out of the meter. But this is a bandage—the threat is identified as only the "tampering of data coming from the meter and commands going to the meter." This is the equivalent of taking off our shoes in the security line at the airport—we have a single threat identified, and a single bandage to address that single threat. There is no consideration for the next new threat. In the case of the meter, the next clever threat might be against the physical meter itself. Can an attacker access the physical meter and load a new application program into the firmware, allowing the attacker to take control of the meter? We now have a new threat: a malicious firmware programmer. But do we develop another bandage or instead think about a broader approach to security?

A broader approach
Bandages will not work. They only prevent the past attacks. Our adversaries are smart enough to move on to a new trick, but our security approaches are not. Is a terrorist today going to approach a plane with a bomb in their shoe? Probably not. They will develop a more creative attack—perhaps they will penetrate the security at a much smaller airport, then fly a private plane to a larger airport where they will have access to larger targets.

1 • 2 Next Page Last Page

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact