X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=SECURITY.md;h=08a6ed8b4f6541147ffb2b7e58a2b61a78a11227;hb=35666f1c4e490f1c3ba9788d314c28172a28d771;hp=e66a43f289896c6d4b3312d5c3e2b6f42fac564c;hpb=bb6c5fad2458a47b4bed35ebd9188224ff1968f2;p=cascardo%2Fovs.git

diff --git a/SECURITY.md b/SECURITY.md
index e66a43f28..08a6ed8b4 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -23,25 +23,33 @@ What is a vulnerability?
 ------------------------
 
 All vulnerabilities are bugs, but not every bug is a vulnerability.
+Vulnerabilities compromise one or more of:
+
+    * Confidentiality (personal or corporate confidential data).
+    * Integrity (trustworthiness and correctness).
+    * Availability (uptime and service).
+
 Here are some examples of vulnerabilities to which one would expect to
 apply this process:
 
-    * A crafted packet that causes a kernel or userspace crash.
+    * A crafted packet that causes a kernel or userspace crash
+      (Availability).
 
     * A flow translation bug that misforwards traffic in a way likely
-      to hop over security boundaries.
+      to hop over security boundaries (Integrity).
 
     * An OpenFlow protocol bug that allows a controller to read
-      arbitrary files from the file system.
+      arbitrary files from the file system (Confidentiality).
 
     * Misuse of the OpenSSL library that allows bypassing certificate
-      checks.
+      checks (Integrity).
 
     * A bug (memory corruption, overflow, ...) that allows one to
       modify the behaviour of OVS through external configuration
-      interfaces such as OVSDB.
+      interfaces such as OVSDB (Integrity).
 
-    * Privileged information is exposed to unprivileged users.
+    * Privileged information is exposed to unprivileged users
+      (Confidentiality).
 
 If in doubt, please do use the vulnerability management process.  At
 worst, the response will be to report the bug through the usual
@@ -59,6 +67,9 @@ the report has been received.
 Please consider reporting the information mentioned in
 REPORTING-BUGS.md, where relevant.
 
+Reporters may ask for a GPG key while initiating contact with the
+security team to deliver more sensitive reports.
+
 The Linux kernel has its own vulnerability management process:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs
 Handling of vulnerabilities that affect both the Open vSwitch tree and
@@ -115,9 +126,16 @@ 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.
+with an embargo date and time set from the time sent.  Downstream
+stakeholders are expected not to deploy or disclose patches until
+the embargo is passed.
+
+A disclosure date is negotiated by the security team working with the
+bug submitter as well as vendors.  However, the Open vSwitch security
+team holds the final say when setting a disclosure date.  The timeframe
+for disclosure is from immediate (esp. if it's already publicly known)
+to a few weeks.  As a basic default policy, we expect report date to
+disclosure date to be 3~5 business days.
 
 Operating system vendors are obvious downstream stakeholders.  It may
 not be necessary to be too choosy about who to include: any major Open
@@ -125,11 +143,11 @@ 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.
+If the vulnerability is already public, skip this step.
 
 
-Step 5: Full Disclosure
------------------------
+Step 5: Public Disclosure
+-------------------------
 
 When the embargo expires, push the (reviewed) patches to appropriate
 branches, post the patches to the ovs-dev mailing list (noting that
@@ -137,11 +155,14 @@ they have already been reviewed and applied), post the security
 advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and
 post the security advisory on the Open vSwitch webpage.
 
+When the patch is applied to LTS (long-term support) branches, a new
+version should be released.
+
 The security advisory should be GPG-signed by a security team member
 with a key that is in a public web of trust.
 
 
-Contact 
+Contact
 =======
 
 Report security vulnerabilities to the ovs-security mailing list: