Standards get a bad rap. Too often, they are used as a stick to compel compliance. Not all standards follow this model, however. Sometimes, they offer help and pointers for best practices which were learned the hard way. ISO/IEC 29147 Information technology – Security techniques – Vulnerability disclosure (2014-02-15) and ISO/IEC 30111 Information technology – Security techniques – Vulnerability handling processes (2013-11-01) are two standards for vulnerability handling and disclosure that follow this latter model. They contain helpful pointers to examples of vulnerability disclosures that were particularly well done that can be used as templates. ISO standards are priced out of reach for open source developers but there are some fantastic resources available from the authors of these standards on the web. One of my favorites is Katie Moussouris’ RSA 2013 presentation slide deck called “A Tale of Two Standards“. Every open source project whether major or minor should put some thought into how they will handle vulnerability notification, handling and disclosure. Mishandling vulnerabilities puts users at risk and has the chance of alienating the people that you are most trying to help.
The standards describe the relationship between the two documents: “While ISO/IEC 29147 deals with the interface between vendors and those who find and report potential vulnerabilities, ISO/IEC 30111 deals with the investigation, triage, and resolution of vulnerabilities, regardless if the source of the potential vulnerability was external to the vendor, or from within the vendor’s own organization, typically security, development, or testing teams.”
Immature organizations sometimes shy away from releasing vulnerability notifications because these are admissions of failure which often get over-hyped in the news. It is important to understand that the goals of vulnerability disclosure according to ISO/IEC 29147 are to
- ensure that vulnerabilities are fixed
- minimize the risk from vulnerabilities
- provide users with enough information to evaluate risk
- promote positive communications
The last point is often overlooked. If you provide security researchers an easy way to get a hold of you, you are less likely to be surprised by an unforeseen vulnerability disclosure. If you give users, an easy-to-process notification so that they are not surprised, nor unexpectedly called in to work during holidays, then they will feel happier about your project.
The first step is to establish a vulnerability reporting process which makes it easy for security researchers to report vulnerabilities that they find in your project. Have a security link on your front page. Reserve security@example.com for vulnerability notification. Provide a way for the security research to give the information to you in an encrypted format – most projects publish one or more PGP keys. I’m not a big fan of shared keys because it is too easy to lose control over this critical key as people come and go from your project, but if you are already using shared keys in your project and it works for you, then you can use a similar approach for creating a security notification shared key. Alternately, you could handle initial disclosure via an https protected web form. Establish a mutually respectful dialog with the security researcher. Let the researcher know of your findings and when/how you plan to remediate the defect. Ask the researcher when they plan to go public, if the researcher hasn’t already offered the information. Ask the security researcher whether they would like credit for finding the vulnerability.
The next step is to establish a vulnerability handling process. Who is informed of the vulnerability so that they can help create, review, and test the fix? How will you track the patch which performs the fix? Code checked in to your public repository to make the fix acts as early notification to those who are watching carefully, so the code release should be coordinated with the release of the fixed version and your security advisory.
Finally, to continue maintaining positive communication flows with your users, you should make it as easy as possible for users to get and process security information about your project. Establish a template for security advisories that you use every time that is easily readable by humans. Establish a pre-notification process for critical security vulnerabilities whereby you notify your users that a critical security patch is coming at a certain time on a certain date. This allows users to plan maintenance windows without pre-disclosing details of the vulnerability which would render the users vulnerable to attack.
ISO/IEC 30111 recommends that security advisories include
- a unique identifier for the advisory/issue,
- a title for the advisory,
- an overview and general description of the issue,
- the impact of the issue,
- a severity rating for the issue, for example, CVSS score or qualitative ranking,
- references (CVEs or other security advisories),
- a list of affected versions (if applicable),
- any workarounds or alternative remediation which exist other than just upgrading the software,
- credit for the person who found the issue (if applicable and desired),
- revision history for the advisory,
- contact information (if needed, may be a pointer to the project’s Contact page),
- terms of use for the advisory (if needed, may be under same license as rest of the site’s documentation),
- description of intended audience for the advisory (if needed, assumed to be the project’s users).
Advisories should have a consistent format and be signed by one of the PGP keys which is published on the Security page. Consistent format is important for rapid scannability by humans. Aggregate the security advisories on a single page with the pre-notifications on the same page. Bonus points if there is a subscription mechanism available for the information on this page. Don’t publish your advisory on a weekend or holiday if you can possibly avoid it. If your project is packaged by one or more distributions, let them know ahead of time that the fix is coming and coordinate with the distro embargo process.
You know your project better than anyone, so if these recommendations don’t work for your project, think about what does work and document your process. Remember the goal is to minimize risk and promote positive communication about vulnerabilities.
While nothing described here is novel nor unique, many open source projects are on the leading edge of working out the best practices for vulnerability disclosure. OpenSSH handled a recent vulnerability by openly recommending that users adopt a simple workaround hours before the vulnerability was disclosed. The Xen Project has thought long and hard about their vulnerability handling process which includes early notification to trusted cloud providers who would be disproptionally impacted (along with millions of cloud customers) by a serious vulnerability. And OpenSSL’s security policy nicely describes the rationale behind their vulnerability process.
I’m always happy to talk to anyone who is starting to develop (or document) the security project for their own project. Hit me up at eratliff at linuxfoundation dot org or ejratl at gmail dot com. You may be able to find me on IRC as ratliff.
