Vulnerability Management - An Overview
March 13, 2020
Vulnerability management will be an indispensable element of cyber security as long as manufacturers continue to build IT hardware and software. Vulnerabilities in complex software are inevitable, as inevitable as human fallibility. So, building a cybersecurity program without a robust vulnerability management process would be akin to building a house without gutters and hoping it won’t rain. This discussion will answer a number of questions about vulnerability management, walk through some best practices, and provide some recommendations for building a vulnerability management program that’s effective and resource sustainable.
Why Vulnerability Management is Required
Each year, countless new hardware products and software applications are released into the market, and even more new versions of existing software are distributed. Today’s software and hardware products are complex, and that complexity inevitably results in flaws - many of them obscure - that can be exploited by bad actors. So, the short answer to the question “why vulnerability management is required” is: vulnerabilities are inevitable. Indeed, just one company, Microsoft, on just one of its “Patch Tuesdays,” released fixes for 115 flaws in its various software products and versions. Moreover, 26 of those vulnerabilities were labeled “critical” by Microsoft. That’s 115 vulnerability patches by just one company, on one day.
Given the number of existing vulnerabilities, and the never-ending supply of new ones, there’s no way for enterprises to avoid building and executing a vulnerability management program. Different analyses put the number in different ranges, but between ⅓ to ⅔ of breaches are related to a vulnerability with a patch available at the time of the breach. So, why vulnerability management is required can be answered with a few related facts:
- Software is written by humans
- Humans are fallible
- Therefore, vulnerabilities are inevitable
- Software types and manufacturers are ubiquitous, so vulnerabilities are numerous, and will continue to be so
- A significant portion of successful breaches are the direct or indirect result of fixable vulnerabilities
- So a robust vulnerability management program is an essential and unavoidable part of any enterprise cyber security program
Why Do We Need Vulnerability Management?
There are two answers to the question “why do we need vulnerability management?” One is compliance, and the other is security. Much like when you were a child, there were two reasons to eat your vegetables: 1) they’re good for you, and 2) mom said so. From a compliance perspective, regulatory requirements vary from standard to standard, but some form of language like “IT must have a comprehensive, risk-based approach to managing security…” is typically part of the requirement, and that includes vulnerability management. Most compliance requirements are vague, and not particularly prescriptive, and can motivate organizations to simply “check the box” when it comes to cyber security, and particularly vulnerability management. Because of this, it’s best to focus the “why do we need vulnerability management” answer on the more important answer: legitimate information security.
An October 2019 Ponemon study concluded that 60% of 2019’s breaches involved unpatched vulnerabilities, and in just about every case, patches were available for the vulnerabilities that resulted in breaches. Given the number of vulnerabilities on the typical corporate network (thousands, hundreds of thousands, or even millions), vulnerability management is needed to deal with the fact that they all can’t be patched quickly, and more importantly, to assure that the ones that are most likely to facilitate a successful attack must be identified and prioritized.
We need vulnerability management to systematically address this reality. There are too many vulnerabilities to address practically, so we need a process, tools, and the discipline to bubble the most critical and high risk to the top of the remediation funnel. But, this can’t be done haphazardly, it must account for dozens of factors for each vulnerability, and it must do it regularly and without significant human intervention.
To summarize why we need vulnerability management:
- Compliance and regulatory requirements
- To assure quality cyber security
- To address the never ending stream of flaws in enterprise software
- To bubble to the top of the remediation funnel the vulnerabilities that are most likely to be responsible for, or contribute to, a data breach
Without question, we need vulnerability management, and, as discussed above, there are a number of reasons why. However, vulnerability management efforts are ineffective if they don't result in intelligent remediation. So, yes, we need vulnerability management, but more importantly, we need vulnerability remediation.
The challenge, however, is that vulnerability remediation depends heavily on vulnerability prioritization. Currently, most enterprise networks are filled with vulnerabilities, thousands, tens of thousands, or even hundreds of thousands of them. Thus makes it virtually impossible for IT remediation teams to "patch everything." Moreover, patching vulnerabilities can break systems, so the process can be risky. Thus, it's important to play remediation cards carefully, spending precious resources on the vulnerabilities that matter most, present the most risk to the organization, and where the patching risk is exceeded by the risk of the open vulnerability to organization.
This is why we need vulnerability prioritization as much as we need vulnerability management. Vulnerability prioritization is the process of assessing which of the thousands of vulnerabilities on the enterprise network are the most important, and need to be remediated the most quickly. There are 3 primary approaches to vulnerability management on the market today. The first relies on the CVSS score, a score that addresses the vulnerability’s severity in a vacuum. In the case of the CVSS score, every vulnerability has the same score, independent of the network it’s on, the external threat environment, or other factors. Another vulnerability prioritization technique is called predictive exploitability, which attempts to predict which new vulnerabilities will eventually have exploits developed for them. The core premise behind predictive exploitability is that only vulnerabilities that are likely to be exploited are prioritized. Predictive exploitability is useful in initially segmenting vulnerabilities, but after they’re bucketed into exploitable and non-exploitable, the exploitable bucket is likely to have thousands of vulnerabilities remaining. So, the question is which of the remaining thousands are the highest priority?
The most advanced vulnerability prioritization technique is called Contextual Prioritization. This is where the context of the vulnerability on the network is combined with the external threat environment, the CVSS score, and organization considerations to arrive at an individual risk score for each vulnerability on the network in its own unique context. The risk evaluation is done using AI techniques, and re-calculated every 5 minutes. The number of factors taken into consideration when developing the risk scores is over 35, so the resulting risk score is highly meaningful. Moreover, the result of Contextual Prioritization is a number list from 1 to n of all vulnerabilities on the network, so IT teams know which vulnerabilities on which assets pose the most risk and need to be remediated first, second, third, and so on.
So, when asking the question, “why do we need vulnerability management?”, it’s probably more meaningful to ask “why do we need vulnerability and remediation prioritization?” Without remediation, vulnerability management is simply a long, overwhelming list of vulnerabilities, and the risk remains constant without a strong, intelligent remediation operation.
Vulnerability Scanning Tools
Vulnerability scanning tools have been available for decades, and today, a number are available from both companies (for a fee) and free sources alike. The reason there are so many options for vulnerability scanning tools is that, when viewed from the perspective of the overall vulnerability management process, scanning is the “easy” part. Certainly, there are challenges associated with vulnerability scanning, from potentially disabling or otherwise impacting the operation of the scanned asset, to the ever-present challenge of false-positives (the identification of a vulnerability on an asset that’s not an actual vulnerability). But, generally, scanning assets and finding thousands of vulnerabilities is not the problem. Today’s vulnerability management products are very good at telling their customers what’s wrong, but not very good at telling them how to go about fixing what’s wrong.
Scanning an enterprise network and its assets for vulnerabilities is only step one in the multi-step vulnerability management or vulnerability assessment process, which entails:
- Machine and connected device discovery
- Machine and connected device scanning
- Web application discovery
- Web application security testing
- Vulnerability Prioritization
- Remediation Planning
- Remediation Execution
- Vulnerability Risk Tracking and Reporting
So, although vulnerability scanning tools receive a great deal of attention in the marketplace, the most critical element of a quality vulnerability management program is the one highlighted in the list above: vulnerability prioritization. All vulnerability scanning tools, even when false positives are accounted for, will identify an overwhelming number of vulnerabilities; some estimates put the average at between 10 and 20 per asset. That means IT and infosec teams are provided a list of thousands, hundreds of thousands, or even, on some large enterprise networks, millions of vulnerabilities. Where do they start? Which vulnerabilities are the highest risk to the organization, and which ones can wait to be remediated? The answers to these questions are the ones that facilitate significant risk reduction during vulnerability remediation efforts. Vulnerability scanning tools - even the best and most sophisticated - provide no answers to the important questions in vulnerability management.
So, does it matter what vulnerability scanning tool is selected for a given enterprise vulnerability management operation? Of course. Does it matter much more what vulnerability prioritization tool is selected? Absolutely.
Vulnerability Management vs Penetration Testing
Vulnerability management and penetration testing are closely related, but certainly different. Vulnerability management exists to close the security gaps that penetration testers (professionals that simulate behavior of bad actors to probe weaknesses in network security) exploit. That having been said, a quality vulnerability management program is built on in-depth knowledge of penetration testing, since penetration testing is the closest analog to the behavior of threat actors.
Like any cyber security discipline, the enemy is the bad actor, and all information security activities are designed to thwart the illicit objectives of threat actors, be they individuals, organized crime syndicates, or hostile governments. And as Sun Tzu taught the world so many years ago, when in battle - and we know that information security is a battle between the good guys and the bad guys - know your enemy. Penetration testing enables vulnerability management practitioners to do just that: know the enemy. So it’s not vulnerability management vs. penetration testing, but rather vulnerability management on the same team as penetration testing.
One example is something penetration testers call “outlier asset identification.” Experienced penetration testers (and unfortunately, skilled hackers) know that assets on an enterprise network that are out of the ordinary can often be the best targets for compromise. For example, a Linux server on a subnet of Windows machines could indicate a development environment that might not be patched regularly, or may fall through the security cracks, so to speak. Sometimes servers with unusual names can be an indicator of a primer attack target for penetration testing. These are just two examples; experienced penetration testers can rattle off dozens more. Penetration testers with years of experience are able to identify these outlier assets and separate them out of the thousands of typical assets on an enterprise network. But, that skill is rare, and takes years to develop. That’s unfortunate, as knowing which assets the bad guys are likely to target is like getting a peek into the opposing team’s playbook.
The good news is that machine learning technology is automating this key element of penetration testing for the benefit of vulnerability management. Machine learning techniques can be used to identify outlier assets on enterprise networks, without the need for human intervention, and more importantly, without the need for the precious few experts available with this rare expertise. The identification of outlier assets - a penetration testing technique - helps vulnerability management teams prioritize the highest risk vulnerabilities. It’s only one of many factors to consider, but if a vulnerability resides on an asset that is likely to appeal to a penetration tester - and therefore also appeal to a bad actor - the risk of that vulnerability being exploited to facilitate an attack is higher than if it was housed on an asset that was more typical and likely to attract less attention from hackers.
So, when comparing vulnerability management vs. penetration testing, it’s important to recognize how the concepts in penetration testing can help those building vulnerability management solutions.
Vulnerability Management Metrics
Vulnerability management metrics have evolved substantially in the past few years. There was a time when vulnerability management metrics were composed primarily of a list of vulnerabilities, and perhaps a historical record of the total number of vulnerabilities over time. Those metrics then matured modestly, breaking the total number of vulnerabilities into CVSS score categories, or buckets. Better, but even then, the progress made by IT teams in patching vulnerabilities was difficult to assess, and even more problematic was the challenge of quantifying vulnerability risk reduction or increase.
Today’s vulnerability management metrics leverage multi-tenant cloud technology and significantly more sophisticated vulnerability prioritization techniques to provide a comprehensive risk picture, along with the ability to compare the vulnerability risk profile of your organization to that of peer organizations (anonymously, of course). One important element of insightful vulnerability management metrics is the ability to track the risk-reduction progress of the IT patching team. The vulnerability landscape changes daily, with new vulnerabilities discovered and published constantly, so IT teams could be making great progress patching vulnerabilities, and yet traditional vulnerability management metrics could paint a picture of them running in place. They could patch 10 vulnerabilities, and then run a scan and find that 12 new ones were discovered on the network. This is why it’s important that the vulnerability management solution be able to:
- Scan regularly without manual intervention
- Automatically re-prioritize vulnerabilities quickly and meaningfully
- Provide risk-centric vulnerability management metrics that focus on overall vulnerability risk, not the absolute number of vulnerabilities
The last item in the list is the most critical. A simple count of the total number of vulnerabilities on a network and the variation in that number over time is not only simplistic and unhelpful, but likely misleading. It’s not the total number of vulnerabilities remediated that’s important, but the overall vulnerability risk reduction. If IT teams aren’t spending precious remediation resources on the highest risk vulnerabilities, then the number of patched vulnerabilities may increase, but the overall network vulnerability risk may decrease much less than it otherwise would have with a remediation plan that was optimized for vulnerability risk reduction, not just a reduction in the absolute number of vulnerabilities.
To do this however, a constant vulnerability prioritization calculation must be executed, and unless this is optimized, it’s impossible to achieve. Further, a remediation scenario trade-off capability must be built into the vulnerability management solution to enable IT teams to game different remediation plans, and select the ones that will maximize the overall vulnerability risk reduction while minimizing the remediation resources needed. Again, without automation, such scenario planning is impractical.
Thus, vulnerability management metrics must be as sophisticated and flexible as today’s threat environment is fluid, and that requires advanced technologies that enable automation and constant re-evaluation to handle vulnerability management in an ever-increasing information security environment.
Vulnerability management metrics have undoubtedly evolved as the vulnerability management space has as well. At one time, the VM community was focused on compliance, which often meant the creation of periodic scan reports that would detail the results of the network scans. Often, these scans were conducted monthly or quarterly, depending on the compliance or regulatory requirements that governed the organization’s operations.
Remediation activities were prioritized manually and enterprises did the best they could and remediated as many vulnerabilities as possible. However, compliance requirements had very little to do with risk analysis or risk reduction, and the mere existence of the periodic scanning reports and some rudimentary remediation process were sufficient to satisfy compliance auditors.
After well over a decade of compliance-driven vulnerability management metrics, risk-based vulnerability management is beginning to gain significant traction.
What is Risk-Based Vulnerability Management?
Risk based vulnerability management is an approach that treats each vulnerability according to the risk it poses to the enterprise. The inherent “danger” of a vulnerability in a vacuum is no longer a major factor in its prioritization within a given enterprise. This change in philosophy has materially changed the vulnerability management metrics that forward-looking enterprises use to gauge the efficacy of their vulnerability management operations.
For example, two previously popular metrics are minimally relevant in a risk-based vulnerability management operation: total number of vulnerabilities and the number of critical vulnerabilities as determined by their individual CVSS scores.
These traditional vulnerability management metrics are unhelpful at best, and more importantly, can be highly misleading. For example, an organization with 100,000 vulnerabilities may have only a fraction of that number that pose a genuine risk to the organization, and many of their “CVSS-Critical” vulnerabilities may be, in reality, low risk given their context on the network.
What are the Best Risk-Based Vulnerability Management Metrics?
For an advanced enterprise that practices risk-based vulnerability management, some vulnerability management metric that clearly defines the enterprise’s vulnerability management risk is essential.
At Delve, we’ve developed the “Health Score” to accomplish that objective. The Delve Health Score is based on the number of scanned assets on the network. Each scanned asset that does not house a critical vulnerability is given a score of 1.
Each asset on which a critical vulnerability resides is given a score of -1. So, if the enterprise has 500 assets and a Health Score of 100, that team clearly has some work to do, as the Health Score varies from zero to the total number of scanned assets.
The Health Score (shown in an example in the figure below) can also be normalized so it can be compared to the Health Scores of other enterprises in the cloud (anonymously, of course), allowing organizations to benchmark their performance against other enterprises.
Another critical vulnerability management metric is the total number of assets regularly scanned versus the total number discovered. The organization’s Health Score can be deceiving if not accompanied by this metric. Not all assets on every network are scanned consistently, so the scanning coverage is clearly important to credibility of the Health Score.
Conceivably, an organization motivated to manipulate the data could scan 100 of their cleanest assets and report a score of 90, for example, when in fact they have 1,000 assets total and their Health Score would be significantly less impressive if all 1,000 assets were scanned consistently.
Why is Vulnerability Management Needed to Battle Ransomware?
It’s difficult to find a story about cyber security in the popular press these days without hearing about ransomware. Ransomware is not only a clear threat to organizations the world over, but it’s a popular topic in the press because it’s an element of cybersecurity that’s easy to understand.
Extortion is a crime common in the American landscape since organized crime organizations would “shake down” local businesses for “protection money.” A local bakery owner paid the mob a monthly percentage or the mob couldn’t guarantee that the bakery wouldn’t burn down.
Ransomware is a modern take on that time-worn cash-generating crime. Instead of burning down the business literally, the ransomware perpetrators hold the critical data of the business hostage until the ransom is paid.
The concept has been around for quite some time, but the advent of Bitcoin and other untraceable currencies has made the monetization of successful ransomware attacks much easier, and therefore ransomware attacks much more popular with cyber criminals.
But, all ransomware attacks have to start with network penetration. The bad guys have to find a way onto the network to begin finding the credentials they’ll need to find and access the data they’ll need to encrypt to monetize their attack.
So, how do most ransomware attacks begin?
The short answer to that question is: just like non-ransomware attacks.
Excluding attacks that originate with an insider, or an employee of the enterprise being attacked, the vast majority of breaches originate with either a successful phishing attack or an unpatched vulnerability. To what degree each of those two causes - software vulnerability or phishing attack - is most prominent is difficult to say.
Many companies are hesitant to provide details of successful attacks on their networks for a number of reasons. However, enterprises do seem to be more willing to voluntarily disclose the cause of a breach if they can show its origin was a successful phishing attack.
This makes sense. As an organization, would you be more embarrassed by a careless employee clicking on a phishing email - one that likely fooled many into clicking - or by a breach caused by an unpatched vulnerability that left the organization open to attack?
This begs the question: is the root cause of many ransomware attacks being under-reported? We don’t know for sure, but it’s reasonable to assume that many ransomware attacks originate from software vulnerabilities or web applications. And this is exactly why we need vulnerability management, especially in this environment.
Without vulnerability management, we would not understand our potential risk exposure, nor would an enterprise be able to separate the many thousands of vulnerabilities that might not pose a significant risk to the organization from those that are ripe for exploitation by ransomware and other attackers.
This is why vulnerability management is so important and why vulnerability management is necessary. Sometimes, we fail to connect the dots between a function that can be mundane, time-consuming, and tedious, and the attacks that the process is designed to defend against.
Vulnerability management is more than a compliance requirement. It’s the first line of defense against many of the attacks that we hear about in the news, and it’s absolutely crucial to an effective cyber security program.
If you were interviewing a football coach and asked the candidate what metric they felt was most important to their success, would you hire one that said anything other than wins and losses? Points scored are obviously important. Turnover ratio tends to be an effective predictor. Some coaches like time of possession as a key performance indicator. But ultimately, the only thing that matters is whether the team wins the game. At the end of the day, it’s the only metric that matters.
In building vulnerability management metrics, much like some football analysts, we sometimes overcomplicate things. Vulnerability management reports can number in the hundreds, and dashboards can be so complex as to deter usage. Some of the most popular vulnerability management metrics include:
- Total number of vulnerabilities
- Number of vulnerabilities patched in xyz timeframe
- Number of CVSS critical vulnerabilities
- Mean time to patch vulnerabilities
- Mean time to patch vs SLA or committed patching timeframe
- Average age of vulnerabilities on the network
The vulnerability management software market is estimated to be over one billion dollars annually. And if the personnel costs associated with vulnerability management scanning and remediation are calculated, the total investment in vulnerability management operations globally likely dwarfs the software expenditure. Why spend such vast resources on vulnerability management? There are two answers to this question:
- Organizations have no choice but to invest in vulnerability management for compliances and regulatory purposes, essentially “checking the VM box”
- Genuinely reduce the risk of a cyber security breach
Without question, the vulnerability management motivation of some organizations is still driven by compliance, but as the incidents of ransomware and other attacks increasingly populate headlines in security and even popular press, many organizations are looking for ways to decrease their risk of being the victims of a successful attack. And, as more than half of all successful breaches are the result of an unpatched vulnerability, a spotlight has been shined on their security teams to minimize their vulnerability risk.
Thus, the answer to the question “what is the purpose of vulnerability management,” for an ever-increasing number of organizations is: reduce vulnerability-based breach risk.
Now that we’ve established the purpose of vulnerability management in the contemporary environment (reduce vulnerability-based breach risk), the answer to this question is probably fairly obvious. No conventional vulnerability management metrics measure risk. Do the conventional metrics potentially contribute to risk reduction? Perhaps. But why not establish as an organization’s principal vulnerability management metric: vulnerability risk? The reason is that it can be difficult to define. Risk can be a nebulous concept, and its measurement is never definitive or unambiguous like height, length or weight. Irrespective of that reality, however, and since it’s pretty much the only thing that matters in the world of vulnerability management metrics, it has to be addressed, and addressed thoughtfully.
Measuring vulnerability risk can take many forms, but all effective approaches start with meaningful categorization of individual vulnerabilities. Here, a one-dimensional view will not suffice. For example, whether or not a vulnerability may or may not be exploited is not a panacea. It’s helpful, and useful, but by itself:
1. May lead security and IT teams in the wrong direction or provide a false sense of security, or
2. Will place vulnerabilities in two buckets: exploitable and non-exploitable. Given the large number of vulnerabilities on typical corporate networks, such an approach does not provide the prescriptive remediation direction that IT operations teams crave.
Many factors impact the criticality or risk of an individual vulnerability (Delve’s contextual prioritization engine uses 42 of them), and using just 2 or 3 will yield potentially dangerous results. However, once you’re confident that your individual vulnerability risk/criticality figures are meaningful and trustable, calculating overall enterprise vulnerability risk is reasonable.
In the Delve solution, “Health Score” is effectively a synonym for enterprise vulnerability risk. To calculate the Health Score of the enterprise, Delve first calculates individual vulnerability risk scores using 42 factors and the DelveAI engine, calculations that are repeated for every vulnerability on the network every 5 minutes. Note that since the context of the vulnerability on the network is key to this analysis, the same vulnerability could have a different score in different locations on the network.
After this exhaustive analysis, assets that host vulnerabilities that are scored in the critical range are given a score of -1, while assets that host no vulnerabilities, or non-critical vulnerabilities are given a score of +1. Thus, if a network has 100 assets, it’s best possible Health Score is 100, while its worst possible score is 0. As the Health Score increases, vulnerability-based breach risk decreases, while the opposite is true as well.
Important to recognize here is that the Health Score is based on regularly-scanned assets, and not all organizations scan all assets consistently. So, if an enterprise has 100 assets total, but they’re only scanning 40, they may have a Health Score of 35, which would indicate a relatively low vulnerability-based breach risk. However, when the total asset footprint of their network is considered, the Health Score figure can be highly misleading.
Absolutely. It is the second most important vulnerability management metric because it is so closely related to - and directly impacts - the overall vulnerability risk metric. Just because an asset isn’t scanned regularly doesn’t necessarily mean it can’t be exploited by bad actors, and limiting the Health Score to a subset of all the assets on the network can completely destroy the metric’s credibility. Thus, scan coverage is a critical component of the vulnerability risk score, and must be presented hand-in-hand with it.