In late October, the United States Cybersecurity & Infrastructure Security Agency (CISA) added a new threat to its Known Exploited Vulnerability (KEV) Catalog. Cyber criminals used remote code execution vulnerability in Microsoft SharePoint to gain access to organizations’ networks. The CISA press release states that “these types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.”
However, Microsoft identified and released a patch for this vulnerability in July 2024. Cybersecurity experts are concerned about the lag between identification by the vendor and the addition to the vulnerability catalog. The question remains whether actual exploitation of the vulnerability could have been reduced with earlier inclusion in the catalog.
What is the KEV Catalog?
CISA launched the KEV Catalog in 2021 to inform the cybersecurity community and network defenders about vulnerabilities that threat actors have already exploited. The goal of the KEV Catalog is to help organizations better manage vulnerabilities and more effectively prioritize vulnerability management.
Once a vulnerability is added to the KEV Catalog, Federal Civilian Executive Branch (FCEB) agencies, which include federal civilian executive branch departments and agencies, must remediate the vulnerability, such as by updating SharePoint with the patch Microsoft released for the most recent entry. However, statutorily defined “national security systems” or certain systems operated by the Department of Defense or the intelligence community are excluded from the requirement. Although not mandated by law, CISA strongly recommends that other organizations also use the catalog to stay up to date on current threats.
Agencies are required to remediate vulnerabilities within a specific time frame included in the KEV Catalog entry. CISA determines the time frame for each vulnerability based on its threat to the federal enterprise. Most vulnerabilities must be remediated within two weeks of issuance, but the time frame can be as short as a few days in cases of grave risk.
CISA recommends that organizations and agencies use automated vulnerability management tools that automatically incorporate and flag or prioritize KEVs. By using automated tools, organizations no longer must manually monitor the KEV, which saves time and reduces the risk of missing a critical vulnerability.
What are the criteria for adding a vulnerability?
When deciding whether to include the vulnerability in the KEV Catalog, CISA uses three specific criteria. If not all three are met, then the vulnerability is not added to the KEV Catalog:
1. The vulnerability has an assigned Common Vulnerabilities and Exposures (CVE) ID.
Once a potential cybersecurity vulnerability is discovered, the nonprofit federally funded research and development center (FFRDC) that runs the CVE program begins the CVE process. The first step is a CVE Numbering Authority (CNA) — which can be a software vendor, open-source project, coordination center, bug bounty service provider or research group — assigns the vulnerability a CVE ID, which is a unique common identifier for a publicly known cybersecurity vulnerability. Next, the CNA posts the vulnerability on the CVE website and assigns to the CVE the status of reserved, which is the initial state. After the CVE is reviewed, then it is assigned either published or rejected.
2. There is reliable evidence that the vulnerability has been actively exploited in the wild.
A common misconception about the KEV Catalog is that inclusion is based on the exploitability of the vulnerability, meaning how easy it is for a cyber criminal to use it to launch an attack or a breach. However, the only criterion for inclusion is actually if the vulnerability has already been exploited or is under active exploitation, which is when malicious code was executed without the system owner’s permission. Three key events — scanning, security research of an exploit and proof of concept (PoC) —do not qualify as an exploitation. If a threat actor attempts exploitation by trying to execute code on a target system, but the code does not execute due to the system not being vulnerable or because it’s a honeypot, the vulnerability still counts as an exploitation because the intent was to exploit.
3. There is a clear remediation action for the vulnerability, such as a vendor-provided update.
CISA requires FCEB — and strongly encourages all organizations — to apply updates per the vendor instructions. If the product is at its end of life or unable to be updated, then it should be removed from agency networks. If the vulnerability does not have a mitigation or workaround, then it is not added to the KEV Catalog.
Using the KEV Catalog to reduce risk
Organizations can reduce their risk by ensuring that they are protecting their systems and networks from known vulnerabilities. Although a catalog of all known vulnerabilities, even if they have not yet been exploited, would be most helpful, that currently doesn’t exist. The KEV Catalog provides organizations with one of the most accurate lists of known vulnerabilities. By monitoring the catalog, organizations can prioritize their actions and make sure that they are taking proper steps to reduce risk.
To learn how IBM X-Force can help you with anything regarding cybersecurity including incident response, threat intelligence, or offensive security services schedule a meeting here.
If you are experiencing cybersecurity issues or an incident, contact X-Force to help: US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.