Not Another Scanner! Use Vulnerability Data You Already Have to Level Up Your VM Program
Every parent has told their kids to “play with the toys you already have.” (Having two young children myself, I say it every time we walk into a Target.) What if I told you that a similar concept applies to vulnerability management?
Every business has a treasure trove of untapped vulnerability data. Tapping into that data in the right way will enable you to level up your organization’s VM program.
The vast majority of enterprises have a lot of security tools. They have tools that scan their CI/CD pipelines, code scanning tools (SAST, DAST, secrets scanning, etc.), container scanning tools, cloud scanning tools, penetration testing reports, and bug bounty reports. And, of course, we can’t forget about the more traditional vulnerability assessment tools. You get the idea.
Security teams can’t (and shouldn’t try to) address all the vulnerabilities those scanners identify. Security teams should, however, take a risk-based approach to address the vulnerabilities that have the most significant impact on the business.
As a VM professional, what can you do to gain insights and drive change based on those findings?
I’m going to look at two types of data that already exist in your organization and how you can use them to improve your ability to reduce risk (without needing to purchase yet another tool/scanner/detection product):
- The vulnerability data that exists from your various scanners
- The other useful data that you can extract from these same scanners
Are you sure you’re looking at all your vulnerability data?
It’s essential for you to consider the vulnerabilities found by your scanners. However, in this post, we will discuss some less obvious vulnerability data that you may not be using yet.
In case you haven’t gotten the memo, modern vulnerability management consists of managing vulnerabilities beyond traditional on-prem infrastructure scanners. Today, security teams must evaluate vulnerabilities across security programs, including infrastructure, applications and cloud. You must determine if your program considers vulnerabilities across security programs and adjust accordingly.
It’s not uncommon for companies with sizable technology infrastructures to reach 10s of millions of vulnerabilities when you contemplate all severity levels. At this scale, you will never address every issue you find. Despite this, you need to ensure you’re not only looking at CVEs.
To some, “vulnerability” equals “CVE.” Using those words interchangeably is becoming dangerously outdated. The reality is that vulnerabilities (in the broad, modern sense) should include risks that aren’t CVEs. For example, a public AWS S3 bucket made public because of a misconfiguration doesn’t have a CVE tied to it, but it still potentially carries an inordinate amount of risk. That’s why it’s important to look at critical CVEs as well as the other critical “vulnerabilities.”
Is your vulnerability risk management program only analyzing data from scans that surface CVEs, or are you also prioritizing other types of vulnerability data from scanners detecting non-CVE risk types (like cloud misconfigurations)?
Use the asset data from security scans to improve the accuracy of your asset inventory
Just as you have scanners looking for vulnerabilities, somewhere in your organization is some system that houses asset data. Usually, this comes in the form of a CMDB — which is notoriously out of date and inaccurate.
And, while vulnerability teams don’t typically own the CMDB, they are one of its heaviest users. This means that while tactically, the accuracy of your asset inventory “isn’t your problem” — in reality, you’ve got to ensure the accuracy and completeness of your asset inventory.
Due to so many security tool scans running in an organization, VM teams are starting to gain unique insights into the systems within their asset landscape. (Because while we hunt for vulnerabilities, the tools we use also provide data on the affected asset.)
If you use this data with the right intentions, you can expose — and fill — gaps in the asset inventory system of record. This helps security teams collaborate productively with their IT counterparts to create more complete and accurate asset inventories, which is essential because, in addition to documenting the systems within an organization, CMDBs and their alternatives include important business context, such as whether an application requires PCI compliance or other essential business context used during the prioritization step of the cyber risk lifecycle.
You don’t need another scanner to reduce business risk
A tremendous amount of data already exists in your security program that you can use to level up your VM program’s ability to reduce business risk — and you can do it without buying yet another scanner.
You need to ensure the VM team is addressing more than just CVEs while also collaborating with IT to improve the accuracy and completeness of the CMDB by applying vulnerability data. That’s how you’ll start reducing your organization’s risk levels by putting the data you already have to work.
Ravi Pentapaty has more than 15 years of cybersecurity experience, including the last decade with Warner Bros. Discovery, where he rose to senior director of vulnerability management and security architecture. This blog series features his real-world practitioner’s insights on vulnerability management.
