When it Comes to Managing Risk, Context is King

When it Comes to Managing Risk, Context is King

Speakers: Lucas Maidar, Tenable

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=Hwyv9WHVyjg

Overview

In the rapidly evolving landscape of cybersecurity, organizations face an overwhelming deluge of vulnerabilities, making traditional vulnerability management (VM) strategies increasingly untenable. Lucas Maidar, a veteran in vulnerability management from Tenable's research organization, presented a compelling case at VulnCon for a paradigm shift: moving beyond compliance-driven, CVSS-centric approaches to a context-is-king methodology. His talk, "When it Comes to Managing Risk, Context is King," highlighted the critical need for security teams to prioritize remediation efforts based on actual threat intelligence and environmental factors, rather than solely on severity scores.

Maidar's presentation underscored the futility of attempting to patch every high-severity vulnerability, a task he likened to "pushing a rock up a never-ending hill." He argued that this approach leads to analyst burnout, a lack of demonstrable risk reduction, and an inability to adapt to emerging threats. By dissecting the limitations of widely adopted scoring systems like CVSS and even the newer Exploit Prediction Scoring System (EPSS), Maidar advocated for a data-driven strategy that leverages actionable threat intelligence to focus on the vulnerabilities that truly pose an immediate and exploitable risk to an organization. This shift promises not only more effective security posture but also a more efficient and sustainable vulnerability management program.

Background

▶ Watch: Speaker introduction and vulnerability management challenges (0:00)

Lucas Maidar's insights stem from over 16 years in vulnerability management at Tenable, where his primary focus is developing plugins for vulnerability scanning. This experience has given him a unique perspective, observing both the challenges faced by customers and the internal struggles within Tenable's research organization to keep pace with the sheer volume of newly disclosed vulnerabilities. He highlighted that the fundamental challenge for almost all organizations is the same: "too many vulnerabilities, not knowing what to cover, how to cover the right ones, getting the coverage out."

The scale of the problem is staggering. The CVE (Common Vulnerabilities and Exposures) program has published over 285,000 CVEs to date. While this averages out to around 11,000 per year over 26-27 years, the rate has accelerated dramatically. Maidar noted a significant jump in 2017 due to program maturation and process improvements, with the annual count quickly rising. He stated that in 2024, the industry is "right around 40,000" CVEs published, a number no organization can realistically keep up with.

Many organizations, Maidar observed, practice compliance-based vulnerability management. This often involves adhering to internal rules or external policies, frequently prioritizing vulnerabilities based on CVSS (Common Vulnerability Scoring System) scores, specifically focusing on "high" and "critical" severities. This approach, however, proves ineffective because the rate at which new high- and critical-severity vulnerabilities are published often cancels out any remediation efforts. "You go, you fix a bunch of things, you get all your patches applied, and you wake up the next morning and there's a whole another set," Maidar explained. Even with apparent progress, proving a reduction in actual risk remains elusive.

Maidar critically analyzed the pervasive reliance on CVSS. While acknowledging its appeal—being an industry standard, easy to work with numerically, and satisfying some compliance requirements (like PCI for in-scope systems requiring remediation of scores 4.0 or higher within three months)—he firmly stated that CVSS was "never intended to measure risk." Its purpose is to quantify severity, not likelihood of exploitation. The CVSS specification instructs analysts to "assume the worst-case scenario." This leads to many vulnerabilities, such as memory corruptions or buffer overflows, being rated as remote code execution (RCE) despite a low probability of successful exploitation in real-world scenarios, simply because it's theoretically possible. Consequently, over 50% of all CVEs published historically, and 48% in 2024, are rated as high or critical severity. Maidar cited research indicating that most organizations have an average of 500 high- and critical-severity vulnerabilities across their infrastructure at any given time, a number far too high for consistent remediation.

He briefly touched upon the underutilized CVSS Temporal and Environmental Metrics. While these components can adjust a vulnerability's score downwards based on exploit availability (Temporal) or specific organizational context (Environmental), Maidar argued they often don't go far enough in reflecting true risk, and environmental metrics can inadvertently mask lateral movement risks once an attacker gains initial access. The core problem remains: CVSS, by design, focuses on the potential impact rather than the probability of exploitation.

