Objectives
This document outlines describes how Rocket.Chat's teams handle security team handles vulnerability management to identify, validate, prioritize , and mitigate security vulnerabilities issues in the company's assets.
This The process aims to minimize our exposure to security risks, maintain compliance with security standards, safeguard protect the privacy of all users , and clarify the roles and responsibilities of each teamthe teams/squad squads involved.
Scope
The scope of this vulnerability management process is crucial for determining its coverage within Rocket.Chat. This includes identifying the systems, applications, and assets that will undergo vulnerability assessment, prioritization, and remediation.
...
Infrastructure: this includes all the assets and resources managed within the OVH and AWS platforms.
...
Such a process should be simple and easy to follow, as the end goal is to effectively fix all vulnerabilities in the shortest possible time. Thus, this document describes and simplifies the most important steps of vulnerability management at Rocket.Chat.
If you have any questions or suggestions about this process or the documentation, please do not hesitate to contact the security team at security@rocket.chat.
Scope
This process covers the following:
Infrastructure: all assets owned and managed by Rocket.Chat, including resources on OVH and AWS.
Application: all the services and applications used and hosted by Rocket.Chat.
Source Code: this includes the source -code: all code developed in all the open public and private repositories under the Rocket.Chat Github 's organization.
Vulnerability
...
To identify and gather information about the vulnerabilities present across the entire Rocket.Chat's scope, the company uses several techniques and tools, including but not limited to the following list of vulnerability sources:
...
http://Tenable.io : as an internal and external vulnerability scanner for both applications and infrastructure assets.
...
Trivy: as a container and Infrastructure as Code (IaC) scanner.
...
Kube-hunter: as a Kerbernetes cluster vulnerability scanner.
...
Snyk: as a third-party dependency scanner.
...
Prowler: as an AWS vulnerability scanner platform.
...
In-house Pentests: penetration tests performed by the Rocket.Chat Security team over the internal and external assets owned by the organization.
...
Third-Party Pentests: penetration tests performed by third-party companies over Rocket.Chat's internal and external assets owned by the organization.
...
Management
Vulnerability management involves a series of steps that a security engineer is responsible for ensuring are properly followed throughout the entire vulnerability lifecycle. The overall steps in this process include:
...
New Vulnerability
...
Several sources can feed the vulnerability management board, including:
HackerOne: Rocket.Chat's public Bug Bounty Program (BBP)
for receiving vulnerability reports from external security researchers.
Vulnerability Management Process
Objectives
External Penetration Testing: assessments conducted by third-party professionals hired by Rocket.Chat.
Internal Penetration Testing: assessments performed by Rocket.Chat's
...
This process aims to minimize our exposure to security risks, maintain compliance with security standards, safeguard the privacy of all users, and clarify the roles and responsibilities of each team/squad involved.
Scope
The scope of this vulnerability management process is crucial for determining its coverage within Rocket.Chat. This includes identifying the systems, applications, and assets that will undergo vulnerability assessment, prioritization, and remediation.
Infrastructure: this includes all the assets and resources managed within the OVH and AWS platforms.
Applications: this includes all the services and web applications used and hosted by Rocket.Chat.
Source Code: this includes the source code developed in all the open and private repositories under the Rocket.Chat Github organization.
Vulnerability Identification
To identify and gather information about the vulnerabilities present across the entire Rocket.Chat's scope, the company uses several techniques and tools, including but not limited to the following list of vulnerability sources:
http://Tenable.io : as an internal and external vulnerability scanner for both applications and infrastructure assets.
Trivy: as a container and Infrastructure as Code (IaC) scanner.
Kube-hunter: as a Kerbernetes cluster vulnerability scanner.
Snyk: as a third-party dependency scanner.
Prowler: as an AWS vulnerability scanner platform.
In-house Pentests: penetration tests performed by the Rocket.Chat Security team over the internal and external assets owned by the organization.
Third-Party Pentests: penetration tests performed by third-party companies over Rocket.Chat's internal and external assets owned by the organization.
HackerOne: as a public Bug Bounty Program (BBP) to receive vulnerability reports from external security researchers.
Vulnerability Management Process
...
The current process starts with an identified vulnerability (1) from any of the vulnerability sources described in the Vulnerability Identification section.
In cases where a new vulnerability is identified, an acknowledgment of receipt (2) may be required. In such cases, the Security Team will be in charge of this communication. Examples of this could be the case of Bug Bounty reports coming from the HackerOne platform.
Right after, the Security Team will start the Vulnerability Validation (3) process, where they will try to reproduce the potential security issue and determine its eligibility.
...
If the vulnerability is deemed invalid, the Security Team will close the associated JIRA ticket (4) and, if necessary, communicate its status (5), thus completing the process.
If the vulnerability is valid, the Security Team will add, if needed, contextual information (6) to the ticket documentation like screenshots, references, recorded PoCs, and internal information to improve the vulnerability understanding and the consequent mitigation process.
Then, the Security Team will prioritize the issue (7) assigning it a severity and the corresponding SLA.
...
Following the prioritization of vulnerabilities, the Security Team will assess the complexity of fixing (8) each vulnerability and determine if they have the necessary resources to address it on their own.
If additional support is required from development squads, the Security Team will start the vulnerability triage (9), and assign the vulnerability JIRA ticket to the relevant squad. If multiple squads need to be involved, the original ticket will be cloned and linked to each squad's JIRA project. The Security Team will then initiate a Vulnerability Meeting Process (10) with the involved squads.
If the Security Team has all the resources needed, they will implement the proper fix for the vulnerability (14).
...
Once the fix is in place, the Security Team will validate (15) if it mitigates the vulnerability. If not, they will repeat the process, starting from the evaluation of the fix complexity (8).
Then, depending on the type of vulnerability, the Security Team will determine if a Squad needs to review the fix (16). If so, they will ask the relevant Squad to carry out a review (17).
Once the Squad has completed the fix review, the Security Team will check if they need to modify the solution based on the Squad's feedback (18). If necessary, the Security Team will repeat the process from the fix analysis stage (8).
...
Subsequently, the Security Team will check if the solution meets the criteria for a QA review (19) to prevent any interference with current features or functionalities. Once confirmed, they will request the review to proceed.
Upon completion of the QA review (20), any functional issues identified will need to be addressed by the Security Team. If changes are required (21), the process will restart from the fix analysis stage (8).
...
Once the fix has been reviewed and approved, the involved squads will proceed with deploying the patched asset (22). Only after, the Security Team will close the associated vulnerability ticket as resolved (23), and if necessary, will also create a CVE request to conclude the process (24), depending on the nature of the vulnerability.
...
Vulnerability Meeting Process
The Vulnerability Meeting process aims to establish an agile communication and collaboration channel when the Security Team requires assistance from the Squads to fix an identified vulnerability (10).
...
This process will start with a triaged vulnerability (9, 25).
First, the Security Team will create a Rocket.Chat discussion in a private channel (26) and invite the necessary Product Owners and Engineering Managers of the Squads involved.
In this discussion, the Security Team will inform stakeholders (27) about the issue's details, including its severity, associated SLA, and potential solutions. They will also provide stakeholders with the option to schedule a meeting to discuss the issue further.
Next, the Security Team will create action items (28), in the form of JIRA tickets, for each of the involved stakeholders.
The Squad responsible for fixing the vulnerability will follow their normal development workflow (11). As per the recent org change (where squads are working a more project-oriented approach) then a project with the vulnerabilities is submitted to request squad's help in fixing those vulnerabilities. Once the fix is complete, the Squad will request the Security Team a security validation (12) to confirm if the vulnerability has been mitigated. If the fix doesn't mitigate the vulnerability, the Security Team will provide recommendations to the Squad on how to fix it and the Squad will repeat the development process (11). If the vulnerability is successfully resolved, the process will continue as usual to release the patched asset (22).
...
internal security team.
GitHub: issues identified by Dependabot, Secrets Scanning and CodeQL.
Jira Issue
Once the vulnerability is identified, a Jira issue will need to be created in the vulnerability management board (VLN board) — either in an automated manner, by tools that we are using, or manually. This Jira issue will have the following fields:
Reporter: the creator of the issue — when using automated tools, it will be a service account.
Assignee: person responsible for tracking and/or fixing the vulnerability.
Risk Owner: person responsible for the product, capable of accepting the risk if needed.
Severity (Vulnerability): critical, high, medium or low.
Priority: highest, high, medium, low or lowest.
Vulnerability Reporting Source: HackerOne, Pen Test, etc.
Due Date: SLA for when the vulnerability should be fixed.
Risk Accepted Date: date documenting when the risk was accepted.
Vulnerability Fixed Date: date documenting when the vulnerability was fixed.
Repository (Vulnerability): GitHub repo, if applicable.
The issue will serve as the main source of information for tracking and managing the vulnerability. If needed, other engineers can create issues on their boards with their own settings and link the security issue to them.
Analysis
When a security engineer begins working on an issue, they will move it from "Backlog" to "Analysis" and assign it to themselves. Throughout the entire process, the security engineer is responsible for providing detailed updates by adding comments to the issue.
During the analysis phase, the security engineer will attempt to reproduce and verify the vulnerability.
During the analysis phase, the security engineer can also change the "Priority" and "Severity" fields if the vulnerability turns out to be less or more critical than originally reported.
Once the vulnerability is confirmed, the security engineer will inform the owner(s) of the vulnerable product and begin working with them to fix it. The security engineer is responsible for follow-up, reaching out to stakeholders, setting up meetings if necessary and providing developers with information and guidelines to help fix the vulnerability.
False Positive
If a vulnerability is determined to be invalid, the issue will be moved from "Analysis" to "False Positive," and a detailed explanation of why it is not valid will be added to the issue.
Risk Acceptance and Review
At this point, a risk owner — generally the highest-ranking individual responsible for the product — will be identified. The risk owner will evaluate whether Rocket.Chat can accept the risk. This evaluation must consider the impact of not fixing the vulnerability as well as the cost of fixing it.
If the cost to fix the issue is deemed too high and the risk owner decides to accept the risk, the issue will be moved to "Risk Accepted," and a detailed update will be added to the comments.
The issue must be reviewed within six months so that stakeholders can reassess whether the vulnerability should remain unfixed.
Mitigation
If the vulnerability risk is not accepted, it must be fixed by the developers involved with the product. Once the vulnerability is mitigated, the fix is reviewed and validated by the security team. If the fix is sufficient, the issue will be moved from "Analysis" to "Mitigated".
The current SLA for fixing vulnerabilities is:
Critical: 14 days.
High: 30 days.
Medium: 60 days.
Low: best effort unless risk accepted.
CVE Submission
Depending on the severity of the vulnerability, the security team may request a CVE. CVEs are typically requested for critical and high-severity vulnerabilities that could significantly impact Rocket.Chat and/or its users.