1. ICS-CERT Takes Control
I have been critical in the past of ICS-CERT’s letting vendors determine when a vulnerability is disclosed. They have changed their policy.
UPDATE! In cases where a vendor is unresponsive, or will not establish a reasonable timeframe for remediation, ICS-CERT may disclose vulnerabilities 45 days after the initial contact is made, regardless of the existence or availability of patches or workarounds from affected vendors.
This new policy gives ICS-CERT the flexibility that the myriad of disclosure cases require. They don’t have to disclose in 45 days, and there are many cases where it wouldn’t make sense. For example if there is no exploit in the wild, it is not an easily identified vulnerability, there are not could compensating controls and the vendor is diligently working on a patch or other fix.
Good job ICS-CERT. Now use this discretion if the vendors aren’t doing the right thing.
2. The ICSJWG Vendor Subgroup Releases Common ICS Vulnerability Disclosure Framework
Rob McComber, Ernie Rakaczky, Bryan Owen and a bunch of other respected vendor security representatives have been working on this for a while, and it’s great to see it out there to educate other ICS vendors. While there are a few items I disagree with, especially in the customer discovery section, the vendors didn’t evade responsibility for disclosing embarrassing info. The best example is this quote from Section 4.2.2:
For exceptionally high risk vulnerabilities which expose customers to significant threats, disclosure of an internally discovered vulnerability is highly recommended even in situations where a resolution is not available.
ICS vendors should definitely check out Section 6 which describes the elements in a vendor vulnerability disclosure policy.
Now that this is out it should get some publicity at the ICSJWG fall meeting, recorded webinar and provided to every ICS vendor who gets drawn into the vulnerability disclosure process by ICS-CERT.