Vulnerability Remediation: Why your security relies on it

What is vulnerability remediation?

To best answer the question of what vulnerability remediation is, let’s start by dissecting the two words that make up the term. According to Oxford Languages, the first definition is:

vul·ner·a·bil·i·ty

/ˌvəln(ə)rəˈbilədē/

noun

• the quality or state of being exposed to the possibility of being attacked or harmed, either physically or emotionally.

Whereas the second term is defined as:

re·me·di·a·tion

/ˌrəmēdēˈāSH(ə)n/

noun

• the action of remedying something, in particular of reversing or stopping environmental damage.

Putting both terms together, the meaning of vulnerability remediation — filtered through the lens of cybersecurity — simply refers to the act of correcting any deficiencies that might otherwise compromise the confidentiality, integrity and/or availability of a computing device.

Why vulnerability remediation is important

Vulnerability remediation is important to limit the impact on computing devices themselves and on the users who rely on them to perform business-related tasks. Equally important is that vulnerability remediation prevents known security threats from exposing sensitive data and user privacy information by identifying and resolving the root cause of a cybersecurity issue.

What’s the difference between remediation and mitigation?

As mentioned in the prior section, remediation identifies and resolves the root cause of a cybersecurity issue or incident. This differs from mitigation, which calls for minimizing the impact of a cybersecurity threat through a control or process.

An example of remediation is patching an application to prevent an attacker from exploiting a buffer overflow vulnerability to gain unauthorized access. An example of mitigation is actively monitoring endpoints that are yet to be patched for signs of exploitation by examining device logs in your SIEM.

Why is timely vulnerability remediation critical?

When speaking of how quickly security vulnerabilities are remediated, many factors, like budgetary concerns and human capital, play a significant role in determining the speed of deployment. Though factors will vary from one organization to the next, what does not change, however, is the best way to address the question of criticality is best summed up by the legal adage: “Time is of the essence.”

The more time a vulnerability remains without remediation, so too does the amount of time threat actors have to exploit it, increasing their chances of successfully performing a data breach.

The Vulnerability Remediation Process

Identification: How vulnerabilities are discovered

Before a vulnerability may be fixed, it must first be discovered. While there are many ways for security teams to identify vulnerabilities, which tools and methods are used can be impacted by different factors, such as budgetary concerns, regulatory requirements governing your industry and whether your organization has a dedicated team with the requisite skill sets to perform discovery themselves vs outsourcing it to a third party.

A few of the common ways discovery is performed are:

• Vulnerability scanners: Software that runs on-device (agent) or cloud-based (agent-less) that scans the endpoints on your corporate network to determine the current health status of each device.
• Penetration testing: Security professionals audit systems and networks to identify problem points while attempting to exploit issues found to verify detected vulnerabilities.
• Code reviews: Similar to pen-testing above, developers review software code on a regular cadence to ensure that changes to code do not produce new vulnerabilities, while regression testing minimizes the risk of reintroducing previous vulnerabilities.

Each of the measures above compares the findings to a list of secure criteria, such as OS and application patch levels, configuration levels that align with security frameworks with compliance requirements and secure code development practices to identify vulnerabilities and verify them, reducing the occurrence of false positives.

Assessment: Evaluating the risk and potential impact

Once vulnerabilities have been identified, the next step involves evaluating the risk they pose to endpoints, users and company data, as well as the potential impact on business continuity. This is often referred to as vulnerability prioritization and it involves categorizing vulnerabilities based on severity, impact and amplification to determine the order in which IT and Security teams should plan their remediation strategy.

An example of how the individual factors affect the overall severity classification level is:

• The type of vulnerability (ex. open source software that allows threat actors to exploit a buffer overflow is a critical threat compared to one that may force an installed app to terminate, classified as a medium threat).
• The potential impact of a vulnerability (ex. curl, which is an open-source binary found in Microsoft, Linux and Apple operating systems will affect each device compared to an in-house app developed by a company that affects only some devices).

Taken into consideration, the higher the severity + the greater the potential for impact of a vulnerability = the greater the severity. Put simply: higher risk/severity means teams should prioritize remediating those vulnerabilities (resolve first) over others that are decidedly less risky, or present a lower impact or amplification level (resolve later), depending on the unique needs of your organization.

Planning: Developing a remediation strategy

Now that you know the type of vulnerability and its impact on your device fleet, you can develop a plan of attack to remediate each vulnerability in a strategic manner, beginning with the highest severity threats and proceeding in descending order until they are all accounted for.

