Feds Investigating Water Utility Pump Failure As Possible Cyberattack 136
SpuriousLogic writes with this quote from CNN:
"Federal officials confirmed they are investigating whether a cyber attack may have been responsible for the failure of a water pump at a public water district in Illinois last week. But they cautioned that no conclusions had been reached, and they disputed one cyber security expert's statements that other utilities are vulnerable to a similar attack. Joe Weiss, a noted cyber security expert, disclosed the possible cyber attack on his blog Thursday. Weiss said he had obtained a state government report, dated Nov. 10 and titled 'Public Water District Cyber Intrusion,' which gave details of the alleged cyber attack culminating in the 'burn out of a water pump.' According to Weiss, the report says water district workers noted 'glitches' in the systems for about two months. On Nov. 8, a water district employee noticed problems with the industrial control systems, and a computer repair company checked logs and determined that the computer had been hacked. Weiss said the report says the cyber attacker hacked into the water utility using passwords stolen from a control system vendor and that he had stolen other user names and passwords."
Re:Could be something incredibly simple (Score:4, Informative)
Sort of. To program or configure the specific SCADA system requires specific knowledge of the device, installation architecture, firmware, and version supplied by the system operating manual. Until you get to the S part of SCADA and it all goes into some sort of aggregation platform with a big old GUI on a windows 2000 or windows XP box hooked into a cable modem.
Well, to program them correctly requires that knowledge.
These manuals are often trade secrets for the manufacturer, but are 'openly' passed around by maintenance technicians and field installers, and probably controls engineers such as yourself--although I never had the pleasure to work with one.
Depending upon the organization, such manuals are often shipped to other third party contractors with a "legitimate need" as determined by an engineer or manager.
When you tell them you have a corporate filter on PDFs, they will send to a personal email address if they would send it to start with. If they won't send it directly to you, their client will find a way to get their hands on it and forward it to you.
These manuals contain relatively complex documentation--including ports, encoding types, bit masks, register sizes and addresses that may be remotely configured by a couple of pretty common protocols which tend to be "extended" by the vendor in odd ways.
Sure, every bigwig in the industry has their own special program for everything that talks some proprietary clusterfuck. But mostly, they all have legacy support and some sort of shitty standard that will do basics.
Admittedly, any piece of hardware may implement complicated control processes specific to the device at hand, but all of which (that I've seen) generally fall into about three different "protocol families" for control purposes once you're down to a sensor or switch. Maybe you can't calibrate the device over your basic serial port, but you can throw a relay with it.
All of which I once wrote software for to control via plaintext text message at the demands of a former employer. Who insisted on static vendor passwords, and no encryption or even authorized whitelists to make our controllers easier and faster to install for subcontractors. Plug and Play. Or Pray. Or Plug and hacker prey. Whatever.
Now, you can say it's operator error to use that device. But the bottom line is even in your wealthy industries that do readonly monitoring over encrypted VPN--sooner or later somebody insists on remote control in order to cut maintenance costs. The moment that happens, they're hooked up to hardware that might be 25 years old. And then they're gonna hire somebody with a cheap solution to plug into it.
Re:Perhaps Not All Remote Management Worth The Ris (Score:4, Informative)
What's really necessary is for some kind of device that will communicate the data to remote places, but refuse to pass any messages from the outside onto the control system. I don't know how difficult this is, but it's certainly harder than "air gap it". On the other hand, this solution actually addresses the problem.
So, what you're saying is, if a utility is too cheap to lay in dedicated network assets and buy their own blacknet (which is not hard to do if you want to), it's ok to just connect the the Internet?
That said, the thing you're looking for is called a unidirectional network [wikipedia.org]. Back in my military network operations days, the colloquial name was "data diode". Data goes one way but nothing (no data, no handshakes, no signaling at all) goes the other way. In that environment, they were used to promote data from a lower-level security environment (say, Secret-only) to a higher-level one with no risk of leak-back.
Yeah. They exist. They're considerably lower-bandwidth than your average gigabit Ethernet switch, but if you're just talking SCADA telemetry, they should suffice.
Re:No Reason (Score:4, Informative)
Unless something goes catastrophically wrong, such as a fire in the control building, in which case the pumps (which must still operate) will need to be controlled remotely. Even during routine operation, the control system is likely connected to a monitoring network of some kind, to make sure things run smoothly.
That means either wiring up a physically-isolated network (and constantly checking it for unauthorized alterations), which is ridiculously expensive, or connecting to the public network physically, and relying on software to keep it secure. Given that this system is probably a few decades old, and probably installed by the lowest bidder, you can make some reasonably-depressing assumptions about how secure that software is.
I call bullshit. (Score:5, Informative)
I have worked with SCADA and water filtration plant pumps, big ass pumps, like 650hp pumps that run on 7200volts.
You cant set it to "burn out". you can adjust the speed of the pump from 10% to 100% the only way to kill a pump is to drop power to it without dropping power to it's valve so it will not close. wait for the pump to start spinning backwards from the water running back downhill through the pump and then slamming the power back on at 100% after the pump was free wheeling in reverse at full speed.
Then they don't burn out, they freaking explode.
This happened when we lost power plant wide and a hydraulic failure kept the valve from auto closing. (not electronic, it's a mechanical/hydraulic thing, a blockage in the pressure line)
Unless the plant was designed by a utter moron and made it so a programming error could blow up parts of the plant.
New information (Score:4, Informative)
The local TV news is on, and they just said that it was Curran, a tiny town five or ten miles from Springfield. They're concerned that the system might have been hacked because the company that designed the system discovered evidence of a breach of sensitive data... passwords, maybe? They did say it was gigabytes of data.