Slashdot Mirror
Malware Targets Shortcut Flaw In Windows, SCADA
tsu doh nimh writes "Anti-virus researchers have discovered a new strain of malicious software that spreads via USB drives and takes advantage of a previously unknown vulnerability in the way Microsoft Windows handles '.lnk' or shortcut files. Belarus-based VirusBlokAda discovered malware that includes rootkit functionality to hide the malware, and the rootkit drivers appear to be digitally signed by Realtek Semiconductor, a legitimate hi-tech company. In a further wrinkle, independent researcher Frank Boldewin found that the complexity and stealth of this malware may be due to the fact that it is targeting SCADA systems, or those designed for controlling large, complex and distributed control networks, such as those used at power and manufacturing plants. Meanwhile, Microsoft says it's investigating claims that this malware exploits a new vulnerability in Windows."
This is the end for sure. Goodbye everyone.
Maybe Realtek has sinister plans other than making crappy drivers?
Realtek != high-tech
Seriously, anyone using Windows for SCADA in this day and age has to get their head checked. With the wealth of proprietary and free embedded operating systems available today, the use of Windows in any sort of embedded device should have ended a long time ago.
We all know what to do, but we don't know how to get re-elected once we have done it
Just up to now, their malware has been confined to hardware.
Have not .lnk security issues been around since Windows 95? Is this a new one?
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.
...for taking shortcuts.
There's no -1 for "I don't get it."
and the rootkit drivers appear to be digitally signed by Realtek Semiconductor, a legitimate hi-tech company.
For very loose values of "legitimate." Realtek is the Yugo of hi-tech.
https://www.eff.org/https-everywhere
SCADA systems do not run in embedded boards but on full fledged computers. I worked in a company that designed a SCADA system long time ago using iRMX as operating system. The problem with Scada systems have always been its costs that increase when you use special operating systems. The trend now is to run Scada systems in windows machines, but the reliability is not the same.
Embedded device? No, it's the control systems. About 6 years ago I did an internship for a little SCADA company, and wrote something which took their existing customizable form structures (stored in databases, displayed in some Windows form framework that looked almost Win 3.1-ish) and made a version in HTML. The technology looked old even then; I'm sure that there are plenty of Windows control systems sitting around.
The World Wide Web is dying. Soon, we shall have only the Internet.
The target here is likely the HMI side of things. Many (most?) of the HMIs are Windows based and often built, installed and then ignored. The implementers routinely expect them to be running inside air-gapped networks, so vulnerability patching is not performed and sometimes even actively discouraged. Yes, there are open-source HMI projects available, but try convincing someone to deploy a life-critical system using one of them.
Windows is used all the time for SCADA applications, especially in distributed control systems. SCADA applications aren't just embedded devices, they are typically a Windows server installed on a workstation that is used for the HMI (human-machine interface) used for operators to communicate with the SCADA devices such as PLCs and DCSs. Most operators would not be able to function without Windows so they can check their email on Outlook, surf the web or play solitaire. If you want to use programming and algorithms from major manufacturers, a Windows machine saves money since there are already drivers and plug-ins made for Windows machines.
eh, Windows Embedded is an embedded OS
the cost of the OS is negligible part of system
Seriously, anyone using Windows for SCADA in this day and age has to get their head checked. With the wealth of proprietary and free embedded operating systems available today, the use of Windows in any sort of embedded device should have ended a long time ago.
Totally useless comment. An attack on a SCADA is a targetted attack. If you are running it on another type of OS, the attacker will simply write it for that OS. This isn't a SPAM dude. This is a directed spying attack.
SCADA usually talks and is control by monitoring computers. That computer needs to email report, compile data, transmit said data, there are many cases where several pieces of SCADA equipment are thousands of feet apart and if one piece fails all the other have to perform differently. scada is not one device in any meaningful plant configuration. there are feed back loops. shit get complex real quick. and SCADA is not a set it and forget type of operation. plant configuration change depending on the weather and the season.
some venders only offer access to there advanced features through there proprietary software. its so awesome when there is a problem and you cant do shit cause Rosewell manual only pertains to a win-tel environment.
you think scada a problem? look up the security of the Hart communication protocol. pwning your water supple is two wires and a palm pilot with physical access anywhere on the 24V main dc line. now there putting blue tooth transmitters on the line for you. google blue tooth sniper antenna.
They're talking about the master/control side of things, the main servers and the operator consoles that people sit at and view indications, and control things. That is where Windows is often run. Embedded devices to this day remain highly proprietary in SCADA systems, though we are seeing more Linux-based embedded devices now.
The server end though is very often a Windows shop. However, forms of *nix are not uncommon at all either and in fact UNIX types used to be the norm for servers in SCADA, but that's been going away for quite a while now. I'd say it's about 50/50 these days between Windows and *nix. Most of the *nix stuff is now AIX or some flavor of Linux (RHEL being the big one). That's on the server side. The actual consoles where the operators sit are about 90% Windows though, if not higher, and that's most likely where you're going to see this virus come into play in the first place because of some stupid user plugging in an infected USB device.
Though a proper SCADA shop should have their SCADA system locked down. We certainly do. All USB ports are secured and thumbdrives are not allowed, and disabled from being attached. An operator that can just walk up and stick a USB drive onto a console is a big, big no-no.
The vector is the windows machine that is networked (stupidly)
to older non windows boxen that do the SCADA work.
In theory, an attacker could manipulate the SCADA machines
and cause disruption.
You are being MICROattacked, from various angles, in a SOFT manner.
I thought they would barely manage to point and click, and the keyboard were a mistery to them, just like the whole UI is designed to train them to behave... :/ But there are some competent UI designers out there. E.g. the Maya ones. :))
I doubt more than 5% of the (l)users actually know what a shortcut is, considering how they are intentionally hidden away as deep as possible, or even completely removed.
(I’m not hating Windows specifically. “modern” [aka. “dumbed down beyond being usable”] KDE/Gnome and OSX UIs often are not much better nowadays.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Most of the IT your life in the Western world depends on runs on Windows.
Yes, you are right: it is not suited for the purpose. It says so in the EULA.
Again, you are right: they have higher down times, increased maintenance due to weekly patching to prevent security problems.
Uh-huh, I agree. In my experience supporting such systems, they are indeed slower than a good Unix box, harder to administer because you are constantly manually typing things in as opposed to automating them.
Why are they using them you ask? Because it's all the developers/admins know how to use. They hate using the Unix boxes here at my work, and they keep coming to me to hold their hand doing anything on them. They prefer Windows because everyone has Windows at home or on their desks, and it's a lot easier for my co-workers to understand and use. That's why your quality of life is in the hands of Microsoft.
BTW, my co-workers are currently plotting to do-UNIXify one our major systems. *groan* They point out how expensive the AIX box is, and how unreliable it is. Um, the same guys who maintain the AIX box are going to maintain the Windows boxes, and if you remember, they did a terrible job keeping them up! It's not AIX that's unreliable -- it's the quality of our admins.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Totally useless comment. An attack on a SCADA is a targetted attack. If you are running it on another type of OS, the attacker will simply write it for that OS.
Because all OSes are equally vulnerable to being owned by anyone who plugs a USB key into the hardware.
Seriously, anyone using Windows for SCADA in this day and age has to get their head checked.
About 6 years ago I worked as an engineer for a manufacturing company. One day a pop up message appears on my computer. It says something like, "this machine will restart in 30 seconds. Please save all of your work." I saved my work and the machine restarted. A few minutes later, it happened again, and I called IT.
IT comes out, and looks at my machine. They figure it's some sort of virus, but it turned out to be a worm. The Sasser worm to be exact.
Machines start rebooting themselves all over the office, and my boss asks the IT manager if this will effect the assembly line PLCs.
The IT manager gives my boss a very firm, "No!" and goes on to explain how those machines are behind a separate firewall, and can't possibly get the worm.
Just as he is explaining this, the foreman comes in from the plant and says, "Hey! all of those computers out on the assembly line just rebooted themselves!"
Our IT director got very red, and went into the server room and unplugged all of the switches. We were one of the few companies using VOIP at the time, and that meant no phone, fax or internet for the whole building.
Why did we use Windows on the assembly line? I asked that my first day on the job. Corporate determined it was cheaper than running embedded devices.
The company was shut down for a whole day, costing $20,000 per minute in lost revenue. I can't imagine those embedded devices were that much more expensive.
As a side note, our IT Manager developed a heart condition at a very young age, and I quit a year later.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
Not Secure OS 2k11, it includes an epoxy substance to jam in the USB ports and floppy if applicable.
Security and vulnerability assessment used to be this poor, but that has undergone significant changes, particularly in this decade. I can't speak for all vendors, but the one we use has security testing, vulnerability assessment, and full patch updates implemented as a standard part of their maintenance contract with their customers.
They have an internal process to verify all patches on the systems they support their software on (RHEL, SuSE, Windows Server 2003, 2008, Windows XP and Vista, with Windows 7 certification coming) and ensure they do not break the SCADA servers or clients, and they release this information to their customers relatively quickly (we usually are about one month behind, implementing patches that've been vouched safe within about 30 days of the patch release, but this process is faster for zero-day and other such critical things).
They do not "assume" anything for their customers. However they do strongly encourage air-gap, and frankly so would I. A SCADA system controlling the power grid should never have an Internet connection. It should never need one. If it must have this, you have something seriously wrong with your design.
Furthermore, I would add that recent (within the last two to three years) updates to CIP and NERC compliance specifications actually require patches to be kept up to date, and also require you to full document the fact that you have patched your servers and workstations. If you have not applied a patch, you must have documentation explaining why (this is why our vendor has their patch vouching program, so you have documentation on why they said don't install something). There are very heavy fines for not implementing this, and can even lead to certification revocation, which means you can't do business.
There's no OS that does not crash or stop working for some time interval. It's not Windows' fault that operation back then was paused, it's architechtural problem. Whatever OS they would use, with that mind, they would have similar hold backs.
I work in support for Wonderware, which unfortunately, is in 33% of production facilities worldwide. It only runs on Windows, then there's iFix, GE's HMI software, Autosol and Standard Automation products running on windows... A GE DCS may run 'nix, but it reports to and is queried by a WinPC. I think it's probably more 75%/25% in favor of Windows for SCADA systems.
Anyone using Windows for anything essential needs to re-evaluate their software choices. How many times have we heard the story "Malware targets flaw in Windows"?
Help me fix my brother's injured butt!
They should avoid holding the USB drive that way.
If the reliability of an embedded system is 1, and the reliability of a Windows system is i, then the modulus of the reliability of the two systems is the same.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
really you are asking the wrong questions. They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too. The question isn't "why were you using windows", vulnerabilities exist in all OS's. The question is "Why the fuck were they not patching known vulnerable systems that are mission critical?" Patch for sasser worm was available well before the worm, secondly "why the fuck if they had a reason to not patch vulnerabilities were they leaving their mission critical devices exposed?".
What you describe is a massive failure on the part of the IT staff.
Power stations (including nuke ones) use SCADA for control systems. Not the kind of stuff you really want to be infected with malware. Sure, the odds of anything really nasty happening is slim (it does happen though - the main Japanese nuke power station has accidentally vented radioactive material into the air in the not-too-distant past). The most likely event is a shutdown, followed by a blackout of a region. If there's a cascading effect, it might even take out a whole State until they reload the computers from backup tapes. Uhhh, they DO have backup tapes, right...?
It bothers me that insecure OS' are being used for any kind of control system. Microsoft is only partly to blame, though. The high cost of real-time and "trusted" Operating Systems (which would have been far better choices) is also responsible. If a mission-critical industry genuinely couldn't afford mission-critical OS' for mission-critical components, something somewhere got SERIOUSLY messed up. (You'd want a real-time OS for components that need a specific response time, and trusted OS' for components that interfaced with stupid operators and the outside world and therefore needed the higher level of security.)
It's unclear if manufacturers would have been permitted to offer a special deal, though, for such organizations on what amounts to an emergency basis. There would be all kinds of anti-competitive rules invoked. It would have required special dispensation by the legislature, plus approval by "Homeland Insecurity", to eliminate such dangers on a legal basis. Even then, it's unclear if such laws would have held much sway with the Supreme Court makeup as it stands. Basically kicking Microsoft out of an entire sector of industry would run very counter to free-market ideals no matter what the potential consequence. The judges are so old that they're very unlikely to ever see the consequences of their decisions so why should they give a flying f*** if there are any?
(I'm not saying those ideals are necessarily wrong in the market, or necessarily wrong in general, but when you try to mix them with a large dose of complacency, a larger dose of greed and a huge dollop of obscurity+secrecy, there isn't a free market for those ideals to operate in anyway. Trying to make those ideals work in a context they were never designed for is where you get problems.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Somebody obviously doesn't know what SCADA is used for in this day and age.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
This is awesome. A major 0day? They stole the signing key from realtek? And it's not like you can instantly invalidate those keys without major hassle. I wonder how many other such "cert" keys have been stolen over they years.
Besides that, why code an interface specifically for Siemens SCADA? One question you'd have to ask is, does that system have marketshare for the control systems of any specific type of thing, or is it generally just popular in industrial automation? I can't find anything specific online, besides advertising writeups about factory control.
Emotions! In your brain!
Windows' reliability can only be expressed as an imaginary number?
Thanks, that explains a lot!
See this link for what can happen to your SCADA systems - total distruction
This issue is a bit more complicated than you think.
More like anti-virus scaremongers.
Only because so many people don't want to understand the computers they use and it is easy to make them buy into the fear of what they do not understand, especially when you have the credentials of expertise. On their shallow level the anti-virus people are technically correct. It is their approach that is systemically flawed. They have no interest in removing the suscpetibility to viruses so they continue using technically correct ways to advance the arms race of malware creators vs. anti-virus companies.
It's like the pharmaceutical companies - they have no interest in promoting natural, drug-free remedies even when these are available because they make more money in a nation of sick people. Antivirus companies make more money when over 90% of PCs use a platform that continues to suffer from the same kinds of flaws that plagued it 15 years ago. You do not trust untrustworthy content and that doesn't change whether it's ActiveX, automatically running scripts in remote e-mails, floppy drives of yesteryear, or USB drives of today. How many iterations of the same principle does Microsoft need before they get it? The code that handles such data needs to be some of the most security-hardened code in the system, against both design flaws like deciding to trust remote e-mails and against implementation flaws like buffer overflows.
They don't get it because they don't want to get it. This helps them sell the next version of Windows that promises to be more secure than ever. This helps the anti-virus companies sell the next version of their arms race. You think they're helping you? They're helping themselves to you.
Posted anon to preserve moderations.
The funny thing is that I work with a lot of GE products. After getting on a first name basis with their tech support people, I know that their programmers are definitely not the sharpest crayons in the box so cracking their software shouldn't be too hard. However they did buy iFix recently and I haven't had a chance to peek the hood of that product so perhaps to might be better than average.
I am Slashdot. Are you Slashdot as well?
So looking at some of the linked info it appears that this is targeting a Siemens SIMATIC WinCC Database. It appears that the database uses a hardcoded username and password combination that end users are told not to change. I found some forum postings from people who made the mistake of changing the password only to have the software fail.
Server=.\WinCC;uid=WinCCConnect;pwd=2WSXcder (+1 for what appears to be a reasonably random looking password, -1 for being short, -1 for not including symbols, -100 for hardcoding it into the app and forcing all users to have the same exploitable entry point into their embedded database that this worm can use to read and inject code into the database)
https://www.automation.siemens.com/forum/guests/PostShow.aspx?PostID=16127&Language=en&PageIndex=2
Product being targeted:
http://www.automation.siemens.com/w2/automation-technology-distributed-control-system-simatic-pcs-7-1075.htm
Seems pretty clear that this was a targeted attack. (Launched by Competitor, former employee, etc)
The actual consoles where the operators sit are about 90% Windows though, if not higher, and that's most likely where you're going to see this virus come into play in the first place because of some stupid user plugging in an infected USB device.
And then the virus rootkits the control console. It can then issue commands to the SCADA systems that appear to be from legitimate operator input.
Back when I worked for Boeing, we fought a loosing battle trying to keep Windows systems off the shop floor. In an ideal world, we would have a secure subnet within the company Intranet behind its own firewall to keep the Windows systems from seeing shop equipment. In the real world, lots of the factory equipment was running Windows. Worse yet, some of the people responsible for loading firmware into avionics used Windows laptops to do so. And then they'd take them home at night where the kids would use them to log on to Facebook, or download kewl stuff from unknown sources.
You can't fire people fast enough to keep Windows out of misson critical areas.
Have gnu, will travel.
It's only after every single motherboard started to include on-board networking that Realtek stopped being relevant.
Not sure if you realize it or not, but 90%+ of all motherboard onboard NICs, are made by Realtek.
Don't believe me? Check your lspci / Device Manager.
Every automaker in the US uses Robots controlled by SCADA apps on Windows machines. This is standard practice. Take a look at your Ford or Chevy the next time around. Hell, Ford liked Windows so much they made a few cars with Windows OS standard.
Considering the reliability of Windows...I'd probably choose to deploy one of the FOSS HMI systems over the commercial ones.
It doesn't matter if you build a fortress- if you build the same on a foundation of shifting sands.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Go check out the Smart Grid Interoperability Standard over at NIST sometime...
They're doing it all the time.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Considering the reliability of Windows...I'd probably choose to deploy one of the FOSS HMI systems over the commercial ones.
It doesn't matter if you build a fortress- if you build the same on a foundation of shifting sands.
Can you furnish any links to any decent/competitive FOSS HMIs? Because building a fortress out of mud doesn't appeal to me when I can user armor plating for my fortress. Also I don't think you have a very realistic appreciation of Windows reliability .. (not that I am a fanboi - typing from my Mac) , just that I have worked on lots and lots of commercial systems running windows.
I am Slashdot. Are you Slashdot as well?
really you are asking the wrong questions. They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too. The question isn't "why were you using windows", vulnerabilities exist in all OS's. The question is "Why the fuck were they not patching known vulnerable systems that are mission critical?" Patch for sasser worm was available well before the worm, secondly "why the fuck if they had a reason to not patch vulnerabilities were they leaving their mission critical devices exposed?". What you describe is a massive failure on the part of the IT staff.
Vulnerabilities do exist in all OSs but that statement of the obvious doesn't enlighten anyone or help anything. There is more to the picture. This certainly could happen to a *nix shop, in the sense that I know of no laws of physics which would make it impossible. However, it absolutely tends not to happen in a *nix shop and there are reasons for this. Here I say *nix because it's one of the leading alternatives to Windows, but really by that I mean Unix, Linux, QNX, or any number of systems better suited for such a purpose.
The lesson here is simple enough: companies that hire incompetent IT staff which commit massive failures choose Windows, even in an environment where another tool would be better suited for the job. Desktop workstations for office workers, assuming a managed environment? Windows is a good choice there. Critical back-end servers or control systems for mission-critical machines? Windows is one of the worst choices you can make for this.
Besides, IT staff who are aware of alternatives to Windows, as in actually have expertise or at least competency with adminstering both Windows and non-Windows systems, would also tend to be aware of the need to patch known vulnerabilities and the high desirability of isolating critical systems wherever this is practical. In a diverse world of many tools for many jobs, the self-proclaimed "experts" who truly know one thing and one thing only tend to be the least competent. So it is with Windows shops full of "admins" who would be completely clueless and helpless if they were placed in front of a non-Windows system.
Windows' reliability can only be expressed as an imaginary number?
Thanks, that explains a lot!
Better yet, if you have a 2 independent systems running at the same time mirroring eachother, the odds failure is the odds of both of them failing at the same time.
(1 - i)(1 - i)
Or 1 -2i + i^2
And the reliability is thus
1 - [1 -2i + i^2]
Which is 1 - 2i.
Get a pair of pairs...
1 - 4i^2 = 5.
Four Windows boxes and you've got a reliability of 500%!
Ok, I am never flying on a Boeing again. Or any other aircraft. And given that modern computers on cars now use regular ethernet and unsecure protocols (see the papers on successful methods for injecting false commands to the engine and braking systems), I'm going to stay clear of the roads as well. Hell, just get me a Dyson Sphere on some star in some remote galaxy - and a wormhole so I can continue reading Slashdot. Gotta have Slashdot.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The reliability sucks if you're running Wonderware, the crap has several serious bugs one of which will cause several ethernet drivers to crash. It in essence is a ddos. I grant that the controller should not crash. Almost all of the controllers I'm aware of it effects have been patched. Yet Wonderware has not deemed it necessary to correct this and is still pumping out flawed versions of their software. Even if that were fixed you would still have an unreliable system because while their HMI is very good their communication drivers are barely usable excrement.
http://global.wonderware.com/EN/Pages/default.aspx
Heck with Windows, the guys building planes don't even know the difference between lose and loose! Did you loose a nut or was it just lose?
The trend now is to run Scada systems in windows machines, but the reliability is not the same.
Do you have anything to support this, because my experience says something else.
My whole point was, the fact that it was windows in his story was incidental. The entire story was a saga about incompetent IT admins, yes they probably exist more in the windows world due to the perceived ease of use, but I see almost as many badly run *nix environments, hell I am working in a badly run *nix environment at the moment that would be just as susceptible to such a disaster.
Re: CIP (CIP-007 R3), the standard actually requires
R3. A patch management program
R3.1. Patches be assessed within 30 days
R3.2. Document the implementation (usually interpreted as an implementation plan) and install the patches or mitigate
There is no requirement on the timing of installing the patches in R3.2, only that assessment be completed in 30 days.
As a result, certain utilities are very legally setting the install plan date for 2013. When they get the opportunity to install, they then update the plan the week they install and document the change. In the interim, they put together a document that shows that IDS, AV, Firewalls, or something else similar mitigates the attack.
While crazy in the desktop world, most control systems cannot be updated without shutting down generation plants. Transmission has a slightly easier time of it but not much. Shutting down generation during peak periods such as heat waves or blizzards are a worse choice than patching as long as decent security is in place. Major upgrades such as O/S Service Packs and SCADA/DCS upgrades only have an opportunity maybe once a year during planned maintenance shutdowns. This is true regardless of the OS ('nix, Windows, VMS...)
Yes, certain vendors are very good about updates (Wonderware and similar) and others are very poor. They are all getting better but there is no way I would patch most systema on running coal or gas turbine generation plant. Risks are too high on environment and life safety. A loss of the control system can result in a plant shutdown or scram. A problem control system can put safety at risk because the plant is running and improperly controlling.
More of a problem is the proprietary hardware, especially on DCS systems. While no direct user interface is present, these systems are never patched, run hidden or semi-proprietary OS's. Worst case I know of is a DCS board that allows remote login with a known unpublished ID/password.
At least today, virtually every control system is behind an internal firewall and the majority have a decent firewall configuration. However, the value of communicating out of the control system outweighs the risk. Especially when running 15 power plants in a major utility and the power supply/demand balance on the grid is more important than air-gapping. If air-gapped, high quality frequency control at 60 Hz would be near impossible.
When I worked at NASA, there were certainly nuts on the loose.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Because any OS can be cracked given enough time and determination.
"But this one goes to 11!"
I'm an unemployed Linux Admin...
Same here. 13 years of IT and I just gave up because of corporate morons. $4million for peoplesoft, $70k for Microsoft, the list of waste goes on.
I agree with the first part of that last sentence, and I suspect that if you asked people, they too would claim that Windows is easier to understand and use....
... But you'd all be wrong.
The plain fact is that Windows is simpler in places where simplicity actually hides essential knowledge. Say what you like about Linux/Unix being harder; the fact of the matter is that it's no harder than it should be. The Windows UI, on the other hand, definitely is simpler than it should be.
Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.
The problem, in short, is not that Linux/Unix is too hard. The problem is that Windows pretends to be too easy.
Crumb's Corollary: Never bring a knife to a bun fight.
I doubt the SCADA apps are *controlling* the robots, standard practice is to have the PLC control the equipment. If you are writing control logic into your SCADA app you probably should find a new line of work.
The funny thing is that I work with a lot of GE products.
Sorry to hear that, if I ever catch up to you in the field I will pick up your bar tab.
Tim?? Is that you?????
Mr. "Please refer to Tech Note #234." ????
SCADA systems are generally not based on an "embedded device", so I fail to see how this comment is insightful.
Where I work the SCADA system is generally used as a HMI system with the support for trending important process variables. The PLCs actually perform the "control" aspect, and the operators only control a limited subset of the process through the SCADA system.
If the SCADA system was to go down (which is does slightly more regularly than it should... yes, it runs on Windows), process control is still handled by the PLCs (unaffected by any sort of malware... that I know of) and if something was looking like it was about to go wrong, then the PLC should be set up to deal with it... not the SCADA system.
That's not what SCADA should be used for.
Oh come on, that's easy - it's used for swimming underwater and looking at whales and things. Like Jacques Cousteau. Right?
Faster! Faster! Faster would be better!
Yes, but your experience at marketing Windows means you HAVE to say something else.
"I've got more toys than Teruhisa Kitahara."
I used to work as a system administrator for a 911 call center (Fire/Ambulance). They had been using a unix system, but the vendor (Intergraph) went all stupid to windblows only. So fire and ambulance dispatches with windows. Bad thing... time is really important on these systems... when was the call taken, when was the fire truck/ambulance dispatched, when did it arrive... lawyers like to subpoena records with this information..... minor problem.... windows (like all crap microsoft) has had really really shitty NTP service (at the time they recommended using 3rd party ntp software. FUCK! Oh, and not just that, they had these systems pushing serial data through (a really old) modem network through dedicated leased lines out to RTU's (Remote Terminal Units) in Fire Halls and Ambulance stations to activate station alerts/PA turn on lights, roll up bay doors and send data to printers so crews get a printed address along with getting it over the radio and PA. The serial data to the RTU's were all SCADA (they also had local control software, which used a basterdized version of the Server Message Block protocol). The only other really dumb thing that happened that I had no say in was allowing this system to access the wider internet. I left. I found out later that after cleaning and de-virusing all of it (oracle databases too), that it became a local (local only) area network. So stupidity is live and well.
Seriously, everybody is using Windows to do SCADA. Almost every HMI SCADA package runs Windows. Citect, WonderWare, WinCC, Proficy, etc. All windows.
They are also perfectly capable of being 100% reliable. All the above packages support dual redundant servers. I can't think of the last time a pair of servers in a production environment fell over. I vaguely remeber some blue screens of death back in the mid 90's.
The control side of SCADA, ie, PLCs, RTUs etc, they obviously don't run Windows, or any operating system, in the normal sense - they don't have an OS that you install and run apps on. They're essentially just a single purpose appliance. They're very proprietary and very expensive, which is a good thing (Allen Bradley, Modicon, GE Fanuc etc)
The only time I've seen SCADA systems go bad is when corporate IT people get involved. IT people and SCADA don't mix. SCADA systems need a big firewall between their world and corporate IT departments.
I've also seen unix based SCADA systems that are unreliable. GE's Enmac system, which is used to control power networks comms to mind. Unix has helped it be stable at all.
That said, the SCADA world would be a nicer place without Windows.
Sorry buddy, but you got it wrong. This problem doesn't affect Linux based systems. I can plug my usb stick into my computer and I'm not affected by this. Everyone. EVERYONE using microsoft is affected by this. Its not a matter of proper patching or not. This is another newly discovered flaw. It was discovered because microsoft didn't test their software prior to shipping. No other operating systems are affected by this. Only microsoft. And not just 'whats a patch?' systems, but all of them. This affects every microsoft system, including yours (as someone defending them, I assume you are beholden to them for you income, and are rubbing patch disks between your legs right now). This problem affects microsoft. Not Linux, not solaris or aix or solaris or bsd or plan9 or system36 or ultrix or vms or vm/cms or mvs/xa. Even systems patched up to this very second with all the patches microsoft has are affected by this. Its a microsoft problem. Don't speculate or say 'just as likely'. Thats bullshit. I don't use microsoft, and I'm completely unaffected by this. Only microsoft is affected. They are the only ones. Quit blame shifting. Its a microsoft problem. Its not a linux problem. Its squarely a microsoft problem.
Until they all reboot at the same time for some windows updates.......
The vector is the windows machine that is networked (stupidly) to older non windows boxen that do the SCADA work.
In theory, an attacker could manipulate the SCADA machines and cause disruption.
I worked with non-windows SCADA systems. Any windows boxes operated with proprietary software and proprietary communication keys. Without the keys, you have nothing. If any dickwad engineer insisted on windows communications, they deserve exactly what they get and I hope it's a Dell.
The mind conceives, the body achieves, the spirit manifests.
Actually at least from experience I'd say Comodo gets it. I have relatives that can end up with more viruses than a Bangkok whore and Comodo keeps them squeaky clean, and cost nothing to boot. I like how Comodo has a built in sandbox and unless you tell it to otherwise will automatically tell you if an installer tries to run and sandbox it. And with the full firewall+AV I'm only using about 28Mb, so it isn't a piggy like a lot of them
And when combined with Comodo Time Machine which is also free I don't have to worry about my GF or family borking their PC beyond repair. It takes snapshots automatically and it took me less than 15 minutes to walk my GF by phone into restoring from snapshot when she'd somehow corrupted Win32.dll during a power loss. Really handy.
As for TFA I doubt it would matter which OS the machine was running, since this is a targeted attack on a very specific kind of system. If the malware writer is gonna go to the trouble to target such a niche system then they could just a easily target whichever OS it was running. Sadly no matter what the OS it always comes down to PEBKAC, and if they are crazy enough to run untrustworthy flash sticks on their highly important system I think they got bigger problems than malware. It takes..what? 3 minutes to boot a Linux live CD and wipe or scan a small flash drive?
ACs don't waste your time replying, your posts are never seen by me.
Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.
For example ?
Yes, there are open-source HMI projects available, but try convincing someone to deploy a life-critical system using one of them.
That's the first time I've seen alpha software with a "This may kill you and everyone around you" warning that was literally true.
It's not a great confidence boost when you're thinking of switching from the commercial solution which I am sure makes plenty of soothing cooing noises about its safety.
Why do you presume an embedded system would even have an OS?
That probably had something to do with it. Yes, I'm sure you could have a second (or third) redundant machine on the assembly line so you could reboot each machine in serial as they're patched and verified to work--a procedure that'd have to be carried out on the order of monthly (and some times randomly on top of that) which seems unreasonably excessive for such a niche application. Or, you could use an embedded system that doesn't have an OS. Or you could use an OS that's small enough that no exploitable vulnerabilities exist because even if a vulnerability exist, you can do enough test cases (and hardware parity/checksum/crc) to verify that software always reacts properly under all possible valid inputs and always fails safe with all possible invalid input, provided the input size is forced to be limited enough.
How about "why the fuck would you use a general purpose OS with millions of lines of code to do a task that ten thousand lines of audited code could do instead"? My guess? Management thought it was cheaper and some IT people thought firewalls were magic that would remove all patching concerns.
No doubt. In management too. At best, they're responsible for hiring IT staff stupid enough to choose to rely upon Windows and a firewall. At worst, they're the ones who forced such a solution on IT staff and selected IT staff who believed it'd work.
Eurohacker European paranoia, gun rights, and h
eh, Windows Embedded is an embedded OS
Windows Embedded is a Windows OS, not an embedded OS.
Contrary to the popular belief, there indeed is no God.
I used to work for a SCADA company our practice was to try to encourage (and was usually successful) to get the customer to cut the ties between the outside network and SCADA control system. Most system designs would often include an extra box with an extra link for an operator to access corporate email, internet, etc
That wouldn't preclude someone slapping something on a USB and taking it over..but why?
Is this from your experience of working in the Comodo sales department?
Are you sure you don't want to buy the extra protection of the Pro edition? That's a nice computer you've got there, it would be a shame if anything bad happened to it. Remember, the early worm gets eaten.
This is why I told my father to fight to have the SCADA system in their plant physically unconnected to the rest of the network. There is nothing funnier than an overheating reactor when the control PCs are in a reboot cycle. (Yes, there is the Big Red Button[tm]. But pressing this button results in $$$ damages to the equipment, so this is *really* only a last-resort-trying-to-avoid-the-big-boom sort of button)
"Windows recently downloaded and installed an important security update to help protect your computer. This update required an automatic SCRAM of your reactor."
Finally had enough. Come see us over at https://soylentnews.org/
really you are asking the wrong questions. They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too. The question isn't "why were you using windows", vulnerabilities exist in all OS's. The question is "Why the fuck were they not patching known vulnerable systems that are mission critical?" Patch for sasser worm was available well before the worm, secondly "why the fuck if they had a reason to not patch vulnerabilities were they leaving their mission critical devices exposed?".
What you describe is a massive failure on the part of the IT staff.
Some years ago I was working in a department of a Telco which was responsible for about 500 critical servers. Out of those about 50 where Windows boxes used mainly for integration with the dealer network. We got a worm the same morning it was first publicized, before there was even a patch available (and you have to be kidding yourself if you think "24/7" systems behind a firewall will be patched the day the patch is released)... The 50 Windows machines caused our department much more work then the 450 Solaris / Aix boxes even though we did not even maintain the Windows machines our self (just ordered and coordinated the changes).
... hoping to become an unemployed UNIX admin.
Seriously, anyone using Windows for SCADA in this day and age has to get their head checked.
While I couldn't agree more, anyone out there running something other than windows for SCADA.... please give me a list of your vendors. You make it sound like we have a grand choice. At our plant we have vibration monitoring systems where the software runs on windows and directly administers the system, and all of our HV switchgear control software runs on windows. About the only system we could buy now that doesn't run on windows is the vibration monitoring system from B&K which runs on ... SCO... I shit you not; and I'm not talking about some old version, we only bought this thing like 6 months ago. Oh our Distributed Control System runs on Solaris. YEAAHHH! Except that we're in the process of an upgrade and all the new software runs on ... Windows.
I was saddened and when our DCS vendor was out here I asked them why. Their answer: "Hardware for Solaris is expensive thanks to licensing, oh and all our competitors run it too" Emerson's DeltaV DCS runs on windows, Honeywell's DCS runs on windows, Invensis's DCS does too and so do several others from the smaller players. It's not like we can vote with our wallets or something. I mean even if there was options vendor lockin makes it impossible to vote with the wallet. It's not like one can suddenly change the control system of a plant.
You had better get started checking the heads of the entire industrial automation landscape.
They do not "assume" anything for their customers. However they do strongly encourage air-gap, and frankly so would I. A SCADA system controlling the power grid should never have an Internet connection. It should never need one. If it must have this, you have something seriously wrong with your design.
It's often not a design problem but a constraints problem. Managers want it cheap, and then want it user friendly. This typically means engineers need to be able to get full diagnostic access to the equipment without moving from their desks, and laying a dedicated fibre to each substation is out of the question. More than likely you're going to end up with a system of independent networks, a control network (for control), an information network (for engineers), and a general network (where the engineer's actually are). This in itself works quite well as long as data is NEVER allowed to move back up the line to the control network. But you'll find in most industrial process networks there is a series of cables which will ultimately lead to our world wide series of tubes.
.... ADSL.
And then the low cost comes into it. I have seen sites where a dedicated copper line leased off the local telecoms company was replaced with
Considering the reliability of Windows...I'd probably choose to deploy one of the FOSS HMI systems over the commercial ones.
It doesn't matter if you build a fortress- if you build the same on a foundation of shifting sands.
Not if your FOSS HMI could only read half of the tags needed (N and F) and the functionality of writing values to the PLC was listed on their webpage as being slated for implementation in 2004(which was the latest news).
I thought the same thing when I first observed my company's control system.... The answer was obvious when I looked for a FOSS alternative. Features that were common in the early nineties were far off in the latest stuff I could find.
With a few notable exceptions (ABEL-abandoned, PyOPC-active, TuxPLC-abandoned); Industrial FOSS is severely lacking. Not a rip on FOSS...the industrial side is pretty sucky when it comes to standards and openness. OPC is a great example of an "open industry standard" that isn't. Lots of proprietary #$%. Meh; this ended up a semi-rant. I'm out.
I'll believe in corporations having personhood when Texas executes one... - advocate_one
Why do you presume an embedded system would even have an OS?
Control. Plain and simple. The embedded code running GE's vibration monitoring is administered from windows. The embedded code in the distributed control systems of all the major vendors (Invensis, Emerson, Honeywell just to name 3 of the top companies) is not only administered but actually controlled from windows machines. The emergency shutdown systems from these majors also are administered from a windows interface.
Good network design and security policies will go a long way, but you're living in fairy land if you think you can control a sizable plant without some windows servers. A lot of companies are even moving TO windows. Invensis's DCS used to run on Solaris, but I have even seen one of the computers controlling the mesh network with a bluescreen on it (redundant computer took over in that case but it didn't make me sleep any better).
Its been my experience that the competent technical workforce is all for unix. However, the high level directional decisions are made by people who either used to be technically competent and aren't anymore now that they have run off to management, or were promoted into management because of lack of competence technically. These people are the ones that love powerpoint, word, excel and outlook, and think that since microsoft works so well for them that it will work everywhere.
Starting to wander a little off-topic here but I couldn't resist one more answer. :) I wasn't aware of the lack of timing requirement, hmm. Certainly our company didn't interpret it that way, so we're actively implementing patches on the month-behind schedule, and this includes our control systems too. We can do this because every server type (data ack, database, human interface server, etc) we have operates in tandem with an identical twin, in standard failover configuration. So we patch the backup, and initiate a controlled failover to it. Problem? Fail back. Works? Patch the other side now. This is how most every SCADA control system I've worked with has operated, even the old 1970s paired-mainframe-based system we had at the company when I first started here.
;) I didn't mean to imply it operated in a vaccuum, totally networkless. I merely meant air-gapped away from the Internet specifically. Communications between facilities is indeed vital, it's just that going the Internet route to achieve that is flat out "wrong" and really, I think should be completely banned, by regulation or otherwise.
We are a central control center though, the HQ for utility company as a whole, not an individual generation plant. So our system setup may indeed be very different from the individual plants we operate, so I can't speak for how the plants manage their DCS control systems directly. Our major SCADA upgrades though are on a yearly basis, unlike OS patches.
I see a few people all replied to my air-gap comment, but I'm lazy and don't need to make three replies!
We do indeed have inter-facility communications all over the place, to all of our various power plants we operate and control, to all our individual substations, all that stuff. However, it's done via private networks. We have our own microwave communications system licensed throughout the state and probably 90% of our communications to our assets is via this. The rest is through dedicated leased lines. We also communicate realtime with the state's central control authority, and that's done via a private frame relay circuit that THEY actually had installed at our facility (along with their equipment) because they actually require this from all utilities under their authority, to communicate to them. They did it right, basically.
process control is still handled by the PLCs (unaffected by any sort of malware... that I know of) and if something was looking like it was about to go wrong, then the PLC should be set up to deal with it...
The PLCs I'm forced to work with (that happens to be from the same manufacturer that produces the POS that's WinCC[*]) can be networked and, as soon as you connect them to a network, you can control them (as in, modify the program, start them, stop them, the whole lot) remotely.
The communication is not encrypted and it's not password protected[**], so anybody that can obtain access to the network (and that's not very difficult in many factories, especially the very big ones) can control them at will.
[*] and other manufacturers aren't better
[**] there's a password protection, but it's enforced by the programming software, not by the PLC itself. You just have to use your own program, using the reverse engineered communication protocol and you're set.
I recently did installation work at one of the largest gas processing plants in Norway.
The control system HMI runs on OpenVMS, the controllers are on a redundant token ring network. (good old coax).
All the control room clients are winxp sp2 with almost no patches. This is required to have the HMI applications work. They also need to be set to 256 colors to get blinking effects (critical in such a system..).
Will the system be replaced with something newer? Not in a few years. Stopping the plant costs 23 million USD per day just in lost sale/production...
Now... have there been problems with these vulnerable machines? Nope. Not ever. Control room personell know not to fuck with the clients and behave... They are running a multimillion dollar plant and fucking up is not something you want to do.... You dont mess with the system.. EVER.
The story describes what I consider an HR issue, not a technical one...
Why the fuck were they not patching known vulnerable systems that are mission critical?
You raise a good point. I seem to remember an issue where the control software had issues with several patches. After a few patches took down the plant, I think they decided to stop patching the system.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
LOL! No, we don't have a "Tim" here. But we do love Tech Note 454 when someone totally hoses their system(s).
You raise a good point. I seem to remember an issue where the control software had issues with several patches. After a few patches took down the plant, I think they decided to stop patching the system.
P.S. I don't like to name names, but this was a Siemens system. The very system the malware in TFA is targeting.
Coincidence?
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
I'm a software engineer who works with my company's manufacturing division to build systems that collect, analyze, and display data on various parts of our manufacturing process. I also function as a systems administrator for some of our off-the-shelf ERP and Data Historian stuff.
Hate to break it to you but the whole OPC/SCADA universe seems to be built around Winderz.
Believe me, I tried to find Linux/Unix-based offerings as I'm much more comfortable with the idea of *nix on a production system for which I have to provide 24/7 on-call coverage.
Even if I could have found something I felt good about, our entire IT infrastructure is so Windows-centric that it would have been a damn hard sell.
To tell you how bad things can be: the default implementation of the ERP system we use actually includes licensing for and INSTALLS ORACLE RDBMS ON A WINDOWS BOX. That's right, they wanted to run our entire ERP system from a Windows box running Oracle. This is STOOPID and I actually won the fight to get our company to buy our own Oracle and put it on a RHEL server. It causes headaches every time I call the vendor for support as they just are used to the DB being on a windows box, so all their procedures and KB docs tell them how to do things on windows. I usually just tell them to tell me what they want to do and I'll do it for them
Ok, I got off track.
Point is that manufacturing seems to be entrenched with OPC which originally came for OLE for Process Control which is pure Windows DCOM-based stuff.
It's horrid, but it's the de-facto standard.
Why, in this day and age, are SCADA units still accessible from the public InterTUBES ?
Slammer worm crashed Ohio nuke plant net
Software failure cited in August blackout investigation
Did Blaster worm play a role in August 14 blackout?
"I used to work for a SCADA company our practice was to try to encourage .. to get the customer to cut the ties between the outside network and SCADA control system"
What company was that and why didn't you build in such functionality by default. Sounds something like a VPN running on embedded hardware?
"The only time I've seen SCADA systems go bad is when corporate IT people get involved. IT people and SCADA don't mix."
Do you have any citations to real world examples?
"SCADA systems need a big firewall between their world and corporate IT departments."
The function of a firewall is to block access to processes using certain ports on a server. By not running unnecessary services you render a firewall unnecessary. Besides which in this day and age of RPC-over-HTML, a firewall is rendered next to useless.
"Totally useless comment. An attack on a SCADA is a targetted attack. If you are running it on another type of OS, the attacker will simply write it for that OS. This isn't a SPAM dude. This is a directed spying attack.
Embedded systems are more secure than ones that you can write to. Of course then leaves in-memory attacks, which are a great deal more difficult to successfully carryout. Troubles with embedded-Windows is you don't really know what's running under the hood. A minimalist system capable of relaying packets from A to B is all that's required.
They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too
..
Bullshit
In my experience (which includes developing a SCADA operator console system on a Windows platform), it is not because that's all the developers know... it's because the companies are run by marketing and bean counters. Customers naively tell marketing they want Windows based consoles, bean counters drink Microsoft cool-aid and think it will somehow save costs, and engineers have little to no input in this decision. In fact the majority of the software developers at these companies were forced from Unix / VAX / VxWorks systems development into the Windows world. Due to OPC, most of the systems rely heavily on Microsoft COM/DCOM and the majority of developers I know would GLADLY scrap our Windows products and welcome the opportunity to go back to the UNIX / VAX days. Even worse most of these developers were not qualified to develop on a Windows platform when the systems were rushed out the door due to marketing requirements claiming that Windows was CRITICAL to selling systems.
I work for a company who develops and deploys SCADA systems on marine vessels. I think Windows based SCADA environments make sense, however as another poster has mentioned the key is to secure the machines (as the case with ANY environment). There are many ways to secure a system, (not just the software). For example, physically make it impossible to put a USB stick into a machine would do the job. Secondly, don't connect it to the internet. Steps like these seem obvious. If you can isolate a system then who cares how many virus's are out there.....if you cant isolate a system, then you should not be responsible for its deployment! .... this isnt news....
If a company looses $20,000 a minute for downtime, is it in the IT staffs best interest to bring the assembly line down for patching? Management would most likely flip shit if the assembly line had to be shut down for routine maintenance. Hell I did a bit of contracted IT work for a company that were reluctant to patch their windows servers out of fear they would not come back up or a patch would cause their applications to break/crash.
10 Release the Hounds 20 goto 10
I will readily admit I don't fully understand SCADA or DCS or PLC and how they're implemented in the real world, but I still don't quite understand your answer. I fully understand why in general there would be a want and a need for Windows servers in such a situation, but I don't really grasp the extent of that need. If an assembly line has 20 steps to make a product, does that mean you need 21 Windows servers (one for each step and a controller)?
It sounded like, and again I could be wrong, the GGGP was speaking of having dozens of Windows or other OS systems that need to be regularly monitored and updated. If this is standard practice and from your comment I gather a necessity of the modern age, then I do find that rather disturbing. Having said that, I still am not sure I understand why Windows was chosen. It would seem that it might have a lot to do with OCP, but it seems amazing that with all the possible security concerns (and risk to millions of dollars of equipment or human life) that even if an OS was required, there wouldn't be extensive glue used to communicate with the necessary Windows server and an OS that needed updated a lot less regularly (like TRON or perhaps OpenBSD) that would be used lower down in the production chain.
Overall, I can see how your point stands, as it sounds like the system as a whole has become reliant much more on software than hardware for production and certainly some OS of some sort might be likely running on most of the equipment. Considering the statements about the vulnerability of OSs, I rather shiver to think about relying so heavily on code that is likely only proven in a very narrow field.
PS - If I completely misunderstood you and you thought I was trying to banish all Windows systems from the production line, then I'm sorry, I wasn't. I can understand why high enough level administration on a relative few servers which can be properly supported by an IT staff could be a reasonable expectation. I find it difficult imagining updating and checking dozens or hundreds of Windows systems attached rather directly to large machines, where even a small glitch in the change of output of a program as a result of a security patch could do very bad things; but, then, I guess that's true no matter the level...it just seems a more manageable thing to control at a single point where one can heavily test under a varied limited range of input/output.
Eurohacker European paranoia, gun rights, and h
Uhhh... to you and the moron that modded me redundant.,..did you not notice the ABSOLUTELY FREE part dumbass? who in the fuck is gonna shill a 100% FREE product? Does that make ANY fucking sense at all to you? The PRO is ONLY for enterprise, which means unless you are running a domain it doesn't apply to you.
So before you start screaming shill while don't you at least read the fucking post dumbass, where it clearly says FREE. And I have never worked for Comodo or any other AV company, I'm just a repairman that sees more viruses in a day than you do in a fucking lifetime, so I know what works and what don't. Moron. Now mod THAT bitch. I'm so sick of this place looking like 4 chan, with a good 70% of the posts being pathetic anon cowards. Fix your fucking system slashdot!!!
ACs don't waste your time replying, your posts are never seen by me.
I think we're both talking about slightly different types of SCADA control. A production line with 20 surely wouldn't require 20 servers. Probably two servers, and two computers though. The backend server to handle requests, a backup in case server one goes down, a computer which serves as a front end for the controllers, and a computer which serves as a read-only front end for engineers and techs.
This however is only for user input such as sending commands to the control system, or updating the control system software. In reality the actual nitty gritty control of nearly all SCADA is still run by very highly specialised embedded logic.
The companies I used in the example are very typically found in larger more complex plants though in theory can be used for very small control as well, I'm not sure how well licence costs scale for small plants. But as an example for a large scale plant like a 100000 barrel per day refinery there are 6 operators, each working on 2 computers for control. These computers connect to multiple redundant windows server which issue commands to the control system (change in set points, requests to open valves, or start sequences etc). In the back room there's another 4 computers which are used by the people who administer the network and are used to make modifications to the control system interface and basic changes to the control system. Somewhere there's another group of computers which are remotely accessed to make changes to the software embedded directly in the PLC. All of this sits directly on the control network which is behind a router that strictly allows one way communication out. A few more windows machines sit on the network which monitor the mesh and pull out vital statistics such as how much network traffic is moving between the distributed parts of the control system.
Now outside this network are another 3 computers with 6 screens giving read only access to the control system for the engineering staff. These computers also allow remote access out of the network (via another firewall) so the displays can be seen over the internet.
These all run a mix of Solaris and windows and ultimately will all move to windows thanks to the vendor making Solaris obsolete. While windows may not directly control any of the physical equipment on the plants it is used to issue commands to and from the control system. Embedded solutions fall down on the interface level, meaning it's all well and good for a SCADA machine running a single robot to have no computer controlling it and local control only, but as soon as you have more than 2 or 3 of these machines a computer is bought in to provide a common display to operators issuing commands to the individual controllers on the machine.
What I described is also only the control system. We also have a separate shutdown system almost as complex but with with no displays there are only 7 computers which are used only for maintenance to read values from the system and override parts of it. These are strictly off the network, but there would be scary consequences if a virus specifically targeting that software got on the machine. Then there's also vibration monitoring from multiple vendors which works the same way, each critical large machine basically has it's own governor with yet another windows based interface hooked to the control system, and ultimately it never ends.
Really I'm quite on your side with regards to not liking it but the reality is it exists and thus needs to be managed. A few things to note about this management though:
- IT do NOT touch the control system. They have nothing to do with anything beyond the one way router from the plant network. The administration of that is specialised, and often you'll have contract staff from the vendor permanently on site helping the administration.
- Windows updates don't get haphazzardly applied on patch Tuesday. There will be months of testing on the simulation machines before a patch is even considered. Remember one way router and
If they had Linux PCs correctly configured for assembly line work (i.e. only components necessary to that work installed, firewalls on PC as well as network, etc.) how many holes would have been left open by a failure to patch?
How many would have been left open on any other embedded device OS?
Wow, 500%... and to think I would have been happy with a mere 100%
True enough as far as it goes. Not properly maintaining any system is a problem. The firewall should have actually prevented the spread.
However, Linux and a number of other OSes (NOT Windows) make it a lot easier to produce a dedicated install with a minimal attack surface (no ports you can't close or services that you can't shut off and uninstall.). The question is why would an industrial control system not be stripped down to essential services. Why was anything there even listening to port 445 or 139?
People are moderating above post as funny. In fact, a Microsoft Security Update really did shut down a nuclear reactor.
Nuclear reactors are vulnerable to shut downs caused by network, malware, and "normal" Microsoft Windows related issues. See: malware shutting down a nuclear reactor, and network trouble shuts down a nuclear reactor.
At the plant where I work, the control system run a very customized version of RHEL and the control room clients runs Windows. These machines will probably never run everything else than Win XP SP2 (and the system estimated lifetime have more than 15 years left. And as you say, there is no problem with these vulnerable machines because the only network they are connected to is the one to the control system. There is no USB ot other bus that can be plugged into these machines.
You dont mess with the system.. EVER.
Exactly! That way this is not really a problem.
Halt and Dump Core?
Certainly beats a boring old "catch fire" message.
Finally had enough. Come see us over at https://soylentnews.org/
And the reliability is thus
1 - [1 -2i + i^2]
Which is 1 - 2i.
> 1 - [1 - 2i + i*i]
= 1 - [1 - 2i - 1]
= 1 - [1 - 1 - 2i]
= 1 - [-2i]
= 1 + 2i
The problem, in short, is not that Linux/Unix is too hard. The problem is that Windows pretends to be too easy.
The real problem is that 90% of users prefer that paradigm over them having to learn to do complicated stuff. They would rather not be confronted with a decision they do not know how to make, instead they would rather something made the decision for them.
I dont read
The story describes what I consider an HR issue, not a technical one...
Err, nope, definite Executive Management problem. As they probably directed HR that we only use Microsoft here, thus do not hire Linux, Unix or other nix knowledgeable professionals.
It use to be said that, "No one got fired from purchasing IBM..."
Around the time NT took over the servers/desktop, it became, "No one got fired from purchasing Microsoft..."
Most Executive Managers just do not understand that there is nothing a Windows (even Windows 7) desktop/server does that can not be done with Linux, usually better and definitely faster, with less chance of virus infections.
In those companies where the IT Director, IT Manager, System Admins only use, understand and push Microsoft Windows platforms then its the entire IT shop that needs some wholesale cleaning....
Its a bias towards Microsoft solutions, though out the entire corporate infrastructure.
If you want to use programming and algorithms from major manufacturers, a Windows machine saves money since there are already drivers and plug-ins made for Windows machines.
There are more device drivers for Linux than any other operating system in the history of computers. This is a known fact. Anything else is FUD.
If the device driver for a new piece of proprietary hardware has not been made available (whether due to collusion or other intent) then blame those responsible, namely the proprietary major manufacturers, Microsoft being among them. Intel, Nvidia, all the BIOS (granted thats software) companies, and many, many others.
Even those proprietary major manufacturers, having released newer hardware, eventually release those proprietary drivers after 6 months, 1 year, 2 years or more into the public domain, (i.e. into Linux, Unix and other NIXs). Why, profit of course, when Microsoft stops buying their hardware because they have moved on, those proprietary companies want to milk their investment for all it is worth, thus they finally release the, now older hardware, into the open source community hoping for additional sales. Thus why there are MORE device drivers available for Linux than any other operating system ever developed.
If something does not work day 1 in Linux, it is by design on someone's part. Some companies just do not release their drivers in Linux, and here too is where the open source community shines. One or more developers will take their valuable time, go through the hardware schematics and develop the device driver for use in Linux, Unix and the open source community.
The Linux Driver Project specializes in creating and maintaining open source Linux kernel device drivers. If a company tries to spread FUD they they are protecting their products from competition OR that they do not have Linux developer knowledge in house, call them on it. Tell them its FUD and tell them why its FUD. Point them to this link. The Linux Driver Project has developed and successfully used this process to get the device drivers developed for many other companys while still protect the company's priority products. Its a Win, Win, Win for all!
WinCC is the process vizualization software package that runs on the plant operators's workstations. IIRC it supports devices running all kinds of embedded software, network protocols, and interfaces. Probably still supports things like TIWAY or DECNET. Dunno (and don't think) there are Unix, Solaris, Linux, Mac versions. Be nice if there are or were. Just like it would be nice if NI and others would port lab software to Linux more often, if ever. But, they don't (shrug)-so it's up to us.
The link you posted that supposed explains how "a Microsoft Security Update really did shut down a nuclear reactor" doesn't even mention Microsoft. It explains that the shut down was caused by some "software update." There is nothing in the article that suggests that the update had anything to do with Microsoft.
Ask BP - or the US Navy...
you had me at #!
Several of the USB sticks I've purchased came with pre-installed malware which Windows dutifully executes when the stick is inserted. A few months ago I made a presentation and stuck one of these in someone else's machine, and their anti-virus actually detected the stick as containing a trojan, about effing time. Given that MS continues to support vendors including viruses (claiming them to be drivers or other necessary software) and executing them, I'm really surprised that a lot more malware hasn't spread this way. I'm also a little surprised that more malware authors have not broken MS Code Signing. As for the target systems it looks like they are living with their heads in the sand, it was just a matter of time for them to be targeted.
minds, get scrambled like eggs, abused and erased. Hard Hearted Alice is who you want to see.
... we're actively implementing patches on the month-behind schedule, and this includes our control systems too. We can do this because every server type (data ack, database, human interface server, etc) we have operates in tandem with an identical twin, in standard failover configuration. So we patch the backup, and initiate a controlled failover to it. Problem? Fail back. Works? Patch the other side now.
And doing it this way creates windows of time when YOU HAVE NO backup:
1) From the time you start the upgrade on the backup until you have completed the controlled failover and discovered it to work, then
2) From the time you start until the time you finish the upgrade of the former primary system, or
3) From the time you start the upgrade on the backup until the time you have finished rolling it back.
This may be enough to achieve the requisite length of the string of 9s in your reliability requirements. But for some applications it seems too risky to me - especially given that one mistake in the upgrade could accidentally take out the running control system when the backup was unavailable.
To avoid this you need THREE systems in a double failover configuration. Then you can upgrade one and still have a primary and backup live.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
"Hey look boss, I know you said don't put the control system computers on public network, but how the hell else will we download these cool internet explorer toolbars?!"
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
My mistake. The link I was thinking of related to an ancillary computer doing semi-critical testing. The safety system detected the ancillary computers failure, and shut down the reactor. The story referenced was about a different type of failure.
Unfortunately, I assumed that computers killing a nuclear reactor was such an unlikely story that only ONE incident had been reported. My mistake.