Stuxnet May Represent New Trend In Malware 58
Trailrunner7 writes "As more information continues to come out about the Stuxnet worm and the vulnerabilities that it exploits, it's becoming increasingly clear that this kind of attack may be a preview of the attacks that are likely to become commonplace in the months and years ahead. The most interesting aspect of all of this is the fact that the attackers behind Stuxnet clearly knew about the vulnerability in the Siemens WinCC system before the malware was written. That implies the malware authors had some advance intelligence about the configuration of the Siemens software and knew exactly where there was a weakness."
How can he get it so wrong? (Score:3, Insightful)
Re:Uh - what? (Score:5, Insightful)
Not always. Some control systems are run on a dedicated computer without Internet access. Some control systems need to have little downtime to avoid serious consequences. (Some manufacturing plants or refineries have razor-thin margins - an extra 1% downtime could mean the difference between profit and bankruptcy.) In cases like these, if a hard-coded password means a faster system recovery, it's the right choice.
If I had software on my desktop system with a hard-coded password, I'd be justifiably pissed. However, for some industrial applications (including some SCADA installations) , the simplicity of not needing to enter a unique password plus a physical air gap of security trumps a forced-unique password with only digital security - particularly if that digital security is Windows-based (where adding a keylogger would have resulted in almost as bad a p0wnage as what Stuxnet already has)!
Re:SCADA frustrations (Score:1, Insightful)
This is just the start in Industrial Automation/SCADA. The workhorse of automation is the "Programmable Logic Controller" or PLC. These have, basically, no security, including open network ports which can be used to change variable (think setpoints for temperature, pressure, startup/shutdown sewage pumping stations, etc.). While most of these are not exposed on open networks, a disgruntled employee could cause major damage. A SCADA virus that exploits these weaknesses could bring down large pieces of infrastructure.
The solution is not to try to protect the network. As the parent says, this is a loosing battle and access to the devices is necessary for Management and for Operators. The solution is to protect the devices. Treat each one as if it were open on a public network, firewalls, strong passwords, limited port access, etc. etc. This is a trivial retrofit with, say an embedded Linux system.
Then you can safely use the Windows systems a views only. No control on those platforms. As views, they work fine since they are familiar and pushing a bad patch, or a virus doesn't bring down the control system.
Re:Uh - what? (Score:5, Insightful)
Not always. Some control systems are run on a dedicated computer without Internet access. Some control systems need to have little downtime to avoid serious consequences. (Some manufacturing plants or refineries have razor-thin margins - an extra 1% downtime could mean the difference between profit and bankruptcy.) In cases like these, if a hard-coded password means a faster system recovery, it's the right choice.
So, why not have a password that is generated in some known way?
The HIS system where I work has a "daily password" - it changes every day. That password is necessary to conduct some operations. Folks who need to conduct those operations know how to look up the daily password. They do so, then they have that password to hand out to whoever needs to do stuff that day. And the daily password becomes useless the next day, so you don't have to worry about it being abused.
The POS system I used to work with had some kind of dynamically generated password. If you had to call technical support for something they'd have you read off some numbers on the screen, and they'd give you back a password to get into the register's internals. Again, it isn't static so it can't be abused for long. But it is generated in a known way so it can readily be obtained.
Seems to me that this would have been a better way to do things.
However, for some industrial applications (including some SCADA installations) , the simplicity of not needing to enter a unique password plus a physical air gap of security trumps a forced-unique password with only digital security
"Air gap" doesn't mean much if you're just using some kind of removable media to transfer information from the insecure world to the secure world, instead of CAT5. If you aren't somehow protecting access to that removable media, your air gap gives you no additional security.
It should be genuinely impossible for anything to auto-run on removable media. Only allow media in your own, special format. Or only allow specific file types to be accessed or imported. And put some kind of password on the media access portion, to make sure only folks who know what they're doing are accessing it.
If you're letting anyone transfer anything on a USB stick, you may as well plug the machine into the network because your air gap isn't doing you any good.
Re:SCADA frustrations (Score:3, Insightful)
Sounds like your organization doesn't have the right support for security (most likely they don't understand).
You need to engage in a business impact analysis exercise and see what comes out of that.
That will be input for your policies, procedures, standards, etc.
Re:Uh - what? (Score:4, Insightful)
"(Some manufacturing plants or refineries have razor-thin margins - an extra 1% downtime could mean the difference between profit and bankruptcy.)"
I think you exaggerate. If not, then the executives and other decision makers are incompetent boobs, and the company SHOULD go bankrupt for hiring them.
I'm a maintenance man at a manufacturing plant. Our management is only marginally competent - but we have enough redundancy to see us through when something goes down. Sure, it HURTS when a computer dies, and the vendor won't honor the guarantee unless we send the computer back to the factory. But, bankruptcy? Come on . . . .