From 5ca344b33cfb17536e38317f65da59aefddcea11 Mon Sep 17 00:00:00 2001
From: anonimal <anonimal@i2pmail.org>
Date: Fri, 1 Sep 2017 01:49:09 +0000
Subject: [PATCH] Resources: link to single-policy VRP on frontpage
---
_includes/header.html | 10 ++-
resources/vrp/index.md | 145 -----------------------------------------
2 files changed, 8 insertions(+), 147 deletions(-)
delete mode 100644 resources/vrp/index.md
diff --git a/_includes/header.html b/_includes/header.html
index 2c618299..5b1ba01f 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -60,7 +60,6 @@
<a href="/resources/moneropedia/">Moneropedia</a>
<a href="/resources/user-guides/">User Guides</a>
<a href="/resources/developer-guides/">Developer Guides</a>
- <a href="/resources/vrp/">Vulnerability Response</a>
<a href="/resources/technical-specs/">Technical Specs</a>
</div>
</div>
@@ -72,6 +71,13 @@
</div>
</div>
</div>
+ <div class="row">
+ <div class="col-xs-12">
+ <div class="text-center nav-item mob">
+ <a href="https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md">Vulnerability Response</a>
+ </div>
+ </div>
+ </div>
<div class="row">
<div class="col-xs-12">
<div class="text-center nav-item mob">
@@ -94,6 +100,7 @@
<div class="row end-xs">
<div class="col-md-12">
<a href="https://forum.getmonero.org" class="mob top-link col-md-4">Forum Funding System</a>
+ <a href="https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md" class="mob top-link col-md-4">Vulnerability Response</a>
<a href="/the-monero-project/" class="mob top-link col-md-3">The Monero Project</a>
</div>
</div>
@@ -150,7 +157,6 @@
<a href="/resources/user-guides/">User Guides</a>
<a href="/resources/developer-guides/">Developer Guides</a>
<a href="/resources/technical-specs/">Technical Specs</a>
- <a href="/resources/vrp/">Vulnerability Response</a>
</div>
</div>
</div>
diff --git a/resources/vrp/index.md b/resources/vrp/index.md
deleted file mode 100644
index 314144e6..00000000
--- a/resources/vrp/index.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-layout: static_page
-title: "Vulnerability Response Process"
-icon: "icon_people"
-attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and is licensed under Creative Commons BY 3.0 -->"
----
-
-# 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
--
GitLab