00002-vulnerability-disclosure-and-embargo-policy

00002: Vulnerability Disclosure and Embargo Policy

• Authors: axel simon
• Status: 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 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.

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, 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) directly
• Contact the back-up contact (Mike Bursell, aka MikeCamel) directly
  In both these cases, you can reach out
  • by email
  • by chat
• Contact the team as a whole on the chat.

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 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), 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.

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.

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 page.

List of Enarx Security Advisories

N/A

---

Reference

Much of this RFC is inspired by the Rust Security Policy, as well as RFPolicy 2.0, 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, 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, in particular its capacity for end-to-end encrypted conversations.
• Keybase messaging.
• Signal: raises question which account (ie: currently, an associated 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 (initially designed for as a way to share and accept documents securely for news organisations, likely overkill).
• A simpler drop box over HTTPS.