Key Findings

▶ Watch: Exponential growth of CVEs makes patching impossible (2:50)

Maidar's talk presented several critical findings that challenge conventional vulnerability management wisdom and underpin his call for a context-driven approach:

1. Exploitation is the True Risk Indicator: A vulnerability that is never exploited is merely a "potential risk." Developing reliable exploits, even with modern tooling and AI, remains challenging. Many vulnerabilities, despite high CVSS scores, never see active exploitation in the wild.
2. Scarcity of Actively Exploited Vulnerabilities: Despite the massive volume of CVEs, a surprisingly small percentage are actively exploited. Maidar highlighted that only 13% of 2024 CVEs had published Proof of Concept (PoC) code, which he considers the "first phase of introducing risk." More strikingly, less than 1% of the 38,000-40,000 CVEs published in 2024 have known active exploitation. Even accounting for unreported exploitation, this number remains "tiny" and "very manageable" compared to the total volume.
3. Targeting the "Left Half" of Attackers: A significant portion of cyberattacks, particularly those by ransomware-as-a-service groups and less sophisticated adversaries, rely on readily available and reused exploit code. By aggressively remediating vulnerabilities with known exploits, organizations can effectively "cut off the left half" of attackers, preventing opportunistic compromises that often make headlines.
4. EPSS: A Promising but Flawed Tool: The Exploit Prediction Scoring System (EPSS), a vendor-neutral standard predicting the likelihood of exploitation in the next 28 days, offers a path toward risk-based prioritization. EPSS can drastically narrow the focus, with only 3% of all CVEs having an EPSS score of 0.3 or higher, and a mere 2,554 CVEs scoring 0.9 or higher. This promises manageable numbers and demonstrable progress.
5. EPSS Limitations and the Need for Context: Despite its promise, Maidar revealed significant issues with EPSS's current performance. He found that:

• 80% of CVEs with an EPSS score greater than 0.9 have no known exploitation.
• 25% of CVEs with an EPSS score greater than 0.9 have no known PoC.
• Conversely, **50% of known exploited CVEs have an EPSS score of less than 0.1.**
• 72,000 CVEs with public PoC code have an EPSS score of less than 0.2.

These statistics indicate that EPSS, as a machine learning black box, can misprioritize, leading organizations to chase non-critical vulnerabilities while potentially missing genuinely dangerous ones hiding in lower score ranges. This underscores the core finding: numbers alone, even predictive ones, are insufficient without rich, real-world context.

Technical Deep Dive

▶ Watch: Why compliance-based VM is an 'endless hill' (3:55)

The technical core of Maidar's argument lies in a critical dissection of vulnerability scoring systems, particularly CVSS and EPSS, and how their design and implementation choices impact real-world risk management.

CVSS: Severity vs. Risk and the Worst-Case Assumption

Maidar reiterated that CVSS, despite its widespread adoption, is fundamentally a severity metric and not a risk metric. Its core limitation stems from the specification's directive to "assume the worst-case scenario." This leads to inflated scores that do not reflect the actual likelihood of exploitation. For instance, a memory corruption or buffer overflow that might typically result in a denial of service (DoS) could be rated as Remote Code Execution (RCE) if, in a theoretical worst-case, RCE could be achieved. This drives many vulnerabilities to "high" or "critical" status, creating an unmanageable remediation backlog.

While most organizations rely solely on the CVSS Base Score, Maidar pointed out the existence of Temporal and Environmental Metrics designed to add context.

• Temporal Metrics adjust the score based on the current state of exploit availability. For example, a base score of 9.8 might drop to 9.3 if a proof-of-concept (PoC) exploit is available, or to 9.0 if the exploit is "unproven." Maidar argued that these adjustments are often insufficient, as the score does not drop "enough when you bring in that threat metric" if no known exploit exists.
• Environmental Metrics are meant to be tailored to an organization's specific context. This allows for adjustments based on factors like a system's exposure (e.g., not internet-facing), its importance, or the sensitivity of data it handles. Maidar provided an example where a CVSS 9.8 RCE vulnerability, when factoring in environmental metrics like "network adjacent attack vector" (instead of network) and "asset not important/no sensitive data," could be reduced significantly, potentially down to a 6.0 (medium severity).

