RFC00003 First version of a vulnerability disclosure policy

00002-vulnerability-disclosure-and-embargo-policy/README.md

@@ -0,0 +1,252 @@
+# 00002: Vulnerability Disclosure and Embargo Policy
+- Authors: [axel simon]([email protected])
+- Status: [PROPOSED](/README.md#proposed)
+- Since: 2020-03-10
+- Status Note: ready to be trialed
+- Supersedes: N/A
+- Start Date: 2020-03-03
+- Tags: security, infrastructure
+
+## Summary
+
+A description of 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: “Please do attack us!”)
+  - to make it easy to report security issues
+  - to maintain and extend our policy of safe defaults / discouraging people
+  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
+  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 (ex. wiki pages) that describe the 
+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 
+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 to the security team. 
+To do so, please reach out either by email at [email protected] 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 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).
+
+As a reminder, **when escalating in these venues, please do not discuss your
+issue.** 
+
+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. 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. 
+  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 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 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/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 “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.
+
+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), 
+to which it refers.
+
+## Drawbacks
+
+- 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.  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
+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
+
+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).
+- 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.