Vulnerability Management Blog

Prioritizing Vulnerability Remediation

Given that more than half of all breaches can be traced to, or involve in some way, an unpatched vulnerability, the process of prioritizing vulnerability remediation is key to ultimately reducing the vulnerability risk of an enterprise meaningfully.  In the post below, we answer some of the most common questions about vulnerability remediation.

What is Vulnerability Remediation?


The process of neutralizing the exposure of a software vulnerability to an attack is called vulnerability remediation.  There are a few general vulnerability remediation solutions:

- “Patch” the vulnerability by replacing the older version of the software with a newer version that includes a fix for the vulnerability

- Isolate the asset with the vulnerability or otherwise re-configure network settings to make it difficult or impossible for unauthorized users to access the asset

- Remove the asset from the network or the vulnerable software from the asset

Each of these options can often be either extraordinarily difficult to accomplish, or even flat out impossible, as networks are complex, and taking assets offline to patch and test can mean that critical business systems are unavailable for a period of time.  Thus, the remediation of vulnerabilities can appear, at first glance, to be straightforward, but in practice, presents significant problems for most organizations.


What is remediation in security?


The term remediation in the field of cyber security typically refers to addressing, often by patching, security holes in software that can expose the organization to a successful cyber attack. Remediation can take different forms, for example, network isolation or configuration changes, but remediation in security usually involves replacing the software with the flaw with an updated version in which the flaw has been fixed. Remediation in security is often the responsibility of an IT or infrastructure team, although the information security team is closely involved in the process, and responsible for the initial identification of the vulnerabilities using tools called vulnerability assessment or vulnerability management tools.

Remediation in security can be challenging since it often involves “patching” software with flaws - another way to say “vulnerabilities” - a process that requires installing new software that has fixed the flaw. Although that may sound relatively straightforward, installing new software can incur risk, as the newer version could break existing functionality. Patches need to be tested, and the process of installation and testing can require critical business systems to be brought off-line, a potential challenge to the continuity of business operations. All in all, remediation in security is critical to an effective cyber security program, but it can be expensive and intrusive when done correctly.

What is the importance of vulnerability assessment and risk remediation?


One of the key pillars of enterprise cyber security is vulnerability management. Information security experts estimate that more than half of all successful cyber breaches can be connected to an unpatched vulnerability.  Thus, a major element of risk risk mitigation can be attributed to the identification, and most importantly, the remediation of vulnerabilities. The first step, however, in vulnerability remediation solutions is a vulnerability assessment, or the process of discovering assets on the network and then identifying vulnerabilities on those assets. The challenge for most organizations is to move beyond the vulnerability assessment stage and onto prioritizing vulnerability remediation.  A vulnerability assessment can sometimes be mistaken for a vulnerability management program, but if the assessment and the accompanying reports are not followed up with vulnerability remediation solutions, then there will be no risk reduction benefit from the vulnerability assessment. If risk remediation is the objective, then a vulnerability assessment alone will not provide the results one may expect.

Who is Responsible for Vulnerability Remediation?


Remediation of vulnerabilities is typically handled by the IT or infrastructure team. However, the identification of vulnerabilities on the network is often the purview of the cyber security team, and this separation of responsibilities can result in political conflict given the number of vulnerabilities on the typical enterprise network. The information security team, using network scanning technology that is very good at finding vulnerabilities may identify thousands or even millions of vulnerabilities, a number that is simply impractical for an IT team to remediate in total.  This is why modern vulnerability remediation solutions need to have a reliable, meaningful means of prioritizing vulnerability remediation efforts, for example, Delve Labs’ leading edge Contextual Vulnerability Prioritization. With a robust and intelligent prioritization solution, the IT team is not left holding the bag (full of hundreds of thousands of vulnerabilities), but rather has a vulnerability remediation solution that can guide their remediation efforts, and maximize the efficiency of their remediation resources to maximize the reduction of vulnerability risk across their enterprise.


What is the difference between mitigation and remediation?


