Ticket #1119: I2P_VRP_draft_2018.04.09.txt

File I2P_VRP_draft_2018.04.09.txt, 7.6 KB (added by jaruga, 2 years ago)
3        Researchers: while you research/hack, we kindly ask that you refrain from the following:
4            - Performing active exploits or Denial of Service attacks on the i2p network
5            - Performing social engineering on i2p development team members
6            - Performing any physical or electronic attempts against i2p property and/or data centers
8        As i2p is an open-source community, many volunteers and development team members run their own EepSites as well as public ("clearnet") domains. These sites/servers are NOT in the scope of the vulnerability assessment / response process, only the underlying code of i2p is.
12I. Point of Contact for Security Issues
14security@geti2p.net - GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A
16II. Security Response Team
18Only the following members have access to the security point of contact:
20    zzz
21    str4d
23III. Incident Response
251) Researcher submits report via one or both methods:
26    a) PGP encrypted email (key can be found in section I)
27    b) HackerOne
292) Response Team designates a Response Manager who is in charge of the particular report based on availability and/or knowledge-set
313) In no more than 3 working days, the Response Team should gratefully respond to researcher using encrypted methods
334) Response Manager makes inquiries to satisfy any needed information and to confirm if submission is indeed a vulnerability:
34    a) If submission proves to be vulnerable, proceed
35    b) If not vulnerable:
36        b1) Response Manager responds with reasons why submission is not a vulnerability
37        b2) Response Manager moves discussion to a new or existing ticket on public Trac if necessary
395) If over email, Response Manager opens a HackerOne issue for new submission
416) a) Establish severity of vulnerability:
42    - HIGH
43        Effects network as a whole, has potential to break entire network or exploit is easily performed
44    - MEDIUM
45        Effects individual routers or must be carefully exploited
46    - LOW
47        Not easily exploited or very low impact
49   b) If there are any disputes regarding the level of severity, the Response Team will define the bugs severity
517) Respond according to the severity of the vulnerability
52    a) HIGH severities must be notified on website and news feed within 3 working days of classification:
53        a1) The notification should list appropriate steps for users to take, if any
54        a2) The notification must not include any details that could suggest an exploitation path
55        a3) The latter takes precedence over the former.
56    b) MEDIUM severity vulnerbilities must be notified on website and news feed within 1 week of classification
57    c) MEDIUM and HIGH severities will require a Point Release
58    d) LOW severities will be addressed in the next Regular Release
59    e) If no severity is found, updates will happen at the discretion of the Response Team
618) Response Team applies appropriate patch(es)
62    a) Response Manager designates a PRIVATE monotone "hotfix branch" to work in
63    b) Patches are reviewed with the researcher. Any messages associated with PUBLIC commits during the time of review should not make reference to the security nature of the PRIVATE branch or its commits
64    c) Vulnerability announcement is drafted:
65        c1) Include severity of vulnerability
66        c2) Include systems/apps effected
67        c3) Include solutions (if any) if patch cannot be applied
699) Release date is discussed
70    a) At release date, Response Team coordinates with developers to finalize update:
71        a1) Response Manager propagates the "hotfix branch" to trunk
72        a2) Response Manager includes vulnerability announcement draft in release notes
73        a3) Proceed with the Point or Regular Release
75IV. Post-release Disclosure Process
771) Response Team has 90 days to fulfill all points within section III
792) If the Incident Response process in section III is successfully completed:
80        a) Response Manager contacts researcher and asks if researcher wishes to receive credit
81        b) Finalize vulnerability announcement draft and include the following:
82            b1) Project name and URL
83            b2) Versions known to be affected
84            b3) Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected)
85            b4) Versions not checked
86            b5) Type of vulnerability and its impact
87            b6) If already obtained or applicable, a CVE-ID
88            b7) The planned, coordinated release date
89            b8) Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations)
90            b9) orkarounds (configuration changes users can make to reduce their exposure to the vulnerability)
91            b10) If applicable, credits to the original researcher
933) Release finalized vulnerability announcement on website and in news feed
94        a) For HIGH severities, release finalized vulnerability announcement on well-known mailing lists:
95            - oss-security@lists.openwall.com
96            - bugtraq@securityfocus.com
97        b) If applicable, developers request a CVE-ID
98            b1) The commit that applied the fix is made reference too in a future commit and includes a CVE-ID
1004) If the Incident Response process in section III is *not* successfully completed:
101        a) Response Team and developers organize an IRC meeting to discuss why/what points in section III were not resolved and how the team can resolve them in the future
102        b) Any developer meetings immediately following the incident should include points made in section V.
103        c) If disputes arise about whether or when to disclose information about a vulnerability, the Response Team will publicly discuss the issue via IRC and attempt to reach consensus
104        d) If consensus on a timely disclosure is not met (no later than 90 days), the researcher (after 90 days) has every right to expose the vulnerability to the public
106V. Incident Analysis
1081) Isolate codebase
109        a) Response Team and developers should coordinate to work on the following:
110            a1) Problematic implementation of classes/libraries/functions, etc.
111            a2) Focus on apps/distro packaging, etc.
112            a3) Operator/config error, etc.
1132) Auditing
114        a) Response Team and developers should coordinate to work on the following:
115            a1) Auditing of problem area(s) as discussed in point 1.
116            a2) Generate internal reports and store for future reference.
117            a3) If results are not sensitive, share with the public via IRC or public Trac.
118        b) Response Team has 45 days following completion of section III to ensure completion of section V
120VI. Resolutions
122Any further questions or resolutions regarding the incident(s) between the researcher and response + development team after public disclosure can be addressed via the following:
124    Trac
125    HackerOne
126    IRC
127    Email
128    Twitter
130VII. Continuous Improvement
1321) Response Team and developers should hold annual meetings to review the previous year's incidents
1342) Response Team or designated person(s) should give a brief presentation, including:
135        a) Areas of I2P affected by the incidents.
136        b) Any network downtime or monetary cost (if any) of the incidents
137        c) Ways in which the incidents could have been avoided (if any)
138        d) How effective this process was in dealing with the incidents
1393) After the presentation, Response Team and developers should discuss:
140        a) Potential changes to development processes to reduce future incidents
141        b) Potential changes to this process to improve future responses