Security teams can at least offload 50% of their workload by utilizing vulnerability patch prioritization, which can significantly enhance security outcomes for organizations. This has been demonstrated in our recent research on asset-context-aware vulnerability patch prioritization, the methodology and findings of which are available as an open-source project.
“Patch and pray” was the sole remediation approach used by organizations for years: overworked security and infrastructure teams on a thankless job of sorting and remediating thousands of vulnerabilities on a weekly or monthly basis. Penetration testing, red teaming, and attack surface monitoring have gained popularity as a way to identify and fix vulnerabilities before malicious actors can exploit them. Unfortunately, this tactic either fails because of its labor-intensive and expensive nature or leaves organizations with a partial outside-in view. The mere competition is who gets to the open-source intelligence first, attackers or defenders. As a result, organizations often find themselves in a never-ending cycle of patching and praying that all critical vulnerabilities have been addressed.
What keeps a CISO up at night and keeps incident response and security operations teams busy over a long weekend? Have you been there? The number of incidents in the news foretells a story of a losing battle — the attacker only needs to be right once, but defenders must be right all the time.
Current approaches suffer from a variety of shortcomings. Vulnerability prioritization decisions are either made on vulnerability information like the Common Vulnerability Scoring System (CVSS) combined with threat intelligence feeds, or on often statically set asset context like business criticality — an approach that might work for on-premises infrastructure but fails in highly dynamic cloud environments. The nature of the cloud means the asset state and even its criticality can go stale rapidly. An asset that was private an hour ago is now public, without any intimation. Companies often resort to a brute-force approach as the only viable option to manage risk: remediating hundreds and thousands of critical and high vulnerabilities weekly and monthly, and the ensuing struggle of scaling to meet the ever-growing problem.
The size of the problem
Year over year, the trend of vulnerability discovery has been on the rise; last year saw the highest number of new vulnerabilities discovered in a single year. The analysis indicates that 29% of the identified vulnerabilities are classified as either critical or high and require action. Factoring in the thousands of assets in any environment, the challenge of vulnerability remediation is apparent. The size of the problem without an effective prioritization strategy is unmanageable at any scale.
That security teams are overworked and underappreciated can easily be deduced from those numbers. The assumption is that production systems with critical and high vulnerabilities must be remediated within service level agreements. But before we make a case for automated remediation, we have to consider the realities of operations. Production patching requires extensive testing, and automated remediation, however excellent it sounds, is seldom practiced. Perhaps there is a case for better vulnerability prioritization to break the problem into more manageable chunks.
The current approaches to prioritization focus on the vulnerability alone (CVSS score and vector), combine threat data, and combine that with static asset context. In the cloud, these approaches fail to produce a granular and accurate level of prioritization. A risk-based approach where static asset criticality is set independently, with a potentially static visibility state, needs to be revised. For example, a low-business-criticality private asset in a non-production environment with a critical remote-code-execution vulnerability will often be deferred and never revisited. The inherent nature of the cloud means that asset states are highly dynamic: they can change within minutes and without much notification, especially in non-production environments. The compromise of a low-criticality asset may not be significant, but lateral movement from that asset can escalate quickly into something more substantial. Another approach is to focus on production instances. However, a compromise anywhere in the environment is a compromise, and lateral movement from non-production to production is relatively frequent and often the preferred attacker approach.
Stakeholder-Specific Vulnerability Categorization
The Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), in collaboration with the Software Engineering Institute (SEI) of Carnegie Mellon University, has come up with a new vulnerability categorization — Stakeholder-Specific Vulnerability Categorization (SSVC) — which considers exploitation status, impact, and the prevalence of the asset. The reference implementation is a good starting point, but the burdensome scale requires significant work by an experienced analyst. With a shortage of skilled cybersecurity staff and the scaling issues of any real environment, most teams will revert to Thor’s hammer: remediate everything critical and high.
SSVC Ore Miner
SSVC Ore Miner extends the reference implementation of the decision tree and automates it end to end. It uses the following four vectors, and calculates each independently from the information available:
- Exploitation
- Checks for the availability of an exploit and its status using open-source threat intelligence feeds. An exploit can be active, PoC, or none.
- Exposure
- Checks the likelihood of exposure if the exploit is used against the vulnerable asset. Exposure can be unavoidable, probable, or unlikely.
- Utility
- Checks the ease of use of the vulnerability against the asset. Utility considers whether the exploit is active, whether it is network-based or local, whether it requires user interaction, and the discoverability of the asset (public, private, and so on). Utility can be effortless, complex, or laborious.
- Impact
- Takes into account the environment (production or non-production), the asset type (compute, storage, and so on), and asset criticality (critical to the business, storage of sensitive data). Impact can be very high, high, medium, or low.
The adopting organization can extend the implementation to meet its specific needs, or use it as is. SSVC Ore Miner automates remediation prioritization end to end, drawing on asset management, environment classification, cloud configuration management, cloud risk, vulnerability identification, CVSS, and vulnerability threat intelligence in a single automated decision tree. The tool produces a remediation priority in four categories: act now, out-of-cycle, scheduled, and review.
Validating the approach
To validate our findings, we ran three test cases. We took 199 unique vulnerabilities from CISA’s Known Exploited Vulnerabilities (KEV) catalog — a popular method of prioritizing vulnerabilities — with the hypothesis that threat-intelligence-driven patch prioritization can be significantly enhanced with asset context. The same vulnerabilities were used for all three cases, with different asset attributes; everything else remained the same.
- unique vulnerabilities from CISA’s KEV catalog in the test
- 199
- landed in act now without asset context
- 26.63%
- landed in act now with asset context
- 12.06%
| Test case | Act now | Out-of-cycle | Review |
|---|---|---|---|
| Without context | 26.63% | 63.82% | 9.55% |
| Pre-set criticality | 21.11% | 55.78% | 9.55% |
| With asset context | 12.06% | 36.68% | 9.55% |
Between the three cases, the results showed over 50% improvement in patch prioritization from case one to case three: the act-now share fell from 26.63% to 12.06%, with the remainder moving to scheduled work. Asset-context-aware vulnerability patch prioritization can significantly improve the patching process, allowing teams to focus and react more nimbly toward real critical issues. In addition, an open, well-understood decision process allows full transparency of risk decision-making, and lets organizations customize and enhance the tree with additional attributes.
SSVC Ore Miner is open to the public as an open-source project. We want to give back to the community and help every security team achieve better outcomes. We have played the defender role; it is a thankless job — and we thank every security team member who goes above and beyond to keep their environment safe. We also thank CISA and CMU’s Software Engineering Institute for their work on SSVC.
References
- Jonathan M. Spring, Eric Hatleback, Allen D. Householder, Art Manion and Deana Shick, Prioritizing vulnerability response: a stakeholder-specific vulnerability categorization, Workshop on the Economics of Information Security, Brussels, December 2020.
- CISA Known Exploited Vulnerabilities Catalog
- Stakeholder-Specific Vulnerability Categorization (CISA)
- Number of security vulnerabilities by CVSS score (CVE Details)
- SSVC Ore Miner on GitHub