In the context of vulnerability management, the difference between mitigation and remediation is subtle, and they’re closely related.  Most organizations attempt to mitigate their vulnerability risk by deploying a vulnerability management program. And the key to any vulnerability management program is the remediation of vulnerabilities. So, in the simplest terms, mitigation requires remediation, and the most effective vulnerability remediation solutions are very good and efficient at prioritizing vulnerability remediation. Prioritization is critical because most enterprise networks have hundreds of thousands of vulnerabilities, and it’s simply not feasible to patch them all.

Note that there are those who may define vulnerability mitigation as the process of addressing a vulnerability without patching it, for example by re-configuring the network or building in policies that isolate the asset with the vulnerability. In this definitional approach, remediation is reserved for traditional patching. However, most practitioners would define remediation as eliminating the risk from the vulnerability, which could take the form of patching or another tactic like isolation or access policy modification.

In the context of vulnerability management, the difference between mitigation and remediation is subtle, and they’re closely related.  Most organizations attempt to mitigate their vulnerability risk by deploying a vulnerability management program. And the key to any vulnerability management program is the remediation of vulnerabilities. So, in the simplest terms, mitigation requires remediation, and the most effective vulnerability remediation solutions are very good and efficient at prioritizing vulnerability remediation. Prioritization is critical because most enterprise networks have hundreds of thousands of vulnerabilities, and it’s simply not feasible to patch them all.

Note that there are those who may define vulnerability mitigation as the process of addressing a vulnerability without patching it, for example by re-configuring the network or building in policies that isolate the asset with the vulnerability. In this definitional approach, remediation is reserved for traditional patching. However, most practitioners would define remediation as eliminating the risk from the vulnerability, which could take the form of patching or another tactic like isolation or access policy modification.

The remediation process in vulnerability management starts with asset discovery and scanning, or the process of identifying the vulnerabilities on the enterprise network.  Scanning technology can use agents and can also be agent-less.  After the network is scanned and, presumably, all vulnerabilities are identified, the list of vulnerabilities can be overwhelmingly large, perhaps tens or even hundreds of thousands. Thus, the next step is the most crucial:  prioritizing vulnerability remediation. Most prioritization methods are outdated, many relying on the flawed CVSS score (which excludes the vulnerability’s context on the network as a factor in its prioritization) or highly manual efforts to determine which vulnerabilities need to be addressed first, and which can be deprioritized. Delve Labs, for example, offers a state-of-the-art, machine learning-based solution called contextual prioritization that accounts for over 40 factors in determining remediation priorities.

Once the remediation priorities are in place, the highest risk vulnerabilities are then remediated, a process that most typically involves installing updated versions of the software with the vulnerability. The process may involve bringing the system housing the software off-line temporarily, and is also likely to include testing after the patch has been applied, as updating software can break existing systems or those they’re connected to.

Typically, vulnerability remediation solutions are integrated with ITSM (information technology service management) systems like ServiceNow, or other task tracking systems like Jira. So, after a patch has been installed and tested, the team responsible can track their progress and record work that has been accomplished.


What are the normal steps to take to remediate a vulnerability system?


Remediating a vulnerability or vulnerability system can be done in multiple ways, but the most common is to apply a software patch, or, in other words, replacing the software with the vulnerability with an updated version of the software in which the vulnerability or flaw has been fixed.  Other vulnerability remediation solutions include isolating the asset with the vulnerability on the network or limiting its access to specific credentialed users. Adjusting network access policies can also be used as a method to remediate a vulnerability system as well.  No matter which technique is used, the remediation of vulnerabilities is key to reducing the overall cyber risk of an organization, and prioritizing vulnerability remediation among the myriad other tasks on the plates of IT and security professionals is where that vulnerability risk reduction starts.


What are the Challenges of Vulnerability Remediation?


Remediation of vulnerabilities is a challenge for two primary reasons that are closely related:

- Most enterprise networks house hundreds of thousands of vulnerabilities, and new ones are released every day.

- Patching vulnerabilities is not only time-consuming and resource-intensive, but is also risky, as installing updated software can break the system on which the software resides, or those it’s connected to

