-
Notifications
You must be signed in to change notification settings - Fork 174
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
makes it closer to bitcoin's vesion of it
- Loading branch information
1 parent
64c1662
commit f1db6ae
Showing
1 changed file
with
9 additions
and
119 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,124 +1,14 @@ | ||
| # Gridcoin Vulnerability Response Process | ||
| # Security Policy | ||
|
|
||
| ## Preamble | ||
| ## Reporting a Vulnerability | ||
|
|
||
| Researchers/Hackers: while you research/hack, we ask that you please refrain from committing the following: | ||
| - Denial of Service / Active exploiting against the main network | ||
| - Social Engineering of Gridcoin developers or maintainers | ||
| - Any physical or electronic attempts against Gridcoin community property and/or data centers | ||
| Contact [security@gridcoin.us](mailto:security@gridcoin.us) to help notify developers about security issues | ||
|
|
||
| If you do need to test the execution of an exploit, use the Gridcoin testnet. | ||
| For sensitive information, the following keys can be used: | ||
|
|
||
| ## Point of Contact for Security Issues | ||
| |Developer | Fingerprint | | ||
| |-|-| | ||
| |[Cy Rossignol](https://github.com/cyrossignol) (also known as cycy) | | | ||
| |[James C. Owens](https://github.com/jamescowens) | 2F03 F85D 0DD8 6635 7698 4E17 2804 081B E891 286A | | ||
|
|
||
| Contact [security@gridcoin.us](mailto:security@gridcoin.us) to help notify developers and or ask questions | ||
|
|
||
| ## Security Response Team | ||
|
|
||
| - [Cy Rossignol](https://github.com/cyrossignol) (also known as cycy) | ||
| - [James C. Owens](https://github.com/jamescowens) | ||
|
|
||
| ## Incident Response | ||
|
|
||
| 1. Researcher submits report via Email | ||
|
|
||
| 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 | ||
|
|
||
| 6. Establish severity of vulnerability: | ||
| - a. HIGH: impacts network as a whole, has potential to break entire network, results in the loss of gridcoin, or is on a scale of great catastrophe | ||
| - b. MEDIUM: impacts individual nodes, 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 the website and Discord within 3 working days of classification (ideally all other platforms too) | ||
| - 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 | ||
|
|
||
| ## Post-release Disclosure Process | ||
|
|
||
| 1. Response Team has 90 days to fulfill all points within the incident response section | ||
|
|
||
| 2. If the Incident Response process 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. The planned, coordinated release date | ||
| - vii. Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations) | ||
| - viii. Workarounds (configuration changes users can make to reduce their exposure to the vulnerability) | ||
| - ix. If applicable, credits to the original reporter | ||
| - c. Release finalized vulnerability announcement on website and Discord (ideally all other platforms too) | ||
|
|
||
| 3. If the Incident Response process is *not* successfully completed: | ||
| - a. Response Team and developers organize an Slack / IRC meeting to discuss why/what points in the incident response 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 the incident analysis | ||
| - c. If disputes arise about whether or when to disclose information about a vulnerability, the Response Team will publicly discuss the issue via Slack / 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 | ||
|
|
||
| ## 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, Slack or GitHub | ||
|
|
||
| 3. Response Team has 45 days following completion of the incident response to ensure completion of the incident analysis | ||
|
|
||
| ## 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/gridcoin/Gridcoin-Research) | ||
| - [Slack Team Gridcoin](https://teamgridcoin.slack.com) | ||
| - [Discord](https://discord.gg/jf9XX4a) or [IRC](irc://irc.freenode.net/#gridcoin) (they are bridged) | ||
|
|
||
| ## 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 Gridcoin 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 | ||
| You can import a key by running the following command with that individual’s fingerprint: gpg --recv-keys "<fingerprint>" Ensure that you put quotes around fingerprints containing spaces. |