Opened 6 years ago

Last modified 18 months ago

#1119 assigned task

Vulnerability Response Process

Reported by: zzz Owned by: sadie
Priority: minor Milestone: n/a
Component: www/i2p Version:
Keywords: docs review-needed Cc: Masayuki Hatta
Parent Tickets: Sensitive: no

Description

Needs significant documentation and process improvement.

Not only a "good thing", but on the Open ITP checklist, i.e. a potential factor in funding / auditing decisions.

refs:

http://trac.i2p2.i2p/wiki/OpenITPReview/Criteria
http://zzz.i2p/topics/780
https://community.rapid7.com/community/metasploit/blog/2013/10/29/seven-foss-disclosures-part-one
http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/meetings/227 and the links referenced re: threat modelling

Subtickets

Attachments (3)

I2P_VRP_draft_2015.09.30.txt (9.6 KB) - added by anonimal 4 years ago.
I2P_VRP_draft_2015.11.16.txt (9.8 KB) - added by anonimal 4 years ago.
I2P_VRP_draft_2018.04.09.txt (7.6 KB) - added by jaruga 19 months ago.

Download all attachments as: .zip

Change History (35)

comment:1 Changed 5 years ago by zzz

GPG keys generated for security@ email and added to contact page.

comment:2 Changed 5 years ago by zzz

<str4d> zzz, have you heard anything about https://hackerone.com/ ?
<str4d> I think it could make the vuln response process easier for us

comment:3 Changed 4 years ago by str4d

Keywords: docs added
Milestone: n/a
Status: newopen

comment:4 Changed 4 years ago by anonimal

Owner: set to anonimal
Status: openassigned

The next time I'm in a ranting mood, I'd rather start sketching a draft VRP instead of ranting; but I do have some questions and points to make.

Regarding HackerOne?:

  1. Does I2P have the budget for bounties and this 20% finder's fee?
  2. What is the appeal in using this service?
  3. Is there an influx of vulns coming in that require us to use a 3rd-party service?

I can see the obvious appeal for using HackerOne? for both organizations and clients: client base (big sell for orgs), easing communications, reduced workload for orgs, etc., but an important point that is not obviously stressed (not obvious to most) is the fact that it [their service] creates an attractive facade for an organization's approach to vulnerability handling. The problem in that is, honestly, a facade is nothing more than a facade; a business suit, a uniform - and does not always reflect the "maturity" (as quoted on HackerOne?'s site) of the organization or it's approach to security.

How does that relate to this ticket and why does that matter? It's not my intent to bad mouth the great accomplishments of other projects but, ironically, after reading https://owncloud.com/owncloud-taps-hackerone-to-bring-its-security-strategy-to-the-next-level-with-new-owncloud-security-bug-bounty-program/ and verbiage that sells you:

"While ownCloud has its own comprehensive security strategy, including in-house security professionals and regularly passing independent
security audits and penetration tests to deliver enterprise-grade security capabilities, bug bounty programs are used by leading companies
committed to bringing their security plan to the next level."

this still happens

https://github.com/owncloud/core/issues/17465#issuecomment-142768877

and no facade, no matter how expensive or glamorous, can overcome simple human error nor can it supplement the importance of one-on-one involvement in development and negotiation between "hacker" and developer, e.g., if they really want to help us, they'll send us a nice email.

I understand that these kinds of services [HackerOne?] are being pushed by massive corporations to bring real "hackers" out into the open so that they [hackers] don't have the power to demand what they deem to be fair-and-just rewards for critical bug bounty (some would call it a ransom), but would this method of using a 3rd-party actually help I2P in reigning-in quality reporting and would this reigning-in not be the largest deciding factor in whether to use this service or not?

Is this all too moral and the true issue is merely having someone else do the work for us? I believe the outcome of this ticket will effect the integrity of I2P's mission statement to at least some degree.

Maybe I'm a complete idiot and have no idea what I'm talking about. Someone, please disagree with me.

comment:5 Changed 4 years ago by zzz

somewhat agree.

We are all tech people, so we want to use tech and tools to solve all problems. Process problems are rarely solved by tools alone. A process could be built around, or inspired by, a tool, but when you're starting from scratch it's best to start with a list of things to do.

I've been involved in some ISO 9001 audits before and believe me it's best to keep things simple. Who is responsible, what are the steps you take, what are the decision points.

maybe hacker 1 is a part of the solution, maybe not. If you want to play with it, ask str4d, he has it set up.

