From 680132f862b0996e6bc1549cb6be34a3d06d2f29 Mon Sep 17 00:00:00 2001 From: axelsimon Date: Tue, 10 Mar 2020 18:07:35 +0000 Subject: [PATCH 1/3] First version of a vuln disclosure policy As well as a description of our approach to embargoes, and a first draft of a Enarx Security Advisories page. Open to debate and improvement. --- ...erability_disclosure_and_embargo_policy.md | 221 ++++++++++++++++++ 1 file changed, 221 insertions(+) create mode 100644 concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md diff --git a/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md b/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md new file mode 100644 index 00000000..cdd23526 --- /dev/null +++ b/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md @@ -0,0 +1,221 @@ +# RFC00004: Vulnerability Disclosure and Embargo Policy +- Authors: [axel simon](github@axelsimon.net) +- Status: [PROPOSED](/README.md#proposed) +- Since: 2020-03-10 +- Status Note: under discussion +- Supersedes: N/A +- Start Date: 2020-03-03 (date you started working on this idea) +- Tags: security, infrastructure + +## Summary + +Describe the security vulnerability disclosure process, including embargoes. + +## Motivation + +Users and researchers who discover security issues in Enarx need to know that +we welcome their efforts and how we will manage their disclosure. They must +also be able to have an idea of how we use security embargoes. + +In other words: +- We want: + - to encourage reporting of security issues (ie: “attack us!”) + - to make it easy to report security issues + - to maintain and extend our policy of safe defaults / discouraging people + from using bad security practices + - to recognise and show appreciation for the time spent researching and + reporting + - to make it possible for people who may be at risk to report issues + pseudonymously + +- We need: + - a clear policy, describing both: + - how to report; and + - what to expect during the process + - a main reporting channel: + - secondary channels, should the main one fail/not be available/be + overloaded. + - a list of people who can be reached directly + - a place to list security reports and give attribution + + +## Tutorial + +This RFC aims to provide a set of documents (wiki pages) that describe the +Enarx vulnerability disclosure policy and the list of security advisories and + fixes. + +The two pages are "Vulnerability Reporting and Embargo Policy" and "Enarx +Security Advisories" + +--- +### Vulnerability Reporting and Embargo Policy +The Enarx project aims to be as safe to use as possible and therefore to +produce code that is as secure as possible. As such, we welcome any and all +research into Enarx and appreciate your efforts to take the time to +responsibly disclose any issues you find. + +Vulnerabilities may be discovered in: +1. Enarx code +2. Enarx dependencies (including compilers) +3. Enarx documentation +4. 3rd party hardware or firmware + +All security bugs in Enarx should be reported by email to security@enarx.io. +This list is delivered to a small security team. Your email will be +acknowledged within 48 hours, and you’ll receive a more detailed response to +your email within 96 hours indicating the next steps in handling your report. + If you wish, you may encrypt your report using our public key. This key is +also on keys.openpgp.org and reproduced below. + +Be sure to use a descriptive subject line to avoid having your report be +missed (as with any publicly listed addresses, it is expected this one will +get a lot of spam). After the initial reply to your report, the security team + will endeavor to keep you informed of the progress being made towards a fix +and full announcement. As recommended by +[RFPolicy](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt), + these updates will be sent at least every five working days. + +If you have not received a reply to your email within 72 hours, or have not +heard from the security team for the past five days, there are a few steps you + can take (in order): +- Contact the current security coordinator (Nathaniel McCallum (public key)) directly. +- Contact the back-up contact (Mike Bursell (public key)) directly. +- Come chat to us on the [chat](https://gitter.im/enarx/community). + +Please note that the chat is a public area. When escalating in these venues, +please do not discuss your issue. +Simply say that you’re trying to get a hold of someone from the security team. + +Should you need to transfer files to us in a private manner, please use +[Magic Wormhole](https://magic-wormhole.readthedocs.io/en/latest/) or make +them available over https. + + +#### Disclosure policy +The Enarx project has a 5 step disclosure process. +1. The security report is received and is assigned a primary handler. + This person will coordinate the fix and release process. +2. The problem is confirmed and a list of all affected versions is determined. +3. Code is audited to find any potential similar problems. +4. Fixes are prepared for all releases which are still under maintenance. + These fixes are not committed to the public repository but rather held + locally pending the announcement. +5. On the embargo date, an announcement is sent to Enarx public channels + (chat, website). The changes are pushed to the public repository and new + builds are deployed. + +This process can take some time, especially when coordination is required +with maintainers of other projects. Every effort will be made to handle the +bug in as timely a manner as possible, however it is important that we follow + the release process above to ensure that the disclosure is handled in a +consistent manner. + +Enarx does not provide financial rewards for security disclosures, but the +team is open working with reporters of issues on publishing and attribution +of vulnerabilities and fixes. We welcome reports of issues to the project, +and want to ensure that the community is aware of and celebrates security +improvements. + +#### Embargoes +While the Enarx project aims to follow the highest standards of transparency +and openness (cf. [Enarx Principles](https://github.com/enarx/enarx.github.io/wiki/Design-principles)), +handling some security issues may pose such an immediate threat to various +stakeholders and require coordination between various actors that it cannot +be made immediately public. + +In this case, security issues will fall under an embargo. + +An embargo can be called for in various cases: +- when disclosing the issue without simultaneously providing a mitigation + would seriously endanger users, +- when producing a fix requires coordinating between multiple actors (such as + upstream or downstream/dependency projects), or simply +- when proper analysis of the issue and its ramifications demands time. + +If we determine that an issue you report requires an embargo, we will discuss +this with you and try to find a reasonable expiry date (aka “unembargo date”), +as well as who should be included in the list of need-to-know people. + +In any case, embargoes are a process that should be used sparingly, as they +are painful and time-consuming. + +For more information about embargoes and vulnerability disclosure, you can +refer to [this article](https://aliceevebob.com/2018/01/09/meltdown-and-spectre-thinking-about-embargoes-and-disclosures). + +Lastly, in no way should an embargo be understood as a means to avoid making +Enarx faults public. Transparency is paramount to the Enarx project. + +--- +### Enarx Security Advisories +This page lists all security advisories, vulnerabilities and fixes in Enarx +itself. + +For security issues, vulnerabilities and fixes in underlying TEEs, both in +SDKs and in hardware, please refer to our +[page on the subject](https://github.com/enarx/enarx/wiki/TEEs-vulnerabilities-and-attacks/). + +If you think you have found a security issue with Enarx, we encourage you to +report it. +To do so, you may follow the process described in the +[Vulnerability Disclosure and Embargo Policy](https://github.com/enarx/enarx/wiki/Vulnerability-disclosure-and-embargo-policy) page. + +#### List of Enarx Security Advisories +N/A + +--- + +## Reference + +Much of this RFC is inspired by the [Rust Security Policy](https://www.rust-lang.org/policies/security), +as well as [RFPolicy 2.0](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt), +which it refers to. + +## Drawbacks + +- The process as currently described makes use of email and OpenPGP. PGP + email is notoriously hard to get right, even more so over time. + +## Rationale and alternatives + +- The most basic alternative is not to have a policy and to simply wait for +people to disclose their findings. This does nothing to provide guarantees +to researchers and users that their work and time will be respected and to +encourage further disclosures. + +## Prior art + +Rust process mentioned above. + +## Unresolved questions +As mentioned, encrypted email is not a good solution. It’s really hard to get +PGP encrypted email right, it offers no Perfect Forward Secrecy (PFS) and key +management is horrible (cf. [this analysis](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html), +for instance). However, in the case of just offering a way for people outside +Enarx to send sensitive information with _some_ security, it may be +acceptable. +Key management is still hard: how many copies of the private key? where do +they live? how do we revocate if maintainers leave project? etc. + +In light of this: +- Can we *not* offer email as a way communication channel while remaining +universal enough to allow everyone to report security issues in Enarx? +- Should we treat email as a public channel, similar to our chat? + +## Implementations + +N/A + +## Future Possibilities + +We could offer further official channels for secure communication and +disclosure. + +Some ideas are: +- Github: work with Github on security issues reporting (WIP) +- A Private Github repo +- [Keybase](https://keybase.io/encrypt) messaging +- [Signal](https://signal.org): raises question which account (ie: phone number) +- [Secure Drop](https://securedrop.org/) (initially designed for as a way to + share and accept documents securely for news organisations, likely overkill) +- A simpler drop box over HTTPS From 72d8e2ace909adf57efe1b8819a98d388004038c Mon Sep 17 00:00:00 2001 From: axel simon Date: Tue, 21 Jul 2020 12:09:54 +0100 Subject: [PATCH 2/3] Improve RFC, incorporating all suggestions made by reviewers. Co-Authored-By: Mike Bursell Co-authored-by: Lily Sturmann Co-authored-by: blazebissar <25300692+blazebissar@users.noreply.github.com> --- ...erability_disclosure_and_embargo_policy.md | 158 +++++++++++------- 1 file changed, 94 insertions(+), 64 deletions(-) diff --git a/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md b/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md index cdd23526..93ce4cb9 100644 --- a/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md +++ b/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md @@ -9,7 +9,7 @@ ## Summary -Describe the security vulnerability disclosure process, including embargoes. +A description of the security vulnerability disclosure process, including embargoes. ## Motivation @@ -19,10 +19,10 @@ also be able to have an idea of how we use security embargoes. In other words: - We want: - - to encourage reporting of security issues (ie: “attack us!”) + - to encourage reporting of security issues (ie: “Please do attack us!”) - to make it easy to report security issues - to maintain and extend our policy of safe defaults / discouraging people - from using bad security practices + from adopting bad security practices - to recognise and show appreciation for the time spent researching and reporting - to make it possible for people who may be at risk to report issues @@ -41,12 +41,12 @@ In other words: ## Tutorial -This RFC aims to provide a set of documents (wiki pages) that describe the -Enarx vulnerability disclosure policy and the list of security advisories and - fixes. +This RFC aims to provide a set of documents (ex. wiki pages) that describe the +Enarx vulnerability disclosure policy - including the use of embargos - and +the list of security advisories and fixes. The two pages are "Vulnerability Reporting and Embargo Policy" and "Enarx -Security Advisories" +Security Advisories." --- ### Vulnerability Reporting and Embargo Policy @@ -61,65 +61,91 @@ Vulnerabilities may be discovered in: 3. Enarx documentation 4. 3rd party hardware or firmware -All security bugs in Enarx should be reported by email to security@enarx.io. -This list is delivered to a small security team. Your email will be -acknowledged within 48 hours, and you’ll receive a more detailed response to -your email within 96 hours indicating the next steps in handling your report. - If you wish, you may encrypt your report using our public key. This key is -also on keys.openpgp.org and reproduced below. - -Be sure to use a descriptive subject line to avoid having your report be -missed (as with any publicly listed addresses, it is expected this one will -get a lot of spam). After the initial reply to your report, the security team - will endeavor to keep you informed of the progress being made towards a fix -and full announcement. As recommended by +All security bugs in Enarx should be reported to the security team. +To do so, please reach out either by email at security@enarx.dev or on our +[chat](https://chat.enarx.dev) stating you'd like to report a security +issue, but **without divulging details**. + +We treat both email and chat as a public channels, so simply saying that +you’re trying to get a hold of someone from the security team is fine. + +From then, we will establish a more secure area where the issue can be +discussed, in the form of a +[Github Security Advisory](https://help.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories). + +You will be invited to join this private area to discuss specifics. Doing so +allows us to start with a high level of confidentiality and relax it if the +issue is less critical, moving to work on the fix in the open. + +This method provides several other advantages: +1. Avoids email, which is unfortunately very difficult to use securely +2. Enables private collaboration to fix the vulnerability in +a temporary private fork +3. Facilitates drafting a security advisory and using the draft to +privately discuss the impact of the vulnerability on the project +4. Simplifies publishing the security advisory and alerting the +community of the vulnerability + +Your initial contact will be acknowledged within 48 hours, and you’ll receive +a more detailed response within 96 hours indicating the next steps in handling +your report. + +After the initial reply to your report, the security team will endeavor to +keep you informed of the progress being made towards a fix and full +announcement. As recommended by [RFPolicy](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt), these updates will be sent at least every five working days. -If you have not received a reply to your email within 72 hours, or have not -heard from the security team for the past five days, there are a few steps you - can take (in order): -- Contact the current security coordinator (Nathaniel McCallum (public key)) directly. -- Contact the back-up contact (Mike Bursell (public key)) directly. -- Come chat to us on the [chat](https://gitter.im/enarx/community). +If you have not received a reply to your initial contact within 96 hours, or +have not heard from the security team for the past five days, there are a few +steps you can take (in suggested order): +- Contact the current security coordinator (Nathaniel McCallum, aka +[npmccallum](https://github.com/npmccallum)) directly +- Contact the back-up contact (Mike Bursell, aka +[MikeCamel](https://github.com/mikecamel)) directly + In both these cases, you can reach out + - by email + - by chat +- Contact the team as a whole on the [chat](https://chat.enarx.dev). -Please note that the chat is a public area. When escalating in these venues, -please do not discuss your issue. -Simply say that you’re trying to get a hold of someone from the security team. +As a reminder, **when escalating in these venues, please do not discuss your +issue.** -Should you need to transfer files to us in a private manner, please use -[Magic Wormhole](https://magic-wormhole.readthedocs.io/en/latest/) or make -them available over https. +Lastly, should you need to transfer files to us in a private manner, please +use [Magic Wormhole](https://magic-wormhole.readthedocs.io/en/latest/) or +make them available over https. #### Disclosure policy The Enarx project has a 5 step disclosure process. -1. The security report is received and is assigned a primary handler. +1. Contact is established, a private channel created, and the security report +is received and is assigned a primary handler. This person will coordinate the fix and release process. 2. The problem is confirmed and a list of all affected versions is determined. + 2.1 If an embargo is needed (see below), details of the embargo are decided. 3. Code is audited to find any potential similar problems. 4. Fixes are prepared for all releases which are still under maintenance. - These fixes are not committed to the public repository but rather held - locally pending the announcement. -5. On the embargo date, an announcement is sent to Enarx public channels - (chat, website). The changes are pushed to the public repository and new - builds are deployed. + 4.1 In case of embargo, these fixes are not committed to the public + repository but rather held in a private fork pending the announcement. +5. The changes are pushed to the public repository and new builds are deployed. + An announcement is sent to Enarx public channels (chat, website), once + these are available. This process can take some time, especially when coordination is required -with maintainers of other projects. Every effort will be made to handle the -bug in as timely a manner as possible, however it is important that we follow - the release process above to ensure that the disclosure is handled in a -consistent manner. +with maintainers of other projects or, for instance, with hardware vendors. +Every effort will be made to handle the bug in as timely a manner as possible, +however it is important that we follow the release process above to ensure +that the disclosure is handled in a consistent manner. Enarx does not provide financial rewards for security disclosures, but the -team is open working with reporters of issues on publishing and attribution -of vulnerabilities and fixes. We welcome reports of issues to the project, +team is open to working with reporters of issues on publishing and attribution +of vulnerabilities and fixes. We welcome reports of issues to the project, and want to ensure that the community is aware of and celebrates security improvements. #### Embargoes While the Enarx project aims to follow the highest standards of transparency -and openness (cf. [Enarx Principles](https://github.com/enarx/enarx.github.io/wiki/Design-principles)), +and openness (cf. [Enarx Principles](https://github.com/enarx/enarx/wiki/Design-principles)), handling some security issues may pose such an immediate threat to various stakeholders and require coordination between various actors that it cannot be made immediately public. @@ -134,8 +160,9 @@ An embargo can be called for in various cases: - when proper analysis of the issue and its ramifications demands time. If we determine that an issue you report requires an embargo, we will discuss -this with you and try to find a reasonable expiry date (aka “unembargo date”), -as well as who should be included in the list of need-to-know people. +this with you and try to find a reasonable expiry date (aka “embargo +completion date”), as well as who should be included in the list of +need-to-know people. In any case, embargoes are a process that should be used sparingly, as they are painful and time-consuming. @@ -169,38 +196,37 @@ N/A Much of this RFC is inspired by the [Rust Security Policy](https://www.rust-lang.org/policies/security), as well as [RFPolicy 2.0](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt), -which it refers to. +to which it refers. ## Drawbacks -- The process as currently described makes use of email and OpenPGP. PGP - email is notoriously hard to get right, even more so over time. +- This process opts for a "secret by default" approach, as any security issue +reported will automatically be in a private area. This may seem at odds with +our goal of transparency. We may need a clear set of criteria according to +which we make a security report public rather than go for / maintain an embargo. ## Rationale and alternatives - The most basic alternative is not to have a policy and to simply wait for people to disclose their findings. This does nothing to provide guarantees to researchers and users that their work and time will be respected and to -encourage further disclosures. +encourage further disclosures. We do not believe that such an approach would be consistent with the transparency and openness goals of the Enarx project. +- Offer full reporting of security vulnerabilities by email, as many other +projects do, and which is what many researchers will be used to. +However, encrypted email is not a good solution. The only usable standard for +encrypted email is OpenPGP, which suffers from very poor usability, offers no +Perfect Forward Secrecy (PFS) and imposes complex and painful key management +on the recipients as well as the senders. Cf. [this analysis](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html), +for more insights. ## Prior art Rust process mentioned above. ## Unresolved questions -As mentioned, encrypted email is not a good solution. It’s really hard to get -PGP encrypted email right, it offers no Perfect Forward Secrecy (PFS) and key -management is horrible (cf. [this analysis](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html), -for instance). However, in the case of just offering a way for people outside -Enarx to send sensitive information with _some_ security, it may be -acceptable. -Key management is still hard: how many copies of the private key? where do -they live? how do we revocate if maintainers leave project? etc. - -In light of this: -- Can we *not* offer email as a way communication channel while remaining -universal enough to allow everyone to report security issues in Enarx? -- Should we treat email as a public channel, similar to our chat? +Can this process be seen as contradictory with our intention to minimise the +use of embargo, and can we make clearer that we don't intend to make every +security report secret? ## Implementations @@ -213,9 +239,13 @@ disclosure. Some ideas are: - Github: work with Github on security issues reporting (WIP) -- A Private Github repo +- Use RocketChat, our current [chat platform](https://chat.enarx.dev) RocketChat's capacity for with end-to-end + encryptted conversations. - [Keybase](https://keybase.io/encrypt) messaging - [Signal](https://signal.org): raises question which account (ie: phone number) +- A OMEMO or OTR enabled Jabber / XMPP account (OMEMO offering the advantage + of allowing to establish a secure channel without both participants being + online) - [Secure Drop](https://securedrop.org/) (initially designed for as a way to share and accept documents securely for news organisations, likely overkill) - A simpler drop box over HTTPS From 4df252c26b395fc86b53d6565fc25342be3a0a58 Mon Sep 17 00:00:00 2001 From: axelsimon Date: Thu, 23 Jul 2020 20:07:37 +0100 Subject: [PATCH 3/3] Move vuln disclosure RFC to PROPOSED - Final tweaks and typo corrections - Move vuln disclosure RFC directory to root of RFC directory (we have done away with the "concepts" etc. directories) --- .../README.md | 29 ++++++++++--------- 1 file changed, 15 insertions(+), 14 deletions(-) rename concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md => 00002-vulnerability-disclosure-and-embargo-policy/README.md (94%) diff --git a/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md b/00002-vulnerability-disclosure-and-embargo-policy/README.md similarity index 94% rename from concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md rename to 00002-vulnerability-disclosure-and-embargo-policy/README.md index 93ce4cb9..8c389611 100644 --- a/concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md +++ b/00002-vulnerability-disclosure-and-embargo-policy/README.md @@ -1,10 +1,10 @@ -# RFC00004: Vulnerability Disclosure and Embargo Policy +# 00002: Vulnerability Disclosure and Embargo Policy - Authors: [axel simon](github@axelsimon.net) - Status: [PROPOSED](/README.md#proposed) - Since: 2020-03-10 -- Status Note: under discussion +- Status Note: ready to be trialed - Supersedes: N/A -- Start Date: 2020-03-03 (date you started working on this idea) +- Start Date: 2020-03-03 - Tags: security, infrastructure ## Summary @@ -42,7 +42,7 @@ In other words: ## Tutorial This RFC aims to provide a set of documents (ex. wiki pages) that describe the -Enarx vulnerability disclosure policy - including the use of embargos - and +Enarx vulnerability disclosure policy - including the use of embargoes - and the list of security advisories and fixes. The two pages are "Vulnerability Reporting and Embargo Policy" and "Enarx @@ -238,14 +238,15 @@ We could offer further official channels for secure communication and disclosure. Some ideas are: -- Github: work with Github on security issues reporting (WIP) -- Use RocketChat, our current [chat platform](https://chat.enarx.dev) RocketChat's capacity for with end-to-end - encryptted conversations. -- [Keybase](https://keybase.io/encrypt) messaging -- [Signal](https://signal.org): raises question which account (ie: phone number) -- A OMEMO or OTR enabled Jabber / XMPP account (OMEMO offering the advantage - of allowing to establish a secure channel without both participants being - online) +- Github: work with Github on security issues reporting (WIP). +- Use RocketChat, our current [chat platform](https://chat.enarx.dev), in + particular its capacity for end-to-end encrypted conversations. +- [Keybase](https://keybase.io/encrypt) messaging. +- [Signal](https://signal.org): raises question which account (ie: currently, + an associated phone number). +- A [OMEMO](https://conversations.im/omemo/) or OTR enabled Jabber / XMPP + account (OMEMO offering the advantage of allowing to establish a secure + channel without both participants being online). - [Secure Drop](https://securedrop.org/) (initially designed for as a way to - share and accept documents securely for news organisations, likely overkill) -- A simpler drop box over HTTPS + share and accept documents securely for news organisations, likely overkill). +- A simpler drop box over HTTPS.