ICS-CERT Vulnerability Reporting

There was an interesting Twitversation this morning about how ICS-CERT deals with the publication of zero day (0day) vulnerabilities (a vulnerability that is released to the public without prior coordination or notification to the vendor) that have been released as parts of exploit packages. The conversation was started by Joel Langill’s (@SCADAhacker) announcement that Gleg had released their latest version of SCADA+® and that it contained 3 0day control system vulnerabilities. I replied with a somewhat sarcastic comment about how I did not expect ICS-CERT to publish an alert for those three 0days. The conversation expanded from there.

Gleg Background

GLEG Ltd. is a Moscow based small security firm. They produce (among other things) a product called SCADA+. It is a penetration testing tool (similar to Metasploit®). It is supposed to contain a comprehensive selection of exploits for industrial control systems. Those include publicly available exploits as well as exploits developed in-house by Gleg, including those for Gleg discovered 0day vulnerabilities.

Gleg sells this tool to companies and researchers and they periodically update the tool. Joel is apparently a customer of Gleg because he routinely reports when a new version of SCADA+ is released and the SCADA+ web site is at least 3 releases behind what Joel is reporting. This is logical because Gleg would want to provide its paying customers with notice about 0day vulnerabilities before they are publicly announced.

NOTE: Gleg has a relatively new product out; MedPack. It apparently does for medical software (device and IT) what SCADA+ does for control systems.

Early ICS-Reporting on Gleg

When the SCADA+ Pack was first released as an add-on to the Gleg Agora product in 2011, ICS-CERT issued an advisory about the product. It also produced alerts (here and here) for two early updates that contained reported 0day exploits. Since then there have been no further alerts or advisories from ICS-CERT on SCADA+.

ICS-Reporting Products

ICS-CERT provides two types of notifications about control system vulnerabilities; alerts and advisories. They describe them this way:

• An ICS-CERT Alert is intended to provide timely notification to critical infrastructure owners and operators concerning threats or activity with the potential to impact critical infrastructure computing networks.

• Advisories provide timely information about current security issues, vulnerabilities, and exploits.

Generally it would seem that alerts are issued when there has been an exploit published for a 0day vulnerability. An advisory is issued when there has been at least some level of notification to the vendor either directly or through a coordinating agency like ICS-CERT.

Why Stop Gleg Reporting

The question that came up in the Twitversation that I describe earlier is why ICS-CERT had stopped producing alerts or advisories for SCADA+ updates since they frequently reportedly contain 0day vulnerabilities. Joel questioned if ICS-CERT had a mandate to report vulnerabilities that were not coordinated through them and that is certainly a legitimate question.

The ICS-CERT web site contains an explanation of the mission of ICS-CERT. In the last two of six bullet points it includes:

• Coordinating the responsible disclosure of vulnerabilities and associated mitigations; and

• Sharing and coordinating vulnerability information and threat analysis through information products and alerts.

Given those broadly painted guidelines it would seem that reporting SCADA+ updates that included 0-day vulnerabilities should definitely a responsibility of ICS-CERT. In fact, I could make the case that for previously reported vulnerabilities for which there had been no publicly reported exploits that the inclusion of the vulnerability in SCADA+ (or other penetration testing products like Metasploit) represents an escalation in the severity of the vulnerability that should be reported by ICS-CERT.

Supposition

I am going to preface this next portion of the discussion by saying this is made up from whole cloth in my head and may bear no resemblance to actual fact. It is being presented for discussion purposes only.

I can think of at least one possible reason to explain why ICS-CERT stopped reporting on the Gleg Scada+, and it is a potential legal issue. The public documentation for the updates provides almost no information on the character of the 0day vulnerabilities. I haven’t seen the customer documentation, but based upon the three ICS-CERT documents that have been published it would seem that there is little detailed information provided to customers. To dig out the 0day exploit details that ICS-CERT would be able to use would require reverse engineering the software.

I fully expect that ICS-CERT has the talent, skill and inclination to do such reverse engineering (and it would presumably get simpler with each new release).  While reverse engineering software falls within grey areas of the law, the public sharing of information from that process would certainly violate a couple of US laws dealing with intellectual property.

I would like to think that ICS-CERT if they discovered actionable details about a 0day vulnerability that they would notify the vendor of the vulnerability so that they could fix the problem. Then in the normal course of events they would publish an advisory for the vulnerability without listing a researcher.

If ICS-CERT acknowledged the Gleg release for a 0day vulnerability and then subsequently reported an advisory for mitigating that vulnerability I can imagine DHS lawyers getting concerned that Gleg might complain (ie: take DHS to court) about ICS-CERT effectively stealing the intellectual property from Gleg. That would be much harder to sustain if DHS publicly ignored the Gleg update.

Policy Question

As it is becoming more and more obvious that control systems in many critical application are vulnerable to cyber attacks the role of ICS-CERT in being an information development and sharing organization becomes ever more important. Congress needs to start considering what type of role ICS-CERT should perform by-law. In my opinion one of the most important tasks that ICS-CERT should have is the information sharing role concerning vulnerabilities in industrial control systems.

That information sharing takes a couple of different directions. They include sharing vulnerability information with:

• Vendors concerning vulnerabilities that have been identified by independent researchers, outside research groups, ICS-CERT and intelligence agencies;

• Researchers concerning actions being taken by vendors to mitigate vulnerabilities;

• Critical infrastructure owners concerning vulnerabilities identified and mitigation measures developed; and

• The ICS community in general about trends in vulnerability detection and mitigation.

There are, of course, other areas of information sharing that would be important for ICS-CERT to be involved in, but those will have to be discussed on another day. This post has gotten a tad too long already.