RFC00003 First version of a vulnerability disclosure policy by axelsimon · Pull Request #19 · enarx-archive/rfcs

axelsimon · 2020-03-10T18:16:45Z

…as well as a description of our approach to embargoes + a first draft of an Enarx Security Advisories page.

Comments and improvements most welcome.

Closes #18.

haraldh · 2020-03-10T22:03:37Z

keybase nowadays provides public links to chat. https://keybase.io/<nickname>/chat
e.g. https://keybase.io/hellobot/chat

axelsimon · 2020-03-11T12:41:07Z

Uh, isn't it a bit strange that this is PR #19, when it should have been #4?

@haraldh That redirects to keybase://chat/hellobot, which my browser has no idea what to do with :)

MikeCamel · 2020-03-11T12:53:27Z

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

+
+In other words:
+- We want:
+  - to encourage reporting of security issues (ie: “attack us!”)


Not entirely happy about "attack us!". Maybe ("please let us know about vulnerabilities!")

I liked the idea of putting the same idea in more abstract terms and in more direct terms, which we have used out loud (hence the quotation marks). However, i agree that there must be a nice way to put it than just "attack us!".

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

MikeCamel · 2020-03-11T13:01:32Z

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

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


We have to decide if we're going to maintain public keys. Neither @npmccallum nor I currently does.

This is one of the big questions this document raises.

I'm warming up more and more to the idea of treating email like public channel, and using it (or the chat) to set up more secure communication channels. The question then becomes: what communication channel do we set up?

Does Zulip have a way of managing this, by any chance?

I'm not sure if this is exactly what you're looking for, but Zulip supports sending an email to a (private?) stream.

I am not sure if it's bidirectional though, so if the Enarx security council maintains a private stream and they receive a vulnerability disclosure, I am not sure if their responses into the stream will be relayed back by email to the security researcher.

I don't have enough data to know if Zulip is an appropriate place for this in terms of security and privacy.

That's a neat Zulip function, thanks for pointing it out. However documentation says nothing about PGP-encrypted email. This means that the email would be unencrypted until it reaches the Zulip server, at which point it's private (but not E2E-encrypted, as the Zulip server is able to relay the content of the email clearly to the stream). Furthermore, replies to the stream to the initial sender would also be unencrypted, as the Zulip server would not know which public PGP key to encrypt it to. So while cool, this is not really an option for us i fear.

Suggest we close the Zulip thread here, as we've gone with Rocket.

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

MikeCamel · 2020-03-11T13:09:15Z

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

+
+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?


I'm now in contact with someone from the Github org to find out if there's something that they're working on that we could use (and the creation of which we could be help with).

That is excellent and would probably be a superior way to do this, if the feature is done right.

MikeCamel

Initial review.

MikeCamel · 2020-03-11T13:09:35Z

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

+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?


There's a distinction, but we should be careful.

A distinction in nature or in risk?
At the end of the day, i believe more and more strongly that we should treat email as a public channel, at least in terms of anything that might need confidentiality. It may not be entirely technically true, but it fosters the right attitude towards the levels of privacy and confidentiality one can expect from email overall.

mbestavros · 2020-03-11T13:56:09Z

@axelsimon The PR being numbered #19 is because issues also count towards numbering. We've filed ~15 issues and 4 PRs, so this ends up being #19.

axelsimon · 2020-03-17T12:49:26Z

@axelsimon The PR being numbered #19 is because issues also count towards numbering. We've filed ~15 issues and 4 PRs, so this ends up being #19.

Makes sense. Thanks Mark.

lkatalin

This looks pretty good! I suggested a few changes. Also I assume we will work out what (non-email) channel to use for this before the RFC is approved, so I left that alone despite it being an outstanding issue.

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

mbestavros

I have two ideas for this, detailed below. Interested in others' thoughts.

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

mbestavros · 2020-03-18T16:13:57Z

...erability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

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


I think it would be a good idea to specify that code changes get pushed to the repo and built before any embargo press lands. This would allow two things:

for us to directly specify the commit/version that patches the vulnerability in the press release, if we want (perhaps this is another thing we want to enforce?);

for people reading the disclosure to be able to migrate to that version immediately upon reading about it. We don't want them to come to our repo only to find that it's still building and won't be available for some period of time.

Good points. Incorporating them.

mbestavros · 2020-07-24T15:52:42Z

@axelsimon The name test is sequential, and it's based on your current tree.

Since the only merged RFC at this point is 00000, you'll want to update it your number to 00001 to make the tests pass (it's currently 00004). If another RFC gets merged before this one, you'll need to update the number to 00002, etc.

lkatalin

This looks pretty good! I found just one typo.
I am also pretty sure that we will require the current 3 commits to be squashed to one before merging.

lkatalin · 2020-07-24T15:58:50Z

00004-Vulnerability-disclosure-and-embargo-policy/README.md

+## 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


Suggested change

Enarx vulnerability disclosure policy - including the use of embargos - and

Enarx vulnerability disclosure policy - including the use of embargoes - and

Thanks, correcting this.

lkatalin · 2020-07-24T16:02:20Z

00004-Vulnerability-disclosure-and-embargo-policy/README.md

+- Contact the back-up contact (Mike Bursell, aka 
+[MikeCamel](https://github.com/mikecamel)) directly  
+  In both these cases, you can reach out
+  - by email


Perhaps this is intended, but Mike's email is not discoverable through this document. (Nathaniel's is in his GitHub bio.)

Ah, good catch. @MikeCamel, how do you want to deal with this?

Added to my github bio.

axelsimon · 2020-07-27T11:34:19Z

Thanks for the review!

I am also pretty sure that we will require the current 3 commits to be squashed to one before merging.

I thought 3 commits (creation, inclusion of improvements, move to PROPOSED state) was an accurate description of history, with neither too much useless detail nor too much simplification. Looking at the commit history, the Chat RFC had 5 commits, so i think the situation here is in line with that.

mbestavros

This looks reasonable to me. I've included a question inline, but one that doesn't necessarily imply any changes.

mbestavros · 2020-07-27T22:01:37Z

00004-Vulnerability-disclosure-and-embargo-policy/README.md

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


Do we have any desire to call out end-to-end encrypted Rocket.Chat as an option here?

It's mentioned at the end in the future ideas. The RFC is only in "proposed" state, so let's leave it as is for now, but i like the idea, and we may want to make it more explicit to use OTR when using Rocket Chat to inform the team of a possible security issue.

haraldh

LGTM

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.

Co-Authored-By: Mike Bursell <mike@p2ptrust.org> Co-authored-by: Lily Sturmann <lkatalin@users.noreply.github.com> Co-authored-by: blazebissar <25300692+blazebissar@users.noreply.github.com>

- Final tweaks and typo corrections - Move vuln disclosure RFC directory to root of RFC directory (we have done away with the "concepts" etc. directories)

axelsimon added documentation Improvements or additions to documentation enhancement New feature or request labels Mar 10, 2020

axelsimon requested review from MikeCamel, connorkuehl, haraldh, lkatalin, mbestavros and npmccallum March 10, 2020 18:16

axelsimon self-assigned this Mar 10, 2020

MikeCamel reviewed Mar 11, 2020

View reviewed changes