Vulnerability Remediation is Broken
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 shall be made available as an open-source project.
‘Patch and pray’ was the sole remediation approach being 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 due to a variety of shortcomings. Vulnerability prioritization decisions are either made on vulnerability information like Common Vulnerability Scoring System (CVSS) combined with Threat Intelligence feeds or 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 criticality can get 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/high vulnerabilities weekly and monthly. The ensuing struggle of scaling to meet the ever-growing problem.
Let’s start by analyzing the magnitude of the problem. Year over year, the trend of vulnerability discovery has been on the rise — The statistic below shows that last year saw the highest number of new vulnerabilities discovered in a year. The vulnerability 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 challenges of vulnerability remediation are apparent. The size of the problem without an effective prioritization strategy is unmanageable at any scale.
The statement that Security Teams are overworked and underappreciated can easily be deduced from the stats above. The assumption is that production with critical and high vulnerabilities must be remediated within Service Level Agreements. But before we go and make a case for automated remediation, we have to consider the realities of Operations. Production patching requires extensive testing, and automated remediation sounds excellent — it is often not practiced. Perhaps there is a case for better Vulnerability Prioritization to break the problem into more manageable chunks.
The current approaches to vulnerability prioritization focus on just vulnerability(CVSS Score and Vector), combing Threat data, and combining this 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. This approach needs to be revised. For example, a low business criticality private asset within a non-production environment with critical RCE 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-business criticality asset may not be significant, but lateral movement from that asset can escalate quickly into something more substantial. Another prioritization approach is to focus on the production instances. However, compromise anywhere in the environment is a compromise, and lateral movement from the non-production environment to the production environment is relatively frequent and often the preferred attacker approach.
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). Considering vulnerability exploitation status, impact, and prevalence of the asset. The implementation was a good reference, but the impractical and burdensome scale requires significant work by an experienced analyst — shortage of skilled Cybersecurity workforce and scaling issues for any size environment, and most will revert to Thor’s hammer — remediate everything Critical and High.
Announcing the release of open-source SSVC Ore Miner. SSVC Ore Miner extends the reference implementation of the decision tree and automates it end to end. Ore Miner uses the following four vectors and calculates each vector independently based on available information.
Exploitation: Checks for the availability of the 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 a vulnerable asset. Exposure can be “unavoidable”, “probable” or “unlikely”
Utility: Checks for utility/ease-of-use of vulnerability against the vulnerability asset. The utility considers whether the exploit is active, whether it is network-based or local, and requires user interaction and discoverability of the vulnerable asset (public, private, etc.). The utility can be “effortless”, “complex”, or “laborious.”
Impact: Impact takes into account the environment(production, non-production), asset type(compute, storage, etc.), and asset criticality(critical to business, storage of sensitive data). Based on these values Impact can be “very high”, “high”, “medium” or “low”
The adopting organization can extend the implementation to meet their specific needs or use it as is if suitable.
SSVC Ore Miner automates vulnerability remediation prioritization end-to-end leverage data from Asset Management, Environment Classification, Cloud Configuration Management, Cloud Risk, Vulnerability Identification, CVSS, and Vulnerability Threat Intelligence into a single end-to-end automated decision tree.
The tool produces Remediation Prioritization in four categories:
To validate our findings, we tested for three test cases. First, we took 199 unique vulnerabilities from Cybersecurity and Infrastructure Security Agency(CISA) Known Exploited Vulnerability Catalog. CISA KEV is a popular method of prioritizing vulnerabilities. The hypothesis was to improve Threat Intelligence-driven patch prioritization and present the case that such prioritization can be significantly enhanced with asset context.
We run the methodology against the following three test cases.
The same vulnerabilities were used for all these tests with different attributes; everything else remained the same. The results showed over 50% improvement in Patch Prioritization from case 1 to case 3.
The stats from each test case are included for reference.
The data shows that 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 patching priority decision process allows for full transparency of risk decision-making. It will enable organizations to further customize and enhance the decision tree by incorporating additional attributes.
SSVC Ore Miner is now 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 — we thank every security team member that goes above and beyond to keep their environment safe.
We want to thank Cybersecurity and Infrastructure Security Agency (CISA) and CMU’s Software Engineering Institute (SEI) for their work on SSVC.
References:
@inproceedings{spring2020ssvc, title={Prioritizing vulnerability response: {A} stakeholder-specific vulnerability categorization}, author={Jonathan M Spring and Eric Hatleback and Allen D. Householder and Art Manion and Deana Shick}, address={Brussels, Belgium}, year={2020}, month = dec, booktitle = {Workshop on the Economics of Information Security} }
Known Exploited Vulnerabilities Catalog
Browse cve vulnerabilities by date
Number Of Security Vulnerabilities By CVSS Scores
Stakeholder-Specific Vulnerability Categorization
https://github.com/rapticore/ssvc_ore_miner