Vulnerability Management Workflow

Introduction

The purpose of the document is to describe the established vulnerability management workflow in the MYRTLE GROUP S.A. (“we” or “Cloudback”).

Overview

Vulnerability Management is the recurring process of identifying, classifying, prioritizing, mitigating, and remediating vulnerabilities. This document will focus on infrastructure vulnerabilities and the vulnerability management process. This process is designed to provide information regarding Cloudback vulnerability workflow, promote healthy patch management among other preventative best practices, and remediate risk; all with the end goal to better secure our environments.

The Vulnerability Management process

Arguably the most important step for a successful vulnerability management process is defining the scope that the process will cover. Security and Infrastructure partnered to come up with a scope that would make sure all of our critical environments and systems were covered during deployment.

Currently, vulnerability management consists of the following steps:

1. Vulnerability Scanning

This step is where we scan resources in our environments to identify vulnerabilities. Once setup, scans are run on regular cadences that meet or exceed our requirements.

2. Reporting/Analysis

Vulnerability scan results are analyzed to provide consolidated vulnerability data and save the results in the internal bug tracking system as a separate issue with corresponding severity and priority. These issues are where all discussion and documentation for the vulnerability will occur. Vulnerability remediation issues should be tagged with the vulnerability type label. The following labels exist to track the vulnerability remediation workflow:

vulnerable: This label identifies that the vulnerability has been opened, but not validated and is considered impactful to our environments per the assigned priority label. With this label a vulnerability issue should not be closed.

validated: This label identifies that the vulnerability has been validated as legitimate and is scheduled for mitigation or remediation. With this label, a vulnerability issue should not be closed.

false positive: This label identifies that the vulnerability has been validated as a false positive and is no longer impactful to our environments. With this label, a vulnerability issue can be closed.

exception: This label identifies that the vulnerability has been validated as legitimate and has an approved exception issue to account for a business need. In extreme circumstances, a vulnerability issue can be closed with an exception.

mitigated: This label identifies that the vulnerability has been validated and triaged. The impact has been reduced through compensating controls, but not remediated (it is still actively identified on vulnerability scans). With this label, a vulnerability issue should not be closed.

remediated: This label identifies that the vulnerability has been remediated and the remediation has been validated. With this label, a vulnerability issue can be closed.

3. Validation

Validation is an important part of vulnerability management. This is where we investigate to ensure that the vulnerability being reported has properly been identified.

Vulnerabilities can sometimes be identified during a scan, but are not on the system. These are classified as false positives and would go through the process to be closed as a false positive.

4. Remediation

Remediation is the part of the process in which a validated vulnerability is fixed. The remediation process would be tracked in the corresponding vulnerability issue in the internal issue tracker. SLAs are in place to help prioritize vulnerability based on severity. Once a vulnerability is remediated, we will run followup scans on the impacted systems to validate that the vulnerability is indeed remediated.

5. Feedback

The last step is for the Cloudback team to determine what we can learn from each vulnerability remediated. This may be an improvement on the vulnerability management process itself or establishing preventive mechanisms for a repetitive vulnerability type. This feedback will be documented in the vulnerability issue and could result in additional issues being opened.

As stated above, this process is a cyclical loop. Vulnerability scans are recurring, providing new vulnerability data that feed new vulnerability remediation and exception issues which then help update/escalate open issues/processes.

Remediation SLAs

Cloudback team has come up with remediated SLAs based on a multitude of factors, such as severity, scope, impact, etc. All of these factors will be considered when mapping the priority to Cloudback’s priority labels. The SLAs are as follows:

• Severity 1, Priority 1:

  • Severity Mapping: Zero-day,

  • Time to mitigate: Within 24 hours

  • Time to remediate: Within 72 hours (when technically feasible)

• Severity 2, Priority 2:

  • Severity Mapping: Critical

  • Time to mitigate: N/A

  • Time to remediate: Within 30 days

• Severity 3, Priority 3:

  • Severity Mapping: High

  • Time to mitigate: N/A

  • Time to remediate: Within 60 days

• Severity 4, Priority 4:

  • Severity Mapping: Medium

  • Time to mitigate: N/A

  • Time to remediate: Within 90 days