Ticket #1119: I2P_VRP_draft_2015.11.16.txt

File I2P_VRP_draft_2015.11.16.txt, 9.8 KB (added by anonimal, 4 years ago)
2I2P Vulnerability Response Process - 2015.11.16
3anonimal@mail.i2p - GPG Key fingerprint = 1218 6272 CD48 E253 9E2D  D29B 66A7 6ECF 9144 09F1
7        1. XXX denotes that a thought, section, or a remainder of a line is variable and open for immediate debate or requires definition.
9        2. "Researcher": entity that submits a security-related issue.
11        3. "Response Team": a team of developers who are solely responsible for adhering to the VRP.
12                a. They may have roles in other aspects of I2P but they work only within their team and the researcher during the VRP.
14        4. "Report Manager": a Response Team member in charge of a particular report.
16        5. XXX "Emergency Release": an update procedure that differs from regular update procedure but includes all the necessities of a regular update.
20        1. I2P would host its own private, confidential, security-related Trac or patch the current Trac for sensitive submissions.
22        2. I2P uses a HackerOne account.
24        3. All parties agree that no information should be made public about the vulnerability until the disclosure process has been complete. This includes:
25                a. Any correspondence regarding the vulnerability made between researcher and any individual or entity outside of the I2P development team.
26                        i. This includes an accidental or intentional CC or BCC within email.
27                b. Exploits posted on any public forum.
31I. Point of Contact for Security Issues
33        security@geti2p.net - GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A
35II. Security Response Team
37        1. Only the following members have access to security@geti2p.net and GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A
38                a. zzz
39                b. str4d
40                c. XXX <insert as needed>
42III. Incident Response
44        1. Researcher submits report via one or both of two methods:
45                a. Email to security@geti2p.net using Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A
46                        i.      If Researcher choses only to correspond via email, then email correspondence will be copied into the private Trac.
47                b. HackerOne at https://hackerone.com/i2p
49        2. Response Team designates a Report Manager who is in charge of the particular report based on availability and/or knowledge-set.
51        3. In no more than 3 working days, Response Team should gratefully respond to researcher using only encrypted methods.
53        4. Report Manager makes inquiries to satisfy any needed information and to confirm if submission is indeed a vulnerability.
54                a. If submission proves to be vulnerable, proceed to point 5.
55                b. If not vulnerable:
56                        i.      Report Manager responds with reasons why submission is not a vulnerability.
57                        ii.     Report Manager opens the issue on public Trac if not already opened.
59        5. Report Manager opens a private ticket for new submission. Ticket status is set to triage/highest priority.
61        6. Report Manager grants researcher access to private Trac for continued correspondence.
63        7. Establish severity of vulnerability
64                a. HIGH
65                        i.   Effects network as a whole, has potential to break entire network or is on a scale of great catastrophe.
66                        ii.  Immediate new post on website, news feed.
67                b. MEDIUM
68                        i.   Effects individual routers, must be carefully exploited.
69                        ii. Depending on severity, may or may not be announced immediately.
70                c. LOW
71                        i.   Is not easily exploitable but must be addressed immediately.
72                        ii.  No immediate news post, news feed.
74        8. Respond according to the severity of the vulnerability
75                a. ALL severities will require an Emergency Release (see 10).
76                b. XXX Sliding-scale bounty
78        9. Response Team applies appropriate patch(es).
79                a. Report Manager temporarily disables the Monotone-to-Git gateway for the duration of VRP.
80                b. Report Manager designates a PRIVATE monotone "hotfix branch" to work in.
81                c. Patches are reviewed with the researcher.
82                d. 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.
83                e. Vulnerability announcement is drafted.
84                        i.   Include severity of vulnerability.
85                        ii.  Include systems/apps effected.
86                        iii. Include solutions (if any) if patch cannot be applied.
87                f. Release date is discussed.
89        10. Response Team coordinates with developers to finalize update:
90        a. Report Manager propagates the "hotfix branch" it to trunk.
91                b. Report Manager enables the Monotone-to-Git gateway.
92                c. Report Manager includes vulnerability announcement draft in release notes.
93                d. Proceed with the Emergency Release.
95IV. Post-release Disclosure Process
97        1. Response Team has 90 days to fulfill all points within point III [Incident Response].
99        2. If the Incident Response process in III is successfully completed:
100                a. Finalize vulnerability announcement draft and include the following:
101                        i.    Project name and URL.
102                        ii.   Versions known to be affected.
103                        iii.  Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected).
104                        iv.   Versions not checked.
105                        v.    Type of vulnerability and its impact.
106                        vi.   If already obtained or applicable, a CVE-ID.
107                        vii.  The planned, coordinated release date.
108                        viii. Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations).
109                        ix.   Workarounds (configuration changes users can make to reduce their exposure to the vulnerability).
110                        x.    If applicable, credits to the original reporter.
111                b. Report Manager contacts researcher and asks if researcher wishes for credit.
112                c. If researcher wishes for credit:
113                        i.   Announce credit on website, news feed, XXX Hall of Fame.
114                        ii.  Include credit in changelog.
115                d. Release finalized vulnerability announcement through I2P medium
116                        i.   I2P website.
117                        ii.  Routerconsole feed.
118                        iii. XXX security@geti2p.net mailing list
119                e. Release finalized vulnerability announcement on well-known mailing lists:
120                        i.   XXX i2p-security@lists.i2p2.de  <-- not currently implemented
121                        ii.  XXX oss-security@lists.openwall.com
122                        iii. XXX bugtraq@securityfocus.com
123                f. If applicable, developers request a CVE-ID.
124                        i.      The commit that applied the fix is made reference too in a future commit and includes a CVE-ID.
126        3. If the Incident Response process in III is *not* successfully completed::
127                a. Response Team and developers organize an IRC meeting to discuss why/what points in III were not resolved and how the team can resolve them in the future.
128                b. Any developer meetings immediately following the incident should include points made in section V [Incident Analysis].
129                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.
130                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.
132V. Incident Analysis
134        1. Isolate codebase
135                a. Response Team and developers should coordinate to work on the following:
136                        i.   XXX Problematic implementation of classes/libraries/functions, etc.
137                        ii.  XXX Focus on apps/distro packaging, etc.
138                        iii. XXX Operator/config error, etc.
140        2. Auditing
141                a. Response Team and developers should coordinate to work on the following:
142                        i.   XXX Auditing of problem area(s) as discussed in point 1.
143                        ii.  XXX Generate internal reports and post in private Trac for future reference.
144                        iii. XXX If results are not sensitive, share with the public via IRC or public Trac.
146VI. Establish Metrics
148        1. XXX Response Team or designated person(s) should gather metrics data from private Trac and organize for brief presentation
150        2. Response Team and developers should hold two annual meetings to review past (or current) incidents
151                a. XXX The first meeting convenes at some point in January, after C3
152                b. XXX The second meeting convenes at some point mid-summer, before I2PCon
154        3. XXX For the meetings, Response Team or designated person(s) should:
155                a. Describe which area of I2P was affected by the incident(s).
156                b. Describe any network downtime or monetary cost (if any) of the incident.
157                c. Report if any outsourcing was needed in the handling and cleanup of the incident
158                d. If applicable, give estimates of any long-term costs such as regulatory fines, brand damage, XXX shaved kittens, etc.
159                e. Propose a stance on what kind of proactive review or operational practice, if properly implemented, may have detected the incident earlier or lessened the damage.
160                f. If practice was in place and implementation failed, describe the failure and review or propose successful solutions.
162VII. Resolutions
164        1. Any further questions or resolutions regarding the incident(s) between the researcher and response + development team after public disclosure can be addressed via the following:
165                a. Trac
166                b. HackerOne
167                c. IRC
168                d. Email
169                e. Twitter
170                f. XXX
172        2. This process is subject to change. Please visit the website for the most up-to-date VRP.
176Resources Considered:
194# vim: noai:ts=4:sw=4