Creating a Vulnerability Management Program – Vulnerability Remediation: More Complex than You Might Imagine

In prior blogs, we’ve spelled out how an organization finds its vulnerabilities and how security teams consider threat intelligence to determine overall risk. Once the danger is understood, the next step, of course, is to contain it. In a word – vulnerability remediation.

For individuals or organizations just starting to understand cybersecurity’s requirements, this might seem like a simple situation: Once you’ve identified a significant risk, you just block it as soon as possible. End of story.

If only it were that simple.

Sure, for a very small organization with few assets to protect, remediation isn’t terribly complex. The person in charge of cybersecurity might send an email to a colleague in IT and explain what needs to be done. As an organization grows, however, so do the complexities. That calls for a careful, well-considered vulnerability remediation process.

The Basics of a Remediation Process

To recap, Vulnerability Management has these major phases:

• Discover
• Prioritize
• Remediate
• Simulate
• Measure and Analyze

Once you’ve discovered your vulnerabilities through scanning and pentesting, you’ll have a baseline of your current risk — and you’ll likely find yourself overwhelmed with the number of vulnerabilities on your remediation list. Prioritization across teams then becomes your biggest hurdle.

See how:

Let’s start with upping the size of the organization from one that has few assets to protect to one that has hundreds of assets. Let’s further assume that the IT department has grown to a few individuals. Now you need to start deciding who’s responsible for each group of assets or network segments.

Now let’s multiply the number of alerts the security team fields daily from a half dozen to hundreds. The security team doesn’t want to take the blame for failing to respond to incoming warnings, so it sends more and more emails to the various IT members. Eventually, the IT team complains that it has plenty of other work to do and it will get to the alerts when it has time.

Then, one day, a breach occurs. It is contained before too much damage is done, but now the top executives are upset. The C-suite and the board now expect any and all vulnerabilities to be addressed immediately. They’re willing to buy new tools to help — but the security team feels overwhelmed by the complex features most vendor solutions provide. Besides, even if the security team is able to use the tool to stay on top of vulnerabilities, relations with the IT team have deteriorated to the point that no one trusts the other side to do what’s needed.

Once Again: People, Process, and Technology

If we rewind the scenario described above and remind ourselves of the role of people and process in implementing technology, we can see what went wrong. The various people involved didn’t reach an agreement on what their responsibilities were. They hadn’t thought through the process to anticipate problems or how to tackle a potential overload of alerts. Consequently, the available technology wasn’t of much help. The damage had been done.

As a starting point, the security and IT teams would need to sit down and reach an understanding. Given the huge increase in cyber threats over the years, it’s unrealistic to try to respond to every identified vulnerability. So the security team needs to determine how to prioritize vulnerabilities and give the IT team a clear idea of what needs to be done immediately and what can wait. The IT team in turn needs to assign roles within its ranks for different asset types, vulnerabilities, etc.

Additionally, you need to be sure that you’re not getting distracted by celebrity vulnerabilities or vulnerabilities with high CVSS scores that don’t actually impact your organization. Prioritizing based on CVSS alone just won’t cut it — you need to prioritize within the context of your own environments. From there, you can reevaluate what is actually high risk and what is relatively low risk based on likelihood of exploitation, compensating controls, and other mitigating factors.

Often your Security and IT Ops teams will codify expectations in a service-level agreement (SLA), much like vendors agree to SLAs to their clients. As a given organization learns more and more about responding to vulnerabilities, it can establish different expected response times based on the level of the threat. Vulnerabilities that pose the most significant risk get the quickest response time, while those of low risk can take longer to remediate. 

One note: be sure that the C-suite understands the idea of prioritization and signs off on at least the broad parameters of the SLAs, if not the nitty-gritty. This will prevent a lot of finger-pointing later and give both the security and IT teams some reassurance that they’re not being asked to do the impossible.

Managing Remediation SLA Exceptions

In addition to bandwidth restrictions when it comes to vulnerability remediation, not every vulnerability will have an available patch or fix. When remediation isn’t possible within standard SLA timeframes, the Vulnerability Management team should choose to either accept the risk, find another way to mitigate against it (ex, Data at Rest Encryption, port disabling, etc) or introduce a compensating control (ex, turning on Malicious Traffic Blocking Policy on the EDR agent.). 