However, Maidar cautioned against over-reliance on environmental metrics. Assuming a system is safe because it's not internet-exposed ignores the reality of lateral movement once an attacker breaches the perimeter. Similarly, deeming an asset "unimportant" simply because it lacks sensitive data overlooks its potential as a pivot point within the network. These metrics, if applied without a holistic understanding of an organization's attack surface and internal network dynamics, can "mask some of that risk."

EPSS: The Black Box of Predictive Scoring

The Exploit Prediction Scoring System (EPSS) represents an attempt to move beyond static severity to dynamic exploit likelihood. Designed to provide a probability (0-1) of a vulnerability being exploited in the next 28 days, EPSS aims to help organizations prioritize. Maidar showed that using EPSS thresholds could drastically reduce the number of vulnerabilities requiring immediate attention. For instance, focusing on CVEs with an EPSS score of 0.3 or higher reduces the target set to only 3% of all CVEs, or just 2,554 CVEs if focusing on 0.9 or higher.

The fundamental technical challenge with EPSS, as Maidar highlighted, is its nature as a machine learning (ML) algorithm operating as a "black box." Unlike CVSS, where the algorithm and its components are transparent, EPSS takes "bunch of data goes in, number comes out." This opacity means organizations must "trust that that black box is giving you the right numbers" without full visibility into its internal logic or features.

Maidar's analysis revealed significant discrepancies between EPSS scores and real-world exploitation:

• High EPSS, Low Exploitation: 80% of CVEs with EPSS > 0.9 (indicating high predicted risk) had no known exploitation. Furthermore, 25% of these high-scoring CVEs lacked even a public PoC. This suggests the EPSS model might be over-predicting exploitation for vulnerabilities that, in practice, are not being actively leveraged.
• Low EPSS, High Exploitation: Conversely, Maidar found that 50% of known exploited CVEs had an EPSS score of less than 0.1. This is a critical failure, as it means many genuinely dangerous vulnerabilities are being classified as low-priority by EPSS, requiring security teams to "sift through 150, 200,000 CVEs to find the right ones." Similarly, 72,000 CVEs with public PoC code (a strong indicator of potential future exploitation) scored less than 0.2 EPSS.

These findings technically demonstrate that while EPSS offers a valuable direction, its current implementation can lead to misprioritization. The lack of transparency in the ML model, coupled with these observed inaccuracies, underscores Maidar's core message: "numbers alone can't help." Contextual data points, especially real-world threat intelligence on exploitation, are indispensable for validating and augmenting any purely numeric scoring system.

Demo / Proof of Concept

▶ Watch: CVSS assumes worst-case, inflating vulnerability severity (6:00)

While the talk did not feature a live technical demonstration or a software proof of concept, Lucas Maidar effectively used three real-world vulnerability scenarios to illustrate the critical role of context in risk assessment and response. These examples served as powerful case studies, demonstrating how Tenable's research organization applies contextual analysis to avoid overreacting to perceived threats and to prioritize genuine risks.

1. CUPS Vulnerability (CVE-2023-45648 and related CVEs):

• Initial Perception: The headlines screamed "unauthenticated RCE on all new Linux systems," causing immediate internal panic and the expectation of a "ruined weekend" for the remediation team. The broad scope (all Linux systems) and unauthenticated RCE capability suggested a catastrophic threat.
• Contextual Analysis: Deeper investigation revealed crucial nuances:
• Scope: While initially appearing broad, the vulnerability was in a component (CUPS) that should not be exposed to the internet and was often not configured vulnerably by default in major distributions like Red Hat. Only about 70,000 internet-exposed instances were identified.
• Ease of Exploitation: The initial exploit was trivial, but achieving successful RCE required chaining three or four CVEs and tricking a user into installing a malicious printer. This significantly increased the complexity of a real-world attack.
• Remediation: The primary remediation involved simple configuration changes or disabling the service, making it relatively easy to mitigate.
• Threat Intelligence: There was a descriptive proof of concept but no easily weaponizable code, and crucially, "no known exploitation in the wild."
• Outcome: Based on this context, Tenable managed the response calmly. They published a blog post and plugins but avoided a "huge response that we're going to drag everyone to," preventing unnecessary panic and resource drain.

