1# Security response team guidelines
2
3These are the guidelines for OpenBMC security responders, including the security
4response team, project owners, and community members who are responding to
5problems reported by the [security vulnerability reporting process][].
6
7Each project within OpenBMC works independently to resolve security
8vulnerabilities. The security response team helps the maintainers, provides
9consistency within the OpenBMC project, and helps to get CVEs assigned.
10
11Here are the primary expectations:
12
13- Keep problems private until announce.
14- Work with diligence.
15- Keep stakeholders informed.
16
17Workflow highlights:
18
191. Handle new problem reports.
20
21   - Within a day, acknowledge you received the report. Note that reports are
22     archived in the mailing list.
23   - Communicate by opening the GitHub draft security advistory as soon as the
24     problem is known.
25
262. Analyze the problem and engage collaborators as needed (upstream, downstream,
27   and OpenBMC).
28
29   - Determine if the problem is new or known.
30   - Determine if the problem is in OpenBMC.
31     - If the problem is in a project that OpenBMC uses, re-route the problem to
32       that upstream project.
33     - Note that the problem may be in a customized version of OpenBMC but not
34       in OpenBMC itself.
35   - Determine which OpenBMC areas should address the problem.
36   - [Create the draft security advisory][] and populate its fields.
37     - The Ecosystem would normally be "OpenBMC" and the package name is
38       normally the repository.
39     - Please describe when the problem was introduced to help users learn if
40       they are affected. Use Git tags and commit IDs if known. It also may be
41       helpful to say what OpenBMC version is affected. For example, if the
42       problem in the original code through OpenBMC release 2.9, the affected
43       version is "<= 2.9". See [OpenBMC releases][].
44   - Use private channels, for example, email, GitHub draft security advistory,
45     or private direct messaging.
46   - Inform contacts this is private work as part of the OpenBMC security
47     response team. For example, link to these guidelines.
48   - Coordinate with all collaborators and keep them informed.
49
50   Considerations in the [CERT Guide to Coordinated Vulnerability Disclosure][] (SPECIAL
51   REPORT CMU/SEI-2017-SR-022) may guide the process.
52
53   Example collaborations:
54
55   - Submit the problem to another security response team, for example, the
56     [UEFI Security Response Team (USRT)][].
57   - Privately engage an OpenBMC maintainer or subject matter expert.
58
593. For OpenBMC problems.
60   1. Determine if this is a high severity problem. Example using CVSS metrics:
61      a remotely exploitable or low complexity attack that has high impact to
62      the BMC's confidentiality, integrity, or availability.
63   2. Avoid pre-announcing problems. Be especially careful with high severity
64      problems. When fixing the problem, use the contribution process but limit
65      the details in the issue or use a private channel to discuss.
66   3. Negotiate how the code review will proceed.
67      - Consider [contributing][] using a Gerrit [private change][] if everyone has
68        access to Gerrit.
69      - Consider using [Patch set][] emails to make reviews accessible to all stakeholders.
70   4. When agreed:
71      - Publish a security advisory to the affected OpenBMC repository.
72      - Make the Gerrit review publicly viewable.
73      - Publish the CVE in the CVE database.
74   5. Improve OpenBMC processes to avoid future problems.
75
76Repository maintainer process steps: 1. Create a private gerrit code review and
77oversee development of the fix. 2. Create a draft advisory under
78github.com/openbmc/<REPO>/security/advisories. Please follow guidance in the
79[OpenBMC Security Advisory Template][]. Add the openbmc security-response group and
80other stakeholders to the advisory. 3. Review the security bulletin with stakeholders
81to get it ready to publish. 4. Work with the SRT to identify CVEs. If you are unsure
82what counts as a vulnerability, please consult with the SRT. For example, independent
83bugs should have separate CVEs. A security advisory can reference multiple CVEs.
84When the CVE is known, add it to the security advisory, and reference it in the commit
85message, stating how the fix relates to the CVE. For example: This fixes CVE-yyyy-nnnnn.
86Doing so helps downstream security responders. If the commit is a partial fix, please
87explain that and provide references to the other parts of the fix. 5. If stakeholders
88negotiate for coordinated disclosure, plan to release the fix and the security advisory
89on the negotiated day. 6. When the code fix and the advisory are both ready (subject
90to coordinated disclosure), please merge the fixes (and make any private review be
91public) publish the security advisory, and email the security-response team.
92
93[security vulnerability reporting process]: ./obmc-security-response-team.md
94[cvss metrics]: https://www.first.org/cvss/calculator/3.0
95[uefi security response team (usrt)]: https://uefi.org/security
96[cert guide to coordinated vulnerability disclosure]:
97  https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
98[contributing]:
99  https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server
100[openbmc releases]:
101  https://github.com/openbmc/docs/blob/master/release/release-notes.md
102[private change]:
103  https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
104[patch set]: https://en.wikipedia.org/wiki/Patch_(Unix)
105[create the draft security advisory]:
106  https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
107[openbmc security advisory template]: obmc-github-security-advisory-template.md
108
109## Template: Initial response to the problem submitter
110
111The OpenBMC security response team has received the problem.
112
113- Thank you for reporting this.
114- Share preliminary results of the analysis.
115- Share preliminary OpenBMC plans or that we are analyzing the problem.
116- Set expectations for follow-up communications.
117
118## Template: OpenBMC Security Advisory
119
120```
121OpenBMC Security Advisory
122Title: ...
123
124...summary: include CVEs, releases affected, etc....
125
126The CVSS score for these vulnerabilities is "...", with temporal score
127"...", with the following notes:
128https://www.first.org/cvss/calculator/3.0
129
130The fix is in the https://github.com/openbmc/... repository as git
131commit ID ....
132
133For more information, see OpenBMC contact information at
134https://github.com/openbmc/openbmc file README.md.
135
136Credit for finding these problems: ...
137```
138
139## Template: Security Advisory notice
140
141When the Security Advisory is created, inform the OpenBMC community by sending
142email like this:
143
144```
145TO: openbmc-security@lists.ozlabs.org, openbmc@lists.ozlabs.org
146SUBJECT: [Security Advisory] ${subject}
147
148The OpenBMC Security Response team has released an OpenBMC Security Advisory:
149${url}
150
151An OpenBMC Security Advisory explains a security vulnerability, its severity,
152and how to protect systems that are built on OpenBMC.  For more information
153about OpenBMC Security Response, see:
154https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md
155```
156
157## Reference
158
159Some of these guidelines were collected from:
160
161- https://bestpractices.coreinfrastructure.org/en/projects/34
162- https://www.kernel.org/doc/html/v4.16/admin-guide/security-bugs.html
163- https://oss-security.openwall.org/wiki/mailing-lists/distros
164- [ISO/IEC 29147:2018 vulnerability disclosure](https://www.iso.org/standard/72311.html)
165
166## Team composition and email maintenance
167
168The security response team (SRT) is controlled by the OpenBMC Technical Steering
169Committee, including membership on the team. General considerations for SRT
170membership:
171
172- Although individuals join the SRT, it is really organizations which join as
173  represented by their SRT members. The SRT members are expected to:
174  - Participate in their organization's SRT.
175  - Designate backup OpenBMC SRT members.
176  - Share OpenBMC security vulnerability information within their organization
177    with the same care as stated in this document.
178- Membership is intended for organizations which have a vested interest in
179  OpenBMC security response. Here are some examples to consider:
180  - Organizations which have products or services built on OpenBMC which are
181    publicly available and disclose security bugs to their users.  This includes
182    systems directly built on OpenBMC, and larger systems such as data centers.
183  - Organizations which focus on BMC security research or security response.
184- Evaluation of an organization may be based on its members' OpenBMC community
185  roles, technical skills, and expertise responding to security incidents.
186- Membership should not be granted without compelling reason. The intention is
187  to avoid premature disclosure of security vulnerabilities by limiting
188  membership to those with vested interest.
189
190The security response team uses the `openbmc-security at lists.ozlabs.org`
191private email list as a channel for confidential communication, so its
192membership reflects the composition of the security response team. The list
193membership should be reviewed periodically and can be managed from
194`https://lists.ozlabs.org/listinfo/openbmc-security`.
195
196The email list subscribers should be reminded periodically to protect access to
197the emails from the list because of the sensitive information they contain.
198
199The email list membership is not intended to be secret. For example, we can
200discuss it a public forum. However, no effort is made to make the list's
201membership public.
202
203The email list identification is
204`for privately reporting OpenBMC security vulnerabilities` with description:
205This email list is for privately reporting OpenBMC security vulnerabilities.
206List membership is limited to the OpenBMC security response team. For more
207information, see
208https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
209
210Sample response for denying list membership:
211
212```
213Thanks for your interest in OpenBMC security.  Subscriptions to the
214openbmc-security@lists.ozlabs.org email list are by invitation only
215and are typically extended only to security response team members.
216For more information, see https://github.com/openbmc/docs/security or
217attend a security working group meeting:
218https://github.com/openbmc/openbmc/wiki/Security-working-group.
219
220Yours truly,
221OpenBMC security response team
222```
223