Apart from this best practice, this phase offers admins the greatest flexibility when developing a strategy that works best for their organization. What is meant by that is that admins will work with stakeholders to best allocate available resources when planning remediation plans that best address the needs of the organization.

When developing a plan, there are certain considerations IT/Sec teams should be keenly aware of to keep challenges to their strategy to a minimum:

• Limited resources: This can range from a lack of human capital necessary to carry out the plan effectively to missing skills needed by IT/Sec teams to perform the tasks needed to remediate the issue(s). Furthermore, resources can also refer to budgetary concerns or time-related matters that further complicate hasty remediation plans.
• Environment complexity: Integrations between solutions, supporting multiple OS’s and hybrid workforces are just a few of the factors that impact the success of a remediation strategy. Understanding the full breadth of how software, hardware and interconnected systems work together is table stakes to the plan’s success. Additionally, third-party partnerships and supply chain add another layer of complexity, especially when considering both the availability of patches from the developer and the mean time to respond (MTTR) between when a vulnerability is identified and when it is remediated.
• Regulatory compliance: Regulated industries are governed by laws that stipulate, among other things, requirements for data security. It’s not uncommon for a compliance requirement to add complexity to remediation plans, requiring admins to prioritize certain remediation workflows in order to remain compliant, even if those prioritized hold a lower severity and impact score than others on the list.
• Business continuity: Most of the time, remediating vulnerabilities introduces some form of disruption to business operations. Be it an update to an impacted app to a low-level update that requires a system reboot to complete — remediation workflows need to work within the context of business operations, not counter to it.
• Modern threat landscape: When considering the vulnerabilities that have been identified for remediation, IT/Sec admins must also keep an outward eye on the nature of the modern computing landscape. This means, that while resolving existing vulnerabilities within your enterprise, other threats may be lurking in the wild that could exacerbate vulnerability remediation plans if admins don’t continue monitoring processes as remediation efforts are underway.

Implementation: Applying fixes and patches

With all that prep work completed, the next step is to actually deploy patches to remediate vulnerabilities identified in the first phase. In the previous sections, we already discussed some of the impacts and challenges that could present themselves, acting as blockers when applying fixes. We won’t regurgitate that here, instead, we pivot to provide some best practices and examples of how some admins deploy patches in real-world environments.

Best practices

• Stick to the plan as closely as possible — deviating often introduces variables that lead to delays that may exacerbate issues.
• Deploy patches using a centralized system: whether it’s via MDM, Self Service, scripted or managed through a policy.
• Automate where and whenever possible. The only thing worse than deploying a critical patch to thousands (ormore) devices is thinking you did, only to find out during verification (more on this later) that due to human error, the update didn’t patch the issue.
• Remember to start with the highest criticality level first, then work your way backward down the severity list.
• Always have a backup plan. If a vulnerability can’t be patched or if the installed update breaks existing workflows, causing the fallout to be worse than the vulnerability itself, having a regression plan in place is key to resolving issues that may arise from patching.
• Test patches, deployment and regression plans in a testing environment before deploying to production.
• Document everything: what worked, what didn’t, which (if any) problems arose, how were they resolved. Each detail will serve IT/Sec teams by helping to refine processes iteratively.

Examples

• MDM solutions allow for centralized deployment of app updates. Applications are checked to determine the latest version of installed apps — if the version installed is lower than the currently available version, App Installers will automatically execute a workflow to bring the out-of-date app into compliance.
• Compliance requirements are there to protect user data in regulated industries. These guidelines also help keep data collected by these companies safe when device configurations are aligned with security frameworks to provide a baseline level of protection to devices scoped to the regulation itself.
• Visibility and enforcement go hand-in-hand. Without insight into your device fleet, admins won’t know what’s at risk nor to what degree; but even knowing that much, given the dynamic nature of technology, vulnerabilities are detected every single day. This means that security is an ongoing process — not a one-and-done. This is where policy-based enforcement helps, by ensuring that a baseline of protection is not only set but compliance is maintained.

Verification: Ensuring the remediation was successful

Why verify, you ask? The patches are deployed, and all is right with your IT world…but how do you know for sure?

There’s a compliance saying, “If it isn’t documented, it didn’t happen.” This refers to the mandate that auditors obtain proof that a requirement was fulfilled. And when it comes to vulnerability management, “proof” means verification that the vulnerability was in fact, remediated.

Like the deployment process above, verification depends greatly on the tools, skill sets and resources available to your teams. There’s no “right” way to obtain verification due to the difference from one company to another, but there are certainly easier ways of obtaining and documenting this proof. Some examples of verification are:

