We’ll start at the beginning.
According to ISO 27002, a vulnerability is “a weakness of an asset or group of assets that can be exploited by one or more threats.”
The SANS Institute goes on to summarize Vulnerability Management as “the process in which vulnerabilities in IT are identified and the risks of these vulnerabilities are evaluated. This evaluation leads to correcting the vulnerabilities and removing the risk or a formal risk acceptance by the management of an organization.”
In security our primary measure is “risk” and our mandate is to understand, lessen, and control that risk. If you remember back to your ISC2 studies, risk is the outcome when you combine threats and vulnerabilities, with threats being anything that can exploit a vulnerability to cause damage to an asset.
Risk = Threat * Vulnerability
So with some of the tomes of the industry weighing in with such broad strokes, why does it often feel like the modern implementation of vulnerability management tools are so narrowly focused on vulnerability scanners, IP addresses, and CVEs as the archetypal entities? I believe that all of the terms above are defined in such vague language on purpose, and that’s because the nature of defining what is a vulnerability is fluid itself.
What is the Status Quo?
In the vendor landscape today there are a few primary object types that the solutions are modeled around.
First are assets, which most often can just be considered as computers of one sort or another. These can be employee workstations, servers, virtual machines, IoT devices, and much, much more. They are often identified by an IP address or a hostname/FQDN. These asset objects often also contain other identifying and/or actionable attributes that are collected during a vulnerability scan. For example attributes such as the MAC Address, operating system, BIOS UUID, and many, many more are frequently added to provide additional context around the assets themselves.
Next are vulnerabilities. These are most often mapped directly to a CVE, which conveniently come with a CVSS score attached to communicate its severity. Frequently though, within the different vulnerability management tools, there can be other vulnerabilities reported that don’t have an associated CVE, but are clearly vulnerabilities in many circumstances. An example of this might be an open port on a host that should not be exposed.
Why is this a problem? While this system can work very well in isolation, when it begins to fall apart is once products from different vendors are used together. Things can still work well for vulnerabilities that directly tie to a CVE, but when vulnerability findings from disparate products are aggregated together and there is a disconnect between the perceived severity level of different vulnerabilities it can limit a team’s ability to categorize and prioritize remediations.
As security organizations grow, the larger the likelihood is that there will be a growing number of tools and vendors used internally. Consolidating all of the generated data in a way that is accurate and actionable is the crux of the problem.
As security teams today see more and more requirements from emerging domains like DevSecOps and cloud governance, the types of data that need to be handled have expanded far beyond network/host-based CVEs.
What Are We Missing?
There is certainly some danger here in defining what Vulnerability Management is too broadly — however since we’ve seen that the status quo is already missing notable categories, I think it is valuable to include the following domains:
Software Vulnerabilities (AppSec)
This is a huge category, encompassing everything from Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA) to Container Security to Pen Testing tools.
There are some blurred lines between several of the categories of AppSec tools, and they can output a CVE and/or a CWE, or neither. Their subjects also differ greatly from what we traditionally considered assets since they’re not a host, but rather just a piece of software under development or actively deployed.
Remediating AppSec findings can also be difficult because applications are tested using different tools at different steps in the SDLC, making quick developer feedback of paramount importance. Remediation itself is also best left to the developers since the steps to remediate are often as simple as applying the latest patch.
Shadow IT (Attack Surface Discovery)
At a certain scale, just knowing what assets belong to an organization becomes challenging. Whether you have multiple development organizations or you engage in a merger or acquisition, it becomes very difficult to maintain an accurate, up-to-date list of all of the assets and services that a VM team needs to oversee.
Even the best Vulnerability Management teams can’t protect what they don’t know about, making this category vitally important for having complete visibility into an organization’s attack surface.
The cloud is pervasive in IT today, touching nearly every organization to some degree. Managing risks in the cloud is a massive undertaking all of its own, requiring everything from managing permissions to tracking down rogue assets.
One major difficulty for cloud security as it relates to VM is the ephemerality of many assets in the cloud. Additionally, depending on how your organization is leveraging the cloud, you may only have varying levels of access to remediate issues on your own.
In addition to discovering on-prem assets, Expanse finds cloud assets belonging to your organization across all cloud providers — not just AWS, Azure, and GCP. We attribute discovered cloud assets back to your organization in a variety of ways, including domain and signature-based attribution.
Where Do We Go From Here?
Think of Vulnerability Management as a process rather than a tool. There are a lot of awesome tools out there that solve some subset of the problems described here — but it may be more useful to start thinking of some of these as Vulnerability Assessment rather than Vulnerability Management.
Redefine what an asset is. We need to redefine assets to be more flexible than just some kind of a computer — an asset could be a workstation, a server, a piece of code, a running container, or more. We need to be able to think of assets generally, but address them specifically.
Vulnerabilities also need some redefining. While CVEs with CVSS scores work well as a means of ranking severity, they fall short when in instances where vulnerabilities are not a specific instance of a known weakness.
Improve how we aggregate and prioritize risks. Teams today are understaffed and overwhelmed — they need to be able to take in findings from a number of tools across categories and prioritize remediations objectively.
Armed with the combined power of Expanse and your VM solution, your security team will be equipped to unlock the full value out of your VM program. If you are not a current Expanse customer, we’d love to talk with you about how we can help. And if you’re a customer, contact your Engagement Manager for assistance.
This article has been adapted from an earlier article on Medium. See the original article here.