Thursday, August 5, 2010

To worry or not to worry about icky worms

Viruses, worms and Trojans are an unfortunate part of the computerized present—albeit not a pleasant part, which Siemens has been finding out all too personally this summer. But, should we really be all that worried about our smart grid’s cyber security, or are we panicking ourselves unnecessarily?

The Siemens thing: In June, the company discovered it was the specific and directed target of some nasty malware which uses a Microsoft Windows loophole dealing with shortcut files to latch on and download secure information from supervisory control and data acquisition (SCADA) systems using a leaked Siemens password. The sticking point, though, is that the worm is rather low-tech (relatively) in its delivery: The computer has to be physically connected to an infected USB stick (although there is also a possibility of it spreading via CDs and file-sharing). If someone views an item from that infected stick, the worm sneaks on out into the system, searching out information to copy.

Named the Stuxnet worm, it seems to be hitting Middle Eastern and Asian countries the most. (Symantec Corp. revealed that over half of the systems impacted were specifically in Iran, but Indonesia and India have also seen a large set of Stuxnet issues, according to one IDG News Service report.)

The worm itself was discovered by an antivirus company in Belarus named VirusBlokAda, which has labeled the worm “very dangerous” and noted that it could lead to a “virus epidemic” on the company website. But, how dangerous is it if I need to connect an infected part and then open something up by hand to create this issue? That doesn’t really sound like a system issue as much as a personnel issue, really.

Right now, according to Siemens spokespersons, the Stuxnet worm has not yet impacted any power generation SCADA system nor any T&D SCADA system.

“To our knowledge, only two industrial systems were affected by this [malware],” a Siemens spokesperson told me, and the fact that power-system SCADA networks weren’t impacted reveals the hearty backbone of those systems, according to Scott Gosnell, CMO with Tatsoft, a developer of software tools, products and services.

“This particular attack shows the strengths of current security technologies and protocols—the worm didn’t come in through a network vulnerability,” he noted.

Industry insiders warn, however, that utilities should not assume they are out of the woods just yet, even if the Stuxnet worm has avoided corrupting power systems this round. It is still spreading, and it won’t be the last threat by far. And, of course, there are other issues recently brought up around smart grid security, including a recent Pike Research report that points to smart meters as “the weakest link in the smart grid security chain” filled to the brim with juicy data that “could be successfully eavesdropped.” (Pike report: Smart Meter Security. Easy to find on their website pikeresearch.com.)

So, what’s a smart grid planner to do? Can he think ahead to the next malware? Can he plug all the security holes? Well, maybe he can’t do it all, but it seems that it is expected that he give it the ol’ college try, really.

“This is not the time to stick your head in the sand and say ‘it can’t happen here,’” said GarrettCom President Frank Madren. “Cyber attacks on industrial control system are happening now and will probably increase.” Madren suggested best practices to prevent damange include a multi-pronged approach of good industry standards, technology and personal, targeted recommendations to fill in holes in a utility’s security program. It’s all about repetition. Never assume that all the holes have been covered. Always go back and check again and again. (In this way, malware is a lot like a zombie horde---always trying to get in a forgotten opening, an unchecked back door, an open window.)

Tatsoft’s Gosnell would add man to Madren’s best practices equation---keep him tech savvy and on top of things, ready for the onslaught.

“This [attack] also demonstrates that operational risks are an inherent part of running these systems,” Gosnell added. “One of your biggest potential problems comes from poor processes and policies at the human level. Maintaining good security hygiene at the human and social level complements good technical hygiene.”

Madren noted that North American Electric Reliability Corporation’s Critical Infrastructure Protection (NERC CIP) regulations help protect power utility substations from a variety of security issues, including worms like this one. They are incredibly comprehensive and offer a great amount of defense.

“However, no system is completely immune from creative new incursions. Constant vigilance is required,” Madren said.

So, worry? Yes. Panic? Not helpful. Just keep one eye open … and try not to fall asleep and unconsciously let in those zombie malware hordes.

1 comment:

  1. Marcos Taccolini, the CEO of Tatsoft, sent me a note about the worm today. Here are his comments:

    That is a perfect example of the hidden costs and potential problems when you keep installing on mission-critical applications, like scada systems, a piece of software that has an architecture created more than 10 years ago.

    What had enabled that VIRUS to be attack those system is that the Siemens system, as well most of the solutions still on the market place, were create on the before the Microsoft.NET Framework era, using technologies like VBA, VBSCRIPT, Active-X and other technologies that are intrinsically "UNSAFE".

    I am not criticizing any supplier here, my own previous product created on the later 90' is still using VBSCRIPT and TEXT non-protect files that also very vulnerable for attacks. Only my latest product generation, created from the principals in managed .NET code I was able to prevent completely that kind of vulnerability.

    The fact is, whatever the supplier, if the technology is used in the product internal is the same from 10 years, a lot of potential problems can happen. I will list some of those problems, that not only Siemens, but many other still have:

    1) Scripting language is VBA or VBSCRIPT, that creates two issues:

    1.1- It is interpreted, not compiled, so an external program, like that virus can add malicious code

    1.2- Lots of errors are only found on RUNTIME, as on the engineering the error-checking capabilities are very limited.

    2) Project is composed by hundreds of files, many of them in pure text files. That create the following problems:

    2.1. There is no encryption on the project configuration, allowing both malicious actions and access to the control logic

    2.2. It is not hard to a file get mixed with an out-to-date version or when moving, an application can "ADD" by accidentally pieces from other applications.

    3) The interface is based on ACTIVE-X and custom TCP/IP protocols on non-standard ports.

    That is the I.T. nightmare for security, you cannot really protect from an Active-X components. The non-standards TCP/IP protocols in one side force to disable Firewall ports, on the other side, most of the protocols those SCADAs use to exchange data between their station or their servers and client viewers is a very simples text or value data stream inside the TCP/IP message what makes very easy to network attacks and also to get access unauthorized access to the data.

    Those are just some examples, but there are more issues. The good news is that is the company decides to stay updated with the current technology, any of those issues would create a problem in a solution created using the latest technologies. For instance:

    On item 1) The new systems can use C# and VB.NET as scripting language that is compiled and embedded inside the application, making impossible the work of that virus and also solves the runtime robustness issues.

    On Item 2) The new systems save all the project files in a unified SQL-compatible database with encryption and access protection

    On item 3) the new systems use WCF (Windows Communication Foundation) and connection oriented data transfers protected by built-in login validation on the protocol and standard firewall-friendly protocols.

    The bottom line is that SCADA is no different from a car, the fact it was working well the past 10 or 15 years is not your security for the next five years, in fact, it exactly the opposite! If is in place the past 10 to 15 years, it means the internal and kernel architecture it is using is from that age, not prepared to our new inter-connected environment and if you want to "drive" safely the next five years you should think about evolve to the generation systems.

    ReplyDelete