GITBOOK-921: Minor fixes to the Vulnerability Reports & Disclosure page.

departments-operations/security/playbooks/vulnerability-reports-and-disclosure.md

@@ -1,87 +1,89 @@
 # Vulnerability Reports & Disclosure
 
-## Bug Bounty / Hackerone
+### Bug Bounty / Hackerone
 
-HackerOne is a service that allows us to interact with \*\*external\*\* parties (e.g. white hat hackers) to collect, manage and disclose vulnerabilities that are discovered by them. HackerOne is managed by the security team. All members of Rocket.Chat can request access if they want or should collaborate directly with the external party. Hackerone runs parallel to Jira, which is used for \*\*internal\*\* collaboration. (HackerOne reports are linked to Jira issues once the report moves to under triage phase)
+HackerOne is a service that allows us to interact with **external** parties (e.g. independent security researchers) to collect, manage and disclose vulnerabilities that are discovered by them. HackerOne is managed by the Security Team. All members of Rocket.Chat can request access if they want or should collaborate directly with the external party. Hackerone runs parallel to Jira, which is used for **internal** collaboration. (HackerOne reports are linked to Jira issues once the report moves to under triage phase).
 
-## Vulnerability Reports & Disclosure
+### Vulnerability Reports & Disclosure
 
-We have an established vulnerability management program that handles all layers of our application and infrastructure by using 8 main data sources, including our HackerOne program, internal pentest, vendors pentest, and tooling that runs vulnerability assessment scans in our ecosystem.
+We have an established [Vulnerability Management program](https://app.gitbook.com/o/-M41dOPtnjO7qK6KCyrt/s/-M7hDnLLoVYXnODyaFd3-41739140/\~/changes/920/departments-and-operations/security/playbooks/vulnerability-management-process) that handles all layers of our application and infrastructure by using 8 main data sources, including our HackerOne program, internal pentest, vendors pentest, and tooling that runs vulnerability assessment scans in our ecosystem.
 
 Secondary channels are:
 
 * Reports or questions come in from customers through our Support Desk or other direct channel.
-* Issues opened on the public issue trackers. The security team can not review all new issues and relies on everyone in the company to identify and label issues as `~security` and mention security team members issues.
+* Issues opened on the public issue trackers. The Security Team can not review all new issues and relies on everyone in the company to identify and label issues as \~security and mention security team members issues.
 * Issues reported by automated security scanning tools
 
 For reported vulnerabilities:
 
-* If the source is HackerOne you can create an Jira issue automatically when moving the report to Triage phase (select Create new Jira issue)
-  * If the vulnerability was reported via a public issue on Github, remove it and refer the reporter to our email adress or hackerone. Still open a Jira task, in case the reporter does not respond.
-* An initial determination is done by the security team as to severity and impact. Never dismiss a security report outright. Instead, follow up with the reporter, asking clarifying questions.
+* If the source is HackerOne you can create an Jira issue automatically when moving the report to Triage phase (select "Create new Jira issue")
+  * If the vulnerability was reported via a public issue on Github, remove it and refer the reporter to our email adress or HackerOne. Still open a Jira task, in case the reporter does not respond.
+* An initial determination is done by the Security Team as to severity and impact. Never dismiss a security report outright. Instead, follow up with the reporter, asking clarifying questions.
 * Remember to prepare patches, blog posts, email templates, etc. on or in other non-public ways even if there is a reason to believe that the vulnerability is already out in the public domain (e.g. the original report was made in a public issue that was later made confidential).
 
-Our current SLA to deal with vulnerabilities are: 
+For all reported vulnerabilities, regardless of source, reporters should expect a first-response time of up to 5 (five) business days.
 
-* **Critical:** 14 days
-* **High:** 30 days
-* **Medium:** 60 days
-* **Low:** Best effort unless risk accepted
+Our current SLA to deal with vulnerabilities are:
 
-If you want to understand how our vulnerability management process works [here](https://docs.google.com/document/d/1bZS01mxfJgnoEZ384W2xYxlBIFw\_8CaXE9\_J1oytGeI/edit?usp=sharing) is a document with the details
+* Critical: 14 days
+* High: 30 days
+* Medium: 60 days
+* Low: Best effort unless risk accepted
 
-### To prepare a Security Fix
+More information about our Vulnerability Management process can be found [here](https://app.gitbook.com/o/-M41dOPtnjO7qK6KCyrt/s/-M7hDnLLoVYXnODyaFd3-41739140/\~/changes/920/departments-and-operations/security/playbooks/vulnerability-management-process).
 
-Security Fixes are developed by the proper dev teams.
+#### To prepare a Security Fix
+
+Security Fixes are developed by the Security Team or the proper Development Teams.
 
 {% hint style="info" %}
-\*\*For our development teams: \*\*A dedicated step-by-step guideline of the policy aspects relevant for you can be found [here](https://docs.google.com/document/d/1Lsc8INA6jDwp8sTDvLR7O7v7PLEt967ubv8BG4yyV14/edit?usp=sharing).
+**For our development teams:** A dedicated step-by-step guideline of the policy aspects relevant for you can be found.
 {% endhint %}
 
 Fixes must be made available as per our [support policy](https://docs.rocket.chat/getting-support).
 
 Security Fixes must not contain keywords such as "exploit", "hack", or similar and should be phrased technology-neutral. We want to explain what has changed, not describe exploit techniques.
 
-Security fixes should be developed and have their testing done on **private forks** of the appropriate Rocket.Chat versions that will receive the fix. That means these PRs should not show up in the public repositories.
+Security fixes should be developed and have their testing done on private forks of the appropriate Rocket.Chat versions that will receive the fix. That means these PRs should not show up in the public repositories.
 
-#### **CVE IDs**
+#### CVE IDs
 
-We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. Since we publicly disclose all security vulnerabilities 30 days after a patch is released, CVE IDs must be obtained for each vulnerability to be fixed. The earlier obtained the better, and it should be requested either during or immediately after a fix is prepared.
+We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. Since we publicly disclose all security vulnerabilities 30 (thirty) days after a patch is released, CVE IDs must be obtained for each vulnerability to be fixed. The earlier obtained the better, and it should be requested either during or immediately after a fix is prepared.
 
-The security team currently requests CVEs either through the HackerOne form (preferred) or directly through MITRE's [webform](https://cveform.mitre.org).
+The Security Team currently requests CVEs either through the HackerOne form (preferred) or directly through MITRE's [webform](https://cveform.mitre.org/).
 
-Keep in mind that some of our security releases contain _security related_ enhancements which may not have an associated [CWE](https://cwe.mitre.org) or vulnerability. These particular issues are not required to obtain a CVE since there's no associated vulnerability. CVE IDs obtained via the webform must be manually referenced in the HackerOne issue.
+Keep in mind that some of our security releases contain security related enhancements which may not have an associated [CWE](https://cwe.mitre.org/) or vulnerability. These particular issues are not required to obtain a CVE. CVE IDs obtained via the webform must be manually referenced in the HackerOne issue and Jira ticket.
 
-### When a Fix is Ready
+#### When a Fix is Ready
 
 When a patch has been developed, tested, approved, and a new release is being prepared, the dev team updates the Jira task with a reference to the PR(s).
 
 Security then informs the researcher via HackerOne. Post a comment on the HackerOne issue to all parties informing them that a patch is ready and will be included with the next release. Provide release dates, if available, but try not to promise a release on a specific date if you are unsure. You may also share relevant code snippets with the researcher for him to comment on or verify the fix.
 
 This is also a good time to ask if the researcher would like public credit in our release blog post and on our vulnerability acknowledgements page for the finding. We will link their name or alias to their HackerOne profile, Twitter handle, Facebook profile, company website, or URL of their choosing. Also ask if they would like the HackerOne report to be made public after the responsible disclosure period counting from the release. It is always preferable to publicly disclose reports unless the researcher has an objection.
 
-For **critical** security issues, prepare a message for Rocket.Cat to be sent out on release day.
+For critical security issues, prepare a message for Rocket.Cat to be sent out on release day.
 
-#### On Release Day <a href="#on-release-day" id="on-release-day"></a>
+**On Release Day**
 
 On the day of the security release several things happen in order:
 
-* All security patches are pushed to the public repository (unless they are not already in there).
-* The new Rocket.Chat version is published.
-* For **critical** security fixes, an additional Rocket.Cat message is sent to all registered workspaces.
-* The update process of the hosted workspaces is started by the infrastructure team
-* The public is notified via the Rocket.Chat blog release post.
-* The security updates page and the White Hat Hall of Fame are updated with appropriate credits to the reporting researchers.
+1. All security patches are pushed to the public repository (unless they are not already in there).
+2. The new Rocket.Chat version is published.
+3. For critical security fixes, an additional Rocket.Cat message is sent to all registered workspaces.
+4. The update process of the hosted workspaces is started by the infrastructure team
+5. The public is notified via the Rocket.Chat blog release post.
+6. The security updates page and the White Hat Hall of Fame are updated with appropriate credits to the reporting researchers.
 
 Once all of these things have happened notify the HackerOne researcher that the vulnerability and patch are now public. The Jira issue should be closed and the HackerOne report should be closed as "Resolved". Public disclosure should occur if the Hacker has requested it and the responsible disclosure period is started. Any sensitive information contained in the HackerOne report should be sanitized before disclosure.
 
-### After release day
+**After release day**
 
-#### Swag for Reports <a href="#swag-for-reports" id="swag-for-reports"></a>
+**Swag for Reports**
 
 We award swag on a case by case basis. Details are in our responsible disclosure policy on HackerOne. When a report is closed, ask the reporter if they would like a swag code for free Rocket.Chat clothing or accessories. Swag codes are available by request from the operations team.
 
-#### Responsible disclosure period ended
+**Responsible disclosure period ended**
 
 After the responsible disclosure period has ended, HackerOne will automatically release the report. Upon notification of the report release, update the CVE entry via the webform if it had been requested via the webform. Otherwise HackerOne will automatically update the CVE entry.