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