Why THE FUCK are industrial controllers connected to the Internet still running Windows?
What is going on here? Why did anyone ever think this was a good idea? Your customers may use Windows, but you don't code your site as a batch script ...
I have a little experience in industrial control systems. Near as I can tell, both support and demand in the industry for controlling these devices with anything but Windows XP is basically nonexistent. Support for Windows 7 seems half-hearted at best, even now, when XP is nearly EOL. The package I have used the most, GE iFix, is so tightly tied in with Microsoft technologies, including OPC, DCOM, VBA, and ActiveX, that it's tough to imagine a port to anything else happening anytime soon. If you're interested in the industry, look up info on this, and stuff like Wonderware.
Most of the people working on these devices are far from being computer experts. I went to an advanced class for them, where the instructor took pains to advise the class that it was an advanced class and you would probably be lost if you hadn't taken the beginner class. I hadn't, and I breezed right through all of their material. Not that I'm that much smarter than anyone there, just from having experience using and figuring out a lot of different types of computer systems. This type of software is made for people who are experts in stuff like chemical plant operations, but who think Excel would be a great way to program their control systems. I'd bet that not one of them have even heard of the Nataz attack.
Given the total lack of interest or experience in computer security that seems to be prevalent in the industry, I expect it will get a lot worse before it gets better.
It's a great question, and as someone heavily involved in industrial control systems, I ask myself and others that a lot.
The only real reason I've heard comes down to cost and support. It's easy to develop software for Windows, easy to find developers, easy to support the operating system, easy (debatable) to use in an industrial environment. It's a known factor.
Always remember that people on the shop floor (or hydrocarbons refinery equally) aren't interested in maintaining a PC they don't understand, and their management aren't interested in maintaining a well-educated IT department. It's a simple cost/benefit equation, and so far the benefits have been completely ignored.
Likewise, vendors of control systems don't want to put the time and effort in to develop their IDE's, display tools etc for a Unix variant. System integrators (ICS programmers and configurators)... well, we'd be cool with a Linux-based control system, if it worked well.
That's why you see Windows in industrial control environments. Couple this with the extremely conservative nature of industry, and you have a huge, glaring problem. We (ICS engineers) know it's a problem, clients are starting to realise it's a problem, but the wheels move slowly.
At least Stuxnet has made the wider industrial community aware of just how deep the shit is. Now begins the slow process of crawling back out of it.
Sorry but in this scenario maintaining a 5-person skilled IT department was/is imperative. The TCO should of the IT department, even if you hire D. Hartmeier[1] to configure the firewalls, should be negligible compared to the operation's TCO.
That said, in this case I believe that the software to manage the centrifuges is made by Siemens (Germany) and it's written on Windows. So partially it wasn't the consumer's choice to use windows. Even if they used linux, is not hard to think that the NSA could have written a Linux clone worm. The only thing that can keep away such threats is "security" as Schneir mentions here[2] "security is a process" and that process can secure any operating system out there imho.
what proves that running windows is the least concern. they would have added some suid crap listening out for reason had this been linux or anything else. this is just negligence. it is the same as bridge falling it two trucks drive there at the same time. everyone would be fine blaming the architect, engineer, construction company, politician that paid for etc... that happens in software, it is nobody business.
They were able to connect to the centrifuges through the internal facility by infected machines.
I remember reading that one of the methods Stuxnet used to transmit data through the facility between two infected machines that were not networked: sound cards and microphones.
Or the operator just didn't follow procedure and plugged it in. Work in an ICS environment for one week, and you'll see the probability of this happening is close to 100%. Most of these folks don't even know what a cyber attack even is, or even how it could happen let alone how to stop it. It's science fiction to them, they don't care because it's FICTION. As a friend in the industry one said once: the typical operator is a monkey: press the button get a banana. Horribly offensive, I admit, but I've unfortunately seen it myself. The human factor, that wonderful human factor will get you every, single time. Remember, these are people that have never even heard of a cyber attack except maybe in a movie or TV show, and even then they probably thought it was nonsense. They not only don't care, they don't even know they should care. It's all magic to them. The world is flat, and it makes sense because it's LOOKS flat.
So, often people will image a computer (e.g. to a 2nd harddisk or DVD) after changes had been made. So returning after one year you'll find that the hardware had failed for whatever reason and the image put back on another PC. So, restricting access in Software is more viable, in my oppinion.
If a government entity was willing to pay for 0-day exploits to target a specific system and infrastructure I don't think it really mattered what OS was behind the controllers since they'd be building the super-virus to the needs of the assignment.
I don't think that conclusion, or the more general one, that endpoint security can't be a significant barrier, can be drawn yet. The level of good security practices in this case is very low. Once the air gap was breached they were done.
Q: Disabling AutoRun in Windows will stop USB worms, right?
A: Wrong. There are several other spreading mechanisms USB worms use. The LNK vulnerability used by Stuxnet would infect you even if AutoRun and AutoPlay were disabled.
The industrial controllers were not connected to the internet. Part of Stuxnet's sophistication was crossing the air gap via USB sticks that were infected through two never-seen-before 0-day attacks, the infamous shortcut icon attack vector, and autorun trojans.
Why were the control systems running Windows? Because it has a GUI. This helps when monitoring control systems, and of course is the only platform Siemens' monitoring systems run on.
Oh god, DCOM memories. I've spent days in a futile attempt to get that working. The best demo of how bad DCOM is would be the existence of OPC Tunneler:
DCOM is such a headache that these guys sell a $1000 program whose sole purpose is to make it easy to make remote DCOM connections. And I've recommended it as a screaming deal at that price. Given what it costs to get myself or a proper tech to a remote site for a day, I'd much rather use that and spend my time solving the actual problem than spend a day trying to get DCOM working before working on the actual problem.
It was a while ago, but I worked for a place that was writing software for boxes that could be used to collect telephone toll data from old bar switches in an Eastern European country. The sales manager thought it would sell better if it was on Windows 95. I suggested to him that they could at least use NT so you could lock down access better. His response was: "Oh, I told them that now their staff can use Windows 95 whenever they want." #facepalm
Another bright idea was that rather than just collect the information and forward it to a central hub (the ultimate destination), the data would be transferred according to the organizational structure... first area level, then regional, etc.
The culture at this shop was like this... sales spec'd the software and there was no push-back allowed from the technical staff. Fortunately, I didn't work on that project.
They did have write protection in the past... if I remember correctly, some of these memory cards really had an old-school Eprom you had to erase by UV light and externally erase using a high-voltage parallel programmer:
Not really, since the control system wasn't connected to the internet. They did, however, rely on "air gap" security, as you appear to be proposing.
Defense in depth is the only valid model of protection, but this requires intentional inclusion of cyber security concerns in the design stage of your plant, and on-going maintenance and auditing by a skilled IT team, and training of all your employees against social engineering, and...
This is a lot harder to do than just unplugging the Internets and giving a thumbs up.
Any targeted attack is likely to succeed given the (apparent) money and talent behind Stuxnet. Many of the exploits were zero-day anyway; I see no reason why they couldn't have used zero-day linux exploits instead.
I do agree, though, Windows is a desktop machine OS and has a vastly larger exploitation surface area.
I do not think that's true. It obviously took a serious amount of time, money, and testing to implement stuxnet. Double the cost and risk might still be do-able. 10X the cost and risk might not.
The level of defense - in this case an air gap - raised cost and risk. That added back bag job to plant the infection, or a bribed operator to the cost and risk. If the SCADA software ran in a VM as a guest OS, and booted from read-only media, stuxnet might not have taken hold, and the bribed operator might have been discovered by forensics on isolated infected systems.
At some point the cost and/or risk exceeds the value of the target or a reasonable threshold for the chance of success. Even when you have infinite money, you don't have infinite time or infinite risk tolerance.
"I see no reason why they couldn't have used zero-day linux exploits instead"
Selinux / apparmor, lxc (or similar), better aslr, daemons usually defaulting to separate users, many other things... There are many security layers so trivial to apply these days that it's really a failure not to. Sure - you can still find zero-days (or may be already sitting on a pile of them), but I get an impression that it's much harder to take over the whole system these days if anyone spent a couple of minutes just to tweak the defaults.
This is incredibly interesting and extremely important. It has clear implications for infrastructure and security, particularly energy infrastructure which I am most interested in.
My Dad used to write software for large technology companies. When he was with Control Data, they had just finished a huge project where they automated a ton of processed for the local energy company to make it more efficient.
When I was in college and the internet got big I and I was touting all this cool stuff you could do, he told me about this project they did way back in the 70's. He said it terrified him at the time because it took the human element out of the equation. If something went wrong, it could do some serious damage. A misplaced decimal point here and it could basically bring down an entire region of the power grid.
He always said the software was great, but it made the people using it lazy - which is where the real danger is.
