Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

DHS Thinks Some SCADA Problems Are Too Big To Call “Bug”

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.

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.

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.

I can atest for that. I work for an ISP. Having just discovered a local water facility having all of its SCADA devices on the public internet. When approached and asked to install a firewall for protection their IT consultant turned around and blamed us for lack of security.

Marty is a DHS bureaucrat. Like any government organization, DHS and ICS-CERT are subject to government regulations regarding dislosure of classified information. If these "design flaws" are found in devices that are connected to critical infrastructure that information would be considered classified as a national security matter. They will disclose that information only to a carefully vetted group of asset owners/operators with the proper security clearance. Some would say that is prudent while others think it is irresponsible to hide that data. Guess which side of that argument the government lawyers that dictate the policy with which Marty must comply are taking?

Hear is a thought to stir the pot with.
The DHS in effect has decided to turn decades of industry poor practice into a virtue...
Rather than let all people with these systems know there are sever critical and difficult to fix security problems, they will keep it quiet and let only "the chosen few know".
Why? well how about they want to add them to the US "Cyber-arsenal" for use against "uppity nations" who chose not to kow-tow to what Hillary Clinton et al says "is good for them" because in reality it's not good for them just "good for the old US of A".
Let's put it this way so far the only well known attack on SCADA systems is "Stuxnet" which according to many has the USA's fingerprints all over it.
There is an old saying about "Don't put the fox in charge of the hen house".

Battelle, which runs the INL (which runs ICS-CERT) is paid by DHS and SCADA vendors. The statements from the Undisclosed Official highlights this "goodness" of the business model for all parties:
* Pretend to care about security
* Do no real work
* Get taxpayer dollars

Typically DHS has it's head in the sand for various reasons. Lots of SCADA consultants out there don't have a clue about secutrity either. Just look at the amount of SCADA running in the Microsoft environment. Think about the DHS requirement for razor wire on fences around water tanks, but not requiring the fence to completely surround the tank. DHS is way too big, doesn't know the territory and blindly listens to vendors.

I think its going to take a huge event for people to really pay attention.

Yup, and you all can be certain that many foreign governments are reading these words even as we type them. I submit that many of the SCADA meisters have it fixed in their heads that Anonymous or LulzSec will be the perps. I will guess that it will end up being some foreign state taking out two of our three electric grids.

hmmmm 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.

So, Stux took advantage of a vulnerability that existed in the S7, but by a new definition, its no longer a vulnerability. Doesnt seem to pass the giggle test to me.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.