The Future of Threat and Vulnerability Management
Threat management and vulnerability management are two crucial components of an effective cybersecurity program. While vulnerability management typically focuses on keeping software and operating systems up to date, threat management usually involves reacting to potential security breaches and implementing lessons learned afterward. Both threat and vulnerability management aid in the overall reduction of your organization’s attack surface. Threat management revolves around the reactive work of security tools, SOC analysts, and security engineers who provide protection from bad actors attempting to conduct unauthorized activity within your network. Vulnerability management is more focused on ensuring that bad actors have minimal attack surface from which to attempt their attacks.
Traditionally, threat and vulnerability management have been separate areas of activity, each with its own limitations and challenges. However, newer, more holistic approaches to threat and vulnerability management are enabling organizations to continue to improve overall security posture while reducing the effort required to do so.
In this article, we look at some of the challenges faced by current threat and vulnerability management programs as well as some best practices to implement that will help improve your organization’s security posture.
Summary of threat and vulnerability management challenges
As mentioned earlier, while both threat and vulnerability management programs help toward improving the organization's security posture, the two can function in distinct realms. When we think of threat management, we often think of security operations center (SOC) analysts responding to security information and event management (SIEM) alerts or unified threat management (UTM) alerts. Threat management is often seen as both proactive and reactive since it frequently relies on receiving alerts and further fine-tuning alert parameters for the future. In contrast, it is typical to associate vulnerability management with software updates.
Another way threat and vulnerability management differ is in their operational structure. Threat management is typically a 24x7 job consisting of incident response (IR) teams either working rotating shifts or available on-call should the need arise. Vulnerability management tends to function on a more periodic basis, though patching vulnerable software and system configurations can also involve defined timelines set by your organization that are typically dictated by the severity of each vulnerability. Many organizations are transitioning to a more proactive approach by utilizing the Continuous Threat Exposure Management model, which further reduces the time a risk exists within your environment by way of continuous scanning.
One challenge that many organizations face is prioritizing which vulnerabilities to remediate first, based on their assessed risk to the environment. There are a few methodologies commonly used to aid in determining technical security risk, likelihood of exploit, and business impact, including the Common Vulnerability Scoring System (CVSS), the Stakeholder-Specific Vulnerability Categorization (SSVC) system, and the Exploit Prediction Scoring System (EPSS).
The CVSS assigns a numeric score between 1 and 10 to rate the severity of a vulnerability, with 10 being the most severe. The SSVC system provides a recommended action based on the severity of the vulnerability, such as “track” or “act.” The EPSS calculates the likelihood a vulnerability will be exploited.
To use any of these systems effectively, your team needs to have detailed knowledge of the environment. Understanding how your systems interact with each other and how they might interact with the public Internet helps determine whether the remediation of some vulnerabilities should be prioritized over others.
Alert fatigue, deduplication, and alert suppression
Whether you decide that CVSS, SSVC, EPSS, or some other vulnerability scoring system fits your organization best, you will need to manage the quality, fidelity, and volume of alerts that your tools will inevitably generate. Without fine-tuning your alert parameters and deduplicating vulnerability data, your team is sure to feel the impacts of alert fatigue.
One way to reduce alert fatigue is by filtering out any known false positives or alerts that involve vulnerabilities for which your organization has already accepted risk. For example, if your organization has alerts for an outdated software package that you know will be replaced as part of a larger project four months from now, it may be worth suppressing alerts related to that program to help keep your team focused on newer vulnerabilities for which there may not yet be a remediation plan.
Reducing duplicate alerts and false positives is an ongoing effort that should be prioritized not only for the sake of your SOC analysts and engineers but also for your overall security posture. Receiving singular true-positive alerts allows your team to spend more time focusing on likely security issues and less time sifting through duplicate and/or false alerts. Applying lessons learned from previous alerts and security incidents will also help your organization further refine the criteria your tools will alert on. Addressing all of these challenges will help manage your organization’s attack surface.
In addition to helping organizations better understand their environments, vulnerability scoring systems such as CVSS and SSVC are designed to help prioritize remediation efforts. While CVSS helps provide a numeric value to represent a vulnerability’s severity, the SSVC model recommends a relative level of urgency for action based on the vulnerability’s impact on specific assets within your organization. The MITRE ATT&CK framework can assist with threat alert response by providing insight such as what indicators to look for and likely attack paths.
Maintaining accurate asset inventory and understanding system functions and associated applications
Maintaining an accurate inventory of your assets can guide with prioritization. This inventory should include the following at a minimum:
- Whether the asset is on-prem or cloud-based
- Whether the asset is a physical device or a virtual machine
- Whether it is managed internally or by a third-party vendor
- Which business function is responsible for the asset(s)
- Which application(s) are the assets associated with
For example, suppose your organization is currently using a vulnerable, outdated version of an application. You cannot upgrade the software due to incompatibility with your organization’s also outdated operating system (OS). Your organization will likely determine that it is more important to focus on upgrading the operating system first, rather than implementing a compensating control for the vulnerable software or switching to a different application altogether. By accepting the risk of one vulnerability in the short term, your organization can address the outdated operating system and mitigate several potential vulnerabilities that eventually come with the technical debt of utilizing an outdated OS.
Maintaining an accurate inventory of your organization’s assets also helps your teams handle the sheer volume of vulnerabilities that may exist. Many organizations use multiple tools to provide insight into their vulnerable software, system configurations, and network configurations, but even with all that data filtering through one tool, it can be difficult to know where to begin.
Having an accurate inventory allows for the proper grouping and tagging of assets by mission criticality and linked applications, which provides tremendous value. This allows your team to filter through loads of data to first address vulnerabilities within specific asset groups, such as your organization’s public-facing assets or domain controllers.
Streamlining your organization’s processes helps not only reduce alert fatigue but also keep your organization more secure overall. By standardizing your organization’s processes for assessing and communicating security risks, you reduce operational friction and decrease your window of exposure.
To further optimize your organization’s threat and vulnerability management processes and improve response times, your organization can integrate security tools with ticketing systems and project management tools.
A common result of such integration is the automatic creation and assignment of tickets; your analysts and engineers will be sent detailed information about what the issue is, what’s already been done, and what actions to take to be able to either successfully close out the ticket or escalate the issue. Similarly, a standardized vulnerability remediation process will reduce the amount of time a vulnerability spends in your environment and better manage your attack surface.
Understanding risk level and overall risk tolerance
Another challenge that almost all organizations face is balancing security best practices with business needs. In an ideal world, every security flaw would be remediated as soon as it is discovered, and cost would be no object, but that’s never the reality.
Your organization’s risk tolerance will be a factor in decision-making, so it is important to establish exactly what types of risks your organization can accept, for what length of time, and what compensating controls may need to be implemented for that duration.
Let’s refer back to our earlier example of the software vulnerability that can’t be updated with the current OS due to incompatibility. The organization has a few choices:
- Prioritize an OS upgrade followed by a software patch to remediate the vulnerability.
- Remove the vulnerable software altogether, if possible.
- Accept the risk associated with the vulnerability while planning and completing an OS upgrade, with compensating controls implemented in the meantime.
Some organizations may have the ability to prioritize that OS upgrade over everything else; this will likely take some time and money, but it’s the ideal solution from a security perspective.
Other organizations may even be able to remove the vulnerable software entirely—perhaps the vulnerability is associated with an unused browser not needed on the affected systems.
However, the most likely choice is the last one, temporarily accepting the risk while planning for an OS upgrade. This decision has minimal impact on current projects, business functions, and budget while still addressing the risk by providing some form of compensating controls.
Knowing when to split responsibility for vulnerability management and threat management
The final aspect of threat and vulnerability management we will discuss is the separation of duties and assignment of responsibilities. As your organization and employee count grow, it may be beneficial to have separate roles managing vulnerabilities and another role focused on incident response activities, rather than having one role manage everything. By splitting these responsibilities, you allow the members of your team to define operational workflows and improve efficiency.
Threat and vulnerability management best practices
Understanding some of the challenges that organizations face with their threat and vulnerability management programs is a good start, but knowing how to begin addressing them is its own challenge. Here are some best practices to help get you started.
Consolidate data from multiple sources
One of the first steps your organization can take to bolster its threat and vulnerability management capabilities is to consolidate data from multiple sources. Feeding multiple data sources into a single platform reduces the likelihood that your team will miss alerts and can aid in alert overall deduplication.
Your organization should also prioritize remediation based on what they know about the environment. This goes back to our earlier discussion of maintaining an accurate inventory and understanding how your assets interact with each other and with the public Internet. Prioritizing your response and remediation efforts appropriately based on your environment’s architecture will greatly aid in protecting your organization.
Prioritize based on contextual information
Prioritizing your response efforts based on the level of risk an alert or vulnerability poses specifically to the impacted assets in your environment is crucial to effective threat and vulnerability management. Your team should know your environment and how all the moving pieces work together, which means they should be able to respond to security alerts with the knowledge of which assets are the next logical steps for adversarial movements if the alert is a true positive.
Additionally, the security and IT teams should have an understanding of which vulnerabilities can be remediated, and when. For example, they should be aware of any downstream software dependencies relying on specific software versions, and should be able to advise whether a change risks breaking other components of the environment.
Foster collaboration across teams to remediate
Your security team can only do so much on their own, so one way your organization can improve its threat and vulnerability management capabilities is through fostering collaboration across all involved teams. All the prioritization in the world will not materially impact security posture or risk reduction if the asset owners do not take the time to implement the remediation, whether that’s updating software, changing permissions, or something else.
Integrating security tools and ticketing systems with project management platforms can help provide a smooth workflow and make collaboration easier.
Evaluate multiple options for remediation, including compensating controls and risk acceptance
Another way your organization can improve how it handles threat and vulnerability management is by accepting some risk in the short term by implementing a compensating control, which reduces your organization’s overall risk while still accounting for business needs.
Balancing security best practices with business functionality is an important step in progressively improving your organization’s security posture.
It’s always better to make small improvements rather than not doing anything at all. Security should work with other teams to determine compensating controls to minimize risk when a vulnerability or configuration cannot be remediated in a timely manner.
Show proof of value
Perhaps one of the most important ways to continuously improve your threat and vulnerability management capabilities is to provide leadership with some form of easily understood proof of value. Some examples of metrics visualize improvement include a reduction in the time that new vulnerabilities exist within your environment prior to remediation (mean time to repair), or a reduction in findings from assessments and penetration tests. Having executive leadership’s support will help guarantee that efforts to improve your organization’s threat and vulnerability management capabilities will be supported in the future.
While threat and vulnerability management are often thought of as two separate components of an effective cybersecurity program, a more holistic approach focuses on interweaving them together. Threat and vulnerability management both face numerous technical, procedural, and organizational challenges that can and must be overcome by organizations of all sizes and compositions.
Threat and vulnerability data should be deduplicated and consolidated from multiple sources into one or two platforms, then processed by an automated ticketing system or project management platform from which your teams can work. Detailed asset information and risk assessment needs to be available prior to your organization prioritizing any action. A categorized inventory will also help your teams prioritize remediation based on mission criticality, while compensating controls should be considered in lieu of remediation when full remediation is not immediately available.
Addressing these challenges can be made easier by working through these recommendations in increments and will help transform your organization’s threat and vulnerability management capabilities and your security posture as a whole.