Slashdot Mirror
Stuxnet Worm Infected Industrial Control Systems
Sooner Boomer writes "ComputerWorld has an article about the Stuxnet worm, which was apparently designed to steal industrial secrets and disrupt operations at industrial plants, according to Siemens. 'Stuxnet has infected systems in the UK, North America and Korea, however the largest number of infections, by far, have been in Iran. Once installed on a PC, Stuxnet uses Siemens' default passwords to seek out and try to gain access to systems that run the WinCC and PCS 7 programs — so-called PLC (programmable logic controller) programs that are used to manage large-scale industrial systems on factory floors and in military installations and chemical and power plants.' If the worm were to be used to disrupt systems at any of those locations, the results could be devastating."
If they still use default password, they deserve to be hacked and face total havoc.
Industry`s security is still so crappy.
Probably the network is behind a firewall, so they think they are safe from outsiders. The problem is when insiders have both windows and no clue.
And they USED Windows as the OS... Brilliant!
Saying that they should airgap the SCADA is obvious- unfortunately, people tend to favor "ease of use" and that airgap is one of the first things that typically tends to get botched in the name of that. So, even if you thought you put it on a standalone, the thing's liable as not to be on the corporate net with all the other machines.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The OS it runs on is.
Often the system IS airgapped... and then they use a USB key to transfer the reports.
That's why USB keys were targeted for infection.
Our past experience indicate the IT staff does more damage to the stability of the system than anything else could. Most IT and network personnel has zero understanding of reliability of a system. The architecture they design are simply too complex and not robust enough. So before anybody can hack in, the system itself becomes unstable, crashed, and end up causing dangerous situation.
One of the most common mistake observed is a super complicated VLAN scheme that link multiple network together under the name of "ease of management" or "security", while in fact the first thing they need to do is to completely seperate the control network with corporate network, and then flatten the control network with air-gap from the corporate network. Also make sure you have zero wireless network access to the control network would be a wise choice not only in security but also improves each component's availability in general.
Again, common sense goes a very long way.
What is the point of a password if it's written in the owners manual of every person that has ever worked on a similar machine? At that point, you may as well call the communications API a "password".
This is manifested in the door security where I work.
We have RFID badge readers.
My boss recently wanted to add one to a lab he controls. When he found out the bill was $10K he balked. We told him it was for the security conduit (intrusion detection conduit, I assume gas charged & detect pressure drop in a leg?).
His response? We don't need the conduit, just run the wire.
Luckily security said F off and use a key lock, we're not installing it without the conduit. But that same attitude is why these machines still have the default passwords.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Our past experience indicate the IT staff does more damage to the stability of the system than anything else could
Agreed, with all your points. Over the past couple decades of doing control systems, one of the most common questions I get asked by engineering is "how can we best keep IT off our control network?" Funny ... the engineers in charge of these things just seem to intrinsically understand the risks of letting IT staff anywhere near a live process control system. Now, before you IT support people get all testy, I'm not saying that you are, as a group, necessarily incompetent within your legitimate purview. However, as Dirty Harry once said, "A man's got to know his limitations" and it's very disturbing to me how many of you are incapable of recognizing where your involvement is a liability. I've been accused of installing "rogue" systems by IT staff, simply because I recommended that a control system not be placed on a company's regular network. Thing is, a failure on an office network is an inconvenience. A failure on an engineering network can be a disaster. Keep that in mind next time you insist that engineering's systems should be under IT's thumb, and subject to whatever corporate "standards" are in force, regardless of their impact.
The higher the technology, the sharper that two-edged sword.
That's besides the questions. The question that needs asking is:
The likely answer to that is: "No"
However, if they simply ran the wire as requested by the boss, and something bad happened, would they get the blame? Yes they would, because they installed and approved it.
If you want me to take the blame for something, then I want to be in charge of how it can happen. If you just want a scape goat, look elsewhere, as I have no need for a "responsible for break-in to lab due to botched security job" on my resume.