It’s because of these factors that effective vulnerability remediation solutions emphasize meaningful, automated prioritization, maximizing risk reduction for a given amount of patching activity. With robust prioritization, IT or other remediation teams can be confident that the effort and risk associated with patching and the remediation of vulnerabilities will be focused on the highest risk vulnerabilities to the organization, and not squandered patching vulnerabilities that are low priority.

There’s no magic bullet that can eliminate the challenges of vulnerability remediation, but modern remediation prioritization can go a long way toward mitigating the pain of those challenges.


How do you prioritize vulnerability remediation?


The short answer:  in context.  Until recently, IT and security teams relied on the CVVS score to bucket vulnerabilities on their networks into high, medium, and low categories, a method that provided a good first pass at understanding which vulnerabilities needed to be addressed immediately, and which could wait. The CVSS score aided the triage process in vulnerability management that mirrors the same process in a typical hospital emergency room:  all patients (or vulnerabilities) are important, but some are much more important than others. Knowing the difference reliably and meaningfully is the key to prioritizing vulnerability remediation. Currently, the conventional “state-of-the-art”  in vulnerability remediation prioritization is predictive exploitation, or the attempt to predict whether or not a vulnerability will have an exploit published for it at some point in the future. This is a reasonable step beyond CVSS, but it still ignores the vulnerability’s context in the network on which it resides, which has by far the most to do with it’s criticality.  An even more state-of-the-art vulnerability remediation solution is Contextual Prioritization, a technique pioneered by Delve Labs that accounts for over 40 factors when prioritizing vulnerability remediation, only one of which is predictive exploitation.  Contextual prioritization uses machine learning and “the wisdom of the crowd” to calculate the relative priority of each vulnerability on an enterprise network every 5 minutes.  To take a deep dive into the philosophy behind Contextual Prioritization, we recommend one of our latest blog posts written by our lead AI researcher.


Can Vulnerability Remediation be Automated?


Elements of vulnerability remediation can be automated, but it’s unlikely that patching vulnerabilities can ever be completely handed off to even the most advanced automated system.  As discussed above, perhaps the most critical element of vulnerability management - prioritizing vulnerability remediation - is being automated today using machine learning technology to take the human effort out of the remediation prioritization process.  There have been attempts to automate patching, and there are certain systems that can be patched and updated without human intervention, but most vulnerabilities require human-based remediation and the subsequent testing required to validate patches.

Given the reality and risk of updating complex enterprise software and systems, the most effective technologies work to automate all the vulnerability management functions leading up to the actual remediation, including discovery, scanning, prioritization, and remediation planning. Doing so doesn’t completely automate the entire vulnerability management process, but it can remove a great deal of manual effort from VM operations.


What is a vulnerability assessment tool?


A vulnerability assessment tool is typically a tool that discovers assets on an enterprise network and scans those assets for vulnerabilities, often delivering voluminous reports that list hundreds of thousands or even millions of vulnerabilities on large corporate networks. A vulnerability assessment tool may include custom reports that aid in regulatory compliance (for example ISO, NIST, or PCI), and they often include the ability to customize scans and manually identify business-critical assets.

A vulnerability assessment tool differs from a vulnerability management tool in that the latter includes all elements of an assessment tool, but also includes mechanisms for prioritization and intelligent remediation planning.  Delve Labs is one company offering a comprehensive vulnerability management solution, part of which includes a vulnerability assessment element. Typically, an organization driven by compliance adherence and reporting requirements will opt for a vulnerability assessment tool, while an organization working to genuinely reduce its vulnerability-related information security risk will deploy a more action-oriented vulnerability management solution.


What is the difference between vulnerability assessment and vulnerability management?


