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
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 Assessment Example
The challenge providing or discussing a vulnerability assessment example is that, by its very nature, the phrase “vulnerability assessment example” implies it’s a point-in-time activity. The very phrase sends the wrong message about vulnerability management best practices and the most effective ways to minimize vulnerability risk.
In short, vulnerability assessments should be an on-going, never-ending part of daily (or at least weekly) information security activities. Patching should be a constant activity, and network scans and vulnerability prioritization and re-prioritization should be continuous, and should reflect the changing and evolving nature of any enterprise network. A typical vulnerability assessment example would include:
- Discovery of machines and other connected devices (those with an IP address) on the network
- Discovery of web applications, as they are particularly appealing targets for threat actors, and, by definition, can be accessed remotely
- Scanning of machines and other connected devices for vulnerabilities
- Dynamic (i.e. while the application is running) security testing of web applications
- Prioritization of all identified vulnerabilities from one to n
- Remediation scenario planning
- Remediation plan establishment
- Remediation execution
- Enterprise vulnerability risk reporting
As you can see, there are almost 10 steps in this vulnerability assessment example, and, as mentioned previously, the vulnerability assessment process should be continuous. Looking at this list and then digesting the reality that this multi-step process is never-ending is likely to be overwhelming to those unfamiliar with vulnerability assessments. And it should be. What’s not obvious from this discussion so far is that much of this effort can be automated with modern AI-based vulnerability management tools.
Leveraging AI-based automation, ongoing vulnerability assessments are practical, and IT teams can respond to rapidly evolving challenges. Indeed, there are a number of moving parts in any vulnerability assessment example. The number of new vulnerabilities expands daily. Every enterprise network changes, as assets are added (new employees, for example), and removed constantly. New software is installed frequently, and existing software - applications that can number in the thousands - are constantly updated with new versions, and sometimes decommissioned. All these and other factors impact a vulnerability assessment, so tracking them and executing around them would be impossible without intelligent automation.
So, to summarize, there really is no such thing (or there shouldn’t be) as a “vulnerability assessment example”. Vulnerability assessment process? Sure. But whatever we call it, the name has to reflect the reality that it’s never just a point in time.