Comment from Ralph Langner
Time: August 20, 2008, 4:06 pm

There is a problem with vulnerability disclosure to CERT, Dale. People from the office IT world tend to think of vulnerabilities as bugs. The vulnerabilities that matter most in the control system world, however, are features, not bugs.

There was an interesting response on Matt’s original blog post (within the FranzBlog) that started the current stream of vuln-disclosure related discussion. The respondent talked about disclosing the default vendor accounts and passwords for popular control system products — an excellent example for a vulnerability that matters, but which would leave CERT without an answer. I could go on with other examples, but we don’t want to get the attention of the guys with the hat here. I don’t advocate security by obscurity, but I’m afraid there are some hot topics within the vulnerability landscape where CERT can’t help. How do we handle these?

Comment from Bill Gross
Time: August 22, 2008, 9:54 am

Dale;

A similar debate recently resurfaced in the IT security space as the result of the Kaminsky DNS vulnerability.

Your assessment is correct, that the only disclosure policy that matters is the one employed by the discoverer of the vulnerability.

Now, Ralph also has a good point.

I have two things to say:
1) The vast majority of bugs are discovered by researchers, and most researchers, in all probability, are regular readers of the US-CERT vulnerability list. If the general consensus is that control system vulnerabilities are disclosed through US-CERT, then a researcher who stumbles across a bug will, in all probability, do what everyone else is doing, and disclose to US-CERT.

Now, some won’t, but the goal is to get some consensus.

2) Ralph’s point about non-vulnerability, but potentially security related issues is valid.

But that’s where having common communications channels comes into play.

It seems that for a lot of this kind of “best practice” discussion, each industry works in a silo, either keeping information within the organization, community, or sector.

The problem is that in a lot of infrastructure situations, you have control systems used in many sectors. For example, in power facilities, you have similar systems you might also find in a water facility.

It would be nice if there was a cross-sector communicating community that focuses on lesson’s learned, best practices, etc.

It seems that this is handled now in the conference space.

Bill

Comment from amino world
Time: August 29, 2008, 3:20 pm

i’ll concede your point(s), dale, and not altogether reluctantly. i’d hoped for better, more grown-up solutions, but i can smell the coffee from here. (mmmmm… coffee.) i worry about what’s in the “freezer”, too. (who hasn’t heard “nobody else is having this problem” from their favorite vendor only to see the fix posted in the next set of release notes?) the user group channel may be the best way for the vendor to disclose the availability (and urgency) of vuln repair.

digital bond’s policy seems to be a ‘best of breed’ — at least for right now — and there’s certainly lots of room to lead by example in this space. using CERT makes sense, too, and helps build that org’s credibility for the process community. thanks for your work and sharing your comments.