I just wanted to say thanks to all that brought this to our attention. The article posted by Gustavo has a simple fix which is to restrict executable rights from network shares and removable media. I forwarded this to our IT guy so we can have a permanent fix for our win2000 machines that are still in service on two of our pieces of equipment (and not likely to change soon...). I recommended doing it for office computers too as I believe it won't take long for this to be exploited by other virus authors.

KEJR

 

Yet another post about it, this time from within the industry:

http://www.managingautomation.com/m...anufacturing_Software_Systems_Worldwide_33612

 

Hi Dave.

I have no doubt that you can secure your installation, within reason and if you keep up with all the patches. So that's one. My point is that with the present method, that is all left up to chance and the responsibility of the installer, who from sad experience could be just about anyone, because anyone can install Windows, right? You cannot even begin to achieve a general level of security with an OS that is maximally vulnerable and the rest of the process being left up to chance, or the guy who's "really good with games". And it's a lot more work.

In it's place, I suggested that the product, as delivered, would secure the machine and close off all unnecessary vulnerabilities regardless of who installed it and leave a completely consistent and known configuration, running on a known reliable and secure platform. All access would be logged. And trusted access would be required to even enable the USB ports. That can be done because you are no longer installing on a general purpose OS configured to meet as many diverse roles, (including virus writing) as possible. The vendor could supply the OS, configured for the application and locked down by people who (hopefully) know what they are doing. And because it's modular, it could be relatively small and fast. Something like what Cisco and others are doing for their reasonably secure routers and switches. With the need for quality graphics it probably wouldn't fit on a floppy, but could be in the 10s of megabytes. I'll leave it as an exercise for the reader to decide which would be more secure. All it would require is a port to a suitable OS, the rest is common practice in my world. And it would support all the things we need for automation instead of trying to deprecate them.

And the lack of R&D funding on the Open PLC project only delays my owning one. Anybody who wants to can build one by next week. My vanity would be served if they would donate a copy back to the project so I could be one of the first at least, but this is the way it was to be distributed anyway. So it's coming along just fine. There would be some additional value add if I build one and test it. But, assuming it works, the files that exist today would be the ones they will get. The programming tools project hasn't seen much time, but the chart recorders will figure into the picture somehow and I consider learning python part of the effort. That's the power of OSS, I can do a great deal without any R&D budget.

And they must believe they don't _need_ any people to build _or_take care of the automation, just lately :^)

Regards
cww

 

Again, it leaves it all up to the installer, no way you can do that with any degree of assurance that it will be secured. It does let you blame the user for problems though, that's how MS gets a free ride. Either you devote your life to securing the thing, or it's your fault.

Regards
cww

 

Hi Curt:

I do not let "anyone who can install Windows" install my controls machines and anyone who does, gets what they deserve. Emerson does exactly what you suggest with DeltaV, you order the PC from them that they have tested and "stamped", then they load their software on it and clean up the machine (is it perfect, noone is) but it is much better set up this way, Then they only "allow"/warrantee it to be on its own network on its own Domain, it is the user that deviates from that.

As far as Linux goes, MOST users cannot take it out of the box and set it up, this is a problem, and most Engineers and IT people will not just accept an installation as set up, they HAVE to know what is going on inside, that is their nature (type A), so there will not be buy in until they have time to learn it and right now, that isn't going to happen.

Lastly right now, when they are all done learning it and installing it, there is nothing to run the plant on that they will TRUST right now. Maybe later, but not in the last 10 years on a big enough scale. Yes there are pockets of examples (Appache, etc.) but not millions of them.

I know people at Rockwell that are experimenting with pre-installed machines on say VMware so they are pre-set up with all software and hardware is not an issue (VM). So you would buy the VM from them load it up and go, still doesn't fully protect from a dumb VM installation though.

I say until we get more people working so that there is time to learn alternatives, this problem will keep going on and users will buy boxed software. You say that because of the issue of no people, you need to learn the alternatives so that you don;t have to deal with these issues.

Chicken or egg, we can agree to disagree.............again.

Dave Ferguson
Control Systems Engineer

 

In reply to Curt Wuollet:

I have to agree, if there are reasonable ways to make a SCADA/HMI system more secure, the SCADA/HMI vendor should be the one researching and providing them. And I also agree that the only practical way of doing that is for that vendor to provide the OS and SCADA/HMI system together on one CD, and to take responsibility for keeping it up to date *as a complete package*. All the user should have to provide during the installation process is what passwords he wants to use, what language to display, and what time zone he's in.

The automation engineer should be responsible only for that 1% which he adds on top of the base install. If the system is well designed, there should be very little he can do in that 1% which can cause a security problem.

