Vulnerability Management: a CSIRT perspective
What Vulnerability Management is about (explained with the support of the CSIRT Services Framework)
Vulnerability management is one of the most daunting tasks for cybersecurity professionals. Trends clearly show continuous growth in the number of reported vulnerabilities as well as a clear lack of cybersecurity professionals and skills.
Which, in practice, means more and more work to do with fewer resources.
For the average IT department of a modern company, the vulnerability management process represents the one where a vulnerability is:
Learned from Public Sources
Identified on all the systems and software owned by the company;
Prioritized and scheduled for remediation.
Even if this is perfectly true and fine for the vast majority of the subjects which are users of third parties’ solutions and software, the perspective changes radically if we look at that part of the process which brings from vulnerability discovery from the public disclosure, and which still goes under the name of vulnerability management.
With this post, I will try to shed light on what vulnerability management actually means, from both perspectives.
I will do this with the support of the "CSIRT Service Framework" by FIRST, a framework that provides a catalog of services to be implemented by Cyber Security Incident Response Teams.
The framework is organized into five "Service Areas", meant to group a set of coherent services related to a common aspect.
Each area features a narrative "description", explaining the focus of the area itself.
Each area is further split into functions and sub-functions, aimed the first at fulfilling the purpose of a specific service, whilst the latter is the purpose of a specific function. Both functions and sub-functions are detailed with a (narrative) description, a purpose (which is the intent of functions and sub-functions), and the outcome which is the tangible result produced by the activities.
As we may learn from the picture, Vulnerability Management is one of the five Areas in the Service framework. The first function of this area is Vulnerability Discovery and Research, which is the one responsible for identifying vulnerabilities. This might mean, as we anticipated above, two things that are radically different: to patch a vulnerability that we learned of from public sources, or to disclose publicly a vulnerability that we have found for some reason (while carrying out vulnerability research, eventually also in the context of an incident response activity if, for instance, a zero-day had been exploited).
We will discuss later on this post these two possible "paths" (“Path to vulnerability patching” and “Path to vulnerability disclosure”) and the related workflows with the support of the “CSIRT Service Framework”.
“Path to vulnerability patching”
The Path to vulnerability patching is familiar to all of us who have to maintain an IT infrastructure or have to develop or maintain a solution that (necessarily) leverages third-party components.
In such a case, we have to consider the specific functions of the framework and some of the related sub-functions. Regarding the Vulnerability Discovery and Research, what is important here is to ensure effective coverage of the public sources' vulnerability discovery. Many valuable repositories exist like for instance the NVD (http://nvd.nist.gov) or CWE (http://cwe.mitre.org) repositories both sponsored by the CISA Agency, as well as other advisory services like the GitHub Advisory Database (https://github.com/advisories).
The second part of the workflow is about the vulnerability response part, which requires first that all the assets affected by the vulnerability are identified. Having in our hands the Software Bills of Materials for the solutions within the perimeter of our verification is true of great help, and could lead us in some cases to have the information regarding the vulnerability within the SBOM itself.
Otherwise, we can leverage scanners (like a DAST scanner for a Web Application) making sure that scanners' signatures are up-to-date and provide coverage about the vulnerability we are looking for.
Then, once vulnerabilities have been identified, we enter the mitigation phase. A crucial step here is the one that brings to the prioritization according to scoring indicators. Different kinds of inputs can be used for this purpose, like:
The CVSS (Common Vulnerability Scoring System) to evaluate the technical severity of the vulnerability;
The SVCC (Stakeholder-Specific Vulnerability Categorization) accounts for a vulnerability's exploitation status, impacts on safety, and prevalence of the affected product in a singular system;
The EPSS (Exploit Prediction Scoring System) which indicates the likelihood of exploitation;
The CISA KEV feed indicates exploited vulnerabilities;
Other commercial scoring mechanisms, for instance, Vulnerability Priority Rating (VPR) from TENABLE to quantify the risk and urgency of a vulnerability;
“Path to vulnerability disclosure”
The second workflow is the one related to the actual vulnerability discovery process. Here the task is not about learning of something known from public sources, but instead to identify a never-before-seen problem, that can be both the outcome of a deliberate "vulnerability research activity", or eventually occur as the outcome of an incident response activity.
Once the problem has been identified, we move to the phase of understanding how big it is and start framing it correctly. The Report Intake functions are actually those responsible for this since they represent a kind of triaging phase where we are collecting reports and information about the vulnerability. At this stage, there is still no full understanding of the vulnerability nor countermeasures have been identified.
All such material represents a valuable input for the Analysis phase, which is indeed the one responsible for identifying either the root causes of a vulnerability as well as possible remediations, with two sub-functions explicitly dedicated to this activity.
The (strictly speaking) technical activities stop almost here since we should now have in our hands a clear picture of the vulnerability: what has caused it, how to exploit it, which consequence it can bring if exploited, and finally how to remediate it.
Then, all this information should be made available outside and all the relevant stakeholders properly informed. We have already seen in a number of past circumstances how crucial this process is. Let's not forget that an ethical approach to vulnerability disclosure should put those affected by the vulnerability in a position to address the issue as quickly as possible, thus making the window of exposure as narrow as possible. Without considering the issues regarding the capability of an organization to act upon the information provided, it is essential for the process to provide at least such pieces of information regarding:
the systems affected by the vulnerability (vendor, version), and the configurations/circumstances under which the vulnerability would be exploitable;
which extent such systems are affected by the vulnerability and which the consequence might be;
how to remediate/mitigate the vulnerability, like if an update is already available or will be released, or possible measures we can implement to at least mitigate it.
Thus, two steps are foreseen by the CSIRT framework to make this activity effective.
The Vulnerability Coordination function is the one where stakeholders involved in the Coordinated Disclosure process share information behind the scenes, to inform each other about the perimeter and depth of the vulnerability, and make sure that all the information that shall be provided outside is available so that the path to vulnerability mitigation is straightforward for the recipients.
The Vulnerability Disclosure function is the one where the information is made available via the pre-identified channels. The sub-functions responsible for defining a vulnerability disclosure policy and for (eventually) updating it based on the feedback received fall under and represent probably the most critical part of the function itself. When this is the case the process of disclosing the vulnerability should be just executed according to the policy.
Once the process is complete, the vulnerability is publicly available and is then ready to feed the Path to Vulnerability patching” described above.
Conclusions
In this post, we clarified what is usually meant by vulnerability management.
We did it with the support of the CSIRT Service Framework, which details a number of services to be offered by Cyber Security Incident Response Teams. Among these services, there are also services connected with Vulnerability Management.
We finally identified two possible paths that both fall under the vulnerability management umbrella: the one where an organization becomes aware of a public vulnerability and has to patch it (path to vulnerability patching) and the one where it is actively engaged in the process of discovery and disclosure (path to vulnerability disclosure), describing the main actions and implications for each of these paths.
References
FIRST - Computer Security Incident Response Team (CSIRT) Services Framework - https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1
FIRST EPSS - https://www.first.org/epss/
FIRST CVSS - https://www.first.org/cvss/
CISA SVCC - https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc;
TENABLE VPR - https://docs.tenable.com/security-center/Content/RiskMetrics.htm;