Vulnerability Management Workflow
The purpose of the document is to describe the established vulnerability management workflow in the MYRTLECONSULTING S.A. (“we” or “Mddocs”).
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 informationregarding Mddocs 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, the 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 run on regular cadences that meet or exceed our requirements.
Vulnerability scan results are analyzed to provide consolidated vulnerability data and save the results in the internal bug tracking sustem as a separate issues 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.
falsepositive: 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.
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 actually on the system. These are classified as false positives and would go through the process to be closed as a false positive.
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.
The last step is for the Mddocs 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.
Mddocs 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 Mddocs’s priority labels. The SLAs are as follows:
|Priority||Severity Mapping||Time to mitigate||Time to remediate|
|severity 1, priority 1||Zero-day||Within 24 hours||Within 72 hours (when technically feasible)|
|severity 2, priority 2||Critical||N/A||Within 30 days|
|severity 3, priority 3||High||N/A||Within 60 days|
|severity 4, priority 4||Medium||N/A||Within 90 days|
|severity 4, priority 4||Low||N/A||Best effort|