Open vSwitch needs some kind of process for handling vulnerabilities. So far, we've been pretty lucky that way, but it can't last forever, and I think we'll be better off if we have at least the outline of an established process whenever a significant vulnerability comes along. Here's my draft of a process based on the documentation of the OpenStack process at https://wiki.openstack.org/wiki/Vulnerability_Management.
I don't have a lot of experience with this kind of thing myself, so I'd appreciate critical review from anyone who does. Signed-off-by: Ben Pfaff <b...@nicira.com> --- Makefile.am | 3 +- SECURITY.md | 107 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 109 insertions(+), 1 deletion(-) create mode 100644 SECURITY.md diff --git a/Makefile.am b/Makefile.am index 46e8610..26528d9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,4 +1,4 @@ -# Copyright (C) 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc. +# Copyright (C) 2007-2015 Nicira, Inc. # # Copying and distribution of this file, with or without modification, # are permitted in any medium without royalty provided the copyright @@ -89,6 +89,7 @@ docs = \ README-lisp.md \ README-native-tunneling.md \ REPORTING-BUGS.md \ + SECURITY.md \ TODO.md \ WHY-OVS.md EXTRA_DIST = \ diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..daac389 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,107 @@ +Security Process +================ + +This is a proposed security vulnerability reporting and handling +process for Open vSwitch. It is based on the OpenStack vulnerability +management process described at +https://wiki.openstack.org/wiki/Vulnerability_Management. + +The OVS security team coordinates vulnerability management using the +ovs-security mailing list. Membership in the security team and +subscription to its mailing list consists of a small number of +trustworthy people, as determined by rough consensus of the Open +vSwitch committers on the ovs-committers mailing list. The Open +vSwitch security team should include Open vSwitch committers, to +ensure prompt and accurate vulnerability assessments and patch review. + + +Step 1: Reception +----------------- + +To report an Open vSwitch vulnerability, send an email to the +ovs-security mailing list (see "Contact" at the end of this document). +A security team member should reply to the reporter acknowledging that +the report has been received. + + +Step 2: Assessment +------------------ + +The security team should discuss the vulnerability. The reporter +should be included in the discussion (via "CC") to an appropriate +degree. + +The assessment should determine which Open vSwitch versions are +affected (e.g. every version, only the latest release, only unreleased +versions), the privilege required to take advantage of the +vulnerability (e.g. any network user, any local L2 network user, any +local system user, connected OpenFlow controllers), the severity of +the vulnerability, and how the vulnerability may be mitigated (e.g. by +disabling a feature). + +The treatment of the vulnerability could end here if the team +determines that it is not a realistic vulnerability. + + +Step 3a: Document +---------------- + +The security team develops a security advisory document. The document +credits the reporter and describes the vulnerability, including all of +the relevant information from the assessment in step 2. The security +team may, at its discretion, include the reporter (via "CC") in +developing the security advisory document, but in any case should +accept feedback from the reporter before finalizing the document. + +When the document is final, the security team should obtain a CVE for +the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). + + +Step 3b: Fix +------------ + +Steps 3a and 3b may proceed in parallel. + +The security team develops and obtains (private) reviews for patches +that fix the vulnerability. If necessary, the security team pulls in +additional developers, who should be asked to maintain +confidentiality. + + +Step 4: Embargoed Disclosure +---------------------------- + +The security advisory and patches are sent to downstream stakeholders, +with an embargo date and time set to 3 to 5 business days from the +time sent. Downstream stakeholders are expected not to deploy or +disclose patches until the embargo is passed. + +Operating system vendors are obvious downstream stakeholders. It may +not be necessary to be too choosy about who to include: any major Open +vSwitch user who is interested and can be considered trustworthy +enough could be included. To become a downstream stakeholder, email +the ovs-security mailing list. + +If the vulnerability is public, skip this step. + + +Step 5: Full Disclosure +----------------------- + +When the embargo expires, push the (reviewed) patches to appropriate +branches, post the patches to the ovs-dev mailing list (noting that +they have already been reviewed and applied), post the security +advisory to appropriate mailing lists (ovs-announce, ovs-users), and +post the security advisory on the Open vSwitch webpage. + + +Contact +======= + +Report security vulnerabilities to the ovs-security mailing list: +secur...@openvswitch.org + +Report problems with this document to the ovs-bugs mailing list: +b...@openvswitch.org + +Visit http://openvswitch.org/ to learn more about Open vSwitch. -- 1.7.10.4 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev