Vulnerability Management Defined
March 3, 2020
There are a number of terms and phrases used in and around the vulnerability management community, and the objective of this post is to explain some of them in plain language.
Vulnerability Risk Assessment
A vulnerability risk assessment is an evaluation of a given enterprise’s vulnerability risk. That is, to what degree are the software vulnerabilities that exist on the network’s machines, connected devices, web applications, and endpoints exposing the organization to the threat of a breach. A vulnerability risk assessment takes into account several factors, including:
- The number of vulnerabilities on the network
- Where those vulnerabilities reside on the network
- The relationship between existing vulnerabilities and web applications
- The number of vulnerabilities on critical business assets
- The severity of each vulnerability, or how serious would the ramifications be if the vulnerability were exploited
- Available remediation resources and patching priorities
It’s common for enterprise networks to have thousands, tens of thousands, or even millions of vulnerabilities, so conducting a vulnerability risk assessment is nearly impossible to accomplish by hand, even if the organization were to do such an assessment only once. But a vulnerability risk assessment is not a one-time, point-in-time analysis; it’s an on-going, essential element of a continuous information security effort. Why? There are several constantly-changing variables in the vulnerability management equation that make a vulnerability risk assessment a continuous operation, including:
- Corporate networks are living/breathing entities and changing constantly, adding and removing assets daily.
- New vulnerabilities are discovered by both threat actors and ethical hackers daily, so today’s ultra-high priority vulnerability may not occupy the top spot a few days later, or even a day later
- The software footprint of the network will change continuously. New software applications are introduced, while others are decommissioned (although much less frequently)
- Many enterprises are frequently acquiring new companies, or restructuring, downsizing, or responding to economic or other crises. These changes have direct ramifications for any vulnerability risk assessment
- Threat actors, be they individual criminals, organized crime syndicates, or state-sponsored efforts, are evolving and growing more sophisticated, so enterprise defenses must evolve quickly as well
Because of these and other fluid dynamics of today’s enterprise network and threat environment, vulnerability risk assessments can’t be static. Thus, the key to a successful vulnerability risk assessment process is automation. Tools are available today that leverage the power of AI and machine learning to automate many of the previously-manual tasks associated with a vulnerability risk assessment, so, for example, vulnerability priorities can be re-calculated almost in real-time, and don’t require specialized security team expertise and hours of manual analysis to establish the best use of precious remediation resources.
In summary, a vulnerability risk assessment is:
- An on-going effort
- Requires the use of automation to be conducted effectively
A vulnerability threat is usually defined as an exploit designed to take advantage of a specific software vulnerability. Certainly, that’s the most simple definition of a vulnerability threat, but it can be misleading. The cyber security world can often be preoccupied with “zero-day vulnerabilities,” or those that are discovered and publicly known about before a patch is available. Without question, zero-day vulnerabilities can be dangerous, as there is a short period of time (usually days) before a patch can be developed and deployed, and therefore systems with the vulnerability are defenseless. It’s important to understand, however, that this vulnerability threat is not the typical source of successful breaches.
Estimates vary depending on the study, but most information security experts agree that between one third and two thirds of all breaches can be traced to, or are connected to, a vulnerability. One recent study - with surveyed about 3,000 IT and security professionals - put the number at 60%. One survey in Europe put the number at 34%, and that survey related those breaches to unpatched (or N-day) vulnerabilities. Other studies and surveys have also concluded that the vast majority of vulnerability-related breaches are the result of N-day, not zero-day, vulnerabilities, suggesting the typical vulnerability threat may not be one that gets the hollywood treatment, but rather old, forgotten vulnerabilities that have gone unpatched for weeks, months, or even years.
That discussion may sound accusatory. Why don’t enterprises “just patch” their vulnerabilities? Pretty simply, right? No really. Patching vulnerabilities is a challenge for several reasons:
- There are usually thousands of them, and patching them all is not practical
- It’s expensive. It’s a resource-intensive effort that takes time
- The work is not stimulating, so it’s not as if IT professionals are walking over each other to secure a patching job
- It’s risky. Patching comprises the installation of new versions of existing software, and, although such upgrades can run smoothly, the process can break existing systems or those connected to them
- Even under the best circumstances with the smoothest patching operation, business critical assets much be temporarily brought off-line to install the patched software
Give these factors, and knowing that patching may be the difference between a successful attack and one that fails, what is the solution? How does an enterprise juggle the risk of existing thousands of vulnerabilities vs the risk and difficulty of patching them? The answer is prioritization.
Not all vulnerabilities are created equally. Some are located on particularly important systems. Some are accessible remotely and therefore vulnerable to attack from anywhere in the world. Some vulnerabilities are easy for bad actors to develop exploits for, and others are more difficult. Thus, when considering a vulnerability threat, it’s important to account for all these and other factors (Delve’s AI engine analyzes over 30 factors before building a prioritized list), or your prioritization won’t be meaningful, and your risk reduction resulting from your remediation efforts will be less than optimized, and your vulnerability threat will not be decreased as much as it could have been for the same remediation effort investment.
There are multiple categories of vulnerability types:
- Zero-day versus N-day vulnerabilities
- Misconfigurations vs native software vulnerabilities
- Software vulnerabilities vs web application vulnerabilities
Of the vulnerability types, the one of most importance is the difference between a zero-day and an N-day vulnerability. A zero-day vulnerability is one for which a patch is not yet available, so bad actors have a brief window to exploit the vulnerability between the time of it’s discovery and the release of its patch.
That timeframe is typically days, and on its face, these zero-day vulnerabilities are exceptionally dangerous, as companies with a zero-day vulnerability are defenseless against attack until a patch is made available by the software manufacturer. But zero-days are one of the vulnerability types that many in the cyber security community rightly consider to be overrated.
Although there is clear danger in a zero-day vulnerability, the vast majority of breaches tied to vulnerabilities are the result of n-day vulnerabilities, or those that have been identified, and for which patches exist. Why would an n-day vulnerability be the cause of more breaches when, by definition, patches exist for these vulnerabilities? The answer is that n-day vulnerability types persist because patching is resource and time-consuming, and enterprises have difficulty keeping up with patching - also called remediation - efforts.
Another set of vulnerability types are misconfigurations versus native software vulnerabilities. A useful analogy here is a plane crash or aviation accident. The Federal Aviation Administration (FAA) investigates aviation accidents and publishes an accident cause, either human error or mechanical failure.
Human error in an aviation incident is analogous to a misconfiguration vulnerability type. Typically, a member of the IT team sets up software and inadvertently provides access to those who shouldn’t have it via a setting. Misconfigurations have been known, for example, to make publicly-available sensitive personal information.
Another example could be an employee copying a sensitive file to what they assumed was a private folder that was, in fact, a shared folder accessible to all employees (and maybe even external entities). The other vulnerability type in this category is a vulnerability built into software.
Again, inadvertently, software is shipped with a flaw that makes it accessible via obscure commands or a sequence of actions. Once discovered by researchers, white hat hackers, pen testers, or other entities, the manufacturer is notified and a patch is developed and released.
The third of the vulnerability types is a web application vulnerability. This is where a web application - one that connects direction to the internet - is susceptible to common web application attack vectors like cross-site scripting or SQL injection.
The vulnerability type in this case is less subtle since many attack vectors for web applications are well-established. Web application security testing is therefore a key element of a comprehensive vulnerability management program.
A typical enterprise network will have many of each of these vulnerability types, with the combined total of all the vulnerability types on one network amounting to thousands, hundreds of thousands, or even millions. Prioritizing remediation efforts with that total of vulnerabilities is impossible when done manually, so automating the discovery, scanning, prioritization and remediation efforts is essential to an effective vulnerability management program.
Cyber Security Vulnerability Scan
A cyber security vulnerability scan is the process of probing the assets on a given network for potential flaws that could enable an attack by a bad actor. Assets, as used in this context include:
- Connected devices (for example, printers)
- IT appliances
- Web applications
In short, anything with an IP address should be part of a cyber security vulnerability scan. There are many products on the market - some even open source and free - for cyber security vulnerability scanning, but today’s machine learning and other automation technology is improving vulnerability scanning in select products.
For example, machine learning can auto-learn the best times to scan certain assets based on user behavior so as to minimize disruptions. Machine learning technology can also be used to optimize scanning of individual assets to avoid overloads and bring the asset down.
Automated products can now auto-trigger scans of appropriate assets when new vulnerabilities are discovered, without the need for manual intervention and potentially risky delay. So, advanced cyber security vulnerability scanning products provide a degree of automation and intelligence that legacy or free scanners don’t.
But, irrespective of the scanner you choose, a cyber security vulnerability scan is only a piece of the vulnerability management puzzle. Scanners and many vulnerability management products are very good at identifying thousands, hundreds of thousands, or even millions of vulnerabilities on the typical enterprise network, but stop there.
This leaves security and operations teams with an overwhelmingly long list of items to patch, and very little, if any, guidance on where to start or how to prioritize the list. This is why vulnerability prioritization is the key to a successful vulnerability management program. Deciding which of the thousands of vulnerabilities on your enterprise network presents the most risk to your organization is the most important element of vulnerability management.
Deciding which one is second is the second-most important element of vulnerability management, and so forth. Emergency room healthcare professionals conduct this type of triage every day, and when there are 5 or 10 patients in the emergency room at one time, prioritizing patients manually is feasible. However, when the number of “patients” is a thousand, two thousand, or a hundred thousand, prioritizing manually is simply not a practical option. Automation is non-negotiable.
Currently, there are 3 primary types of prioritization after a cyber security vulnerability scan has been completed. The first is using the CVSS score, which ranks the severity of a given vulnerability from 1 to 10 based on the vulnerability’s characteristics and potential risk to the security of networks.
The next, and relative new prioritization method, is predictive exploitability. Predictive exploitability attempts to predict whether a new vulnerability will be exploited based, again, on the new vulnerability’s characteristics. The newest, and most technically sophisticated method is called contextual prioritization.
Contextual prioritization uses AI technology to process three dozen factors about not only the vulnerability, but the vulnerability’s unique environment on the enterprise network. Contextual prioritization uses the CVSS score as a starting point, also includes predictive exploitability as just one of its three dozen factors in ranking each vulnerability from 1 to n. To learn more about the three methods of vulnerability prioritization, download our white paper, Prioritizing Network Vulnerabilities: A Survey and Comparison of Today's Options.
Vulnerability Scanning Best Practices
Vulnerability scanning is a critical element of any enterprise security program, and vulnerability scanning is the second step in the vulnerability management process. (The first is asset discovery, although discovery and scanning are closely related.) There are a few vulnerability scanning best practices that any organization should consider for their program.
First and foremost, vulnerability scanning is not an isolated or point-in-time activity. Vulnerability scanning must be an on-going activity, as there are so many changing variables in a vulnerability risk reduction program. The threat landscape is constantly evolving as threat actors find new and more effective means of compromising enterprise networks.
Enterprise networks, themselves, are changing entities, as assets and users come and go on a weekly or even daily basis in some cases. Thus, one of the most important vulnerability scanning best practices is to scan the network frequently. Some organizations scan monthly or quarterly, generate a report, and then consider that activity to have constituted a sufficient vulnerability management effort. That’s clearly not the case.
Another vulnerability scanning best practice is to be aware of the best times to scan assets. At its core, vulnerability scanning is the process of making requests or queries to ports on network-connected machines (e.g. servers, laptops) and analyzing the responses.
Making these requests or queries, if done too aggressively or at times when the asset is handling a high volume of legitimate requests, it could bring the asset down. Knowing when to scan assets to minimize the chance of over-stressing the asset is another one of the vulnerability scanning best practices that can facilitate a successful vulnerability management program.
The challenge, however, is that, given the complexity of today’s enterprise networks - the number and different kinds of assets - it’s impossible to optimize scan times manually, so advanced tools are needed to be able to apply this vulnerability scanning best practice.
Free or legacy scanning tools are not sufficient to accomplish this objective. AI-based solutions like those being delivered by Delve are leveraging machine learning to constantly improve scanning scheduling based on the continuous collection and analysis of data. Using an advanced scanning tool that takes advantage of modern technology, in and of itself, is a vulnerability scanning best practice.
But perhaps one of the most important vulnerability scanning best practices has little to do with scanning. No matter how effective or best-practice-driven your scanning effort, it’s bound to produce an overwhelming list of vulnerabilities.
If that list is thousands, hundreds of thousands, or millions of vulnerabilities long, where does the operations team start? Which vulnerability presents the highest risk to the organization and must be remediated first? Which is second? Triaging a long list of vulnerabilities is called vulnerability prioritization, and unless a robust tool or system is in place to prioritize vulnerabilities (which is really the same as prioritizing remediation efforts), scanning is useless.
Like a hospital emergency room where nurses decide which of the 10 or 15 patients waiting for care is the highest priority (the highest risk), vulnerability prioritization must do the same. The challenge? With 10 or 15 patients in line, triaging manually is perfectly acceptable.
But if there were ten thousand patients in the emergency room, so some type of automation would be non-negotiable. The same is the case for vulnerability prioritization. Thus a list of vulnerability scanning best practices should include:
- A plan to frequently scan the network
- An automated means of optimizing scan schedules to avoid disruptions
- An automated means of determining which assets are most critical to business operation and require more frequent scanning
- Scanning/testing not only physical assets, but web applications as well
- A robust means of meaningfully prioritizing the list of vulnerabilities generated by scans
Vulnerability Risk Reduction Management Unit
A vulnerability risk reduction management unit is used to measure:
- The overall vulnerability risk on an individual enterprise network
- The risk reduction progress made by the company’s security and IT operations teams from their vulnerability management efforts
There are a number of metrics that can be applied to assess the vulnerability risk management effort, and specifically, the vulnerability risk reduction management unit. These include:
- The total number of unpatched vulnerabilities
- The total number of new unpatched vulnerabilities (since the last scan was completed)
- The total number of patched vulnerabilities
- The total number of critical vulnerabilities
- The total number of non-critical vulnerabilities
- The total number of assets scanned versus the total number of assets on the network
These are some of the common metrics used today as a common vulnerability risk reduction management unit. Delve, on the other hand, has developed a vulnerability risk rating for enterprises that accounts for the relative health of individual assets on the network.
Aptly named, the “Health Score,” it provides the best overall view of any vulnerability risk reduction management unit.
The Delve Health Score looks at each asset individually, and determines 1) if that asset has any vulnerabilities, and 2) if any of the vulnerabilities on that asset are critical. (Note that Delve uses its exclusive contextual prioritization to score the severity of every vulnerability on the network, so the Health Score depends on that meaningful score to be calculated.) If the asset has at least one critical vulnerability, it receives a score of (-1). If the asset does not have a critical vulnerability, its score is (+1).
The overall Health Score of the network is then calculated by summing the scores of all the assets on the network. The best possible score would be the total number of scanned assets, while the worst possible score would be zero.
Also included in this vulnerability risk reduction management unit is a presentation of the total number of assets scanned versus the total number of assets on the network, which is a combination of the output of discovery and scanning.
This is an indication of the coverage surface of the enterprise’s scanning surface, and also provides additional insight into the vulnerability risk profile of the network. Similar to the CoronaVirus crisis, lack of testing can yield a false sense of security since the organization doesn’t know how exposed they really are until all or most assets are regularly scanned.
Finally, the Delve Health Score dashboard includes a comparison of your organization’s vulnerability Health Score to other organizations in Delve’s customer cloud (anonymously, of course), enabling security and IT teams to benchmark their vulnerability risk against other organizations.
So, the appropriate vulnerability risk reduction management unit used to assess vulnerability management risk is up to the individual organization, but using one that comprehensively and honestly displays the true risk of vulnerability exposures to the organization is critical to understanding exactly where your enterprise stands.