mirror of
https://github.com/monero-project/meta.git
synced 2024-11-17 00:07:52 +00:00
Merge pull request #116 from anonimal/VRP
The Monero Project: create single-policy VRP
This commit is contained in:
Riccardo Spagni
GitHub
commit
f4095aaee4
1 changed files with 168 additions and 0 deletions
168
VULNERABILITY_RESPONSE_PROCESS.md
Normal file
168
VULNERABILITY_RESPONSE_PROCESS.md
Normal file
|
|
@ -0,0 +1,168 @@
|
||||||
|
# The Monero Project Vulnerability Response Process
|
||||||
|
|
||||||
|
## Preamble
|
||||||
|
|
||||||
|
1. Researchers/Hackers: while you research/hack, we ask that you please refrain from committing the following:
|
||||||
|
- Denial of Service / Active exploiting against the Monero/Kovri networks
|
||||||
|
- Social Engineering of Monero/Kovri Project staff or contractors
|
||||||
|
- Any physical or electronic attempts against Monero/Kovri community property and/or data centers
|
||||||
|
|
||||||
|
2. As a pro-privacy project we have volunteers running copies of the websites on hidden services on Tor and I2P, as well as on multiple public domains. **The live sites are NOT in the scope of this process; only the code is!**
|
||||||
|
|
||||||
|
## I. Points of Contact for Security Issues
|
||||||
|
|
||||||
|
### Monero (CLI/GUI/Website)
|
||||||
|
|
||||||
|
```
|
||||||
|
ric [at] getmonero.org
|
||||||
|
BDA6 BD70 42B7 21C4 67A9 759D 7455 C5E3 C0CD CEB9
|
||||||
|
|
||||||
|
luigi1111 [at] getmonero.org
|
||||||
|
8777 AB8F 778E E894 87A2 F8E7 F4AC A018 3641 E010
|
||||||
|
```
|
||||||
|
|
||||||
|
### Monero (CLI/GUI)
|
||||||
|
|
||||||
|
```
|
||||||
|
moneromooo.monero [at] gmail.com
|
||||||
|
48B0 8161 FBDA DFE3 93AD FC3E 686F 0745 4D6C EFC3
|
||||||
|
```
|
||||||
|
|
||||||
|
### Kovri (CLI/Website)
|
||||||
|
|
||||||
|
```
|
||||||
|
anonimal [at] i2pmail.org
|
||||||
|
anonimal [at] mail.i2p
|
||||||
|
PGP key fingerprint = 1218 6272 CD48 E253 9E2D D29B 66A7 6ECF 9144 09F1
|
||||||
|
```
|
||||||
|
|
||||||
|
## II. Security Response Team
|
||||||
|
|
||||||
|
- fluffypony
|
||||||
|
- luigi1111
|
||||||
|
- moneromooo
|
||||||
|
- anonimal
|
||||||
|
|
||||||
|
## III. Incident Response
|
||||||
|
|
||||||
|
1. Researcher submits report via one or both of two methods:
|
||||||
|
- a. Email
|
||||||
|
- b. [HackerOne](https://hackerone.com/monero)
|
||||||
|
|
||||||
|
2. Response Team designates a Response Manager who is in charge of the particular report based on availability and/or knowledge-set
|
||||||
|
|
||||||
|
3. In no more than 3 working days, Response Team should gratefully respond to researcher using only encrypted, secure channels
|
||||||
|
|
||||||
|
4. Response Manager makes inquiries to satisfy any needed information to confirm if submission is indeed a vulnerability
|
||||||
|
- a. If submission proves to be vulnerable, proceed to next step
|
||||||
|
- b. If not vulnerable:
|
||||||
|
- i. Response Manager responds with reasons why submission is not a vulnerability
|
||||||
|
- ii. Response Manager moves discussion to a new or existing ticket on GitHub if necessary
|
||||||
|
|
||||||
|
5. If over email, Response Manager opens a HackerOne issue for new submission
|
||||||
|
|
||||||
|
6. Establish severity of vulnerability:
|
||||||
|
- a. HIGH: impacts network as a whole, has potential to break entire monero/kovri network, results in the loss of monero, or is on a scale of great catastrophe
|
||||||
|
- b. MEDIUM: impacts individual nodes, routers, wallets, or must be carefully exploited
|
||||||
|
- c. LOW: is not easily exploitable
|
||||||
|
|
||||||
|
7. Respond according to the severity of the vulnerability:
|
||||||
|
- a. HIGH severities must be notified on website and reddit /r/Monero (/r/Kovri for kovri) within 3 working days of classification
|
||||||
|
- i. The notification should list appropriate steps for users to take, if any
|
||||||
|
- ii. The notification must not include any details that could suggest an exploitation path
|
||||||
|
- iii. The latter takes precedence over the former
|
||||||
|
- b. MEDIUM and HIGH severities will require a Point Release
|
||||||
|
- c. LOW severities will be addressed in the next Regular Release
|
||||||
|
|
||||||
|
8. Response Team applies appropriate patch(es)
|
||||||
|
- a. Response Manager designates a PRIVATE git "hotfix branch" to work in
|
||||||
|
- b. Patches are reviewed with the researcher
|
||||||
|
- c. 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
|
||||||
|
- d. Vulnerability announcement is drafted
|
||||||
|
- i. Include the severity of the vulnerability
|
||||||
|
- ii. Include all vulnerable systems/apps/code
|
||||||
|
- iii. Include solutions (if any) if patch cannot be applied
|
||||||
|
- e. Release date is discussed
|
||||||
|
|
||||||
|
9. At release date, Response Team coordinates with developers to finalize update:
|
||||||
|
- a. Response Manager propagates the "hotfix branch" to trunk
|
||||||
|
- b. Response Manager includes vulnerability announcement draft in release notes
|
||||||
|
- c. Proceed with the Point or Regular Release
|
||||||
|
|
||||||
|
## IV. Post-release Disclosure Process
|
||||||
|
|
||||||
|
1. Response Team has 90 days to fulfill all points within section III
|
||||||
|
|
||||||
|
2. If the Incident Response process in section III is successfully completed:
|
||||||
|
- a. Response Manager contacts researcher and asks if researcher wishes for credit
|
||||||
|
- b. Finalize vulnerability announcement draft and include the following:
|
||||||
|
- i. Project name and URL
|
||||||
|
- ii. Versions known to be affected
|
||||||
|
- iii. Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected)
|
||||||
|
- iv. Versions not checked
|
||||||
|
- v. Type of vulnerability and its impact
|
||||||
|
- vi. If already obtained or applicable, a CVE-ID
|
||||||
|
- vii. The planned, coordinated release date
|
||||||
|
- viii. Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations)
|
||||||
|
- ix. Workarounds (configuration changes users can make to reduce their exposure to the vulnerability)
|
||||||
|
- x. If applicable, credits to the original reporter
|
||||||
|
- c. Release finalized vulnerability announcement on website and reddit /r/Monero (/r/Kovri for kovri)
|
||||||
|
- d. For HIGH severities, release finalized vulnerability announcement on well-known mailing lists:
|
||||||
|
- i. oss-security@lists.openwall.com
|
||||||
|
- ii. bugtraq@securityfocus.com
|
||||||
|
- e. If applicable, developers request a CVE-ID
|
||||||
|
- i. The commit that applied the fix is made reference too in a future commit and includes a CVE-ID
|
||||||
|
|
||||||
|
3. If the Incident Response process in section III is *not* successfully completed:
|
||||||
|
- 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
|
||||||
|
- b. Any developer meetings immediately following the incident should include points made in section V
|
||||||
|
- 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
|
||||||
|
- 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
|
||||||
|
|
||||||
|
## V. Incident Analysis
|
||||||
|
|
||||||
|
1. Isolate codebase
|
||||||
|
- a. Response Team and developers should coordinate to work on the following:
|
||||||
|
- i. Problematic implementation of classes/libraries/functions, etc.
|
||||||
|
- ii. Focus on apps/distro packaging, etc.
|
||||||
|
- iii. Operator/config error, etc.
|
||||||
|
|
||||||
|
2. Auditing
|
||||||
|
- a. Response Team and developers should coordinate to work on the following:
|
||||||
|
- i. Auditing of problem area(s) as discussed in point 1
|
||||||
|
- ii. Generate internal reports and store for future reference
|
||||||
|
- iii. If results are not sensitive, share with the public via IRC or GitHub
|
||||||
|
|
||||||
|
3. Response Team has 45 days following completion of section III to ensure completion of section V
|
||||||
|
|
||||||
|
## VI. Resolutions
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
- IRC on Freenode
|
||||||
|
- `#monero-dev`
|
||||||
|
- `#kovri-dev`
|
||||||
|
- [GitHub](https://github.com/monero-project/monero/issues/)
|
||||||
|
- [Monero (CLI)](https://github.com/monero-project/monero/issues/)
|
||||||
|
- [Monero (GUI)](https://github.com/monero-project/monero-core/issues/)
|
||||||
|
- [Monero (Website)](https://github.com/monero-project/monero-site/issues/)
|
||||||
|
- [Kovri](https://github.com/monero-project/kovri/issues/)
|
||||||
|
- [Kovri (Website)](https://github.com/monero-project/kovri-site/issues/)
|
||||||
|
- [HackerOne](https://hackerone.com/monero)
|
||||||
|
- [Reddit /r/Monero](https://reddit.com/r/Monero/)
|
||||||
|
- [Reddit /r/Kovri](https://reddit.com/r/Kovri/)
|
||||||
|
- Email
|
||||||
|
|
||||||
|
## VII. Continuous Improvement
|
||||||
|
|
||||||
|
1. Response Team and developers should hold annual meetings to review the previous year's incidents
|
||||||
|
|
||||||
|
2. Response Team or designated person(s) should give a brief presentation, including:
|
||||||
|
- a. Areas of Monero/Kovri affected by the incidents
|
||||||
|
- b. Any network downtime or monetary cost (if any) of the incidents
|
||||||
|
- c. Ways in which the incidents could have been avoided (if any)
|
||||||
|
- d. How effective this process was in dealing with the incidents
|
||||||
|
|
||||||
|
3. After the presentation, Response Team and developers should discuss:
|
||||||
|
- a. Potential changes to development processes to reduce future incidents
|
||||||
|
- b. Potential changes to this process to improve future responses
|
||||||
Loading…
Reference in a new issue