Comment from Jake Brodsky
Time: July 17, 2007, 7:40 am

Dale, this problem is a bit larger than a simple survey can do justice to. There are dimensions for severity of the problem, the impact of an upgrade, and contractual conditions during discovery (if you discover the vulnerability during an assessment at a customer’s site, one ought to give them some time to fix their problems before going public with it).

US-CERT may not know what to do if a vulnerability is found with a PLC, for example. What if the vulnerability with the embedded logic in an instrument or a motor control center? Would they still know what to do? I’ve heard a few very smart programmers make some rude but accurate observations about CERT’s judgment. Frankly, it’s very hard to be an expert on all software. I don’t trust CERT, or anyone else for that matter, to get these sorts of judgment calls reasonably correct.

Disclosure is not a panacea though it often it is the right thing to do. Let’s agree that this problem is not a simple “if discovery, then do this” kind of deal.

Comment from Matt Franz
Time: July 17, 2007, 11:11 am

Jake,

Something I’ve been meaning to chime in for a while and to be honest I’m restraining myself. [Sentences deleted here]

Believe or not back in the Spring of 2006 when I was meeting with CERT/CC (trying to figure out what to do with the 1st 3 vulns Digital Bond submitted) up in Pittsburgh there were folks at the table that did not want to go forward with disclosure practice. In the end a judgement call was made to go forward with LiveData and the others because there was simply no forum to get the information to the right parties. Yes we discussed working with industry groups. The problem was nothing was being done. There was nowhere for reporters to go. Vulnerabilities were not being disclosed to end users such as yourself. Researchers couldn’t find out who within the vendor to report the flaw. Vulnerabilities that were being found as part of one DHS supported activity (INL CSSC) were not being passed on to another DHS supported activity (US CERT)

By going forward with standard CERT/CC-US-CERT dislosure practices the control system community it put the burden on the control system community to fix the problem if it really needed to be fixed. Who has stepped up to provide a forum? NERC? The ISACs? ISA? IEC? Discussions about risk, impact, are nothing new or unique to SCADA Disclosure and were tackled in the NIAC Disclosure Guidelines. Back to work.

Comment from Jake Brodsky
Time: July 17, 2007, 12:47 pm

Matt, I’m not criticizing anyone’s past decisions in this post. What I am attempting to point out is that these decisions are not simple affairs. Furthermore, I think that subject is something that needs to be discussed among the SP-99 community.

The point is that I couldn’t fill in the survey even if I wanted to, because this is not a problem with only one dimension to it and there are no simple answers.

Comment from Dale Peterson
Time: July 17, 2007, 12:57 pm

Jake, I know it is a multi-faceted subject, and one the IT community, who has been dealing with this for years, still argues about.

Look at it from a researcher or other vulnerability discoverer’s perspective. I find a vulnerability in a control system device, either accidentally or through an assessment, what do I do with it? I think the five answers in the poll represent the range of responses. So in some sense the response is straightforward and not complex.

Now I’m sure one could answer, the response depends on the details of the vulnerability, but we treat them all the same.

Comment from Ron Southworth
Time: July 17, 2007, 1:01 pm

I think Matt you have certainly made the community aware of the need to address this issue and the need to discuss how to approach it.

Where to from here? It needs to be raised as an agenda in various forums and meetings and see if a general workable approach can be found.

The stuff may be nothing new to you Matt and many others, the impact well that may be another point of differences of opinion.

Jake is certainly “keeping it real”. I do think that expertise is there to evaluate such risk Jake, however I don’t think that it can be handled at this point in time in the traditional Cert environment or approach.

I think that the end user, the vendor, the “designated” applied research facilities need to be involved along with the governments in some form and the activity needs co-ordination and dissemination of data and analysis of risk impact and even possibly resources to help with mitigation. All of this needs a wrapper with some mechanism for the industry to gain and develop trust.

Without this you won’t gain meaningful uptake of dealing with this in a control systems context. I have heard figures of 20% disclosure of information in the IT space , If uptake of the industry is a desirable then the above needs to happen, I believe. How it evolves in the long term is subject to change as comfort levels improve. The alternative I suspect is the intentions and effort you have exerted Matt may otherwise be wasted.

