Sunday, December 1, 2013

Automation Is War! (Wait, what?!?)

Unless you've been living under a rock, you would know that STUXNET refers virus that impacts automation control systems. It was first discovered at the Iranian facility that was enriching uranium. And since then, we learned that this virus wasn't created by hackers; the sophistication of it points to a government with vast resources. Check out this fascinating article on STUXNET.

Here are some main points:
  • There isn't one Stuxnet, there are a set of twins.
  • The first Stuxnet attack happened in 2007 and was designed to stealthily disable the uranium enriching centrifuges by overpressurization. Its impact is uncertain.
  • The second Stuxnet attack was less stealthy and was designed to disable the centrifuges by over-spinning the centrifuge rotors.
  • The second Stuxnet virus spreads and infected the laptop of system integrators that connected to the SCADA system and the intent appears to be to disable the Iranian nuclear program over the long-term.
  • The forensics on the Stuxnet virus points to government involvement as the Stuxnet attack uses "zero day" Windows weaknesses and stolen digital certificates that would cost hundreds of thousands of dollars to create.
Here's something amazing:
One of the first things this Stuxnet variant does is take steps to hide its tracks, using a trick straight out of Hollywood. Stuxnet records the cascade protection system's sensor values for a period of 21 seconds. Then it replays those 21 seconds in a constant loop during the execution of the attack. In the control room, all appears to be normal, both to human operators and any software-implemented alarm routines.
Stuxnet can intercept sensor measurement and send false values to operators at the HMI. Operators at the HMI are none-the-wiser. OPC Servers have no idea that these values are counterfeit. OPC Interfaces, repeating what they were sent by OPC Servers, would simply re-transmit these false values. Data Historians, archiving what they are told by OPC Interfaces, would insert these false values in the archive as told.

The long-term effects are truly pernicious because long-term process understanding is impacted.  The power of data historian software is the ability to let users look in the archives and understand real phenomenon from sensor readings.  And since Stuxnet decoupled sensor transmissions from reality, there will be armies of engineers scratching their heads.

I'm headed to OSIsoft's vCampus next week and going to take part in the security hack-a-thon as SCADA security comes to the fore.  Most data historian run as read-only systems: data flow unidirectionally from the control system to the data historian, so for most systems, security impact ought not be that large for process data historians.

In the meantime, if you're a system integrator, do not connect to customer SCADA.  And if you're a customer, don't be letting system integrators connect to your SCADA.

Also, questions for automation purchasers to think about:

Have you assessed the risk of a stealth virus/worm infection like Stuxnet?

What risk-mitigation tactics are available to your automation team?

4 comments:

Anonymous said...

It's my understanding that stuxnet only could impact Siemens PLCs and associated HMI software. If someone is using Rockwell or Emerson PLCs, I don't think there would be any concern. That's not so say that someone isn't writing a new virus to impact those PLC vendors, but if Iran only uses Siemens technology, there's no point in Stuxnet coders wasting time writing for other PLC vendors.

Anonymous said...

Yet...

Dallas West said...

Wanna read more about hacking PLCs? Read on...

http://www.digitalbond.com/tools/basecamp/

Dallas West said...

Want to read more about hacking Rockwell? Read on...

http://www.digitalbond.com/tools/basecamp/

-->