Locally Exploited Vulnerability (LEV) Catalogue

For the benefit of the cybersecurity community and network defenders—and to help every organization better manage vulnerabilities and keep pace with threat activity—the CIRT Division maintains the authoritative source of vulnerabilities that have been exploited in the wild and identified in the .JM space: the Locally Exploited Vulnerability (LEV) catalogue. The CIRT Division strongly recommends all organisations review and monitor the LEV catalogue and prioritise mitigation of the listed vulnerabilities to reduce the likelihood of compromise by known threat actors.

All Ministries, Departments and Agencies (MDAs) are required to mitigate vulnerabilities in the NEV catalogue within prescribed timeframes issued in Vulnerability Notifications, reducing the Significant Risk of Locally Exploited Vulnerabilities.  Although not bound by Vulnerability Notifications, every organisation, including those in private industry can significantly strengthen their security and resilience posture by prioritising the mitigation of the vulnerabilities listed in the LEV catalogue as well. The CIRT Division strongly recommends all stakeholders include a requirement to immediately address LEV catalogue vulnerabilities as part of their vulnerability management plan. Doing so will build collective resilience across the cybersecurity community.

 

How To Use the LEV Catalogue?

The LEV catalogue sends a clear message to all organisations to prioritise mitigation efforts on the subset of vulnerabilities that are causing immediate harm based on adversary activity. Organisations should use the LEV catalogue as an input to their vulnerability management prioritisation framework. Vulnerability management frameworks—such as the Stakeholder-Specific Vulnerability Categorization (SSVC) model—consider a vulnerability's exploitation status and the LEV catalogue serves as the authoritative repository of that information. Organizations should also consider using automated vulnerability and patch management tools that automatically incorporate and flag or prioritize LEV vulnerabilities. 

The following sections detail the criteria behind each of the three thresholds for LEV catalogue updates, which are:

  • The vulnerability has an assigned Common Vulnerabilities and Exposures (CVE) ID.
  • There is reliable evidence that the vulnerability has been actively exploited in the wild.
  • There is a clear remediation action for the vulnerability, such as a vendor-provided update.

 

