.gif)
SCADA-targeted malware was inevitable and I suspect, despite the fact that it took this long to happen, that we haven’t seen the last of it. There’s a forest and trees lesson here that I hope we learn through this. Before we get too carried away on a specific vulnerability and throwing stones at software vendors, let’s not forget about the importance and value of basic, layered security controls.
The Stuxnet malware was active for at least a month and spread around the world before it was identified and recognized. To Dale’s point, what else is out there that we don’t know about yet? And if you can’t prevent an attack, how can you limit the damage through effective security controls? Here are a few random thoughts:
Egress filtering. Most control system networks have room for improvement on this and I still find myself explaining why it is important. This is one area where control systems have more ability to be restrictive than enterprise networks. Take advantage of it.
Your control system application has default accounts and passwords. I would just start with that assumption and plan accordingly. If you can change them, great. If not, implement mitigating controls like IP-based restrictions and then monitor where possible. Don’t forget about supporting applications like database servers. If you’re buying a new system, make sure you address default accounts and passwords in the requirements and verify at FAT and SAT.
Host hardening. You had to know I’d mention this one. Obviously it doesn’t always prevent a 0day exploit, but it may limit the damage or effectiveness. Case-in-point: Microsoft’s Security Advisory for Stuxnet lists disabling the WebClient service as a means to block a likely remote attack vector (WebDAV) for this malware. Many of our Bandolier Security Audit Files verify that the WebClient service is disabled for control system applications components running on Windows.
Application whitelisting. Yes, I’m still a fan. CoreTrace, maker of the Bouncer application, has a blog related to Stuxnet here. They continue to make inroads to the control system world. I know it’s not a cure-all but what else has as much promise of preventing 0day threats? Traditional AV obviously doesn’t.
I realize that I’m lumping vulnerability, exploit, and payload into one issue here and only hitting a few possible controls but I think the point is valid: basic layered defense is still important and we can do better at it in the control system space. Let’s let the Stuxnet/WinCC malware be a reminder and a call to action.
I agree on pushing egress filtering, hardening, and whitelisting. I must say that I am happy about having successfully implemented whitelisting solutions at clients’ sites on WinCC stations weeks ago.
One point where I disagree is to specifically focus on default accounts and passwords. There are so many other iDay vulnerabilities (= infinite day, they won’t go away because they’re not really bugs) in the popular products that one should really think about a Swiss cheese with all its holes. The worst thing would be to assume “all we have to do is fix that password issue, and we’re secure”.
The suggested workaround to defeat the effect of disabling the .lnk file the result of “lost” icons & to loose their visual significance on an operator screen is equally one of those useability questions for may SCADA operators to suggest that it creates more problems than it solves.
So if for some reason you have not done it already you disable the web client and move on. Wherever you can you change defaults accounts unless they are embedded in the operating system code. There are a heap of other mitigatons that the enterprise should have in place and it be merely a matter of assessing the risks and validating the mitigations you put in place and continue with whitelisting -/ Trust but verify effective segmentation (not just logical) etc, as you have both mentoined. Outbound channel monitoring is a wonderful way of detecting unauthorised activity. the thing is these are all things that are not high in capital outlay but rather usually involve some configuration and validation. The trick is in havng enough time to do security justice it is a struggle. Certainly I agree with the need to call everyone to action.
Keep smiling
Good points again – in my comment over on Dale’s post, what about grander concepts of whitelisting, that check activity on the network — such as which applications are in use, what they’re being used for, whose using them, etc. –matches a whitelist of known policies? I tried to expand on the notion of broad monitoring and correlation over at siemblog http://bit.ly/dfofN3 … check it out, and if there’s interest in more detail, I can go into more depth … well, maybe after blackhat ;-)