Early access to security issues for support customers?

At the face to face last year we discussed future funding models, and we are exploring a range of possible options. One suggestion raised was we could sell more support contracts and give those support contract users patches for security issues in advance.

But before we can even discuss this as an option we would have to change our public stance. Our security policy since 2014 has stated we would not do this and currently reads:

“We strongly believe that the right to advance patches/info should not be based in any way on paid membership to some forum. You can not pay us to get security patches in advance.”

So we will hold a OMC vote shortly to remove this from the security policy which would then allow consideration of alternative funding models.

No matter the outcome, no decisions on funding models have been made yet, and we do not plan to change our actual policy until we have a clearer view on all our funding options.

This is a delicate issue so the rest of this blog will give a bit of background on why we had this statement in the first place and what it meant.

Dealing with security prenotification co-ordination is quite time consuming; in the run up to release it can easily take several days of work just handling the prenotifications ¹ – this is partly because patches and advisory text often changes, sometimes as the direct result of testing by the people we prenotify. We also have to maintain a different system to allow this sharing which is cumbersome and error-prone, so extra diligence is required. But it is generally worth doing this for the companies we currently prenotify as many of them actually test and sanity check the patches and in the past these company have found problems that would have caused us to have to do multiple releases in quick succession. So our policy is to notify companies that have OS distributions that include OpenSSL and ask them to add value to those prenotifications.

We have tried using various third parties to help us handle wider prenotifications in the past, including CPNI, oCERT, CERT/CC. None were suitable due to a variety of reasons, but mostly because the timeline we want for the issues is so short for them. We want embargos to be in the range of of days, not weeks, as we believe it helps reduce risk and better protect all our users.

*[CPNI]: UK Centre for the Protection of National Infrastructure *[oCERT]: Open Source Computer Security Incident Response Team *[CERT/CC]: CERT Coordination Center

OpenSSL is ubiquitous, and we often get asked for prenotification by other organisations that are not an OS vendor but otherwise may include OpenSSL in their project or product in some way. But once you start doing this for one you have to have some defined program to vet and deal with these companies (such as maintaining NDAs) and the prenotification process becomes bigger and more time consuming to run.

An example of a company with a support model like this ISC. You can buy a support contract from ISC that includes early access to security vulnerabilities. This model has had some problems and public concerns, but we could learn from the changes they have had to make over their many years of experience.

Even if we get rid of the principal in our security policy, even if we decide to consider funding models such as this, it is not even clear if companies would want to buy advance notice for OpenSSL issues. There actually are not that many High/Criticals ². Even when ones crops up, if say that issue is found being exploited in the wild, we are not going to hold off releasing updates just because we have paying support customers expecting early access.

Let us know your opinions, we will start a thread on the openssl-users mailing list