There's nothing particularly unusual about this concept. It's how most of the IT world works when it comes to critical business systems. For a lot of less critical applications, they are going to what they call the "appliance" model. Sometimes they give it to you as a VM image which you run on whatever you want. There are several companies which specialise in providing engineering services for application companies that want to do this. The way the SCADA/HMI vendors operate is an anomaly in this respect.

 

And again, this time with an interesting tidbit. Apparently, Siemens IS aware of the issue, but has only seen one example in the wild.

http://www.theinquirer.net/inquirer/news/1723566/virus-power-station

-James Ingraham
Sage Automation, Inc.

 

The article said they are aware of one customer *in Germany*. Microsoft said the virus appears to be hitting mainly Asia at this point (Iran and Indonesia in particular). It hasn't peaked yet however, and it appears to have been active for weeks before it was discovered.

 

Hi Dave

We can certainly agree to disagree on many points, but I can't let you sell users short like that. MOST users _can_ set up Linux these days. That is what brought Ubuntu from an idea to a leading and almost dominant distribution in the last few years. And it is all the buzz this year whether Fedora or Ubuntu has the easiest install. I just brought two _notebooks_ up on F13 and the hardest question was what time zone I was in. Both connected to my wireless network with zero configuration. As you know, notebooks are "special" and usually require that you get drivers for almost all the gadgets when installing Windows. And these aren't anything special, a Thinkpad T23 and a Compaq Armada M700. I'd be confident betting a virtual beer that you could get Fedora running on one long before I could get Windows running on the other. Then we could switch and you could double down. And I don't think you are going to convince anyone that it's harder to know what's going on with your machine under Linux than it is under Windows. After all that's what Open is about.

But, more to the point, under the plan you wouldn't have to get any thing set up. With no variables, it could simply be an appliance as far as the OS is concerned. Linux is used for this all the time. If you have an old machine, download a live install disk from Fedora or Ubuntu and run it. Then when you're done playing with it, pick the install icon and see what happens. I think you'd be surprised. And you could very likely fire up FireFox and let us know :^) Alas, my expertise is no longer needed to install Linux either :^)..........

Regards
cww

 

The fix is now available.

http://www.microsoft.com/technet/security/bulletin/ms10-046.mspx


As M Griffin pointed out in another post, anything prior to Windows XP with Service Pack 3 is not supported and doesn't get the fix.

-James Ingraham
Sage Automation, Inc.

 

What I do not understand is why only Linux is considered as an alternative to Windows. Certainly, Linux is more secure but the other operating systems used in SCADA systems are Solaris and OpenVMS. These are also good candidates for new systems. When I scanned the US Government reporting database for operating system vulnerabilities, not attacks but reported vulnerabilities, the numbers were Windows: 300, Solaris: 41, Linux: 41, OpenVMS: 2

I have to believe that the major vendors have their Windows sources based on the many unique Windows features so that moving the product to another platform is essentially an expensive re-write. I have always held that the popular package is popular because it has features that make it vulnerable and thus unsuitable for a secure and stable usable system.

Peter Clout
Vista Control Systems, Inc.

 

A Question that I have is how the hackers were able to get the PLC to process certain code without the PLC software being able to "see" or display it.

 

In reply to Peter Clout: Why Linux and not VMS or Solaris? The reasons are simple:

1) VMS is a niche OS and is slowly disappearing. The only people using it are people who need to run old VMS software. If you want development tools, libraries, databases, etc., your choices are very limited. Hardware support is also very limited.

2) Sun never made Solaris easy to install or use on any hardware other than their own, and Oracle (who now own Sun) have no interest in doing so. Nobody is going to use Solaris these days for any new installations other than running large scale critical financial and business applications. It's also expensive, and Oracle has pulled the plug on OpenSolaris. Be prepared to pay through the nose now that Oracle is in charge. The same holds true for AIX, HP-UX, etc. SCO has run their business into the ground due to some spectacularly bad management decisions (not that they were ever in the same league as the other Unix vendors).

3) Linux runs on more hardware than any other OS. It's easier to install, maintain, and update than any other OS. There are multiple competing suppliers. It's cheap (right down to free). There's thousands of programs available for it, and it's already packaged and in the distro repositories where you can install it with a couple of clicks of a mouse (Apple copied their App Store idea from Linux). When people switch OS, they typically switch to Linux. It's a matter of cost, performance, and not being locked into a single vendor. Basically, it's giving customers everything that they always wanted from Unix.

4) You could also use some form of BSD (another unix clone), but that doesn't have the same sort of commercial support environment. It's widely used commercially, but companies who do use it typically provide their own support in house. It's also used in a lot of embedded applications. It's certainly a possibility however.

You also have to look at what is called "community". If you are trying to do something on Linux, chances are someone has already done or knows how to do it, and can help you with it. Plug the question into Google and you will come up with lots of answers. Try the same thing with VMS, and if you're lucky if you find anything.

