The Stuxnet worm may be the most famous piece of malicious software ever written. When it was first detected, a little over a year ago, the worm sounded a warning to nations around the world that critical infrastructure systems were potential targets of attack for foreign governments and cyber criminal organizations alike. But with the anniversary of the Stuxnet worm’s discovery just past, the Department of Homeland Security admits that it is now reevaluating whether it makes sense to warn the public about all of the security failings of industrial control system (ICS) and SCADA software.
Changes in the way DHS warns the public and the vendor community about security issues in ICS products could recast certain kinds of vulnerabilities as “design issues” rather than a security holes, according to a senior DHS cybersecurity official.
In an interview with Threatpost, the senior DHS cybersecurity official, who agreed to speak on the condition that his name not be used, said that some of the security problems facing ICS and SCADA systems are just too big to describe as “vulnerabilities” and that issuing vulnerability alerts for them doesn’t make sense. SCADA experts working outside the agency, however, wonder if the agency is simply caving in to vendors and ducking responsibility for forcing changes that will secure the nation’s critical infrastructure.
Speaking at the Applied Control Systems (ACS) Conference last week in Washington, D.C., Marty Edwards, the director of DHS’s Industrial Control System Computer Emergency Readiness Team (ICS-CERT) said that the agency is pursuing a different process for handling what it considers the security implications of “systemic design features” in ICS systems apart from the process it uses for warning about security vulnerabilities in those systems. DHS will refrain from issuing ICS-CERT security advisories for problems that it considers “design” issues, rather than software security holes.
Edwards said the community needed a different process for addressing systemic design features than the current CERT vulnerability alerting process. “CERT is there to provide near real-time, actionable mitigation information. We can’t afford to bog down that process by trying to redesign entire control systems from scratch,” the senior official told Threatpost on Monday.
As an example, the official used a hypothetical situation of an ICS system – or even a whole category of ICS products – that communicate with each other using clear text protocols, which can be easily intercepted and deciphered. “If a control system is designed to use clear text protocol, and upgrading it to make it secure means replacing all the functions that use that protocol, that’s not something we’ll alert on from CERT,” the senior cyber security official told Threatpost.
If, on the other hand, an ICS product contains a buffer overflow vulnerability that could be exploited, and for which a patch could easily be created and applied, that is something that ICS-CERT would issue an advisory for. The difference, said the DHS official, is that the clear text protocol issue is a “larger design process” that can take a lot longer to fix.
The official cautioned that DHS, through its Control System Security Program (CSSP) isn’t ignoring the larger design problems, just taking a longer view to addressing them. “Its an entire thought process the community has to go through,” he said.
But security experts briefed on the agency’s new thinking are concerned. Ralph Langner, an ICS security expert for Langner Communications GmbH, wrote critically of the new approach on his blog last week, arguing that DHS was pursuing a “semantic approach” to mitigating vulnerabilities in ICS software.
“This radically cuts the amount of vulnerabilities in the ICS space by roughly 90%, since the vast majority of security ‘issues’ we have (I try not to call them vulnerabilities) are not bugs, but design flaws. So today everybody has gotten much more secure because so many vulnerabilities just disappeared,” Langner wrote.
The new thinking about what constitutes a software vulnerability is also a departure from earlier DHS guidance. The DHS/CSSP “Catalog of Control Systems Security” (PDF) document defines the term “vulnerability” as ” A flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy,” Langner pointed out.
But the DHS official cautioned against making too much of the agency’s shift in approach for software vulnerabilities.
DHS and ICS-CERT will almost certainly continue to issue advisories for security holes that are being actively exploited. Besides, the CSSP has many different avenues through which to talk to vendors and critical infrastructure owners. “They understand. They get it and they’re working diligently through the different working groups.”
The shift by DHS seems intended, in part, as a response to recent press coverage of vulnerabilities discovered in SCADA and ICS software.
Researchers like Dillon Beresford of NSS Labs have made headlines by calling out serious and exploitable vulnerabilities in ICS products, including hard coded administrative passwords and denial of service vulnerabilities. Beresford unveiled 18 such vulnerabilities affecting Siemens Step 7 (S7) ICS products at the Black Hat Briefings security conference in Las Vegas in August, and put pressure on officials and vendors to address the problems. ICS CERT issued advisories in July to the industrial control community regarding some of those vulnerabilities.
However, behind the scenes, some in the ICS community expressed frustration over the work of researchers like Beresford, whose background is working with more traditional IT systems and networks, not within the industrial control sector. Speaking to Threatpost, the senior DHS cyber security official said DHS is worried that it will be accused of “crying wolf” over low level issues or vulnerabilities that are not likely to be actively exploited.
“It seems like some folks come into this area and aren’t used to ICS nuances and get overly concerned immediately,” he told Threatpost. “You have third party researchers who leverage same design deficiancy in 15 different devices. If (the ICS devices) use a clear text protocol and everybody knows that, its not a vulnerability that it talks clear text,” he said. While some of the discoveries by researchers like Beresford may warrant an advisory, he said, others may not. “It may not contain enough uniqueness to warrant an alert. We don’t want to spam the industry.”
What does and doesn’t warrant an advisory may come down to the judgement of an ICS-CERT analyst, though DHS has few specific guidelines.
“If its a bug that can be patched, we’re gonna talk about it. If there’s a buffer overflow or hard coded password that the vendor can fix without re-engineering its products, that’s something we’ll issue an alert on,” the DHS cyber security official said.
However, in other cases, the agency may not. For example, hard coded administrative passwords of the kind that the Stuxnet worm took advantage of in Siemens S7 ICS devices might not qualify as a vulnerability – the existence of the password was well known within ICS circles and was a critical component to the S7 system – so much so that Siemens advised customers not to disable or change it even after it was known to be exploited by Stuxnet.
DHS officials declined to speak specifically about Stuxnet. However, in such a case, the DHS official said ICS-CERT may merely advise customers to work with their ICS vendor on a workaround, rather than issue an advisory that forces customers to change or remove the password.