The first criteria for adding a vulnerability to the LEV catalogue is the assignment of a CVE ID. A CVE ID—also known as CVE identifier, CVE record, CVE name, CVE number, and CVE—is a unique, common identifier for a publicly known cybersecurity vulnerability. (See https://www.cve.org/ResourcesSupport/FAQs.)

The CVE Program is sponsored by CISA and run by a non-profit, federally funded, research and development centre (FFRDC), which is operated by The MITRE Corporation. The mission of the CVE Program is to identify, define, and catalogue publicly disclosed cybersecurity vulnerabilities. (See https://www.cve.org/About/Overview.) 

The process of obtaining a CVE ID begins with the discovery of a potential cybersecurity vulnerability. The information is then assigned a CVE ID by a CVE Numbering Authority (CNA). (See https://www.cve.org/About/Process#CVERecordLifecycle.) A CNA is an organisation authorised to assign and populate CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope. Becoming a CNA is voluntary. A CNA can be a software vendor, open-source project, coordination centre, bug bounty service provider, or research group. (See https://www.cve.org/ProgramOrganization/CNAs.) 

After the CNA creates the CVE record, including a description and references, MITRE posts it on the CVE website. (See https://www.cve.org/About/Process#CVERecordLifecycle.) 

The MITRE CVE® List website https://cve.mitre.org/cve and the National Vulnerability Database (NVD) https://nvd.nist.gov/ website, maintained by the National Institute of Standards and Technology (NIST), provide a running list of all assigned CVEs. The NVD is synchronized with CVE such that any updates to CVE appear immediately on the NVD. It augments information provided by CVE List with a database of security checklist references, security related software flaws, misconfigurations, product names, impact metrics, and a search engine. (See https://nvd.nist.gov/general/FAQ-Sections/General-FAQs.)  

According to https://www.cve.org/About/Process#CVERecordLifecycle, a CVE entry can be in one of three states:

  1. Reserved: The initial state for a CVE Record; when the associated CVE ID is Reserved by a CNA. If the CVE record shows as reserved, visitors/users can submit a CVE Request to MITRE via https://cveform.mitre.org/ to request the CVE record be published. In the form, select ”Request Type” as “Other” and ”Type of comment” as “Issue.”   
  2. Published: When a CNA populates the data associated with a CVE ID as a CVE Record, the state of the CVE Record is Published. The associated data must contain an identification number (CVE ID), a prose description, and at least one public reference.
  3. Rejected: If the CVE ID and associated CVE Record should no longer be used, the CVE Record is placed in the Rejected state. A Rejected CVE Record remains on the CVE List so that users can know when it is invalid.

 

 

The term “exploitable” refers to how easily an attacker can take advantage of a vulnerability. It evaluates various aspects such as: availability of a public proof-of-concept (PoC), network accessibility, unprivileged access, wormability, and skill-level needed to carry out the exploit. Wormability refers to a cyberattack that can spread from one machine to another without user interaction. An analysis of a vulnerability's exploitability can assist in determining the severity of the vulnerability. 

However, a vulnerability's exploitability is not considered as criteria for inclusion in the LEV catalogue. Rather, the main criteria for LEV catalogue inclusion, is whether the vulnerability has been exploited locally or is under active exploitation. These two terms refer to the use of malicious code by an individual to take advantage of a vulnerability. In reference to the LEV catalogue, active exploitation and exploited are synonymous.

A vulnerability under active exploitation is one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner. 

Active exploitation, in reference to the LEV catalogue, also includes attempted exploitation and successful exploitation. 

  • Attempted exploitation occurs when an attacker executes code on a target system, but the code does not execute due to the system not being vulnerable, or the system being a honeypot, etc. A honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems. Successful malicious code execution on a honeypot is considered attempted exploitation because the attacker does not obtain actual target information.
  • Successful exploitation occurs when an attacker successfully exploits vulnerable code on a target system, allowing them to perform additional, unauthorized actions on that system or network.

The two key takeaways for active exploitation are: the intent of the actor is to succeed in exploitation and the attack(s) occurred in real time, or “in the wild.” 

Events that do not constitute as active exploitation, in relation to the LEV catalogue, include:

  • Scanning
  • Security research of an exploit
  • Proof of Concept (PoC)

PoC is the code for a vulnerability that, when executed, would allow for exploitation. Exchange of PoC between security researchers and vendors occurs regularly to demonstrate how the vulnerability can be exploited and to assist vendors in developing a patch for the vulnerability. Making PoC publicly available can increase the likelihood of an attacker exploiting the vulnerability in the wild. However, the public availability of a PoC does not automatically indicate the vulnerability has been or will be exploited. Having a publicly available PoC is not a requirement for a vulnerability to be included in the LEV catalogue.

Note: Organizations or individuals with information about an exploited vulnerability not currently listed on the LEV are encouraged to contact us at vulnerability@opm.gov.jm.

 

The CIRT Division adds locally exploited vulnerabilities to the catalogue when there is a clear action for the affected organisation to take. The mitigation action referenced in Vulnerability Notifications require MDAs to take the following actions for all vulnerabilities in the LEV, and the CIRT Division strongly encourages all organisations to do the same:

  • Apply updates per vendor instructions. There is an update available from the security vendor, and users should apply it.
  • Remove from agency networks if the impacted product is end-of-life or cannot be updated otherwise. 

Mitigations are temporary solutions users can implement to prevent a vulnerability's exploitation. For an example, see the PDF below on Mitigating Attacks Against Uninterruptible Power Supply Devices, which provides best practice guidance to prevent exploitation of uninterruptible power supply (UPS) devices.

Mitigating Vulnerabilities Affecting Uninterruptible Power Supply Devices(PDF, 206.46 KB )

A workaround involves implementing manual changes to an affected product to protect a vulnerable system from exploitation until the vendor releases a formal security patch. It is a best practice for users to transition from a workaround to an official patch, when available. However, implementing a workaround is recommend as opposed to leaving a product vulnerable.

Note: The CIRT Division relies on stakeholder feedback to improve its services to the cybersecurity community. To provide feedback on the LEV catalogue criteria and process, email cirt.ja@opm.gov.jm 

Go to the LEV Catalogue