If a SCADA vendor wanted their own specialized Linux distro built just for them there are multiple companies out there they could subcontract development and support to. This sort of thing is done all the time for IT applications and is called a "software appliance". You create a Linux distro that is tailored for your needs, and then add your own software on top of it. Several companies have completely automated the process, so it's not difficult or expensive to do. Here's an example:
http://susestudio.com/
Their counter says they've built 4,639 appliances this week.

If a SCADA vendor was going to switch to Linux, it would make sense to do it as an appliance. They would have just the stuff they need for a SCADA system on there, and it would come automatically configured just the way that would be needed. There would be no long involved "lock down" procedure. Everything would already be that way right out of the box and there would be no need to change it. Support would be simple because the vendor would know exactly what was on each SCADA system and how it was set up. The only thing the customer would add would be their application specific configuration files and scripts.

So, from a commercial point of view, Linux makes more sense than VMS or Solaris.

 

Hi Peter

Those _would_ be good choices from a security standpoint, as would the various BSD UNIX distributions. As you can see, from a security standpoint, nearly anything would be a better choice than Windows. One of the best options would be all of the above, so that it would require a portable virus with a whole list of diverse vulnerabilities to propagate which is extremely unlikely. But the reason Linux heads the list is that it would be much, much, cheaper and easier to use Linux. Linux has intense development at this time and is a rising star. It's particular structure lends itself to custom versions and customization. Driver availability is better and the ability to interface your weird gadgets and add anything needed is assured. In general Linux is far more "alive" than those you mention and growing rather than receding. Google, for example, could have based Android on anything, or even written it from scratch. But the unique feature set of Linux as a basis let them leapfrog into eminence from nowhere in the telco game. Anyone else needing an OS they can mold into what's needed will probably reach the same conclusion as it would be hard to make a convincing case for the other options. And I know where they can get an automation oriented Linux guy :^). And yes, there is no doubt the majors are very much locked into Windows, by design and popularity. But we are talking about security here and that lock-in is a major vulnerability in and of itself. And control over the OS would be a tremendous asset to any secure product line. Only Linux comes with that degree of control. An ABix or Siemensix would be cheap, easy, and secure. They would probably gag on the Open part, but the positives would greatly outweigh the negatives and the ports couldn't possibly be that much worse than the MS churn. And the churn could go away.

Regards
cww

 

Probably no one was looking:^) But that really wouldn't be much of a trick. If you have the resources to create the program, it wouldn't be very hard to observe how a download works and fake it, or even record it. I've faked protocols to use a PC to talk to a PLC or machine tool. They're usually not too complex because a PLC doesn't have much in the way of resources. Almost all are simply some sort of stx,ack/nak,chksum game so, the PC stuff is really the more complicated part. And if you can simply buy that or even download it for free, it doesn't take a rocket scientist to do this. With a serial datascope, it wouldn't probably take all day to figure out the download and commands if you've done this sort of thing before. The hardest part might be getting control of the serial port.

Regards
cww

 

And do note that I used the suffix -ix in ABix and Siemensix rather that -ux as in Linux, because neither of those would be good PR :^)

Regards
cww

 

In reply to Kevin Cooper: The reason the PLC programming software wasn't able to "see" or display it was that what the virus was affecting was the computer with the programming software on it. This was an *MS Windows* virus, not a *PLC* virus. The only thing you're going to see is what the virus wants you to see. This is completely standard behaviour for viruses and not something new to Stuxnet.

In the case of Stuxnet, the virus just has to look for the pattern corresponding to the PLC code changes and edit them out of the copy that you are viewing. It can also insert the changes back into any block that you try to download into the PLC. The virus can also initiate downloads of modified PLC code into PLCs that were not already affected. The PLC doesn't know that it's the virus writing this PLC code and not actually you typing on the keyboard.

 

Yeah, I was just wondering about the mechanics of the hack. It seems that it would take someone (or a group of people) a good deal of time to exploit the PLC software vulnerabilities.

 

In reply to Kevin Cooper: A lot of viruses are written using third party tool kits. It's just like any other part of the software industry. There are various groups who specialize in different parts of the business. You combine a "dropper" (the part which delivers the virus) with the "payload" (the part which does the work in arrival). The Stuxnet people may possibly have done a lot of the work themselves, but that isn't the case for many viruses. You could probably subcontract the whole job to one of the established virus writing groups.

There are tens of thousands of MS Windows viruses out there. If creating them was hard, there wouldn't be so many.

 

If you have internal knowledge of the plant and have somebody who gives an USB stick to the operators it is impossible to build a secure system.

http://www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.html?_r=2&hp

I think Stuxnet uses "social engineering" as the primary method.
Stuxnet is the next step in cyberwar.