Stuxnet worm can reinfect PCs even after disinfection A security researcher has found yet another way the Stuxnet worm infiltrates computers used in nuclear plants and other industrial facilities, a technique that has the ability to reinfect machines even after they've been cleaned of the malware. Stuxnet has already proven itself as one of the most sophisticated pieces of known …
So lets recap...
We have:
A semi immortal worn specifically designed to infect and control industrial systems
The American government
Iranian Nuclear Plants....
To quote the immortal Mel Brookes...
"Oh shit, there goes the planet..."
Gucci Hazmat = ON
This sounds more like Israel than America.
The yanks are secretive and all but this virus actually works so it's more likely they had nothing to do with it.
Then there's the fact that it's infected American power plants aswell.
Plus the Israelis are good at this kind of thing so i think it's more likely to be them.
Step7 files are the actual PLC programming files. Now I'm even more worried ... does this mean that the PLC programming may have been in fact tampered? This is serious. Really serious.
If anything, this might prompt Siemens to move all PLC-manipulating software to non-Windows platforms, probably QNX. Linux would be nice, but I'm kinda paranoid when the software is managing stuff where errors are in the "oops-I-did-a-Chernobyl" category.
1) They are specifically targeting Siemens. They will follow whatever platform it is on.
2) No operating system is bullet proof. They will find holes in it.
3) Its expensive enough getting the licence for S7. Think of the extra costs in having separate servers, tape backup, etc for all the S7 code. What, you were thinking of putting it on your normal file server which is probably a Windows box or has windows boxes with read/write access to your projects area? Its going to get eaten eventually.
It is a bit scary that the PLC code could be compromised. If it managed to send a copy back to the writer's server, they might be working on versions removing all the safety interlocks.
Probably not so much of a problem with nuclear power as they usually have several protection channels developed separately on different platforms (including hardwired relay logic). But it might mess up lesser types of plant.
"No operating system is bullet proof". Too true, but at least UNIX model privilege separation and no write access for ordinary users to the system directories means that not only do you have to get code running in a system, you have to get it running as a user with escalated privileges in order to do serious damage. A double hurdle. And there are even better security models available.
Let's face it. The security and application installation model on Windows pre-Vista was just terminally flawed. It required serious knowledge of Windows to allow it to work in a secure manner. This is why those systems are such ripe targets, not just because there are so many instances of Windows. And I am prepared to argue this point out with anybody, although preferably over a pint rather than in these forums.
If there is software running nuclear power stations that needs admin rights to run, then I laugh at their folly! Or I would if I did not live within 20 miles of one!
Jonathan Richards 1 - The whole point is that Windows is not mission critical. Its running a SCADA system. The control of the system is via a PLC, not a Windows, or anyone else's box. The operator uses the PC to initiate events, but all the interlocking and safe control of your plant is handled by a PLC.
Peter, true it sounds harder to get past the Unix way of doing things. But I doubt its impossible, going by the lengths these people have gone to in their attempts to compromise systems.
Remember that power stations work more on protection channels. Each protection channel is designed to stop anything silly happening. Some are via Windows based systems, others hard wired version of the same logic. I even know one using a VAX in its monitoring. But no one system being compromised will allow a big bang.
Well, in saying that, some countries do not think of safety in such big terms as we do in the UK.
I never said UNIX was invulnerable. Only a fool would claim that any OS is absolutely secure, and I can think of several ways to target a UNIX system, but most involve some form of social engineering together with lax root administration.
But in the write up of the worm on the Symantic site http://www.symantec.com/connect/blogs/distilling-w32stuxnet-components, it is quite clear that in order to infect the SCADA PLC, normal Windows methods are involved, although what is described is very sophisticated.
I'm glad that dual-vendor redundant systems are involved in our power stations, but I would guess that the next generation will probably have less of this, because Windows is slowly taking over the world.
"in the write up of the worm on the Symantic site ... it is quite clear that in order to infect the SCADA PLC, normal Windows methods are involved"
Uhh, yes, seeing as Windows is used.
And if they were IRIX systems, IRIX methods would be involved. (Actually, IRIX viruses do exist.)
Alternatively, apparently Israeli agents who apparently had real live agents steal security certificates from an office park in Taiwan in order (apparently) to hit a nuclear site that is (apparently) meant to make weapons grade fuel to nuke Israel, would learn that the systems run UNIX, give up and take a nap.
That makes perfect sense.
Cracking the OS was probably the easiest part of this whole shindig, and I somehow doubt that using a different OS would change that.
...at weapons grade worms?
The Calutrons in the Manhattan Project were controlled by clueless ladies. Iran has plenty of those. And the new supermagnets make building mass spectrometers a snap.
Funny... Netflix just dropped "China Syndrome" through my mail slot.
Genetic engineers can now create plants (yes, hemp) that selectively remove metals from soil. That technology could lead to very cheap enrichment.
Has America become the World's Hall Monitor?
No beer cause copper thieves got the brewing vat.
Did you know that BORON quenches both fire and fission?
I really don't understand it myself. Windows is extensively used for the SCADA layers, most of the smaller HMI panels are WinCe based (despite lack of ongoing support from MS) and the programming environment is all Windows.
The latter is just the same case of follow-the-market that all the PLC manufacturers suffer from, and you will find that Rockwell/Alan Bradley use "wonderware" on windows based machines for their scada and C&C layers.
I think the pressure came from customers, for cheap control stations, rather than being a failure of imagination at the PLC manufacturers.
In my first C&C job we used rtos running on Motoroloa 68K hardware. We had an SQL database server so the customer could hook up external systems for data extraction. That was 25 years ago. Things are obviously so much better now...
I didn't think about this until your post, but I've worked in a windows heavy industrial environment where downtime is costed in the millions per day. I think a scenario where PLCs can be infected by a virus from a windows machine will quite frankly terrify some project managers.
Wouldn't it be funny if the Stuxnet virus was the thing to end windows as an industrial OS?
Doubly hilarious if it used backdoors installed into windows by the US government :D
Unfortunately, I expect that being only funny and scary, it won't.
I think it will only stop being used for industrial processes after it is flagged as the key culprit in a major industrial accident, e.g. Chernobyl or Bopal. At which point it will be sad and tragic instead of funny.
Those replying may do well to research what a PLC actually is. They are stand alone hardware devices, and do not run on windows in any way, shape or form. They are more often than not run on a closed network, with no internet access.
However, to program the PLC, you need to connect to it using Siemens software, this runs on Windows. This particular virus spreads between Windows PCs, looking for a laptop that is used to program PLCs, and will spread by various methods, including infecting the project files stored on a fileserver (the server could be running any OS, as long as a Windows PC has access to them, they could become infected), or USB keys. Once the target laptop has become infected, when it is conencted to the PLC to change the code, the PLC becomes infected.
Dont forget no virus like this has ever been found before, so previously there was no danger at all to PLCs as they do not run Windows. Its all well and good asking why the laptop used to program them runs Windows, but up until now it was never an issue. Additionally, this virus has been specifically written to target this platform, so as others have said, you could change the software to run on Linux / QNX or anything else, the makers of this virus would just target that platform instead.
"Is that having used Windows, some balloon decided to connect the reactor controls to the internet."
I'm gonna go out on a limb and say this is why they have so many different attack vectors.
How do you shuffle files from one computer to another? Either a LAN or USB keys or some kind of removable media. This transmits through both Windows file sharing and USB keys. As long as it gets into the physical site, there's a decent _chance_ it will make the necessary jumps even if the actual control computers are not connected to the internet.
In hindsight, it seems incredibly stupid of Siemens to be running such critical systems on WIndows. I agree (and have been saying the same for years - one of a few voices in the wilderness).
I guess that Siemens is wondering about the survival of their credibility, as well as that of the managed systems. Attaching yourself to Windows doesn't seem quite the "obvious decision" that I assume it was originally. Still an obvious decision but in the other sense.
However, Siemens is in good company. After all, the Royal Navy and United States Navy are both running warships on Windows, so it has to be OK. Right?
I wonder if *they* have any Siemens gear?
There is really no reason that you can't run Windows is this sort of mission critical environment, you just have to setup the environment correctly. For a start all servers running SCADA software should be in a totally separated (firewalled off) environment that at most should only allow RDP access to the servers. Updates should be delivered via a server in a DMZ, which can access certain specific servers in the main environment and be the only servers that can send updates to the fully firewalled off area.
the implications of what some people are saying is that Linux (or UNIX) would be fine running SCADA systems if it was connected directly to the Internet, when in actual fact you should be looking at exactly the same sort of network security as with Windows.
As for this being a government written worm, I'm suspicious that a government agency would use four or five zero day expoits in one go, it seems a bit wastefull of a precious resource.
While it is true that no OS is free of bugs and potential exploits, Windows has been such a basket case it beggars belief that you would use it for a safety critical role! In fact, I think MS specifically exclude its use in potentially dangerous applications.
Yes, there is a lot you can do to harden windows, such as firewalling it off to the point it can't auto-update, locking down all USB ports, etc. But you must ask why it is needed, rather than being safe by default, for an industrial application.
Then we get on to the other major issue here: the monkeys in charge at Siemens had HARD_CODED PASSWORDS that you could not change (or more precisely, would brake it if you did). That is just so WTF it also beggars belief.
Realy security comes from very tight restrictions on access, but it also helps to start with something that has a good history few exploits and well-structured modular separation of code. Basically most things OTHER than Windows.
Just a minor point, but computers can't get reinfected by files remaining on a computer after they've been cleaned. If that's happening, then they weren't properly cleaned in the first place. The definition of proper cleaning is to remove everything so that there's no trace left behind.
The article might better have said that reinfection can occur when previous cleaning methods were used - those that were incomplete as they hadn't yet identified the new discovery.
It's probably worth pointing out that Windows (or whatever OS that is sitting at the top end of the control system) isn't actually doing any control at all - this is true for all industrial process control systems, whether they are by Siemens, Alan Bradley, Invensys, whoever. The PC side of things is used to configure the PLC and control hardware and log and record stuff. If the whole set of PC's suddenly suffer from BSOD then the control system will quite happily continue or at the very worst, fail safe. Stuff that would be logged to the PC systems can be cached by the control hardware until the PC's are back up again, when it will then forward the stuff on.
So Windows isn't being used in a control role - that side of things is done by highly specialised, custom OS's running embedded on the control hardware.
Windows does deserve a lot of stick, but those who are getting their knickers in a twist about 'Windows running nuclear reactors' clearly have never used or know much about modern industrial control systems. If in this case Stuxnet is deliberately targetting for PLC config files then it wouldn't matter what OS was used on the top side - I would expect Stuxnet to be able to exploit whatever weaknesses exist in any OS to carry out it's mission.
Sounds like the power plants need better IT admins. I know everyone here hates Windows but I really think this could have been avoided with better network guidelines. Granted, Windows may have provided a method for this to happen that might not have happened if it was Linux or whatever but I really don't see this being all of Microsoft's fault.
"There is really no reason that you can't run Windows is this sort of mission critical environment"
Hopefully that argument will struggle to find any independent minded (rather than MS-dependent) support from now on. The only other place I've seen it so far is some far right nutter/bogger in the good ole U S of A.
"some balloon decided to connect the reactor controls to the internet."
Wrong. Please try to understand the story before commenting with carp like that.
There is no requirement for internet connectivity in this or related pictures, it just makes things more convenient. Sneakernet (USB stick) is more than adequate for conficker-class stuff like this.
Same reason it gets chosen in all the other places where something else (anything else) would be more appropriate than Windows. (1) Clueless PHBs (2) too many MS-dependent people and organisations who would stand to lose out professionally and financially if they admitted that Windows wasn't always the answer.
Obviously mainstream Windows isn't always the answer, even MS know that, otherwise Windows CE wouldn't exist. But try getting these folks, e.g. your stereotype IT department, or your roomful of MS evangelists, hangers-on, and MCPs, whoever, to admit that.
Does Nic have even half a clue about what he is commenting on? I mean, really ... "restoring from un-checked backups might be a bad idea after an infection". Gee, you think?
How about "you might get re-infected after cleaning out the malware ... if you didn't actually clear out the malware in the first place". Really? Please, tell me more ... so I can point & laugh at you, and maybe take your job after you are fired for being incompetent. Not that Symantec could pay me enough ... I mean would YOU want that on your resume/CV?
Gawd/ess. The mind boggles. Fucking numpties.
A high level observation here - the actual control system is PLC (or PAC in the case of S7) based not "Windows-based" (which means a propretary OS running on industrially rated hardware. Only the operator and programming interfaces that are Windows based. A good PLC/PAC/DCS configuration is implemented that allows the system to operate without user interface in the event that the operator interface (potentially running on a Windows machine) were to crash. Most serious / dangerous systems also have manual control backups / safety systems (in case the PLC/PAC/DCS system fails).
The above point aside, the issues that we are talking about here - a highly skilled / knowledgeable group developing a clearly targeted, malicious worm/virus - are not "Windows" specific. It wouldn't matter what the interface system was - ALL of them have potential exploit opportunities...UNIX, QNX, LINUX, Windows, OSX, etc. - every single operating system you could select has potential vulnerabilities due to the complexities of producing a machine with a modern GUI, network stack, etc. The point here being, that whatever the control system and associated operating system used for the configuration/programming interface, the party responsible for financing this software would have found exploits. Mindlessly blaiming M$ and proclaiming the wonders of <insert favorite fanboy OS here> is being either naive or disingenuous.
Incidentally, for those of you who can not fathom why all of these vendors would have used Windows as a platform - All you need to understand the fundamental economics of software development for industry. 1) End-customers don't want to spend rediculous sums of cash for hardware. 2) Software development is expensive. Therefore, when most of these MFGs moved to Windows and away from the proprietary hardware they all used in the infancy of computing; they initially selected DOS and migrated to Windows for there programming software. Same thing for their GUI operator interfaces. They guys who based their system on UNIX either died or migrated because the cost of UNIX implementations were not cost competitive / attractive to customers. In this same timeframe, Apple was a joke, spiralling down and LINUX didn't really exist and/or wasn't reliable. (Nobody in their right mind would have developed on LINUX because you couldn't know if your particular flavor of LINUX was going to be around the following year - Actually a few people did try and many learned the hard way that the OS they developed under was too much of a moving target and/or disappeared on them). So, Windows was the ONLY logical choice based on the economics.
So the question is what should these companies do now. Do any of you really believe that there is an unexploitable OS out there? Stop being delusional. It wouldn't matter what the OS was, all of these systems are networked and software programmers are human - exploits will exist. The cost of moving code to a different OS would be pointless - there would be potential exploits on the new OS too - and the networking allows nice vectors for propogation.
Oh and before someone starts bitching again about networked control systems - expecting them to not be networked is pretty naive too. Plant operational staffs are smaller and smaller - the networking, associated data collection, and data analysis are necessary for operation under reducing staff levels. Why reduced staff? So that our electricity or latest widget or packaged food product is as cheap as possible to be as competitive as possible. Without increases in productivity, inflation would be a b and we all tend to select based on price - if you have two products on the shelf, both good, and one is cheaper - which one do you buy?
Lots of things you have written trigger outrage in me, but I believe that to encapsulate what you've said, it's always an economic argument. And not to keep services prices to the customer down, but to increase shareholder return.
My view is that some things should be beyond raw bean-counter accountant economics, and safety is number one on this list.
And the argument that other OS's would be equally exploitable is just fatuous. If the account that you logged in to use the PC for everyday use did not have write access to the PLC code, then ordinary everyday use of the system would not expose the control system to infection. This would be the case if it were designed to use a UNIX type OS, or QNX, or VMS, or, in fact, any OS that did not evolve from a 'Personal Computer'.
I am not saying that it would be totally safe, your point about nothing being totally secure is quite true, but the times that the system would be vulnerable would be significantly reduced, mainly to system updates.
Part of the underlying problem is that as Windows is not regarded as a secure OS, many generations of programmers have grown up without having to think of making their code work in a system with anything like a decent security model. I've come across this time and time again when I get to install a piece of software on a UNIX or Linux box that was written by a PC programmer, and find that you have to have log and configuration files globally writeable, and even worse, whole directory trees in a similar state.
It is possible to control user access on a Windows system running NTFS 5 or later, but not enough people care enough to design their software to install and run in a safe manner.
In fact, the underlying user and file permission model on NT based systems is actually much better than UNIX (and this is a UNIX bigot saying this - the UNIX model is actually quite simple and restrictive), but how many people know how to use the policy editor to take advantage of this. If you are a Windows programmer, do you set up multiple accounts. Do you have a specific account to install the software that is neither an admin account or a day-to-day user account. Do you use the access rights user and group attributes to control who can do what with which file. Do you even know what acledit is!
The simple answer is No! I would say that almost without exception, Windows programmers just don't think that way. (BTW, if you are a Windows programmer who does take the require amount of care, wade in, and prove me wrong!). I believe that Windows administrators have more idea than the application developers, and that is just because they have been burned too often because of the vulnerabilities. of Windows.
If you grew up in a UNIX or VMS or even a RACF world, you would understand this or you would not get work.
Whilst I agree that the IO is controlled by PLC processors running embedded code, don't forget that it has been increasingly common to create integrated C&C systems to oversee the PLCs.
Things like target throughput, or acceptable emission limits, or duration of run, are passed down from the Windows systems into the PLCs nowadays.
it didn't used to be like that - SCADA was just for monitoring and display, it was far too slow for process interaction. But with faster workstations and broader systems it has become quite common for the overall plant control - not just supervision - to be done at the level of the windows systems not within the PLCs.
Its bad practice, and the safety cases are supposed to make sure that the PLC and its failsafes are ultimately in charge. But do you think they always are? I don't.
BB, because even though he only watched, he influenced everything you did.
It's funny that most financial institutions are really heavy users of Windows, typically the main software which handles accounts is run on Mainframe (that was the only thing available when it was developed.) but you'll find ATMs, workstations, counter tills, cash handling systems, directory services, Web serving/internet banking (it may be fronted by Apache sometimes, but often as not that runs on Windows) loads and loads of applications are run on Windows servers and there generally isn't a problem. (I'm not saying it all is, just a load of it)
This stuff is critical national infrastructure (by the Government's definition) and it all seems to run just fine, in fact it runs well enough that it's major headline news when it doesn't run or if it's compromised in some way. I have yet to hear of an ATM network which is compromised by anything except a conspiracy of multiple employees of a bank and I've only heard of two of these globally in the last twenty years.
This all brings me on to the elephant in the room: Why is it that SCADA systems seem to be so poorly put together? Why have the customers allowed Siemens to get away with crap like hard coded passwords? Why are there not basic precautions like installing SCADA servers and workstations in firewalled areas and DMZs? Sure Windows is not the most secure system in the world but most, if not all, of the attack vectors are neutralised by proper network design, proper user access configuration (somthing at which Windows is actually really quite good) and securing of local ports.
I remember a conversation with an IT pro who dealt with Siemens code in PBX a few years ago. The general comment was it looked like it was done by students on asignment. The PBX was a mixed TDM and IP system so presumably the 'security by obscurity' security model of yesterday was a default. I can imagine PLC control/dev. software development culture at Siemens being not much better. And to be fair, not only Siemens. It looks like a whole industry just has been caught in being out of date with security, pretending that they can effectively ignore the Internet. The Windows security architecture is pretty much secondary here to the security model of the application layer. Look at modern databases - they do not assume OS level rights suffice to grant access.
@Brian 47
"if you have two products on the shelf, both good, and one is cheaper - which one do you buy?"
If you're one of the many ignorant PHBs, you override the techies and force the purchase of the one which has more advertising. It has more advertising not because it's better, but because more people (MCSEs, MCPs, VARs, OEMs, etc) are dependent on the income from the (MS) ecosystem. Sometimes the cheaper one is actually better, because all these MCSEs etc want to take their cut of the money along the way somewhere, and so the price has to be high enough to enable that.
@Peter Gathercole
Well said.
@Fraser
You're making yourself (and your employer?) look silly. Come back when (1) sneakernet isn't a valid propagation vector for Windows viruses (2) there are no more PHBs who prefer "widely advertised" and allegedly "cheap" to "good".
The PLC programs are developed and documented in one environment and deployed in another. Even if there's a DMZ or firewall or even airgap between the two environments, the programs have to be periodically transferred between development environment and deployment environment. Sometimes data goes the other way too. Sometimes it's via a cable, sometimes it's sneakernet. There's *always* data transfer in this kind of setup, even if it's not there all the time.
In host/target environment days before Windows, when the hosts were mostly Unix (or VMS) boxes and the targets were mostly VME crates with dedicated OSes, there was no such security problem although there was still a need for data transfer. The security problem only arrived with Windows.
These days, routine electronics lab stuff like logic analyser and oscilloscopes comes with a fair chance of having Windows Embedded as its OS. The same probably applies in the automation environment; what used to be "programming panels" are now Windows laptops. In factories, kit that used to be VME (or even PDP11!) is now CompactPCI stuff, likely with Windows Embedded in it. Same in smart kit in hospitals, and doubtless other places too.
All this kit is probably not networked and the IT department probably either don't know it exists or don't know what to do with it because it's not a PC. Those who are responsible for it don't know what to do with the Windows side of things. So these Window boxes will be vulnerable, unpatched, and probably without an up to date AV. Nice. But people use sneakernet to get data on and off these boxes, and because they run Windows they're vulnerable, and not only are these boxes at risk, they put other Windows-based kit at risk too.
Anyone who says this kind of thing doesn't happen is kidding themselves.
Anyone who says this kind of thing doesn't happen in environments where it matters is kidding themselves. And it's a lot closer to home than Iran.
Windows simply does not belong in this kind of non-desktop kit. This kind of kit does not generally need data interchange with Windows beyond simple virus-proof file transfer. It does not need GUI compatibility with any of the (various, incompatible) incarnations of the Windows GUI. It does not need Word or Excel or Outlook. For these boxes, there are plenty of alternatives, be they commercial, free, or open.
This kind of kit does not need Windows. End of story.
Ok, "sneakernet" isn't a valid method of file transfer if you've locked down your ports. I can't get any data on or off my work laptop without going via the corporate network, I can't connect an external drive or use the CDROM when it's booted. I can't even take the hard disk out or boot it from a USB drive and put files on like that, because it's encrypted. This is bog standard basic security for corporate laptops, the OS? It's Windows XP.
Financial considerations have to be part of a purchase, if all your programmers program AIX, you wouldn't buy Windows or VMS, likewise if all your developers are Windows guys this will give a heavy skew towards using Windows.
As for your assertion that programming/dev work has to happen in one network and then be moved into a secure network where the SCADA machine reside: This is basically the same as what happens with ATMs and other such secure hardware, they operate in a separate network and have to have software transfered onto them and data is passed to and from the back end system. You just have to put in place proper checks and controls. The OS run in most ATMs? Windows XP.
The point is that you just need to set it up properly, which is obviously not happening. Like I said, Windows is not perfect, but if system designers don't know the first thing about network security of refuse to pay for essential hardware, allow people to install their own media, have users running as admin etc. etc. your system is going to be compromised. This goes for pretty much any OS.
Many banks started to move from OS/2 (a personal fave of mine) onto NT4 when it became obvious that OS/2 was going out of support. Those who missed NT4 moved directly onto XP. OS/2 is now totally out of support and has been for several years, no banks run anything as important as ATMs on unsupported software.
Yes all those process set up things are necessary and need to be done properly, and some of them have not been done properly in the case of Stuxnet. But on their own they are not *sufficient*.
Like it or not, Windows has to go, from places where IT don't go. IT don't do factory automation, IT don't do electronic lab equipment, IT don't do hospital medical equipment, etc. Why should these people have to do IT's job for them ?
"if all your programmers program AIX, you wouldn't buy Windows or VMS,"
If an application's requirements call for AIX or VMS, and all you've got is Windows people, then Windows is still the wrong answer. Picking the right tool is the answer.
If you want a hedgecutter you don't buy a lawnmower because there's only lawnmowers in your company's chosen shop do you? Do you? Sensible open-minded people find another shop, perhaps a rental shop if it's only an occasional job, and use the right tool for the work at hand. Even if they're very nice lawnmowers, advertised on QVC and marketed on The Garden Channel, a lawnmower is still not a hedgecutter.
I am familiar with this concept, I have used Windows CE (hammered down from Big Windows, right?) and I have worked in factories in Birmingham (from where the expression "Birmingham screwdriver" presumably originates).
Based on that experience, I can assure you that this tactic doesn't always work, though it definitely has its good points.
See, the thing is, even Microsoft know there's a difference between computers and equipment. Equipment is supposed to run Windows CE, not Windows PC. If only the likes of Fraser could see this. How easy is it to get a virus in a ROM file system? (Whether any sensible person uses Windows CE anyway is a different story for a different day).
Anybody want to buy a 2nd hand Flymo, very low mileage, some cosmetic damage?
Can't stop, need to get to B+Q. Unlike some alleged IT people, they have a bit of a clue about using the right tool for the job in hand.
I've used CE on dumb terminals, it's a pretty good system for dumb terminal and embedded type stuff. I agree that it would be vastly preferable to use than normal Windows for monitoring terminals etc. You'll still be needing a proper server of some sort to store data and program code and move it to and from the PLCs. However, this wasn't really the point that I was making, I was trying to say that you can safely run normal Windows systems - and many do - with a modicum of though. I daresay that the sort of people who put their main SCADA servers onto a production network which is visible to everything in the site are also the sort of people who run their CE terminals in read/write mode so that anyone can update the local filesystem.
This goes for anything: Don't get non-IT people to design and maintain IT equipment. Likewise, don't get IT guys to operate your plant.
In fact to go further: Don't get single OS only people to design the OS that they are not expert in. We have plenty of people at work who think that because they know UNIX of one sort or another they know Linux, or becuase they know Linux they know Windows. It's just not the case.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
