Vulnerability Management Process

Owned by Renata Pereira Juraski
Last updated: Jul 17, 2024 by Julio
4 min read

Objectives

This document describes how Rocket.Chat's security team handles vulnerability management to identify, validate, prioritize and mitigate security issues in the company's assets.

The process aims to minimize our exposure to risks, maintain compliance with security standards, protect the privacy of all users and clarify the roles and responsibilities of the teams/squads involved.

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: all code developed in the public and private repositories under Rocket.Chat's organization.

Vulnerability 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:

diagram-mermaid.svg
Vulnerability Management @ Rocket.Chat

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.

    • External Penetration Testing: assessments conducted by third-party professionals hired by Rocket.Chat.

    • Internal Penetration Testing: assessments performed by Rocket.Chat's 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.