Add how to handle private security vulnerabilities

Adds two new documents:
- "How to report a security vulnerability" says how to privately
   report a security vulnerability with the intention of getting
   a fix before public disclosure.
- "Security response team guidelines" is for the security response
   team and community members who are responding to privately
   disclosed problems and working to provide a fix.

Change-Id: I83475bd4bfa014106ab5c3b50ad81e3488d06ba3
Signed-off-by: Joseph Reynolds <jrey@us.ibm.com>

2 files changed, 185 insertions, 0 deletions

diff --git a/security/how-to-report-a-security-vulnerability.md b/security/how-to-report-a-security-vulnerability.md
new file mode 100644
index 0000000..9a304b4
--- /dev/null
+++ b/security/how-to-report-a-security-vulnerability.md
@@ -0,0 +1,41 @@
+# How to report a security vulnerability
+
+This describes how you can report an OpenBMC security vulnerability
+privately to give the project time to address the problem before
+public disclosure.
+
+The main ideas are:
+ - You have information about a security problem which is not yet
+   publicly available.
+ - You want the problem fixed before public disclosure and
+   you are willing to help make that happen.
+ - You understand the problem will be publicly disclosed.
+
+To begin the process:
+ - Send an email to `openbmc-security@lists.ozlabs.org` with details
+   about the security problem such as:
+   - the version and configuration of OpenBMC the problem appears in
+   - how to reproduce the problem
+   - what are the symptoms
+
+The OpenBMC security response team will respond to you and work to
+address the problem.  Activities may include:
+ - Privately engage community members to understand and address the
+   problem.
+ - Work to determine the scope and severity of the problem,
+   such as [CVSS metrics](https://www.first.org/cvss/calculator/3.0).
+ - Work to create or identify an existing [CVE](http://cve.mitre.org/about/index.html).
+ - Coordinate workarounds and fixes with you and the community.
+ - Coordinate announcement details with you, such as timing or
+   how you want to be credited.
+ - Create an OpenBMC security advisory.
+
+Alternatives to this process:
+ - If the problem is not severe, please write an issue to the affected
+   repository or email the list.
+ - Join the OpenBMC community and fix the problem yourself.
+ - If you are unsure if the error is in OpenBMC (contrasted with
+   upstream projects such as the Linux kernel or downstream projects
+   such as a customized version of OpenBMC), please report it and we
+   will help you route it to the correct area.
+ - Discuss your topic in other [OpenBMC communication channels](https://github.com/openbmc/openbmc).
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
new file mode 100644
index 0000000..a6b38bd
--- /dev/null
+++ b/security/obmc-security-response-team-guidelines.md
@@ -0,0 +1,144 @@
+# Security response team guidelines
+
+These are the guidelines for the security response team members
+including OpenBMC community members who are responding to problems
+reported by the [security vulnerability reporting process](./obmc-security-response-team.md).
+
+The security response team coordinates activity to address privately
+disclosed security vulnerabilities, engages resources to address them,
+and creates security advisories.
+
+Here are the primary expectations:
+ - Keep problems private until announce
+ - Work with diligence
+ - Keep stakeholders informed
+
+Workflow highlights:
+
+1. Handle new problem reports
+    - Within a day, acknowledge you received the report.
+      Note that reports are archived in the mailing list.
+    - Communicate within the security response team, typically be
+      cc'ing the openbmc-security email list.
+
+2. Analyze the problem
+    - Determine if the problem is new or known.
+    - Determine if the problem is in OpenBMC.
+       - If the problem is in a project that OpenBMC uses, re-route
+         the problem to that upstream project.
+       - Note that the problem may be in a customized version of
+         OpenBMC but not in OpenBMC itself.
+    - Determine which OpenBMC areas should address the problem.
+    - Draft a CVE-like report which includes only:
+       * the vulnerability description: omit OpenBMC specifics
+       * [CVSS metrics](https://www.first.org/cvss/calculator/3.0)
+       * CVE identifiers, if known
+    - Gather data for the security advisory (see template below).
+
+3. Bring in contributors as needed (upstream, downstream, and OpenBMC)
+    - Use private channels, e.g., email.
+    - Inform contacts this is private work as part of the OpenBMC
+      security response team.  For example, link these guidelines.
+    - Coordinate with all stakeholders and keep them informed.
+
+4. For OpenBMC problems:
+    1. Determine if this is a high severity problem.  Example using
+       CVSS metrics: a remotely exploitable or low complexity attack that has
+       high impact to the BMC's confidentiality, integrity, or availability.
+    2. Avoid pre-announcing problems.  Be especially careful with high
+       severity problems.  When fixing the problem, use the contribution
+       process but limit the details in the issue or use a
+       private channel to discuss.
+    3. Negotiate how the code review will proceed.
+        - Consider [contributing](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server)
+          using a Gerrit [private change](https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes) if everyone has access to Gerrit.
+        - Consider using [Patch set](https://en.wikipedia.org/wiki/Patch_(Unix))
+          emails to make reviews accessible to all stakeholders.
+    4. When agreed, publish a security advisory to
+       https://github.com/openbmc/openbmc/issues and email list
+       openbmc@lists.ozlabs.org.
+       Make the gerrit review publicly viewable.
+    5. Improve OpenBMC processes to avoid future problems.
+
+## DRAFT Template: Initial response to the problem submitter
+The OpenBMC security response team has received the problem.
+- Thank you for reporting this.
+- Share preliminary results of the analysis.
+- Share preliminary OpenBMC plans or that we are analyzing the problem.
+- Set expectations for follow-up communications.
+
+## DRAFT Template: OpenBMC Security Advisory
+```
+OpenBMC Security Advisory
+Title: ...
+
+...summary: include CVEs, releases affected, etc....
+
+The CVSS score for these vulnerabilities is "...", with temporal score
+"...", with the following notes:
+https://www.first.org/cvss/calculator/3.0
+- AV:
+- AC:
+- PR:
+- UI:
+- S:
+- C/I/A:
+- E:
+- RC:
+
+The fix is in the https://github.com/openbmc/... repository as git
+commit ID ....
+
+For more information, see OpenBMC contact information at
+https://github.com/openbmc/openbmc file README.md.
+
+Credit for finding these problems: ...
+```
+
+## Reference
+Some of these guidelines were collected from:
+ - https://bestpractices.coreinfrastructure.org/en/projects/34
+ - https://www.kernel.org/doc/html/v4.16/admin-guide/security-bugs.html
+ - https://oss-security.openwall.org/wiki/mailing-lists/distros
+
+## Team composition and email maintenance
+
+The security response team is controlled by the OpenBMC Technical
+Steering Committee.  Membership is restricted to a core group, with
+selection based upon their community role(s), experience, and
+expertise responding to security incidents.
+
+The security response team uses the `openbmc-security at
+lists.ozlabs.org` private email list as a channel for confidential
+communication, so its membership reflects the composition of the
+security response team.  The list membership should be reviewed
+periodically and can be managed from
+`https://lists.ozlabs.org/listinfo/openbmc-security`.
+
+The email list subscribers should be reminded periodically to protect
+access to the emails from the list because of the sensitive
+information they contain.
+
+The email list membership is not intended to be secret. For example,
+we can discuss it a public forum. However, no effort is made to make
+the list public.
+
+The email list identification could be `for privately reporting
+OpenBMC security vulnerabilities` and its description could be: This
+email list is for privately reporting OpenBMC security
+vulnerabilities.  List membership is limited to the OpenBMC security
+response team.  For more information, see
+https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
+
+Sample response for denying list membership:
+```
+Thanks for your interest in OpenBMC security.  Subscriptions to the
+openbmc-security@lists.ozlabs.org email list are by invitation only
+and are typically extended only to security response team members.
+For more information, see https://github.com/openbmc/docs/security or
+attend a security working group meeting:
+https://github.com/openbmc/openbmc/wiki/Security-working-group.
+
+Yours truly,
+OpenBMC security response team
+```