comment:6 in reply to:  4 Changed 4 years ago by str4d

I'm glad zzz replied first, because it gave me a chance to calm down and respond rationally to the rant :)

Replying to anonimal:

Regarding HackerOne:

  1. Does I2P have the budget for bounties and this 20% finder's fee?

There is no requirement to offer bounties. From HackerOne's own FAQ:

Q How much should I pay for bounties?
A That all depends on you. The bounties already paid by programs on the HackerOne platform range from $100 - $20,000.
Q How much does it cost to use your services?
A The HackerOne vulnerability coordination platform is free to use. If you choose to offer a bug bounty, we charge a 20% commission. As part of our bounty payment service, we take care of getting the hackers paid, including getting them the right tax forms and removing that operational headache for you, so you can focus on getting your vulnerabilities fixed.

If we decided that we don't have the finances to sustain bug bounties, then we would simply not offer financial bounties. (We could offer swag, e.g. T-shirts, I believe there is facility within their system to do this.)

  1. What is the appeal in using this service?

Several big points:

  1. HackerOne provides a convenient and purpose-built system for managing vulnerabilities, communicating with the researchers, and handling things like public disclosure.
  2. There is an established community of researchers using the platform that we can try to tap in to.
  3. It is not a good idea to track critical vulnerabilities in a public forum while they are being fixed, and currently we only have this public Trac for collecting and managing issues. If we don't use something like HackerOne then we will have to run our own separate private issue tracker, or modify Trac to support private tickets that only the developers and reporter can see, and neither of these sound easy to implement or use.
    • HackerOne supports integration with Trac, which I have to investigate, but this may allow us to have a public ticket here with private comments on H1, and then get the comments transferred here after public disclosure.
  1. Is there an influx of vulns coming in that require us to use a 3rd-party service?

There are almost no vulns coming in, which is what concerns me. I want to get more eyes on I2P, and part of that is reaching out to researchers. If they are using HackerOne or other similar services, IMHO it is worth it for us to go there.

I can see the obvious appeal for using HackerOne for both organizations and clients: client base (big sell for orgs), easing communications, reduced workload for orgs, etc., but an important point that is not obviously stressed (not obvious to most) is the fact that it [their service] creates an attractive facade for an organization's approach to vulnerability handling. The problem in that is, honestly, a facade is nothing more than a facade; a business suit, a uniform - and does not always reflect the "maturity" (as quoted on HackerOne's site) of the organization or it's approach to security.

How does that relate to this ticket and why does that matter?

I agree that this ticket is about establishing and documenting a good process, but I dispute that HackerOne merely provides a facade. In fact, I'd say it is far better than our current system, which is "find this email address on our website, send us an email, and… who knows what happens next?" - the ultimate facade.

Setting up a HackerOne profile is not going to close this ticket, but it is a step in the right direction IMHO.

and no facade, no matter how expensive or glamorous, can overcome simple human error nor can it supplement the importance of one-on-one involvement in development and negotiation between "hacker" and developer, e.g., if they really want to help us, they'll send us a nice email.

Or they could send us a report on HackerOne, which provides that one-on-one involvement and discussion between the "hacker" / researcher and the developer(s), in an environment that is far easier to use and secure than email.

And no, "researchers should know how to PGP-encrypt emails" is not an appropriate response, because PGP usability sucks and it is trivially easy to screw up, by researcher or developer (also, HackerOne supports PGP-encrypted reports).

Is this all too moral and the true issue is merely having someone else do the work for us? I believe the outcome of this ticket will effect the integrity of I2P's mission statement to at least some degree.

Who is doing the work? We are. HackerOne is simply a platform on which to do the work, not a place to outsource vulnerability responses to.

comment:7 Changed 4 years ago by anonimal

zzz + str4d: do you have any pointers or suggestions on how to pursue this ticket now that H1 could be a viable solution? I could start writing up something that answers what zzz mentioned: "who is responsible, what are the steps you take, what are the decision points" and a site page but if H1 is a viable solution, where do you think my time should go regarding this ticket?

str4d: thank you for clearing things up and just for the record, I meant no disrespect or intent to cause emotional response from my comment (if that was the case). I tend to play devil's advocate whenever a shiny new product hits the scene because, all too often, such products come with consequences that I don't agree with. I am in complete admiration of your suggestions and have the utmost respect for your insight and work that you've produced and continue to produce!