• MDM solutions keep records for each managed device. Suppose a report is run Monday morning indicating that 1,000 devices have a vulnerable OS version installed, and after deployment, two days later. In that case, the report is rerun, stating that only 100 devices are still vulnerable, then the report reflects that 90% of the affected devices are verified as having been patched successfully.
• Endpoint security software allows the creation of benchmarks that set requirements for compliance. If a device falls out of compliance, multiple responses can be configured, from alerts that notify admins of affected endpoints that have fallen out of scope to remediation workflows that are executed. Each action triggers a log entry, which can be sorted by SIEM solutions, providing a timeline of events.
• A follow-up penetration test may be performed after the initial one to assess the status of previously identified vulnerabilities. Specifically, the scope of subsequent tests may be limited to only the areas of concern, streamlining the assessment process.

Documentation: Keeping detailed records of the process

A critical part of any change management process, the documentation phase is often the last step in many IT workflows, yet a crucial one. Documenting findings provides administrators with concrete data that directly informs the success of the project. Not only that, it also provides feedback to iteratively inform processes and workflows for future projects as well. Also, documentation is essential for post-mortem debriefing meetings, as the “lessons learned” from a project can help stakeholders address issues to help future projects avoid known pitfalls that affected previous ones, shaping them up to be more efficient while increasing efficacy.

From a compliance perspective, the importance of documentation cannot be understated. Documenting the entire vulnerability remediation process is not only important but also a critical requirement in the audit process. It provides auditors with evidence that compliance is maintained, while regulated industries are provided with proof that they have met the required guidance set forth by governing agencies.

The role of security vulnerability remediation in your cybersecurity strategy

Without a vulnerability remediation strategy, your cybersecurity plan will only be capable of providing unbalanced protection. Malware software alone does not make for a robust cybersecurity strategy. It is a series of controls, processes, workflows, policies and many other factors that go into developing a comprehensive cybersecurity plan. Below are three considerations to bear in mind when deciding on how to best incorporate vulnerability remediation as part of your organization’s cybersecurity plan:

How it fits into the broader security landscape

Security does not occur in a vacuum. Just as there are many different types of security threats and variables that impact cyber resilience, there are multiple components that make up a comprehensive cybersecurity plan.

Vulnerability remediation is just one part of that plan, but it is one that plays a significant role in not only identifying vulnerabilities but also deploying remediation workflows to resolve issues before they can grow into something far worse, like a data breach.

One example of how this fits in with other components that are part of a comprehensive security plan is integrating endpoint security software with mobile device management solutions. Through seamless integration, IT/Sec teams can leverage the active monitoring and reporting capabilities of the former to trigger remediation workflows that enforce compliance through policies configured on the latter. The end result? An automated incident response workflow that:

• Constantly scans device health to identify known vulnerabilities.
• Securely shares telemetry data with MDM.
• Triggers compliance policies that maintain compliance.
• Policy-based management executes workflows to remediate vulnerabilities.
• Endpoint security tooling rescans impacted devices to verify remediation.
• Devices log processes, forwarding them to endpoint security or SIEM for documentation.

Collaboration with other cybersecurity measures (e.g., threat detection, incident response)

Another example of how vulnerability remediation may be used as a collaborative effort between other security solutions is with Zero Trust Network Access (ZTNA).

By default, the zero trust model functions by implicitly denying requests for accessing protected resources until both user credentials and device health are verified to meet baseline security requirements. If both are verified, access is granted; if either fails verification, the request remains denied.

In the event of a failed verification, say for an installed app that poses a vulnerability, ZTNA will hand off the request to MDM, which will deploy the latest version of the affected app to the impacted device. After the app is updated, the request is handed back to your Identity Provider (IdP), where ZTNA attempts to verify the user’s credential and device’s health status again. Not until both are verified will access be explicitly granted for that request.

The impact of effective remediation on organizational security posture

In the case of ZTNA, for each request made, zero trust needs to verify credentials and health status, ensuring that access to protected resources is only granted to authorized users on devices that meet baseline requirements for data security while upholding user privacy.

By design, the principle of “never trust — always verify” is the cornerstone of endpoint security for keeping resources protected from unauthorized users, as well as devices that may be compromised or could otherwise introduce risk to secured resources and systems.

Vulnerability remediation offers a similar benefit to the device and organizational security postures by mitigating risk from known vulnerabilities, preventing threat actors from exploiting bugs in code to compromise devices, harvesting sensitive data, including confidential business data and user privacy information, or opening the door to other attack types, such as lateral movements, privilege escalation or executing remote commands.