The security of software used to control hardware at nuclear plants, gas refineries and other industrial settings is coming under renewed scrutiny as researchers released attack code exploiting dozens of serious vulnerabilities in widely used programs. The flaws, which reside in programs sold by Siemens, Iconics, 7-Technologies …
As usual I'm sure these systems would be fine if they had been installed with a correct security mindset. Namely keeping critical systems isolated. If they must co-habit a network, use a firewall. All rules denied by default. No traffic goes to or from the critical subnet except for specific and required protocols. Even these are locked down so only specific machines can use specific protocols. Deep packet inspection would also be preferable.
Unfortunately we have all got a far different idea of how these systems have been installed... I can only assume the only reason an exploit hasn't been found for critical systems like autopilot is not so much due to any diligence on behalf of the designers/maintainers, but a lack of a cat 5 cable long enough to remain connected to the 747!
who needs cat5
I'm sure I've seen this in other places (but this was the first one I could find).
Most SCADA systems are just that....
for supervisory control and data acquisition. They supervise but do not perform control themselves, as such. They acquire and store data for presentation. They have probably not been a focus because they are seen as 'too technical' and they are, relatively speaking, a minority sport in the grand scheme of computer thingys.
Manufacturing control (Processes & Equipment) is, generally developed by competent aware specialists and executed in environments that are difficult to access both physically and electronically and requires more than a modicum of specialist knowledge. Most, the vast majority I would suspect, environments are well segregated and, if using TCPIP, make use of relevant firewall and technical controls - otherwise they wouldn't get insured?
Given the well publicised attacks on the Iranian centrifuge control systems it is now much more likely that industry will have to spend even more capital and design time defending itself against opportunistic pirates and thieves.
SCADA attacks are important. It is the ones that get into the data ( if you don't believe it you cant rely on it) and equipment controls (do we want to sequence stop that cooling pump now!) that we really need to worry about.
Isolated from the Network
You do know that the SCADA machines that were targeted by Stuxnet were physically isolated from the Internet, don't you?
The generic "Security 101" lesson you want is "always sanitise your inputs". Unfortunately, verifying the validity of SCADA programs is quite a bit harder than correctly escaping SQL queries.
Re: Isolated from the Network
Ah yes... Lesson 101.1
Remove user access to any ports (preferably physically as well as in software), especially those that permit storage devices to be attached!
It's only been a matter of time.
Most SCADA hardware still ships with default passwords ... but the folks who deal with SCADA day-to-day have no clue about "off-site" networking capability.
And then they plug the hardware into TheInternetAtLarge[tm] ... Remember the early days of Sun Microsystems (c.1982)? Any Sun box plugged into the 'net was accessible to anyone who knew the "as shipped" root password ... That's where SCADA is today ...
We tugged on their capes, and were shrugged off. We tapped 'em on the shoulder & were elbowed away. We tugged on their shirts, and were thrust aside. Some even kissed their boots, and were trodden upon. Our message was always "Please, PLEASE, **PLEASE**!! don't connect SCADA to publicly available networking systems!"
But did they listen? No. They did not. The idiots.
On the bright side, those of us with a clue are making a pretty penny in our retirement, cleaning up the resulting mess :-)
These problems have been known for years
Actually, SCADA has been known for years to be weak. There is a particular PLC you can shut down with just one (1) malformed packet. Not only will it fail in an undetermined state, that failure is also unrecoverable - you have to reprogram it from scratch.
It is impossible to close this hole at present - some systems are too hard to replace so they are left until they reach end of life, others simply don't have the processing power to have anti-virus added (not to mention the complete unpredictability of anti-virus software of when it interferes - do you want a full disk scan to start when you're trying to shut down a nuclear reactor?). The good news is that the number of systems that have to be left in their unpatched state is diminishing, the bad news is that almost any factory is still sensitive to insider threat. One engineer with an infected laptop and you have a problem.
Oh, and worse: a lot of industrial real estate is remote controlled..
Thank God that ESD (Emergency ShutDown) systems have been left proprietary..
Perfect Stormy Weather Forecasting. An AQwired Immune Facility and Advanced Quantum Leaping Utility
"Oh, and worse: a lot of industrial real estate is remote controlled." ..... Fred Flintstone Posted Tuesday 22nd March 2011 10:11 GMT
Good Moaning and 'Allo, 'Allo, Fred,
You may like to consider as a matter of fact, rather than just accept as a concept in sophisticated fiction, that in a Virtual Machine world, is everything remote controlled by Beings Eponymous and Anonymous, Ubiquitous and Invisible ....... for the Greater and Beta Good in the Beta and Greater Bad.
"On the bright side, those of us with a clue are making a pretty penny in our retirement, cleaning up the resulting mess :-)" ...... jake Posted Tuesday 22nd March 2011 10:11 GMT
One imagines that is as a grain of sand on a beach relative to what can be earned by/spent on those who do so easily create what is invariable Classified CHAOS in Command and Control Circles and leave not even a Clue ...... for True AIMastery of Universal Virtual Forces with Immaculately Resourceful Assets.
I'll take a wild stab at the thinking here.
1) It's a control system. *Assume* Information about it is difficult to get hold of as it's proprietary and frankly *no* one cares about them.
2) There is no need to connect it to the Internet (IRL the likelihood is that the PC used to configure it *will* be). *Assume* it will not be.
3) Penetration testing is *expensive* in time and money. *Assume* we don't *really* need to do it.
Do sense a *bad* case of security-by-obscurity at work?
BTW The register ran a story some time ago about an Australian con-tractor who messed about with some counties water or sewerage system.
FAIL because Stuxnet should have had *every* SCADA supplier reviewing their code (and how it's *accessed* for update and configuration). By now they *should* have been making initial announcements that they were all clear or issuing patches.
What have they done?
Er, so what?
When you bought that industrial process control software, did it say "internet-safe" on the side? Thought not. So don't connect it to a hostile network. Oh, and whilst we're on the subject, don't tweet your internet banking details, kids. It's a *really* bad idea. I did it once but I think I got away with it.
Process control software should have holes *deliberately* added to the code so that everybody either learns to keep such systems off the internet or they have to find another job. Certainly if I were working at a plant where dangerous stuff happened, I'd be pretty pissed off if I discovered that the plant network admins had let every script kiddie on the planet have a crack at killing me. It's called "negligence" and where I live it's a breach of health and safety laws.
Control has always been scarily flakey
A lot of the problem is that SCADA is often seen as a control or operations thing rather than anything to do with the IT function. As such, the IT peeps often don't know about it and the operations guys don't know about data and network security.
These things don't often get tested. The vendors see no value in it and even if a user's IT dept. are aware of it, it is often left out of testing scopes due to the fact that the systems often have little or no redundancy and the IT guys have no clue how to fix it. Never mind the catastrophic business impact of a device failing.
Yes, I have accidentally crashed a controller and halted a factory during a pen-test (with no more than a simple TCP port-scan). Admittedly that was a few years back but there's been no indication of the vendor's attitudes changing over the years.
This is hopefully the big kick up the ass they need to do something about the problem. Either that or some form of legal regulation of the vendors to force them to take the issue seriously.
I've a couple of friends who work in process control/design and have done so a a few different plants each. I've asked both of them about this and they have both said that they're not even anecdotally aware of plants where the SCADA controll systems are not firewalled off from the Internet. Control termainls being on the same network, wired, secure.
I do custom SCADA and process control software. Every time I get asked about security, I explain that I can implement security features X, Y and Z, and everyone is happy. Then I say that they cost A, B and C respectively, and they invariably say "okay, then don't do it - our network is secure anyway". This doesn't seem to depend on the actual values of A, B or C.
So far, *nobody* has been willing to pay for even the most basic security feature, and it's time-consuming enough to do correctly that I won't do it for free. I can't even do it at a loss and use it as a selling point, because nobody cares. Don't blame the software designers, blame the factory owners.
Probelms securing control systems
Theres a good opportunity here for someone to earn a lot of money telling people how to secure their scada/control systems. We have been under pressure for years to connect out system to the intranet/internet and have only just caved in due to the decision being taken out of our hands. Why is it connected-? purely to service the need of 'visualisation' /business information, and this is the trend throughout all industry it seems. Don't listen to your technical guys on the control system who don't want to connect to the internet, listen to the IT guys who want to provide information to the manaement.
The main problem in securing the system is that you can't patch and reboot without stopping production. On out site we have a 4 hour window every other year to do anything we have to with hardware/system upgrades. The only other time we could patch the system is if the power and generators and UPS all fail
vulnerability of SCADA systems had long been theorized?
> The security of software used to control hardware at nuclear plants, gas refineries and other industrial settings is coming under renewed scrutiny .. The flaws, which reside in programs ..
What Operating System does this SCADA software run on and why is it connected directly to the Internet instead of behind VPN units running of embedded hardware.
> The vulnerability of SCADA systems had long been theorized, but it wasn't until last year that the world got an object lesson on just how susceptible they could be to attack ..
Oh, come on elREG, even your own previous stories have covereed this, hardly theorized ..
> There simply is no boardroom advocate of Proper Engineering. Boardrooms are populated with Excel-Warriors, Marketing Propagandists and Law Twisters (aka "lawyers"), Frank Gerlach Handle
I like it ... :)
Locking down SCADA is a nice thought but...
When it comes down to it SCADA/PLC/Controls folks have less authority then even IT. I expect most have tried to keep these systems locked down because they are so fragile. In the end you have to crack them open so people can get the pretty charts and graphs. When it comes down to it most of this stuff was intended to never be hooked into the internet or internet capeable computers and has no protection as a result. When you can't say "NO" to opening up stuff security stops being a serious priority. Even had a department head once dual home his PC so it could touch internet and control network directly. Because, using ftp to get files through the control network firewall was too inconvienent.
Why bother knocking out the app...
If all you want to do is stop the application and whatever it controls, usually these days all you have to do is stop Windows. Remotely taking out a Window box is so trivial it hardly seems worth looking for SCADA-specific exploits.
Windows (and its vulnerabilities) isn't even mentioned in the article; does it get mentioned in the original source material?
Re: why bother knocking out the app
"Remotely taking out a Window box is so trivial it hardly seems worth looking for SCADA-specific exploits."
That may or may not be true for the unpatched ancient versions of Windows that some control systems run on, but it certainly isn't true for a fully patched current version. The black hats have given up running the contest to crack a Windows box, because in recent years no-one has been able to do it. (Now if you can persuade someone to surf the web from that machine and maybe use some Adobe plug-ins, then yes, it's pretty easy to knock out the box. But that's a different situation again.)
Another reason to target the app is because you don't want to knock out the box. You want to knock out the centrifuges it controls.
"You want to knock out the centrifuges it controls."
In an ideal world, yes, you want to knock out the centrifuges the Window box controls. But sometimes a denial of service is good enough.
"The black hats have given up running the contest to crack a Windows box, because in recent years no-one has been able to do it. "
I thought it had become so trivial that no one was particularly impressed any more?
"[take out Windows] certainly isn't true for a fully patched current version"
You're joking, right? Did you follow Stuxnet at all? How many zero-day exploits did it use? Zero-day exploit meaning an exploit that was unpublicised and therefore unpatched? And just because Stuxnet used a few doesn't mean there aren't plenty more waiting in the wings for whatever Stuxnet-inspired effort comes next on whatever version of Windows is still relevant at the time.
Five seconds of Internet searching finds a February report of a zero day exploit which immediately provides a Denial of Service attack and in the right (admittedly obscure) circumstances potentially provides a remote code execution attack. DoS on all versions of Windows with an SMB server.
Or do others know better?
Secure SCADA Comm Isn’t I.T. it’s Eng
Folks with all due respect, I politely suggest you backtrack to "what is the anatomy of the problem?" While as IT folks we're all naturally analyzing / working with the SCADA Master Control "frontend" (a/k/a HMI) and the Internet issues, SCADA systems' functionality occurs via legacy "endpoint" SCADA control devices. There are issues here from 40-50 yrs ago: SCADA’s control protocols (and vendors’ and proprietary / custom-built sftwre and even hrdwre dvcs) were designed under "closed-trust". Most control devices require no authentication from any device issuing a command proving it is allowed to do so.
Therefore, while the Internet's important, with securing SCADA Comm you've got to put that in the back of your mind, because really the key issue is that legacy physical architecture(s): PLCs and RTUs that can be hacked/jacked-into like hot knives into warm butter, esp. since these devices are remote and isolated. Yet, despite their locations, some of these can cause a lot of damage, and some are even critical. And that ain't changing, until the agri, power, trans, water, chem, and other industries decide to replace all this critical SCADA endpoint/device infrastructure. That’s billions we’re talking here …dollars, euros, yuan, etcetera. Who’s going to pay for it? Furthermore (for now, specif. RE: the elec. power indus.) until recently there hasn’t existed any approved public or private SCADA cybersecurity guidelines or standards (SOURCE: Dr. Göran N. Ericsson of the Svenska Kraftnät (Swedish National Grid), "Toward a Framework for Managing Information Security for an Electric Power Utility—CIGRÉ Experiences." IEEE Transactions On Power Delivery 22.3 (2007): 1466; although 08/2010 the U.S. NIST did publish NIST IR-7628.) But while that's great, risk mgt., e.g., mitigation, is not enough – so look to “YASIR: A Low-Latency, High-Integrity Security Retrofit for Legacy SCADA Systems” - http://www.ists.dartmouth.edu/library/451.pdf
- Geek's Guide to Britain INSIDE GCHQ: Welcome to Cheltenham's cottage industry
- 'Catastrophic failure' of 3D-printed gun in Oz Police test
- Game Theory Is the next-gen console war already One?
- Apple cored: Samsung sells 10 million Galaxy S4 in a month
- BBC suspends CTO after it wastes £100m on doomed IT system