My dream vision: an open alternative to H1, much like GitLab? is to GitHub?. Something that we could host but, alas, I don't think there is such a thing at this moment. If H1 looks/works too much like GitHub?, my next suggestion would be to consider that I2P hosts its own private GitLab? instance. I have experience with GitLab? and some of its code (not a RoR fan, but am familiar). We could work out hosting details later if that ends up being the solution.

str4d: should we coordinate on irc/email so I can see the work that you've already done on H1?

comment:8 in reply to:  7 Changed 4 years ago by str4d

Replying to anonimal:

zzz + str4d: do you have any pointers or suggestions on how to pursue this ticket now that H1 could be a viable solution? I could start writing up something that answers what zzz mentioned: "who is responsible, what are the steps you take, what are the decision points" and a site page but if H1 is a viable solution, where do you think my time should go regarding this ticket?

H1 may be a viable solution for hosting the process, but there is still more to do here.

I would suggest the following steps:

  • Look at the vulnerability response processes of other projects:
    • Similar to ours
    • Open-source institutions e.g. Apache, PSF
    • Commercial
  • Read over the links in the description and related articles e.g. https://www.owasp.org/index.php/SAMM_-_Vulnerability_Management_-_1
  • Identify and summarize common ideas and processes
  • Write a draft vulnerability response process

str4d: thank you for clearing things up and just for the record, I meant no disrespect or intent to cause emotional response from my comment (if that was the case). I tend to play devil's advocate whenever a shiny new product hits the scene because, all too often, such products come with consequences that I don't agree with. I am in complete admiration of your suggestions and have the utmost respect for your insight and work that you've produced and continue to produce!

Np, I was very tired when I first saw the comment, and didn't take it as well as I should have :P

My dream vision: an open alternative to H1, much like GitLab is to GitHub. Something that we could host but, alas, I don't think there is such a thing at this moment. If H1 looks/works too much like GitHub, my next suggestion would be to consider that I2P hosts its own private GitLab instance. I have experience with GitLab? and some of its code (not a RoR fan, but am familiar). We could work out hosting details later if that ends up being the solution.

H1 is not like GitLab, it is closer to Trac etc. If we were going to run our own setup, we would just host a private Trac instance, and set up some front page that researchers could use to create an account and submit reports, or just manually copy them in via email.

str4d: should we coordinate on irc/email so I can see the work that you've already done on H1?

PM me an email address and I can invite you to H1 so you can test it out, and see for yourself how it works. I don't mind inviting additional people at the testing stage, but whatever system we do eventually use will of course be limited to the vulnerability response team.

comment:9 Changed 4 years ago by anonimal

Thank you for the excellent response; this helps tremendously.

Changed 4 years ago by anonimal

comment:10 Changed 4 years ago by anonimal

Summary

Attached is a brief skeleton VRP draft that's not yet written in prose. It culminates a mix between how I interpret current I2P VRP and a possible future I2P VRP.

Questions

  1. Will prose eventually be needed or would a tiered approach suffice? I imagine some prose would be needed regardless. I personally like a simple tier because of the amount of information it would cover. VRP as a whole is quite linear too.
  1. Please consider point 1 in the "Assumptions" section as a temporary placeholder for now, though I do think that a private trac (or current trac with a "security-sensitive" patch applied) should be seriously considered.
  1. Is there a better way to handle this ticket besides uploading attachments to trac? Maybe with monotone? Or I [or someone] start working on a /security/ page within i2p.www.anonimal? I would need push privs if that were the case.

My more-informed thoughts on HackerOne

Pros:

  1. Functional UI with useful resources. Some would say 'responsive'.
  2. Great metrics system that minimizes our work load.
  3. If we don't end up using H1, having a profile that directs to our website would be a win-win.

Cons:

  1. Potentially very dangerous:

"In addition to personal information, we collect any Vulnerability Information and Content that you submit, post, or display on the Services."

  1. No client-side encryption. They see all, they know all, and that makes them a target.
  2. They don't encrypt their disks or use a hardened OS, or at least they don't say they do. ISAE 3402 does not require this either, as far as I know.
  3. If we used the site, I2P 0days would be available to people outside of I2P and the researcher.

If I were one or all of the Five-eyes, why is this site interesting?

  1. They only employ SSL/TLS.
  2. They currently service Yahoo (a fortune 500), Dropbox, Shopify, and many others, and have complete access to their undisclosed vulnerabilities.
  3. The site is a researcher hub. This makes it easier to target researchers.
  4. See point 4 above.
  5. The site's "Infrastructure & Operational Security" section doesn't eliminate the fact that someone, somewhere, at sometime, will have complete access to all available content. And because H1 sides with the law, they are subservient to the will of the law - and we all know how that usually plays out.

In a perfect world, HackerOne would be an opensource distributed decentralized platform, but it's not. I know this all sounds tin-hatty, but the real question is: is the risk of using this site worth the reward?

comment:11 Changed 4 years ago by anonimal

Keywords: review-needed added

comment:12 Changed 4 years ago by zzz

Skimmed the doc. I think it's too long already, certainly doesn't need conversion to prose. As I said in comment 5 above, ISO 9001 teaches you to keep it simple.

In the assumptions section, those are fine for now. Will the final answer be Trac with private tickets? Maybe, maybe not, doesn't really matter right now.

It doesn't say who is in charge of the process/team for a particular report. Somebody has to be. Probably the first thing the team must do is decide that.

Another missing topic is what to do about building and testing the fix. Does it get checked into mtn and git as usual where everybody can see it? Or in a branch? Or first a branch and then propagate it to trunk just before the release? Maybe we disable the mtn-to-git gateway until the release?

I don't see any variation in the process for HIGH, MEDIUM, or LOW, except for how we announce. There must be a difference in how (or whether) we do a special release to fix it. I guess that's section III.8.

In part IV, I don't know what you mean about 'point III being fulfilled". Does it mean we had a response of some sort, or what?

comment:13 Changed 4 years ago by str4d

Keywords: review-needed removed

Will prose eventually be needed or would a tiered approach suffice?

I would suggest that we have on the website an explicit VRP in succinct language rather than prose, but prefix it with a quick prose summary, (e.g. bullet-points under the headings "We commit to:" and "We ask that researchers commit to:").

Is there a better way to handle this ticket besides uploading attachments to trac?

Stick with attachments for now.

"In addition to personal information, we collect any Vulnerability Information and Content that you submit, post, or display on the Services."

This is simply a statement of fact - if we or researchers submit data to the website, they store it. If they didn't, the site would be pretty useless :P The point of this statement is to implicitly show what they don't collect; it is standard for site T&Cs, and on its own is not "potentially very dangerous".

I do think that a private trac (or current trac with a "security-sensitive" patch applied) should be seriously considered.

This combined with the other HackerOne comments essentially amounts to "I don't trust the law/legal authorities". HackerOne is based in San Francisco, and therefore I agree it is potentially vulnerable to the US and/or FiveEyes coercion. Hosting our own private Trac would indeed make this harder, by way of potentially being run in another country, or in secret behind an I2P Destination. However, I would assert that it is overall a more vulnerable setup in general.

I2P has many adversaries to be concerned about, and IMHO FiveEyes is not the most concerning. Remember that FiveEyes-level adversaries are already far more likely to be able to conduct traffic confirmation attacks, which I2P is not designed to resist. The vulnerabilities that we are most concerned about are those that enable simpler attacks, that can be conducted by non-FiveEyes-level adversaries. Those adversaries would most likely attempt to attack our vulnerability service remotely, rather than by coercion of the host. HackerOne will always have far superior defences against remote attacks than a private setup, by virtue of having more developers and more eyes on their platform.

Now, onto reviewing the draft VRP:

  • Assumption 4 - "Non-security-related issues" are not defined, but I assume the intention is issues that do not contain a vulnerability listed in Assumption 3. I think this is too restricting, and potentially confusing. Unless there is a good reason for an explicit list (feel free to justify its inclusion), I would suggest that it be left to the researcher's judgement. If they find an issue that they think is a vulnerability, but that we determine is a non-security-related bug, we can simply re-open the ticket on our public Trac ourselves as a bug.
  • III-1: If we use HackerOne, this needs to be reflected here.
  • III-2: Yes this is technically how the security@ email works, but it is superfluous, and the "without response" bit falsely implies some level of human processing. Should be removed.
  • III-4b: Should note that some issues may be re-raised on the public tracker as non-security-related bugs, rather than simply rejected.
  • III-5: At this point (or just after), the response team should pick a member to be the lead for the ticket, based on availability and relevant expertise. This enables a flexible response, rather than relying on one chosen "leader" of the response team. (This would be the "Assigned to" field on HackerOne, or the "Owned by" field on Trac.)
  • III-6: Some researchers may only want to communicate via email. There needs to be some statement to the effect of "email correspondence will be copied into the private tracker" - akin to HackerOne's declaration of collected information.
  • III-7: I agree with zzz, there should be a iii. stating how the fix will be released (e.g. emergency update vs. regular update schedule). Also, ii. doesn't state what the immediate notification should contain - perhaps this should be defined elsewhere and contrasted with the post-fix notification (in a "Responses" section)?
  • III-8a: Is it industry practice to award any bounty on verification of a valid issue, before a fix has been determined? My impression was that bounties are normally paid once the issue has been fixed. This point seems to conflict with IV-2b.
  • III-9: I agree with zzz, this point needs to be expanded. III-9b currently implies that the fix is applied to mtn with an innocuous message, and is later "uncovered" by some later commit of unspecified format that links the fixes to a CVE-ID per IV-2h. If we are concerned that the vulnerability response service could be compromised or coerced, should we not also be concerned that patches could be found in the public repo? To be discussed.
  • III-9c: Possibly move to a new "Responses" section, or to III-10.
  • III-9d: Should be moved into III-10.
  • III-10: A bit verbose given it is just standard release protocol. Do other VRPs contain this?
  • IV-1: 7 days is very short and could easily run afoul of developer time restrictions. The industry-standard period is 90 days, I see no reason for us not to adhere to this.
  • IV-2: Should read something like "If the Incident Response process in III is completed:". Likewise for IV-3.
  • IV-2a: Possibly move to a new "Responses" section.
  • IV-3e: How does this point compare to other VRPs? It sounds like the researcher could potentially disclose within the period specified in IV-1. Interaction with IV-3 statement needs to be clarified, ie. if IV-3e is triggered are we outside the IV-1 period?

Changed 4 years ago by anonimal

comment:14 Changed 4 years ago by anonimal

Keywords: review-needed added

Thank you both very much for taking the time to review this lengthy draft proposal. I have done my best with this 2nd draft to address every point brought up and I welcome more feedback. If the draft is still too long, what would help me is if someone could please provide specifics on *exactly* what needs to be cut.

How does this point compare to other VRPs?

Please see "Resources Considered".

I also think a meeting is in order to finalize our stance on HackerOne. I'm now leaning more towards str4d's argument but I'd also like to hear what the community-at-large has to say.

comment:15 Changed 4 years ago by kay

Great to have this soon!

I have two questions:

about III.9.a.: Couldn't such disabling give a hint about a problem being worked on? And thus, lead to rumors and unwanted discussions? Wouldn't a total separation of the version control during the coding of the fix and later addition to monotone be preferable?

What will the response process look like for a published vulnerability? This could happen if the research entity just chooses to publish their findings or just drops it in the public trac or a public disclosure happening during the vrp either accidentally or willingly.

comment:16 Changed 4 years ago by kay

regarding H1:
I see the points made by str4d, but using a centralized, commercial service provider for the vrp of i2p just doesn't feel right. That said, I continue more pragmatically:

Setting up a profile redirecting to i2p as suggested by anonimal would help i2p be more visible to the research community and just open another door for vulnerability reports, which is good. Even using it for communication if the disclosing researcher prefers it this way in order to up their reputation, might be fine, too.

But, it should be clearly stated that there is a non-H1 way to communicate vulnerabilities and H1 is a second option to get in touch.
People just might have reasons not to register at H1 in order to report. Being employed somewhere working on such issues or just being politically (or otherwise) opposed to using H1 or simply working at such thing while being payed for something else or …

Last edited 4 years ago by kay (previous) (diff)

comment:17 Changed 4 years ago by Alex Rice

Hi, I'm one of the founders at HackerOne?. Arrived here from this note: https://twitter.com/str4d/status/672232159655141376

First of all, just wanted to comment that the thoughtfulness that has went into this discussion so far is absolutely fantastic. Helping vulnerability disclosure become more broadly embraced as a norm in software security is a strong passion of mine and I2P's VRP draft goes above and beyond. I sincerely hope more projects follow suit.

Few areas of comment:

H1 Fee

We waive our fee for non-commercial OSS and would certainly do so for I2P.

Bounties Only

If you decide against centralized storage of vulnerability information but do end up launching a bounty program, we have a simple API for handling bounty payments without the administrative overhead. (Only email address and the amount is shared with H1)

Infrastructure Security

We have the utmost respect for the trust our clients have placed in us and take that responsibility seriously. We are acutely aware of how much of a target our service makes us.

I am always tempted to rattle off the extreme precautions we have taken, but none of those precautions provide any guarantees against a breach. Our working assumption is that we are not immune and that should be your assumption as well. This leads to our commitment to absolute transparency to our clients: we promptly disclosure any and all security breaches, including all detected vulnerabilities in our platform (you can see a historic list here: https://hackerone.com/security). If we're ever eventually breached, we can at least offer that you'll hear about it from us and we'll do whatever we can to help mitigate the fallout.

H1 employees are never authorized to view vulnerability information and much of our security model is based around that property. Access to production data is either maintenance work (rare, requires dual-factor, multi-stage auth) or a security breach. We are able to employ aggressive monitoring, auditing, and anomaly detection as a result.

One debatable silver lining here is that, because we are not an intermediary, all vulnerabilities in the platform have a half life: your team will be in possession of them and begin working on a fix immediately. That property makes vulnerabilities that have been sent through H1 unattractive to a number the more sophisticated adversaries.

Privacy

We will only share Your Information (including Vulnerability Information) with your consent…

One very noteworthy exception:

We may disclose Your Information if we believe it is reasonably necessary to comply with a law, regulation, or valid legal process. If we are going to release Your Information, our policy is to provide you with notice unless we are prohibited from doing so by law or court order…

HackerOne? is incorporated in the US and the Netherlands. Our servers are located in the Netherlands. HackerOne? employees with maintenance production access include both US and Dutch citizens. We are unable to provide any assurances against government requests for data, but we've made it prohibitively difficult even for our own employees to access vulnerability information, would fight such requests aggressively, and promise to notify you unless we are prohibited from doing so. I can currently say that we have received no such requests.

In the "FiveEyes?" concern raised here, it is unlikely that we would receive such formal requests. We can offer no privacy assurances against this class of adversary.

Functionality

We always love to hear suggestions on how we can help make vulnerability coordination easier or more suitable to your use cases. We are first and foremost an engineering team who prides ourselves on being very responsive to feature requests. On the two suggestions mentioned here so far:

  • Client-side Encryption: we've investigated several options but haven't found a particularly compelling solution - still open to suggestions. The best option for our clients who desire this is currently to require PGP submissions (you can configure a Trigger that rejects all non-PGP content). This is pretty terrible for all the reasons PGP usability is terrible in addition to search becoming inoperable. But it does completely remove any unauthorized access.
  • Open Source On Premise Install: this is something I'd love for us to build for a number of reasons, but it is unfortunately *at least* 18 months out.

—-

Whether or not this scenario is acceptable given your threat model is a uniquely personal decision that I am not qualified to weigh in on, but hopefully some transparency can help inform your decision.

Please throw any other questions my way that I may have missed!

Thanks,
Alex

comment:18 Changed 4 years ago by anonimal

Thank you Kay and Alex for such an incredible response! I am truly grateful for such quality feedback.

We are having a project meeting in #i2p-dev on Feb. 2, 8 PM UTC, where I believe we will resolve this issue once-and-for-all so I can wrap-up this ticket.

If you can't make the meeting, I'll be sure to post the results as they come.

On a side note: I've been busy with The Kovri I2P Router Project of which I'm happy to say is officially using HackerOne (but is not yet ready to invite researchers). Though I'm aware of the danger in using HackerOne, there is a balancing act of cost/reward so, for our anonymity concerns, I believe that "the more eyes, the better": even if there are 5 of them ;)

comment:19 Changed 4 years ago by zzz

Unfortunately, nobody put VRP on our Feb. 2 meeting agenda. Don't know exactly what happened but nobody got the message, certainly not that it would be resolved at that meeting.

We did discuss it briefly; str4d and I to review this ticket by Feb. 12; decisions to be made at March 5-6 roadmap meetings. http://zzz.i2p/topics/2014

my review to follow

comment:20 Changed 4 years ago by zzz

review of 2015-11-16 draft

  • III 2. "Report Manager" is an odd label. what would be better? chief fireman? :)
  • III 7 a. For a HIGH vulnerability we immediately make it public? HUH????? Isn't this a responsible disclosure kind of thing, where we fix it first?
  • III 8. Everything requires an emergency release? HUH????? Surely some stuff can wait until the regulary scheduled release. How can our only choices be 'don't do anything' or 'do an emergency release' ? Seems like we need another severity in III 7, "NEXT RELEASE" ?
  • III 9. You're on the right track here with a private mtn branch, although there's not really any such thing. We either have to use a separate mtn db and not sync it, or just sync it anyway and hope for the best, doubt anybody is trolling for mtn branches… but who knows.
  • VI Not bad but I would put this last (after VII) as it's not related to the specific incident. I suggest minimizing the details here and our obligations. Make it once a year and just say we'll review the last year's worth of issues. Call it 'continuous improvement', not 'establish metrics'. The whole section is way too specific and restrictive. Also, who is in charge of keeping the data throughout the year?
  • V Need to set a deadline for this (part of the 90 days for III or not? how much more time allowed?) and say who is in charge. The way this is written, it will never happen.

