What vulnerability prioritization looks like when KEV, EPSS, and CVSS disagree
In this Help Net Security interview, Dr. Joye Purser, Global Field CISO at Cohesity, explains how to rank vulnerabilities when KEV, EPSS, and CVSS point in different directions. Active exploitation comes first, then exploit likelihood, then technical severity, with adjustments for asset exposure, business criticality, and compensating controls.
The interview sets a 24 to 72 hour remediation target for exploited internet-facing systems and covers what an organization gives up to meet it, the hidden failure modes of deception technology, and where a 400-person manufacturer with a $250,000 budget should spend its first $50,000.
If a security leader has KEV, EPSS, and CVSS all pointing different directions on the same vulnerability, what is your tiebreaker rule? Give me the decision logic you would write down for an analyst.
An actively exploited vulnerability, as indicated by KEV, would be the highest priority, particularly if it affects an internet-exposed or business-critical asset. After that, I would assess exploit likelihood using EPSS, followed by CVSS, to understand the potential technical impact.
The decision logic I would give an analyst is: active exploitation first, then exploit likelihood, then technical severity, with adjustments for asset exposure, business criticality, compensating controls, and the potential consequences of compromise. A lower-severity vulnerability in an exposed identity system may pose a more immediate risk than a critical vulnerability in an isolated asset. The scores are useful, but they need to be applied in the context of the environment.
What is a realistic mean time to remediate for internet-exposed assets at a mid-sized enterprise right now, and what does the org have to give up to get there?
For a critical, internet-exposed vulnerability with known exploitation, a target of 24 to 72 hours is reasonable, though many mid-sized organizations will struggle to achieve it consistently.
Getting there requires tradeoffs. Security and IT teams need the authority to interrupt normal release schedules, dedicate engineering resources to emergency testing and deployment, and sometimes accept temporary service disruption or reduced functionality. When an immediate patch is not possible, organizations also need to be prepared to use compensating controls, such as restricting access, disabling a vulnerable feature, or isolating a system.
The biggest requirement is organizational. Actively exploited internet-facing vulnerabilities have to be treated as an operational priority rather than another item in the normal patch queue. Faster remediation requires ownership, pre-approved emergency procedures, and coordination across security, IT, and application teams.
What is the failure mode of deception technology that vendors do not advertise? Have you seen a honeypot become an attacker foothold or a compliance liability?
The primary failure mode is that the deception environment becomes overly connected, overly trusted, or poorly maintained. A honeypot intended to observe attackers can become another foothold if it has access to production systems, reusable credentials, excessive privileges, or vulnerabilities of its own.
Compliance and governance concerns can also arise. Deception systems may capture attacker activity, credentials, production-like data, or other sensitive information. If retention, privacy, legal, and evidentiary requirements are not considered in advance, those systems can create obligations the organization did not anticipate.
Deception technology should therefore be isolated, tightly permissioned, and continuously monitored. Treat it as potentially hostile infrastructure from the outset, and never allow unnecessary trust relationships with production environments.
What is one control that is unglamorous, cheap, and still buys defenders more time than anything trendy?
Phishing-resistant multifactor authentication remains one of the most important controls an organization can deploy. It is not new or glamorous, but preventing stolen credentials from immediately becoming usable access can significantly slow an attacker down.
Basic identity hygiene is equally important. Organizations should remove dormant accounts, restrict privileged access, enforce least privilege, rotate credentials, and apply stronger controls to administrative accounts. Attackers still succeed because credentials are reused, privileges are broader than necessary, or old accounts remain active.
These controls are most effective when used together. MFA, restricted administrative access, segmented privileges, and credential revocation can make common attack paths harder and limit lateral movement after an initial compromise.
If you had to defend a 400-person manufacturer with a $250,000 security budget against machine-speed attacks, where does the first $50,000 go?
Every organization is different, and in manufacturing, the priority has to be protecting operations and human safety. I suggest ensuring critical operational technology is segmented from corporate IT and eliminating unnecessary external access.
The next priority would be identity. Use phishing-resistant MFA for privileged and remote access, remove stale accounts, and tightly control administrative privileges. I would also ensure the organization has protected backups of its most critical systems and has tested that those systems can be recovered.
Some of the budget should also go toward basic visibility and response readiness. The organization needs to know which assets are exposed, who owns them, and who has the authority to isolate systems when something goes wrong.
With a limited budget, the goal is to reduce the number of easy paths an attacker can use, contain the blast radius if an attack succeeds, and ensure that a single compromise does not stop the entire operation.
Download report: How security controls perform in practice
