Ticket #1119: I2P_VRP_draft_2015.09.30.txt

File I2P_VRP_draft_2015.09.30.txt, 9.6 KB (added by anonimal, 5 years ago)
Line 
1== DRAFT FORM - NOT FOR OFFICIAL USE ==
2I2P Vulnerability Response Process - 2015.09.30
3anonimal@mail.i2p - GPG Key fingerprint = 1218 6272 CD48 E253 9E2D  D29B 66A7 6ECF 9144 09F1
4
5Legend:
6       
7        1. XXX denotes that a thought, section, or a remainder of a line is variable and open for immediate debate.
8
9        2. "Researcher": entity that submits a security-related issue.
10
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.
13
14Assumptions:
15       
16        1. I2P would host its own private, confidential, security-related Trac or patch the current Trac for sensitive submissions.
17
18        2. All parties agree that no information should be made public about the vulnerability until the disclosure process has been complete. This includes:
19                a. Any correspondence regarding the vulnerability made between researcher and any individual or entity outside of the I2P development team.
20                        i. This includes an accidental or intentional CC or BCC within email.
21                b. Exploits posted on any public forum.
22                c. XXX
23       
24        3. Vulnerabilities, as used in this document, are defined by the following criteria:
25                a. XXX <insert or remove as needed>
26                b. Broken Authentication or Session Management
27                c. Command Injection
28                d. Cross-Site Request Forgery (CSRF)
29                e. Cross-Site Scripting (XSS)
30                f. Cryptographic Issue
31                g. Denial of Service
32                h. Insecure Direct Object Reference
33                i. Memory Corruption
34                j. Missing Function Level Access Control
35                k. SQL Injection
36                l. Security Misconfiguration
37                m. Sensitive Data Exposure / Information Disclosure
38                n. UI Redressing
39                o. Unvalidated Redirect or Forward
40                p. Using Components with Known Vulnerabilities
41
42        4. Non-security related issues are not subject to this VRP and are instead handled by the public Trac.
43
44BEGIN
45
46I. Point of Contact for Security Issues
47
48        security@geti2p.net - GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A
49
50II. Security Response Team Members
51
52        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
53                a. zzz
54                b. str4d
55                c. XXX <insert as needed>
56
57III. Incident Response
58
59        1. Researcher submits report via email to security@geti2p.net using Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A
60
61        2. Message is relayed, without response, to security response team.
62
63        3. In no more than 3 working days, response team should gratefully respond to researcher using only encrypted methods.
64
65        4. Response team makes inquiries to satisfy any needed information and to confirm if submission is indeed a vulnerability.
66                a. If submission proves to be vulnerable, proceed to point 5.
67                b. If not vulnerable, response team responds with reasons why submission is not a vulnerability.
68
69        5. Response team opens a private ticket for new submission. Ticket status is set to triage/highest priority.
70
71        6. Response team grants researcher access to private Trac for continued correspondence.
72
73        7. XXX Establish severity of vulnerability
74                a. HIGH
75                        i.   Effects network as a whole, has potential to break entire network or is on a scale of great catastrophe.
76                        ii.  Immediate new post on website, news feed.
77                b. MEDIUM
78                        i.   Effects individual routers, must be carefully exploited.
79                        iii. Depending on severity, may or may not be announced immediately.
80                c. LOW
81                        i.   Is not easily exploitable but must be addressed immediately.
82                        ii.  No immediate news post, news feed.
83
84        8. XXX Respond accordingly to severity of vulnerability
85                a. XXX Sliding scale bounty
86                b. XXX <insert any other responses>
87
88        9. Response team applies appropriate patch(es).
89                b. Patches are reviewed with the researcher.
90                a. XXX Any messages associated with commits during the time of review should not make any reference to the security nature of the commit.
91                c. Vulnerability announcement is drafted.
92                        i.   Include severity of vulnerability.
93                        ii.  Include systems/apps effected.
94                        iii. Include solutions (if any) if patch cannot be applied.
95                d. Release date is discussed.
96
97        10. Response team coordinates with developers to finalize update:
98                a. Include appropriate fixes in new release.
99                b. Append changelog.
100                c. Append appropriate version number.
101                d. XXX Proceed with usual update process.
102
103IV. Disclosure Process
104
105        1. Response team and developers have XXX 7 days to fulfill all points within point III [Incident Response] XXX or else face the Wrath of Khan.
106
107        2. If point III is fulfilled:
108                a. Finalize vulnerability announcement draft and include the following:
109                        i.    Project name and URL.
110                        ii.   Versions known to be affected.
111                        iii.  Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected).
112                        iv.   Versions not checked.
113                        v.    Type of vulnerability and its impact.
114                        vi.   If already obtained or applicable, a CVE-ID.
115                        vii.  The planned, coordinated release date.
116                        viii. Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations).
117                        ix.   Workarounds (configuration changes users can make to reduce their exposure to the vulnerability).
118                        x.    If applicable, credits to the original reporter.
119                b. Contact researcher to (XXX offer bounty or say thanks) and ask if researcher wishes for credit.
120                c. If researcher wishes for credit:
121                        i.   Announce credit on website, news feed, XXX Hall of Fame.
122                        ii.  Include credit in changelog.
123                d. Announce vulnerability details through I2P medium
124                        i.   I2P website.
125                        ii.  Routerconsole feed.
126                        iii. XXX security@geti2p.net mailing list
127                f. Announce vulnerability on well-known mailing lists:
128                        i.   XXX i2p-security@lists.i2p2.de  <-- not currently implemented
129                        ii.  XXX oss-security@lists.openwall.com
130                        iii. XXX bugtraq@securityfocus.com
131                g. If applicable, developers request a CVE-ID.
132                h. XXX The commit that applied the fix is made reference too in future commits which includes a CVE-ID.
133
134        3. If point III is *not* fulfilled:
135                a. XXX Beat each other with a stick or semi-hard object.
136                b. Response team and developers organize an IRC meeting to discuss why point III was not resolved and how we can avoid that in the future.
137                c. Any developer meetings immediately following the incident should include points made in section V [Incident Analysis].
138                d. 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.
139                e. If the consensus on a timely disclosure is not met, the researcher has every right to expose the vulnerability to the public before the IV. Disclosure Process has completed.
140
141V. Incident Analysis
142
143        1. Isolate codebase
144                a. Response team and developers should coordinate to work on the following:
145                        i.   XXX Problematic implementation of classes/libraries/functions, etc.
146                        ii.  XXX Focus on apps/distro packaging, etc.
147                        iii. XXX Operator/config error, etc.
148
149        2. Auditing
150                a. Response team and developers should coordinate to work on the following:
151                        i.   XXX Auditing of problem area(s) as discussed in point 1.
152                        ii.  XXX Generate internal reports and post in private Trac for future reference.
153                        iii. XXX If results are not sensitive, share with the public via IRC or public Trac.
154
155VI. Establish Metrics
156
157        1. XXX Response team or designated person(s) should gather metrics data from private Trac and organize for brief presentation
158
159        2. Response team and developers should hold two annual meetings to review past (or current) incidents
160                a. XXX The first meeting convenes at some point in January, after C3
161                b. XXX The second meeting convenes at some point mid-summer, before I2PCon
162
163        3. XXX For the meetings, response team or designated person(s) should:
164                a. Describe which area of I2P was affected by the incident(s).
165                b. Describe any network downtime or monetary cost (if any) of the incident.
166                c. Report if any outsourcing was needed in the handling and cleanup of the incident
167                d. If applicable, give estimates of any long-term costs such as regulatory fines, brand damage, XXX shaved kittens, etc.
168                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.
169                f. If practice was in place and implementation failed, describe the failure and review or propose successful solutions.
170
171VII. Resolutions
172
173        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:
174                a. Trac
175                b. IRC
176                c. Email
177                d. Twitter
178                e. XXX
179
180        2. This process is subject to change. Please visit the website for the most up-to-date VRP.
181
182END
183
184Resources considered:
185
186http://trac.i2p2.i2p/wiki/OpenITPReview/Criteria
187http://www.oracle.com/us/support/assurance/vulnerability-remediation/introduction/index.html
188https://access.redhat.com/security/team/contact/
189https://bounty.github.com/#rules
190https://duck.co/feedback/bug/-
191https://hackerone.com/
192https://help.github.com/articles/responsible-disclosure-of-security-vulnerabilities/
193https://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/
194https://www.apache.org/security/
195https://www.apache.org/security/committers.html
196https://www.google.com/appserve/security-bugs/m2/new?rl=&key=
197https://www.mozilla.org/en-US/about/governance/policies/security-group/bugs/
198https://www.owasp.org/index.php/SAMM_-_Vulnerability_Management_-_3
199https://www.python.org/news/security/
200https://www.torproject.org/about/contact.html.en#security
201
202# vim: noai:ts=4:sw=4