comment:21 Changed 4 years ago by str4d

Review of 2015-11-16 draft:

  • III 4 b ii: "Report Manager opens the issue on public Trac if not already opened." → "Report Manager moves discussion to a new or existing ticket on public Trac if [there are any remaining issues|necessary]." (pick one)
  • III 7: I assume that "immediate new post" in (a) (i) means a notice of the form "we are currently dealing with a severe security vulnerability, we will post more info later, but for now please do XYZ if you are using I2P". The purpose of the announcements should be explained somewhere. I also don't see any difference between the definitions of MEDIUM and LOW currently; this should be fixed.
  • III 8: I agree with zzz. I would class LOW as security vulnerabilities that can get fixed in the next release, while MEDIUM and HIGH deserve point releases.
  • III 9 a/b: No current need to disable mtn→git sync, and in fact that would raise a red flag. It would be better for the response team to have a separate mtn repo for this, which only ever pulls from upstream; then perhaps require that final patches are manually applied to trunk instead of via "mtn propagate" (or "git merge" if we ever move to git). That would make syncing branches between the response team a pain, but then again perhaps we want to minimise our surface area by only having patches in the private tracker. What do other projects do here?
  • I agree that VI should go after VII, and that it is over-specified. I would make VI 2 a single meeting, move VI 1 below VI 2, move the subpoints of VI 3 to VI 1 (and reduce them), and replace VI 3 with a general sentence about how after the presentation we will discuss changes to e.g. the VRP to do continuous improvement.

Overall this is looking pretty reasonable.

comment:22 Changed 4 years ago by zzz

Owner: changed from anonimal to str4d

Discussed at the March 6 roadmap meeting.
We will be using H1, starting with closed beta.
Reassigning to str4d (with help from me) to do final edits to anonimal's november draft and post the VRP on our website by end of the month, and to update the H1 configuration and info.
Thanks to anonimal for the great start.

comment:23 Changed 3 years ago by str4d

Edited draft to include the above comments. Added to the website in f1605f1774ba85af4ad06b7a6d4549f9865312bc. Please review.

comment:24 Changed 3 years ago by zzz

  1. At least echelon also gets security@ emails. As an aside, I am not getting them currently, as welt's forwarder to @mail.i2p addresses is broken. Not sure if the team needs to be defined in the process anyway… is this section really required?

III.5. What's the value in copying email/trac reports to H1? There's almost nothing following this step that uses H1. If we intend to use H1 for more than just a simple reporting platform (tracking, followups, management, etc.) it sure isn't obvious from this process, and we'd need more checkpoints below where H1 gets updated and synchronized with this process. At the least, entering email/trac reports into H1 for LOW (and MEDIUM?) could be overkill and should be optional.

III.6. s/Effects/Affects/

III.8. PRIVATE mtn branch means what? It's pushed to public mtn repos but we just don't declare the branch name publicly? I think this would be sufficient. Or do we need private mtn repos? But maybe this doesn't need to be in the process, we just need to understand internally.

IV.2.e. s/too/to/

comment:25 Changed 3 years ago by anonimal

Hi, sorry to butt-in, I know it's trivial but it's a pet peeve: I believe III.6 should stay as Effects and not Affects.

comment:26 Changed 3 years ago by Alex Rice

Two quick non-blocking updates from H1 that might be relevant to the VRP flow:

1 - Email Integration

If over email, Response Manager opens a HackerOne? issue for new submission.

We have recently built an email integration that would enable forwarding security@geti2p.net directly into your H1 Inbox.

This has a few benefits to consider:

  • Section III.1 could be simplified to one unified reporting method
  • A more familiar email-based reporting method for researchers
  • Easier usage of PGP/GPG for end-to-end encryption
  • Migrating away from HackerOne? is as simple as disabling email forwarding

