Digital Bond performed its first SCADA security assessment in 2000. The 9/11 attacks that supposedly changed everything in critical infrastructure security occurred in 2001. Yet as we have chronicled in this blog, the ICS community as a whole is still amazingly vulnerable ten years later. We will not get that lost decade back, but we should learn from it and adapt our approach as a community.
Ten years later we still have PLC’s, RTU’s and other field devices that have no security; the only security solution is don’t let the bad guys reach them. Control system protocol stacks while improving, still often crash if even a port scan is performed let alone intelligent fuzzing. The researcher/hacker community is showing that the ICS applications suffer from common and easily identified and exploited vulnerabilities. And a still high percentage of owner/operators are not performing Security 101 of timely patching, current malware protection, hardening configuration, least privilege firewall ruleset or user management.
This is not to say there has been zero progress. We have personal experience with asset owners whose systems SCADA and DCS are much more secure. Many SCADA application vendors have added security features to their solutions that run on workstations and servers and have begun to implement a security development lifecycle. Even the much maligned CIP standards have resulted in substation communication gateways with authentication, firewall capability and role based access control. But these success stories are all too often the exception, not the rule.
The community needs to take a serious look at why so little progress was made in the last ten years. What should we do differently to accelerate securing critical infrastructure ICS? Looking back, maybe treating ICS security differently than IT security and with kid gloves was a mistake. The mantra that ICS is different than IT led to dramatically lower expectations. A fragility was accepted for the SCADA application and network that would never be accepted in a mission critical IT system, or even in corporate email or the health benefits web app. Instead of shock and a call to action, the ICS community said control systems are different and you can’t do this or that or because it will break the ICS with catastrophic consequences. Hard to believe when you think about it.
Maybe if the ICS security guru’s had presented the findings loud and proud at events like Black Hat back in 2003 we would be much further along. There are a few data points now with 0day disclosures with exploit code, and accompanying publicity, that have caused a rapid response that quite frankly wasn’t and isn’t commonly happening when those in the ICS security community practice “responsible disclosure”.
Look at what Dillon Beresford did recently discussing multiple easily exploited vulnerabilities in the Siemens’ S7 controller. What if this had been done in 2005 to Siemens, Rockwell Automation, GE, and other controller vendors. The problems were known back then by those active in security in the ICS space. Would the vendors have begun then and released by now secure solutions? Would customers have demanded it? (The answer one would expect to both of these question is yes, but Stuxnet has not caused any visible reaction yet. Even the Automation press has stated that Siemens has handled Stuxnet well. It might take repeated vulns and widespread impact, like what happened to Microsoft with the worms, to truly change behavior)
Control systems are different has led to people accepting highly vulnerable systems for a decade or more until they have a scheduled install or upgrade of their control system. While control systems are not free or even cheap, they are a very small percentage of the underlying asset being controlled and often the very reason the company exists. Companies regularly spend large dollars on hardware refresh, ERP, financial software, on the corporate network, but hesitate to make regular investments in the control system IT. Why? Because control systems are different and the community has not pushed to make the investment.
Some vendors and asset owners are waking up and budgeting for regular software upgrades and hardware refresh for SCADA and DCS applications and networks.
As a final example, it would be hard to find a mission critical network that has as little support as many SCADA and DCS. Domain controllers, router, switches and firewalls, databases and other hardware and software is deployed by the vendor at commissioning and is critical to the continued operation. Yet all too often the ICS team lacks the trained personnel in these IT technologies. This is like putting an IT person in charge of plant engineering after commissioning and hoping no process changes or even troubleshooting is required. If you select and install this IT technology you can’t ignore it for ten years. You need competent personnel to maintain and manage it like any mission critical IT system.
The later President Bush did not have many memorable, serious quotations, but he said one thing that always stuck in my mind as being relevant to ICS Security. Speaking about education in certain American communities he discussed “the soft bigotry of low expectations”. We have accepted low expectations for the last ten years in ICS security. And this has resulted in very low results or minimal improvement in the security posture.
The new reality is that the ICS security community can no longer keep this as an inside secret even if we wanted to. There is blood in the water, and it is attracting researchers, hackers, criminals, offensive security efforts from nation states and others. There will be some attacks that affect the critical infrastructure. There will be market winners and losers based on how they react to this new risk environment. But there will also be significantly accelerated progress towards securing SCADA and DCS as compared to the last, lost decade.
Image by Mario in arte Akeu