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