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

Reply via email to