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][]
51   (SPECIAL 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
68        has access to Gerrit.
69      - Consider using [Patch set][] emails to make reviews accessible to all
70        stakeholders.
71   4. When agreed:
72      - Publish a security advisory to the affected OpenBMC repository.
73      - Make the Gerrit review publicly viewable.
74      - Publish the CVE in the CVE database.
75   5. Improve OpenBMC processes to avoid future problems.
76
77Repository maintainer process steps: 1. Create a private gerrit code review and
78oversee development of the fix. 2. Create a draft advisory under
79github.com/openbmc/<REPO>/security/advisories. Please follow guidance in the
80[OpenBMC Security Advisory Template][]. Add the openbmc security-response group
81and other stakeholders to the advisory. 3. Review the security bulletin with
82stakeholders to get it ready to publish. 4. Work with the SRT to identify CVEs.
83If you are unsure what counts as a vulnerability, please consult with the SRT.
84For example, independent bugs should have separate CVEs. A security advisory can
85reference multiple CVEs. When the CVE is known, add it to the security advisory,
86and reference it in the commit message, stating how the fix relates to the CVE.
87For example: This fixes CVE-yyyy-nnnnn. Doing so helps downstream security
88responders. If the commit is a partial fix, please explain that and provide
89references to the other parts of the fix. 5. If stakeholders negotiate for
90coordinated disclosure, plan to release the fix and the security advisory on the
91negotiated day. 6. When the code fix and the advisory are both ready (subject to
92coordinated disclosure), please merge the fixes (and make any private review be
93public) publish the security advisory, and email the security-response team.
94
95[security vulnerability reporting process]: ./obmc-security-response-team.md
96[cvss metrics]: https://www.first.org/cvss/calculator/3.0
97[uefi security response team (usrt)]: https://uefi.org/security
98[cert guide to coordinated vulnerability disclosure]:
99  https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
100[contributing]:
101  https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server
102[openbmc releases]:
103  https://github.com/openbmc/docs/blob/master/release/release-notes.md
104[private change]:
105  https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
106[patch set]: https://en.wikipedia.org/wiki/Patch_(Unix)
107[create the draft security advisory]:
108  https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
109[openbmc security advisory template]: obmc-github-security-advisory-template.md
110
111## Template: Initial response to the problem submitter
112
113The OpenBMC security response team has received the problem.
114
115- Thank you for reporting this.
116- Share preliminary results of the analysis.
117- Share preliminary OpenBMC plans or that we are analyzing the problem.
118- Set expectations for follow-up communications.
119
120## Template: OpenBMC Security Advisory
121
122```
123OpenBMC Security Advisory
124Title: ...
125
126...summary: include CVEs, releases affected, etc....
127
128The CVSS score for these vulnerabilities is "...", with temporal score
129"...", with the following notes:
130https://www.first.org/cvss/calculator/3.0
131
132The fix is in the https://github.com/openbmc/... repository as git
133commit ID ....
134
135For more information, see OpenBMC contact information at
136https://github.com/openbmc/openbmc file README.md.
137
138Credit for finding these problems: ...
139```
140
141## Template: Security Advisory notice
142
143When the Security Advisory is created, inform the OpenBMC community by sending
144email like this:
145
146```
147TO: openbmc-security@lists.ozlabs.org, openbmc@lists.ozlabs.org
148SUBJECT: [Security Advisory] ${subject}
149
150The OpenBMC Security Response team has released an OpenBMC Security Advisory:
151${url}
152
153An OpenBMC Security Advisory explains a security vulnerability, its severity,
154and how to protect systems that are built on OpenBMC.  For more information
155about OpenBMC Security Response, see:
156https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md
157```
158
159## Reference
160
161Some of these guidelines were collected from:
162
163- https://bestpractices.coreinfrastructure.org/en/projects/34
164- https://www.kernel.org/doc/html/v4.16/admin-guide/security-bugs.html
165- https://oss-security.openwall.org/wiki/mailing-lists/distros
166- [ISO/IEC 29147:2018 vulnerability disclosure](https://www.iso.org/standard/72311.html)
167
168## Team composition and email maintenance
169
170The security response team (SRT) is controlled by the OpenBMC Technical Steering
171Committee, including membership on the team. General considerations for SRT
172membership:
173
174- Although individuals join the SRT, it is really organizations which join as
175  represented by their SRT members. The SRT members are expected to:
176  - Participate in their organization's SRT.
177  - Designate backup OpenBMC SRT members.
178  - Share OpenBMC security vulnerability information within their organization
179    with the same care as stated in this document.
180- Membership is intended for organizations which have a vested interest in
181  OpenBMC security response. Here are some examples to consider:
182  - Organizations which have products or services built on OpenBMC which are
183    publicly available and disclose security bugs to their users.  This includes
184    systems directly built on OpenBMC, and larger systems such as data centers.
185  - Organizations which focus on BMC security research or security response.
186- Evaluation of an organization may be based on its members' OpenBMC community
187  roles, technical skills, and expertise responding to security incidents.
188- Membership should not be granted without compelling reason. The intention is
189  to avoid premature disclosure of security vulnerabilities by limiting
190  membership to those with vested interest.
191
192The security response team uses the `openbmc-security at lists.ozlabs.org`
193private email list as a channel for confidential communication, so its
194membership reflects the composition of the security response team. The list
195membership should be reviewed periodically and can be managed from
196`https://lists.ozlabs.org/listinfo/openbmc-security`.
197
198The email list subscribers should be reminded periodically to protect access to
199the emails from the list because of the sensitive information they contain.
200
201The email list membership is not intended to be secret. For example, we can
202discuss it a public forum. However, no effort is made to make the list's
203membership public.
204
205The email list identification is
206`for privately reporting OpenBMC security vulnerabilities` with description:
207This email list is for privately reporting OpenBMC security vulnerabilities.
208List membership is limited to the OpenBMC security response team. For more
209information, see
210https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
211
212Sample response for denying list membership:
213
214```
215Thanks for your interest in OpenBMC security.  Subscriptions to the
216openbmc-security@lists.ozlabs.org email list are by invitation only
217and are typically extended only to security response team members.
218For more information, see https://github.com/openbmc/docs/security or
219attend a security working group meeting:
220https://github.com/openbmc/openbmc/wiki/Security-working-group.
221
222Yours truly,
223OpenBMC security response team
224```
225