Often the terms are used interchangeably, but recently, a distinction has been made between tools that provide a vulnerability assessment, and those that provide more analysis on top of the assessment’s results.  This evolution of the lexicon is developing alongside a related development, specifically, the goal of vulnerability management moving, for many organizations, from one of compliance to one of true vulnerability risk reduction.  Indeed, the term “risk-based vulnerability management” was coined recently to reflect the changing philosophy around vulnerability management. Traditionally, vulnerability assessment implies the analysis of a network’s vulnerability posture, with the output of that analysis taking the form of a report used to satisfy auditors or compliance requirements.  Actually fixing vulnerabilities was certainly a goal, but often the reporting was a more important outcome than vulnerability remediation. Part of the challenge in moving from vulnerability assessment to vulnerability management - especially risk-based vulnerability management - is knowing where to start and how to deploy precious remediation resources. With tens of thousands or more vulnerabilities on the typical enterprise network, without a means to intelligently prioritize vulnerabilities, remediation teams are shooting in the dark, making educated guesses about which vulnerabilities pose the most risk to the organization and should therefore be addressed first.  New technologies, however, like Delve’s exclusive Contextual Prioritization are now making risk based vulnerability management feasible by automating the prioritization process and using over 40 factors to prioritize each vulnerability on the network in near real time.
 
Thus, the fundamental difference between vulnerability assessment and vulnerability management is a focus on remediation, and more importantly, real vulnerability risk reduction, versus reporting and compliance.

What are the 3 main types of vulnerability?


The word “vulnerability” in the context of information security refers broadly to a security hole that enables a bad actor to gain access to a system they are unauthorized to access.  There are 3 general types of security holes that a bad will exploit to penetrate system:
 
- Traditional software vulnerability
- Web application run-time flaw
- Misconfiguration
 
When we think about or write about vulnerabilities, we’re typically talking about software vulnerabilities, or flaws in software that are designed into it inadvertently - there are some open source vulnerabilities planted purposely by bad actors, but that’s a discussion for a different blog post. Those flaws are “discovered” by researchers, bug bounty hunters, and, in the worst case scenario, bad actors, and exploits are developed and published for them, often on the dark web.  The typical approach to addressing these vulnerabilities is the release of a patch by the software manufacturer, or an updated version of the software that has eliminated the flaw. Traditional software vulnerabilities are the most common types, but by no means the only ones, or the most dangerous.
 
Web applications can have security holes that can be exploited at run time.  SQL injection and cross-site scripting are classic examples of web application issues that are commonly exploited by cyber criminals, and are detected via different means than a typical software vulnerability scanning product.
 
Misconfiguration vulnerabilities are not a new development, but they’ve become more prominent as enterprises move increasingly to the cloud. There are a number of high-profile data exposures that have resulted from misconfigurations, and a recent survey highlighted the dearth of solutions in this area to automate the identification of misconfigurations.  When asked what they need most to reduce misconfiguration risk, 95% of respondents said tools to identify configuration changes that jeopardize security.


How do you perform a vulnerability scan?


The basic technology needed to perform a vulnerability scan has been available for more than 2 decades.  Essentially, devices with an IP address connected to a network are probed by making requests to ports on those devices.  Based on the responses to those requests, scanning products can identify which devices running which software are presenting vulnerabilities.  Multiple products are available on the market that can accomplish that basic task, but more sophisticated tools add a number of features to that, now-commoditized capability.  These features include: 
 
- Auto and smart scanning when new vulnerabilities are published (which is daily)
- Addressing the challenge of false positives (the identification of a vulnerability where one doesn’t exist)
- Sophisticated reporting
- Automatic handling of blackouts and scan failures
- Tracking the connection between web applications, assets, and network architecture
 
The key to advanced scanning solutions is to recognize that scanning and identifying vulnerabilities is just one element of a comprehensive, true, risk based vulnerability management program. Thus, the scanning element of the process should be designed to set up the next step:  prioritization.  Like a good pitcher that uses one pitch to set up the next, good scanning products are designed to be the foundation of the vulnerability management house that ultimately optimizes remediation, and by doing so, genuinely reduces the risk of a breach as the result of an unpatched vulnerability.

Who is responsible for vulnerability management?

Responsibility for vulnerability management often depends on the size of the organization. In smaller enterprises, those responsible for scanning for vulnerabilities and identifying them are often the same group tasked with remediating identified vulnerabilities.  In larger organizations, information security teams are often tasked with identifying vulnerabilities, while IT and infrastructure teams are responsible for remediation activities.  In the former example, smaller teams are often overwhelmed by the dual role of vulnerability scanning and remediation, particularly when using legacy vulnerability assessment tools that are difficult to operate and maintain.  In the latter example, an acrimonious relationship between the security and IT teams can develop if the handoff from identification of vulnerabilities to the prioritization and remediation of vulnerabilities is not accomplished collaboratively.
 