Comment from Matthew Franz
Time: July 17, 2007, 2:46 pm

Ron,

I really don’t see any of my effort as wasted regardless of what ultimately may happen. The US-CERT has a process (and several analysts that have some level of awareness on control systems) for handling vulns if they get reported. Other researchers have reported vulns to them which resulted in additional advisories. That alone is worth the 1-2 man months Digital Bond spent on this back in the winter/spring of 2006.

- mdf

Comment from David
Time: July 18, 2007, 1:46 pm

Missing option:
Open a consistent dialogue with the vendor through which the discoverer and vendor can plan:
A fix
A temporary workaround that can be applied until the fix can be installed/implemented
And the full disclosure of the problem
If the vendor is non-responsive, or not willing to produce a fix, or not able to produce a fix then full disclosure should occur with as much interaction with the vendor as possible.

I would recommend resisting the urge to build this process from scratch.
Start with a time tested vulnerability disclosure process. The software community, and related security researchers, have been pounding this issue into a malleable form that both vendors, researchers and users have become satisfied with. They have been working on it in a formal documented process since 2002.

http://www.wiretrip.net/rfp/policy.html

That policy directs the action toward the missing option, between the Vendor of the Software/Hardware/System and the finder (discoverer) of the vulnerability….And it works.

Comment from Matt Franz
Time: July 18, 2007, 9:37 pm

David,

I was not unfamiliar with RFPolicy when I started working this area but I think it is sort of obsolete and I’m not sure it is actually followed by researchers in the non-SCADA world, either.

I think it is a nice historical artifact of a more idealistic time prior to the release of 0-days, Month of whatever-stupid-protocol-or-application bugs, vulnerability sharing clubs and auctions, or folks shooting their mouths off about OSX Worms on Blogger then redacting.

The idea of a vendor-researcher exchange is nice idea but a disinterested third party is vital for both the interests of the finder and the vendor. I didn’t think it was reasonable to follow such an aggressive timetable for this community. Look at the timelines for the 1st 3 ICCP vulns (in http://www.threatmind.net/papers/franz-pcsf-disclosure-final.pdf)

But I do agree that starting from scratch is foolish. Although I seriously doubt interested parties (or that there are any Aleph1 or Russ Coopers of within the SCADA security world) to craft a policy.

And over a year later, I don’t think really think a special policy for SCADA is needed. These sorts of policy are really only necessary when there is a vigorous community of [naive] independent security researchers finding bugs. And by “independent” I mean finding/fixing bugs for the “good” of the community (trying to do the right thing) vs. as part of some commercial activity.

Is there any SCADA vulnerability research not tied to consulting practices or security products? If there isn’t then this is a non-problem IMHO.

Impacted vendors will do what they have to not lose customers, security consulting companies (I’m including the DoE labs here), and security vendors that do SCADA Vuln research (such as Mu and Tippingpoint) will do whatever makes business sense. Different business models and client bases will result in different types of disclosure policies and practices.

So I think the market will solve this issue just fine and before some standards body gets around to drafting a document that everyone can agree with 5 years from now.

Comment from David
Time: July 23, 2007, 11:42 am

“So I think the market will solve this issue just fine and before some standards body gets around to drafting a document that everyone can agree with 5 years from now.”

I like your observation.
Here is a question, what is the difference between “the market” and “some standards body?”
Are not they one in the same…for this and any other industry wide issue?

I like this observation too:
Once you can get their attention, SCADA/EMS
Vendors can and did release security fixes in a
relatively short time period
- Would not have moved as “quickly” if a trusted third-party
had not been notified
- Researchers should consider simultaneous notification to
vendors and coordination centers

I like the involvement of a CC, especially if it speeds things up.
I suppose my support would be behind any process that places its focus on infrastructure protection above all else. Where the primary goal is the safety and security of people.
I don’t think that is possible without notifying ALL users (operators of the effected control systems) of the serious issues QUICKLY. So that they are aware of the risk and can take mitigation steps.

This is a very interesting topic, with quite a few challenges. It will be interesting to see what direction all the various driving factors take it.

David