Exceptions should be documented, reviewed and approved and should always include an expiration date after which they can be re-reviewed and extended or allowed to expire after which the affected vulnerabilities will be subject to the standard SLA

Technology’s Role in Vulnerability Remediation

As your organization grows and remediation efforts become more complex, you’ll find that emails or manual methods quickly become inadequate. Not only are they too slow, but they also allow for more communication errors than is permissible. Instead, you’ll want to use an IT Service Management (ITSM) platform to channel requests for remediation into tickets. That helps quickly establish the nature of the issue, the asset involved, the team members assigned to repair the problem, and the time at which the assignment was complete. This, too, is useful in getting a strategic view of how well each element of the remediation process is performing.

Before long, you’ll need to employ automated remediation to address the issues, for several reasons:

1. The sheer volume can become too much to expect team members to address. 
2. Many vulnerabilities can be exploited so quickly by cybercriminals that there’s no time to wait for a human response. Remediation may have to occur in a matter of a minute or less to contain an invader once it’s detected.

Additionally, it’s essential that the security team knows how effective its controls are in keeping the organization safe. Are the controls performing as expected, or are they missing some threats while overreacting to others?

Finally, all the tools that are used in the remediation process need to be well-integrated. There’s no time for individuals to try to port information from one system to another. The tools must work effectively and efficiently to keep the organization protected.

NopSec’s Tools for Remediation

NopSec’s Unified VRM provides the overarching framework for effective cybersecurity management, starting with providing institutions a view of their assets – including IoT, unmanaged assets and internet-facing devices. It then analyzes the assets’ attributes and checks for vulnerabilities or behavior that is differentiated from a normal baseline.

Unified VRM also prioritizes risks and vulnerabilities and provides alerts based on prioritization analytics, then provides automated action plans on the mitigation of prioritized threats with embedded native detection and response capabilities.

Beyond Unified VRM, NopSec also offers modules specific to the remediation process:

• Collaborator: This tool  automatically creates remediation tickets with assigned SLAs and team ownership in your ITSM platform for seamless hand-offs from security to IT operations.

• InControl: Integrated with EDR/policy management platforms, this module validates the existence and effectiveness of compensating controls for a true picture of vulnerability risk.

• Defender: Use Defender to prioritize, track, and push automated remediation actions to your EDR, policy management, or orchestration platform to resolve threats caused by misconfigurations.

At NopSec, we know how much there is to think about when you’re trying to lead your security team from the initial stages of protection to the more advanced levels. See how other leading cybersecurity teams are succeeding by reading the 2022 State of Vulnerability Management Report.

FAQ

Question #1: What is vulnerability remediation?

Answer: Remediation is the third phase of Vulnerability Management and is the process or tasks through which you deploy patches or change configurations in order to eliminate vulnerabilities.

Question #2: What is the difference between remediation and mitigation?

Answer: Remediation resolves a vulnerability, ensuring that it no longer has the potential to be exploited. Mitigation occurs when remediation is not immediately available. Mitigation is the limitation of impact of a vulnerability. 

Question #3: What is the difference between mitigation and compensating controls?

Answer: For instances where remediations are not available or not possible, mitigations are generally aimed at minimizing the impact of an exploit while compensating controls are aimed at reducing the likelihood of a successful exploit. Examples of mitigations include Data at Rest Encryption or deployment of a Data Loss Protection agent that limit the damage should the unremediated vulnerability get exploited. Examples of compensating controls are Air Gapping the asset so it is difficult for an attacker to reach, or turning on an M/L based malicious traffic blocking policy on the asset’s EDR agent.

If you haven’t read the previous installments of this series you can do so here:

• Why You Need a Vulnerability Management Program – Starting Now
• What is Vulnerability Management and the VM Lifecycle Stages?
• Creating a Vulnerability Management Program – The People, Process, and Technology
• Creating a Vulnerability Management Program – Discovering Your Vulnerabilities: The First Foray
• Creating a Vulnerability Management Program – Patching: Take the Panic out of Patching by Managing CVE Threat Overload
• Creating a Vulnerability Management Program – Vulnerability Scanners: How They Help Cybersecurity Readiness
• Creating a Vulnerability Management Program – Penetration Testing: Valuable and Complicated
• Creating a Vulnerability Management Program – Cybersecurity Risk: Why You Need Both Vulnerability and Threat Assessments