The key to both the smaller organization scenario as well as the larger enterprise team handoff is vulnerability prioritization.  Smaller organizations have even more limited remediation resources than larger ones, so knowing which vulnerabilities must be addressed immediately and which can wait is critical to a successful risk-based vulnerability management program.  For larger organizations, if the information security team can hand off a list of vulnerabilities in risk-priority order, that would go a long way toward building a solid working relationship with the IT remediation/patching team.  If the security team hands the IT team a list of 100,000 vulnerabilities with a note that says “good luck,” that is likely to engender some ill will.  On the other hand, if the information security team can provide that list of 100,000 vulnerabilities in ranked order of risk and therefore priority, not only will the hand-off be much smoother, and the relationship between teams harmonious, but most importantly, the organization’s vulnerability risk will be minimized since the vulnerabilities that expose the organization to the most risk will be addressed first.  This, in a nutshell, is why intelligently prioritizing vulnerability remediation is so critical to an effective cyber security program.

What is the difference between patch management and vulnerability management?

Patch management and vulnerability management are closely related, but there are subtle differences between them.  Patch management is typically thought of as the process of automatically updating certain systems, often irrespective of the vulnerabilities resident on that system, and most importantly, irrespective of the priority of any vulnerabilities on those systems relative to all other vulnerabilities on the enterprise’s network. Vulnerability management - certainly modern, risk-based vulnerability management - focuses less on routine patch management, and more on the overall reduction in vulnerability risk to the organization.
 
The key difference between traditional patch management and modern, risk-based vulnerability management is the emphasis on vulnerability remediation prioritization.  Most enterprises can count the number of vulnerabilities on their networks in the tens or hundreds of thousands.  Some large organizations can exceed a million vulnerabilities on their networks at any given time.  Knowing which of these countless vulnerabilities represents the most risk to the organization, and which vulnerabilities can wait is the key to risk-based vulnerability management.  Until recently, technology didn’t exist to provide an automated, meaningful risk score for each vulnerability on the typical enterprise network, but that has changed, revolutionizing vulnerability management and giving birth to the risk-based vulnerability management concept. For example, Delve’s exclusive Contextual Vulnerability Prioritization leverages over 40 factors for vulnerability and Delve’s ML engine to risk-rank every vulnerability on the network every 5 minutes.  Thus, organizations have a near-real time view of their vulnerability posture and risk, and more importantly, know exactly which of their vulnerabilities are the highest priority for remediation, and which can be deprioritized.  Moreover, the Contextual Prioritization risk score is unique to every vulnerability on the network, unlike other vulnerability risk ratings like the CVSS score that are constant across all vulnerabilities across all networks, irrespective of context.

What are the normal steps to take to remediate a vulnerability system?

The steps necessary to remediate a vulnerability system vary depending on the vulnerability and the system.  Typically, the vulnerability is “patched” by replacing the existing software with the vulnerability with a newer version of the software in which the vulnerability has been fixed. Although this sounds relatively straightforward on the surface, it can be complex and fraught with risk in practice. First, the system being upgraded with the new software may need to be brought off-line.  Then, the newer version of the software must be installed, and anyone who has installed new software on their computer knows that this process doesn’t always complete cleanly and without issue.  Once the new software is installed, the system must be tested to make sure that the new software hasn’t broken anything on that individual asset, or any system adjacent to or integrated with it.
 
However, not all vulnerabilities need to be remediated by installing new software.  Sometimes, a vulnerability can be addressed by modifying network controls that render the vulnerability much less of a risk to the organization, perhaps by isolating it, for example.  Depending on the system and its criticality to the organization, it may make sense to address a vulnerability more creatively than traditional patching.

Most Recent Related Stories

What is Risk Based Vulnerability Management?

Read More

Risk Based Vulnerability Management Product Update

Read More

Growing a Machine Learning project - Lessons from the field

Read More