This post was inspired by two tweets from Reid.
@SynAckPwn@digitalbond I’d be happy just seeing ICS-CERT publish its internal advisory-handling guideline documents.
— K. Reid Wightman (@ReverseICS) October 21, 2014
@SynAckPwn@digitalbond Right now I think the public has assumptions about what they do, assumptions which are totally wrong.
— K. Reid Wightman (@ReverseICS) October 21, 2014
First, DHS needs to stop putting everything they do under the ICS-CERT umbrella. There is a CERT function, and there is a bunch of other non-CERT activity. The naming confuses everyone, and you would almost think that is intentional.
Next, as Reid suggested they should be very clear about their vulnerability handling processes. Right now it is coordination of what researchers submit and the vendor response. There is no analysis, no evaluation of impact, no validation of the vulnerabilities, and no validation of the fix. If the vendor says it is fixed, the alert or advisory says it is fixed. The vendor is not even asked how they fixed the vuln. The process, the best that we can tell, is simply coordination of messaging from other peoples info. Figure out what boilerplate fits best, pull some info from the vendor announcements, and put out an Alert or Advisory.
You probably surmise from my tone that I think this is inadequate and actually of little use. It is particularly harmful when they measure success based on the number of alerts and advisories issued. My recommendation would be to shut ICS-CERT down and just roll it into US-CERT. The whole purpose of ICS-CERT at its creation was to provide second level support for US-CERT when ICS vulns were found. We did not need to replicate the existing coordination function.
However, I realize some see value from the Alerts and Advisories, so I would count it a success if ICS-CERT was simply forthright about how they handle ICS vulnerabilities and generate Alerts and Advisories. Reid is right that the public has assumptions about what they are doing that are totally wrong.
———
I’ve been sitting back and watching to see what activity Reid’s S4xJapan talk would generate. When he found the vulnerabilities in Version 2 of CoDeSys it generated some Advisories that eventually stated the problem was fixed in Version 3 based on the vendor provided information. As we now know Version 3 has the same vulnerabilities as Version 2.
Yet two weeks later there has been no correction or updated Advisory. This is an issue that affects PLC’s and RTU’s from over 100 different vendors, and many of these vendors and their customers believe all is well since they are running on Version 3 of CoDeSys.
Reid showed the exploits on two Japanese products, one from Hitachi and the other from Sanyo-Denki. The later is used to control robot arms. There have been no Alerts or Advisories for these specific examples or the 100’s of affected products.
———
To be clear, I’m not saying ICS-CERT should jump every time a researcher demonstrates a vulnerability. The whole vulnerability in ICS is overplayed given that ICS-CERT does not consider insecure by design as a vulnerability.
They should have a clear and public set of procedures for vulnerability handling so the community can understand what they can expect and how they should interpret the Alerts and Advisories.