Adding value.

After Heartbleed we figured we ought to formally define a disclosure process, and the team voted on a proposal of how to deal with the next serious security issue.

We based our proposal on our experiences dealing with OpenSSL issues as well as how they are handled by the rest of the industry. It was based on these assumptions:

- the more people you tell in advance the more likely is that a leak will occur. This has been proven with previous notifications both from OpenSSL and other projects.

- OpenSSL is used in a lot of products. Seriously, a mindblowing number of products from an equally large number of companies use OpenSSL.

- OpenSSL strongly believe that the right to advance patches/info should not be based in any way on paid membership to some forum. You must not be able to pay cash to get security patches in advance.

- OpenSSL saw some companies that were given advance notice of the Heartbleed issue use it in marketing statements about how they protected their customers before their competitors. "if you bought our product/service then you would have been protected". This is egregious.

- We don't get enough serious vulnerabilities in OpenSSL to warrant spending signficiant time keeping our own list of vendors we trust, or signing framework agreements, or dealing with changes, and policing the policy. (Even dealing with the disclosure around this CCS issue was several person-weeks of effort.)

- OpenSSL has attempted using third parties to handle notification on our behalf in the past, like CPNI, oCERT, or CERT/CC, but we have had issues with all of these.

- It's in the best interests of the internet as a whole to get fixes for security issues out quickly. OpenSSL embargoes should be measured in days and weeks, not months or years.

- Many public sites affected by OpenSSL issues will be running a version of OpenSSL they got from some vendor (like Red Hat or Ubuntu). The quickest way for them to be protected is to get a new vendor version of the package to deploy. Sites who use their own OpenSSL compilations should be able to handle a quick patch and recompile once the issue is public.

- We can benefit from peer review of the patches and advisory. Keeping security issues private is a pain because they can't get the level of testing or scrutiny that they otherwise would.

For our June OpenSSL advisory we therefore decided

- to give a couple of companies we know to have experience with in depth SSL protocol issues a few weeks headsup to help investigate and ensure our fixes and advice was valid, and to probe if this issue was being exploited in the wild (there were no signs of this)

- to let the companies that have a general purpose OS that uses OpenSSL have a few days notice in order to prepare packages for their users. We used the http://oss-security.openwall.org/wiki/mailing-lists/distros for this purpose. Two of the companies we told found issues with the patches that would otherwise have required additional releases.

- to give companies that handle critical infrastructure or have widely used sites some notice that an update was coming with the date and time, but no other details about the issues. We used the ops-trust forum for this purpose. https://openid.ops-trust.net/about

- We'd like to have given the whole internet notice that an update was coming out at a certain date and time, but given the level of press around Heartbleed this would just have led to a lot of stress and panic. Next time we might try this (or set up some regular cadence for updates so users always know when the next update is coming).

Things were a little more complex this time because the reporter of the most serious issue first contacted JPCERT who notified CERT who in turn gave a headsup to all their contacts. This meant we had to turn down requests for patches from companies who didn't qualify for disclosure this time. Can't hug every cat. Some companies were quite insistant that they were more important than others and that we should just allow them as an exception. Even though in many cases they just wanted the details so they can patch their products in advance. If you are one of those companies you should consider how you can add value to the open source projects you rely on.

What is a "general purpose OS" anyway? How about a provider that doesn't provide you an OS but provides you an OS as a platform/service. One of the reasons we used the distros list was so they could make those determinations in a wider context and not have arbitrary made up rules from OpenSSL. It would certainly help other OSS projects that want help giving advance notifications if there was a standard way that works. (As stated in this article OpenBSD had said not to be told about issues under embargo, but they've now asked to find out about future OpenSSL issues).

OpenSSL have said we'll evaluate how disclosure went this time and use it to adjust our process for future serious issues (and publish the policy so it's clear and obvious). Some of the companies told in advance certainly added value to the process, finding issues in the advisories and patches, but that was unfortunately the minority of those who were told.