From 3c0375685c04623e4b52a5d85d1dabe7d9f251a8 Mon Sep 17 00:00:00 2001 From: anonimal Date: Wed, 21 Jun 2017 19:21:53 +0000 Subject: [PATCH 1/2] Repo: add Vulnerability Response Process --- VULNERABILITY_RESPONSE_PROCESS.md | 138 ++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 VULNERABILITY_RESPONSE_PROCESS.md diff --git a/VULNERABILITY_RESPONSE_PROCESS.md b/VULNERABILITY_RESPONSE_PROCESS.md new file mode 100644 index 00000000..6960b091 --- /dev/null +++ b/VULNERABILITY_RESPONSE_PROCESS.md @@ -0,0 +1,138 @@ +# Monero Site Vulnerability Response Process + +## Preamble + +Researchers/Hackers: while you research/hack, we ask that you please refrain from committing the following: +- Denial of Service / Active exploiting against the network +- Social Engineering of Monero staff or contractors +- Any physical or electronic attacks against Monero community property and/or data centers + +## I. Points of Contact for Security Issues + +``` +ric@getmonero.org +BDA6 BD70 42B7 21C4 67A9 759D 7455 C5E3 C0CD CEB9 + +luigi1111@getmonero.org +8777 AB8F 778E E894 87A2 F8E7 F4AC A018 3641 E010 +``` + +## II. Security Response Team + +- fluffypony +- luigi1111 + +## 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 site as a whole, has potential to break entire site, results in the loss of user-data, or is on a scale of great catastrophe + - b. MEDIUM: impacts individual users, 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 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. LOW and MEDIUM and HIGH severities will require a rolling release update of the site + +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 + - 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: + +- [GitHub](https://github.com/monero-project/monero/issues/) +- [HackerOne](https://hackerone.com/monero) +- [Reddit /r/Monero](https://reddit.com/r/Monero/) +- IRC +- 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 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 From cb5fdf21d9158b0d09caad3accd3544d2b4ed4af Mon Sep 17 00:00:00 2001 From: anonimal Date: Thu, 22 Jun 2017 20:35:05 +0000 Subject: [PATCH 2/2] Knowledge-base: create VRP page --- _includes/header.html | 2 ++ _strings_en.yml | 1 + .../vrp/index.md | 7 +++++++ 3 files changed, 10 insertions(+) rename VULNERABILITY_RESPONSE_PROCESS.md => resources/vrp/index.md (97%) diff --git a/_includes/header.html b/_includes/header.html index a5c2374b..34280034 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -60,6 +60,7 @@ Moneropedia User Guides Developer Guides + Vulnerability Response @@ -147,6 +148,7 @@ Moneropedia User Guides Developer Guides + Vulnerability Response diff --git a/_strings_en.yml b/_strings_en.yml index 1145b730..4bf81edb 100644 --- a/_strings_en.yml +++ b/_strings_en.yml @@ -37,6 +37,7 @@ menu: people: The People Behind Monero userguides: User Guides developerguides: Developer Guides + vrp: Vulnerability Response Process goals: Design & Development Goals openalias: The OpenAlias Project lab: Monero Research Lab diff --git a/VULNERABILITY_RESPONSE_PROCESS.md b/resources/vrp/index.md similarity index 97% rename from VULNERABILITY_RESPONSE_PROCESS.md rename to resources/vrp/index.md index 6960b091..314144e6 100644 --- a/VULNERABILITY_RESPONSE_PROCESS.md +++ b/resources/vrp/index.md @@ -1,3 +1,10 @@ +--- +layout: static_page +title: "Vulnerability Response Process" +icon: "icon_people" +attribution: "" +--- + # Monero Site Vulnerability Response Process ## Preamble