1# Security response team guidelines
2
3These are the guidelines for the security response team members
4including OpenBMC community members who are responding to problems
5reported by the [security vulnerability reporting process][].
6
7The security response team (SRT) coordinates activity to address privately
8disclosed security vulnerabilities, engages resources to address them,
9and creates security advisories.
10
11Here are the primary expectations:
12 - Keep problems private until announce
13 - Work with diligence
14 - Keep stakeholders informed
15
16Workflow highlights:
17
181. Handle new problem reports.
19    - Within a day, acknowledge you received the report.
20      Note that reports are archived in the mailing list.
21    - Communicate within the security response team, typically by
22      cc'ing the openbmc-security email list.
23
242. Analyze the problem and engage collaborators as needed (upstream,
25   downstream, and OpenBMC).
26    - Determine if the problem is new or known.
27    - Determine if the problem is in OpenBMC.
28       - If the problem is in a project that OpenBMC uses, re-route
29         the problem to that upstream project.
30       - Note that the problem may be in a customized version of
31         OpenBMC but not in OpenBMC itself.
32    - Determine which OpenBMC areas should address the problem.
33    - Draft a CVE-like report which includes only:
34       * the vulnerability description: omit OpenBMC specifics
35       * [CVSS metrics][] with explanations as needed
36       * CVE identifiers, if known
37    - Gather data for the security advisory (see template below).
38    - Use private channels, e.g., email.
39    - Inform contacts this is private work as part of the OpenBMC
40      security response team.  For example, link to these guidelines.
41    - Coordinate with all stakeholders and keep them informed.
42
43   Considerations in the [CERT Guide to Coordinated Vulnerability
44   Disclosure][] (SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
45
46   Example collaborations:
47    - Submit the problem to another security response team, for example, the
48      [UEFI Security Response Team (USRT)][].
49    - Privately engage an OpenBMC maintainer or subject matter expert.
50
513. For OpenBMC problems.
52    1. Determine if this is a high severity problem.  Example using
53       CVSS metrics: a remotely exploitable or low complexity attack that has
54       high impact to the BMC's confidentiality, integrity, or availability.
55    2. Avoid pre-announcing problems.  Be especially careful with high
56       severity problems.  When fixing the problem, use the contribution
57       process but limit the details in the issue or use a
58       private channel to discuss.
59    3. Negotiate how the code review will proceed.
60        - Consider [contributing][] using a Gerrit [private change][] if
61          everyone has access to Gerrit.
62        - Consider using [Patch set][] emails to make reviews accessible to
63          all stakeholders.
64    4. When agreed:
65        - Publish a security advisory to
66          https://github.com/openbmc/openbmc/issues and email list
67          openbmc@lists.ozlabs.org.
68        - Make the Gerrit review publicly viewable.
69        - Email the Security Advisory to the OpenBMC community (see below).
70    5. Improve OpenBMC processes to avoid future problems.
71
72[security vulnerability reporting process]: ./obmc-security-response-team.md
73[CVSS metrics]: https://www.first.org/cvss/calculator/3.0
74[UEFI Security Response Team (USRT)]: https://uefi.org/security
75[CERT Guide to Coordinated Vulnerability Disclosure]: https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
76[contributing]: https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server
77[private change]: https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
78[Patch set]: https://en.wikipedia.org/wiki/Patch_(Unix)
79
80## Template: Initial response to the problem submitter
81The OpenBMC security response team has received the problem.
82- Thank you for reporting this.
83- Share preliminary results of the analysis.
84- Share preliminary OpenBMC plans or that we are analyzing the problem.
85- Set expectations for follow-up communications.
86
87## Template: OpenBMC Security Advisory
88```
89OpenBMC Security Advisory
90Title: ...
91
92...summary: include CVEs, releases affected, etc....
93
94The CVSS score for these vulnerabilities is "...", with temporal score
95"...", with the following notes:
96https://www.first.org/cvss/calculator/3.0
97
98The fix is in the https://github.com/openbmc/... repository as git
99commit ID ....
100
101For more information, see OpenBMC contact information at
102https://github.com/openbmc/openbmc file README.md.
103
104Credit for finding these problems: ...
105```
106
107## Template: Security Advisory notice
108When the Security Advisory is created, inform the OpenBMC community by
109sending email like this:
110
111```
112TO: openbmc-security@lists.ozlabs.org, openbmc@lists.ozlabs.org
113SUBJECT: [Security Advisory] ${subject}
114
115The OpenBMC Security Response team has released an OpenBMC Security Advisory:
116${url}
117
118An OpenBMC Security Advisory explains a security vulnerability, its severity,
119and how to protect systems that are built on OpenBMC.  For more information
120about OpenBMC Security Response, see:
121https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md
122```
123
124## Reference
125Some of these guidelines were collected from:
126 - https://bestpractices.coreinfrastructure.org/en/projects/34
127 - https://www.kernel.org/doc/html/v4.16/admin-guide/security-bugs.html
128 - https://oss-security.openwall.org/wiki/mailing-lists/distros
129 - [ISO/IEC 29147:2018 vulnerability disclosure](https://www.iso.org/standard/72311.html)
130
131## Team composition and email maintenance
132
133The security response team (SRT) is controlled by the OpenBMC Technical
134Steering Committee, including membership on the team.  General
135considerations for SRT membership:
136- Although individuals join the SRT, it is really organizations which join as
137  represented by their SRT members.  The SRT members are expected to:
138   - Participate in their organization's SRT.
139   - Designate backup OpenBMC SRT members.
140   - Share OpenBMC security vulnerability information within their organization
141     with the same care as stated in this document.
142- Membership is intended for organizations which have a vested interest in
143  OpenBMC security response.  Here are some examples to consider:
144   - Organizations which have products or services built on OpenBMC which are
145     publicly available and disclose security bugs to their users.  This
146     includes systems directly built on OpenBMC, and larger systems such as
147     data centers.
148   - Organizations which focus on BMC security research or security response.
149- Evaluation of an organization may be based on its members' OpenBMC community
150  roles, technical skills, and expertise responding to security incidents.
151- Membership should not be granted without compelling reason.  The intention
152  is to avoid premature disclosure of security vulnerabilities by limiting
153  membership to those with vested interest.
154
155The security response team uses the `openbmc-security at
156lists.ozlabs.org` private email list as a channel for confidential
157communication, so its membership reflects the composition of the
158security response team.  The list membership should be reviewed
159periodically and can be managed from
160`https://lists.ozlabs.org/listinfo/openbmc-security`.
161
162The email list subscribers should be reminded periodically to protect
163access to the emails from the list because of the sensitive
164information they contain.
165
166The email list membership is not intended to be secret. For example,
167we can discuss it a public forum. However, no effort is made to make
168the list's membership public.
169
170The email list identification is `for privately reporting OpenBMC security
171vulnerabilities` with description: This email list is for privately reporting
172OpenBMC security vulnerabilities.  List membership is limited to the OpenBMC
173security response team.  For more information, see
174https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
175
176Sample response for denying list membership:
177```
178Thanks for your interest in OpenBMC security.  Subscriptions to the
179openbmc-security@lists.ozlabs.org email list are by invitation only
180and are typically extended only to security response team members.
181For more information, see https://github.com/openbmc/docs/security or
182attend a security working group meeting:
183https://github.com/openbmc/openbmc/wiki/Security-working-group.
184
185Yours truly,
186OpenBMC security response team
187```
188