1. Ivanti Secure Connect Vulnerability (CVE-2023-46805, CVE-2024-21887, CVE-2024-21888, etc.):

• Initial Perception: This was immediately flagged as a severe threat.
• Contextual Analysis: The context painted a clear picture of high risk:
• Zero-day Exploitation: Evidence of "zero-day exploitation in the wild" was identified even pre-disclosure. This is the ultimate indicator of immediate danger.
• Impact: Remote Code Execution (RCE) paired with an authentication bypass. This meant attackers could gain unauthenticated RCE.
• Scope: The vulnerability affected a "popular VPN access tool" (Ivanti Secure Connect), which is "internet-facing by design." Edge products like VPNs are inherently high-risk targets.
• Ease of Attack: The attack was "fairly trivial."
• Lateral Movement: VPNs are "trusted services," meaning a compromise provides a trusted pivot point into the internal network.
• Proof of Concept: Available "pretty quickly."
• Outcome: This was an "easy one for us" to declare as critical. Tenable immediately mobilized resources for broad coverage and urged rapid remediation, acknowledging the immediate and severe threat.

1. Apache Parquet (CVE-2024-????, CVSS 10.0):

• Initial Perception: Headlines like "max severity RCE flaw discovered in widely Apache Parquet severe threat big data environment CVSS 10.0" caused alarm.
• Contextual Analysis: Again, context mitigated the panic:
• CVSS: A perfect 10.0, indicating maximum severity.
• Exploitation Preconditions: A successful attack required "tricking [a] user into reading in the malicious parquet files" or having them "exposed." It required loading an untrusted, malicious parquet file, which is an unusual operational scenario.
• Threat Intelligence: Crucially, there was "no proof of concept available," "no evidence... of exploitation," and "no more proof of concepts posted" even after several days.
• Outcome: Despite the frightening CVSS score, the practical path to exploitation was complex and unlikely. Tenable advised a planned remediation rather than an immediate, panic-driven shutdown. Maidar's internal advice was: "Yes, I know this sounds bad, but we don't need to go reload all our services that are using Apache Parquet. Let's come up with a plan to patch because we don't want to ignore it, but I'm not going to make you all stop what you're doing, pull down time, and do that."

These examples vividly demonstrated that a high CVSS score or alarming headlines alone are insufficient for effective risk assessment. Real-world context—including exploit availability, attack complexity, affected assets, and observed exploitation—is essential for making informed decisions and building trust within an organization.

Defensive Implications

▶ Watch: Over 50% of CVEs are high/critical severity (6:50)

The core message for defenders is to fundamentally shift their vulnerability management strategy from a compliance-driven, volume-based approach to a contextual, risk-based methodology. This involves building a defensible, measurable, risk-reducing VM strategy that prioritizes based on actual threat intelligence rather than just severity scores.

Here are the key defensive implications:

1. Prioritize Known Exploited Vulnerabilities (KEVs) Aggressively:

• Focus on vulnerabilities that are actively being exploited in the wild. Maidar specifically highlighted CISA's Known Exploited Vulnerabilities (KEV) Catalog, which contains around 1,300-1,500 CVEs. Remediating these provides a clear, defensible explanation of risk reduction.
• Target ransomware-associated vulnerabilities (Maidar noted around 381 CVEs). Removing these specific vectors significantly reduces ransomware risk.
• Address persistently exploited vulnerabilities – older CVEs that attackers continue to leverage due to their reliability or widespread presence.
• Prioritize recently exploited vulnerabilities (around 26 CVEs at the time of the talk) that show current high activity from attackers.
• Implement rapid remediation SLAs (e.g., 7 days) for KEVs. Attackers often exploit these within days, so speed is critical.

1. Contextualize Assets and Their Exposure:

