A lot’s happening this week in ICS vulnerability handling and a lot of it is positive.
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.
3. More Examples of Vendors Self Reporting
Last week I praised OSIsoft for self reporting a vulnerability, along with the security patch, found in a DHS/INL assessment. This is still rare in the ICS space, but I had a number of people point out other instances where this happened.
For example, Emerson Process Management had a DHS/INL assessment of their WirelessHART implementation. The assessment found OpenSSL vulns, XSS, unsigned firmware updates and a couple of other issues. Emerson developed new firmware to address these issues, presented the findings at a User Group event, published the information for customers, and encouraged users to upgrade. They did not sit on the issues or do a silent fix to avoid embarrassment.
I’m sure there are more success stories, and loyal readers should know we are always receptive to publishing good news.
One cautionary note on the term “self-reported”. We should not be calling vulnerabilities that were found long ago by researchers, that are fixed much later by vendors, as self-reported.
Image by Chicagogeek