As well as some downsides:

  • Researcher still needs to use hackerone.com UI for guaranteed transport level encryption (we can't validate GPG or STARTTLS)
  • H1 infrastructure would be forwarded a copy all security@ email (unless you configure an alternative alias, like vrp@geti2p.net)

This is currently in a closed beta but I can enable for the i2p program if interested. Public release in February.

2 - CVE-ID

If applicable, developers request a CVE-ID.

Small optimization, but HackerOne? recently became a CNA (CVE Numbering Authority) and can now distribute CVEs for vulnerabilities coordinated through the platform. If you don't have an existing CNA relationship you can email us to request a CVE-ID with a prompt turnaround. We're working with the CVE Automation Working Group to automate the assignment process from the UI (coming soon!).

Thanks!

Last edited 3 years ago by Alex Rice (previous) (diff)

comment:27 Changed 3 years ago by zzz

I noted in comment 12 above, 15 months ago, that we did want to know who was on the team, so I'll retract my suggestion in comment 24 above about section I. that we don't need it in the doc. I think I was right the first time.

The current draft btw is at http://i2p-projekt.i2p/en/research/vrp or https://geti2p.net/en/research/vrp

thx arice for the updates

Changed 19 months ago by jaruga

comment:28 Changed 19 months ago by jaruga

Did a bit of reading and made a few modifications to the last draft, mostly grammatical but a couple other key points. Sent it off to YrB1rd for review, but posting it here for open discussion / critique.

Last edited 19 months ago by jaruga (previous) (diff)

comment:29 Changed 19 months ago by zzz

Owner: changed from str4d to sadie

comment:30 Changed 19 months ago by zzz

Cc: Masayuki Hatta added

Draft doesn't talk about notifying "downstream" packages, including Debian, Ubuntu, Tails, and other OSes (arch, gentoo, …) in sections III and IV.

We control our own Debian archive. We are now in Debian sid, and mhatta controls that. mhatta would then send a request to Ubuntu to pull it from sid into bionic. We aren't currently in Tails but if we return, it would follow from Debian and mhatta would control that as well.

We don't currently have a list of other downstreams at all, much less a secure contact for the maintainers.

All of this would need to be coordinated.

In III 8) how to do a "private" monotone branch is TBD. We could just not tell anybody the branch name, but it's easy to list the branches. We could do it in a separate private database, but we'd have to take careful steps to ensure it isn't cross-populated by anybody to the public database. None of this is set up yet. As with a lot of this, not sure how much has to be done in advance.

comment:31 Changed 18 months ago by str4d

I'm reviewing the diff compared to current https://geti2p.net/en/research/vrp

III 6b) - Good addition. s/define the bugs severity/define the severity/

III 7b) - Note that all releases are accompanied with notifications on the website and news feed. Is the intent that a notification is made before the point release, or with it? A week may be too short a timespan for preparing the point release in some cases, but in general it will be a reasonably short turnaround. For a MEDIUM vulnerability we probably don't need a separate notification ahead of release time, but we probably also don't want to allow ourselves to slip notification of a MEDIUM to the end of the 90-day window. I'd be okay with making this a bit longer (15 working days / three weeks? i.e. about half a single release cycle).

III 7e) - Reason for adding this? I would assume that vulnerabilities with no severity don't count as vulnerabilities, and thus would be bumped out in 4b).

III 8b) - This on the website is split into 8b) and 8c), which I prefer.

III 9) / 9a) - Discussion of release date is a separate task to what happens on the actual release date. I can see why 9) was extracted from 8), so 9a) should probably become 10).

IV 2b8) - s/orkarounds/Workarounds

IV 3) - This illuminates an interesting point. 3) doesn't make sense on its own, because if 2) is not satisfied then 2b) wouldn't be completed. But even if 2) isn't satisfied we'll want to post *something*, because per 4d) the researcher likely will. How about this:

  • Put 3) (and children) back under 2)
  • Move 4) above 2)
  • Change 2) to "Once either the Incident Response process in section III is completed, or the vulnerability is otherwise disclosed:"

IV 3b1) s/too/to (also present on the website)

comment:32 Changed 18 months ago by jaruga

RE: III 7b) - The idea was to have a notification posted on the site within a week of the actual bug being identified and classified, regardless of if the point release was also coming within that timeframe. If it's preferred to keep seperate notifications for MEDIUM level severity vulns until the point release, I can fix that and adjust the timeframe as per suggestion.

RE: III 7e) - I suppose you are correct on that. What I had in mind was essentially bugs without severity - Small, vague example: Users navigating to a part of the router console results in a malformed path / page, Not severe by any standard, but still a bug that would likely be fixed in the next rollout.

Noted on all your other suggestions, I'll make some changes for the next draft regarding them. If you had anything to add on my two above points I'll also get them completed and upload it.

Note: See TracTickets for help on using tickets.