• Externally Facing Assets: Aggressively patch vulnerabilities on network devices, VPNs, and firewalls that have management interfaces exposed to the internet. These are prime targets for opportunistic attacks.
• Internal, Remotely Exploitable Assets: Recognize that once attackers breach the perimeter (e.g., via phishing), internal systems become the next target for lateral movement. Prioritize vulnerabilities that facilitate internal compromise.
• Data Sensitivity and Business Impact: Identify assets that hold sensitive data or are critical to business operations.
• Beyond C-Suite: While C-suite devices carry reputational risk, Maidar suggested focusing more on "senior staff software engineers who have access to every single resource" as higher-value targets for attackers seeking deeper access.

1. Develop a Strategic VM Program with Clear SLAs:

• Compliance Baseline: Maintain SLAs for all high and critical vulnerabilities (e.g., PCI requirements), as this is a non-negotiable baseline for many organizations.
• Planned Responses: Anticipate and plan for known events like Patch Tuesday (Microsoft) and Oracle Critical Patch Updates (CPUs). Allocate resources in advance.
• Automate Low-Risk Patching: Implement automated patching for low-risk software (e.g., web browsers) where updates are frequent and unlikely to cause major disruptions.
• Playbook for Emerging Risks: Create a structured playbook for responding to "emerging risk vulnerabilities" – the high-profile, panic-inducing events that hit the news cycle. This playbook should emphasize rapid contextual analysis to avoid overreactions or underreactions.

1. Build Trust and Avoid Burnout:

• Defensible Explanations: Be able to clearly articulate why specific vulnerabilities are being prioritized for rapid remediation. This builds trust with operations teams and leadership.
• Avoid "Troll" and "Ostrich" Responses: Do not fall into the trap of panicking over every headline ("troll") or ignoring all emerging threats ("ostrich"). A balanced, data-driven approach preserves credibility. Over-reacting to non-critical issues leads to "destroying trust" when truly critical events demand immediate action.
• Measure Risk Reduction: Focus on metrics that demonstrate a reduction in risk (e.g., number of KEVs remediated) rather than just the volume of patches applied.

By integrating these defensive implications, organizations can move toward a more intelligent, efficient, and ultimately more secure vulnerability management posture, ensuring that resources are directed where they matter most.

Key Takeaways

• Overwhelming Volume Demands Prioritization: The sheer volume of new CVEs (40,000+ in 2024) makes it impossible to remediate everything. Prioritization based on actual risk is no longer optional, but essential.
• CVSS Measures Severity, Not Risk: Relying solely on CVSS scores for prioritization is ineffective. CVSS describes potential impact (severity) under worst-case assumptions, not the likelihood of exploitation.
• Context is King for True Risk Assessment: Effective vulnerability management requires rich contextual data, including exploit availability (PoC, weaponized), active exploitation in the wild, attack complexity, and environmental factors like asset exposure and data sensitivity.
• EPSS Needs Contextual Validation: While EPSS is a promising step towards predictive scoring, its "black box" nature and observed inaccuracies (missing exploited CVEs, over-prioritizing non-exploited ones) mean its scores must be validated with real-world threat intelligence.
• Focus on Known Exploited Vulnerabilities (KEVs): Prioritize vulnerabilities listed in sources like CISA's KEV Catalog, those associated with ransomware, and persistently or recently exploited CVEs. This provides a manageable, defensible, and measurable path to risk reduction.
• Build a Defensible, Measurable VM Strategy: Implement a strategy that balances compliance requirements with threat intelligence, allowing for aggressive SLAs on KEVs, planned responses for recurring events, and a structured approach to emerging threats. This fosters trust and prevents analyst burnout.

About the Speaker(s)

Lucas Maidar is a seasoned expert in vulnerability management with over 16 years of experience at Tenable. He works within Tenable's research organization, where his primary focus is on writing plugins for scanning and identifying vulnerabilities. Throughout his career, Maidar has been instrumental in shaping Tenable's tactical response to emerging vulnerabilities and risks, as well as developing long-term content strategies to ensure comprehensive and accurate coverage. He has also played a key role in developing Tenable's internal vulnerability database, which provides the critical context needed to make informed decisions about prioritizing and covering important vulnerabilities. His extensive experience provides a deep understanding of the challenges organizations face in managing the ever-growing landscape of cybersecurity threats.