www.cisa.gov Open in urlscan Pro
23.14.20.231  Public Scan

Form analysis
2 forms found in the DOM

<form class="gsc-search-box gsc-search-box-tools" accept-charset="utf-8">
  <table cellspacing="0" cellpadding="0" role="presentation" class="gsc-search-box">
    <tbody>
      <tr>
        <td class="gsc-input">
          <div class="gsc-input-box" id="gsc-iw-id1">
            <table cellspacing="0" cellpadding="0" role="presentation" id="gs_id50" class="gstl_50 gsc-input" style="width: 100%; padding: 0px;">
              <tbody>
                <tr>
                  <td id="gs_tti50" class="gsib_a"><input autocomplete="off" type="text" size="10" class="gsc-input" name="search" title="search" aria-label="search" id="gsc-i-id1" dir="ltr" spellcheck="false"
                      style="width: 100%; padding: 0px; border: none; margin: 0px; height: auto; outline: none;"></td>
                  <td class="gsib_b">
                    <div class="gsst_b" id="gs_st50" dir="ltr"><a class="gsst_a" href="javascript:void(0)" title="Clear search box" role="button" style="display: none;"><span class="gscb_a" id="gs_cb50" aria-hidden="true">×</span></a></div>
                  </td>
                </tr>
              </tbody>
            </table>
          </div>
        </td>
        <td class="gsc-search-button"><button class="gsc-search-button gsc-search-button-v2"><svg width="13" height="13" viewBox="0 0 13 13">
              <title>search</title>
              <path
                d="m4.8495 7.8226c0.82666 0 1.5262-0.29146 2.0985-0.87438 0.57232-0.58292 0.86378-1.2877 0.87438-2.1144 0.010599-0.82666-0.28086-1.5262-0.87438-2.0985-0.59352-0.57232-1.293-0.86378-2.0985-0.87438-0.8055-0.010599-1.5103 0.28086-2.1144 0.87438-0.60414 0.59352-0.8956 1.293-0.87438 2.0985 0.021197 0.8055 0.31266 1.5103 0.87438 2.1144 0.56172 0.60414 1.2665 0.8956 2.1144 0.87438zm4.4695 0.2115 3.681 3.6819-1.259 1.284-3.6817-3.7 0.0019784-0.69479-0.090043-0.098846c-0.87973 0.76087-1.92 1.1413-3.1207 1.1413-1.3553 0-2.5025-0.46363-3.4417-1.3909s-1.4088-2.0686-1.4088-3.4239c0-1.3553 0.4696-2.4966 1.4088-3.4239 0.9392-0.92727 2.0864-1.3969 3.4417-1.4088 1.3553-0.011889 2.4906 0.45771 3.406 1.4088 0.9154 0.95107 1.379 2.0924 1.3909 3.4239 0 1.2126-0.38043 2.2588-1.1413 3.1385l0.098834 0.090049z">
              </path>
            </svg></button></td>
        <td class="gsc-clear-button">
          <div class="gsc-clear-button" title="clear results">&nbsp;</div>
        </td>
      </tr>
    </tbody>
  </table>
</form>

<form class="gsc-search-box gsc-search-box-tools" accept-charset="utf-8">
  <table cellspacing="0" cellpadding="0" role="presentation" class="gsc-search-box">
    <tbody>
      <tr>
        <td class="gsc-input">
          <div class="gsc-input-box" id="gsc-iw-id2">
            <table cellspacing="0" cellpadding="0" role="presentation" id="gs_id51" class="gstl_51 gsc-input" style="width: 100%; padding: 0px;">
              <tbody>
                <tr>
                  <td id="gs_tti51" class="gsib_a"><input autocomplete="off" type="text" size="10" class="gsc-input" name="search" title="search" aria-label="search" id="gsc-i-id2" dir="ltr" spellcheck="false"
                      style="width: 100%; padding: 0px; border: none; margin: 0px; height: auto; outline: none;"></td>
                  <td class="gsib_b">
                    <div class="gsst_b" id="gs_st51" dir="ltr"><a class="gsst_a" href="javascript:void(0)" title="Clear search box" role="button" style="display: none;"><span class="gscb_a" id="gs_cb51" aria-hidden="true">×</span></a></div>
                  </td>
                </tr>
              </tbody>
            </table>
          </div>
        </td>
        <td class="gsc-search-button"><button class="gsc-search-button gsc-search-button-v2"><svg width="13" height="13" viewBox="0 0 13 13">
              <title>search</title>
              <path
                d="m4.8495 7.8226c0.82666 0 1.5262-0.29146 2.0985-0.87438 0.57232-0.58292 0.86378-1.2877 0.87438-2.1144 0.010599-0.82666-0.28086-1.5262-0.87438-2.0985-0.59352-0.57232-1.293-0.86378-2.0985-0.87438-0.8055-0.010599-1.5103 0.28086-2.1144 0.87438-0.60414 0.59352-0.8956 1.293-0.87438 2.0985 0.021197 0.8055 0.31266 1.5103 0.87438 2.1144 0.56172 0.60414 1.2665 0.8956 2.1144 0.87438zm4.4695 0.2115 3.681 3.6819-1.259 1.284-3.6817-3.7 0.0019784-0.69479-0.090043-0.098846c-0.87973 0.76087-1.92 1.1413-3.1207 1.1413-1.3553 0-2.5025-0.46363-3.4417-1.3909s-1.4088-2.0686-1.4088-3.4239c0-1.3553 0.4696-2.4966 1.4088-3.4239 0.9392-0.92727 2.0864-1.3969 3.4417-1.4088 1.3553-0.011889 2.4906 0.45771 3.406 1.4088 0.9154 0.95107 1.379 2.0924 1.3909 3.4239 0 1.2126-0.38043 2.2588-1.1413 3.1385l0.098834 0.090049z">
              </path>
            </svg></button></td>
        <td class="gsc-clear-button">
          <div class="gsc-clear-button" title="clear results">&nbsp;</div>
        </td>
      </tr>
    </tbody>
  </table>
</form>

Text Content

Skip to main content

An official website of the United States government

Here’s how you know

Here’s how you know

Official websites use .gov
A .gov website belongs to an official government organization in the United
States.

Secure .gov websites use HTTPS
A lock (LockA locked padlock) or https:// means you’ve safely connected to the
.gov website. Share sensitive information only on official, secure websites.


Cybersecurity & Infrastructure Security Agency
America's Cyber Defense Agency

Search

×

search
 

Menu
Close
×

search
 

 * Topics
   Topics
   Cybersecurity Best Practices
   Cyber Threats and Advisories
   Critical Infrastructure Security and Resilience
   Election Security
   Emergency Communications
   Industrial Control Systems
   Information and Communications Technology Supply Chain Security
   Partnerships and Collaboration
   Physical Security
   Risk Management
   How can we help?
   GovernmentEducational InstitutionsIndustryState, Local, Tribal, and
   TerritorialIndividuals and FamiliesSmall and Medium BusinessesFind Help
   LocallyFaith-Based CommunityExecutives
 * Spotlight
 * Resources & Tools
   Resources & Tools
   All Resources & Tools
   Services
   Programs
   Resources
   Training
   Groups
 * News & Events
   News & Events
   News
   Events
   Cybersecurity Alerts & Advisories
   Directives
   Request a CISA Speaker
   Congressional Testimony
   CISA Conferences
   CISA Live!
 * Careers
   Careers
   Benefits & Perks
   HireVue Applicant Reasonable Accommodations Process
   Hiring
   Resume & Application Tips
   Students & Recent Graduates
   Veteran and Military Spouses
   Work @ CISA
 * About
   About
   Culture
   Divisions & Offices
   Regions
   Leadership
   Doing Business with CISA
   Site Links
   Reporting Employee and Contractor Misconduct
   CISA GitHub
   2023 Year In Review
   Contact Us

Report a Cyber Issue
America's Cyber Defense Agency
Breadcrumb
 1. Home

Share:




REDUCING THE SIGNIFICANT RISK OF KNOWN EXPLOITED VULNERABILITIES



For the benefit of the cybersecurity community and network defenders—and to help
every organization better manage vulnerabilities and keep pace with threat
activity—CISA maintains the authoritative source of vulnerabilities that have
been exploited in the wild: the Known Exploited Vulnerability (KEV) catalog.
CISA strongly recommends all organizations review and monitor the KEV catalog
and prioritize remediation of the listed vulnerabilities to reduce the
likelihood of compromise by known threat actors.

All federal civilian executive branch (FCEB) agencies are required to remediate
vulnerabilities in the KEV catalog within prescribed timeframes under Binding
Operational Directive (BOD) 22-01, Reducing the Significant Risk of Known
Exploited Vulnerabilities.  Although not bound by BOD 22-01, every organization,
including those in state, local, tribal, and territorial (SLTT) governments and
private industry can significantly strengthen their security and resilience
posture by prioritizing the remediation of the vulnerabilities listed in the KEV
catalog as well. CISA strongly recommends all stakeholders include a requirement
to immediately address KEV catalog vulnerabilities as part of their
vulnerability management plan. Doing so will build collective resilience across
the cybersecurity community.


HOW SHOULD ORGANIZATIONS USE THE KEV CATALOG?

The KEV catalog sends a clear message to all organizations to prioritize
remediation efforts on the subset of vulnerabilities that are causing immediate
harm based on adversary activity. Organizations should use the KEV catalog as an
input to their vulnerability management prioritization framework. Vulnerability
management frameworks—such as the Stakeholder-Specific Vulnerability
Categorization (SSVC) model(link is external)—consider a vulnerability's
exploitation status and the KEV catalog 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 KEV vulnerabilities. 

The following sections detail the criteria behind each of the three thresholds
for KEV catalog 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.


CRITERIA #1 - ASSIGNED CVE ID

The first criteria for adding a vulnerability to the KEV catalog 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(link
is external).)

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

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(link is external).) A
CNA is an organization authorized 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 center, bug bounty service provider, or research group.
(See https://www.cve.org/ProgramOrganization/CNAs(link is external).) 

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(link is external).) 

The MITRE CVE® List website https://cve.mitre.org/cve(link is external) 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(link is
external), 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/(link is
    external) 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.


CRITERIA #2 - ACTIVE EXPLOITATION

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 KEV catalog. Rather, the main criteria for KEV catalog
inclusion, is whether the vulnerability has been exploited 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 KEV
catalog, 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 KEV catalog, 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 KEV
catalog, 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 KEV catalog.

Note: Organizations or individuals with information about an exploited
vulnerability not currently listed on the KEV are encouraged to contact us at
vulnerability@cisa.dhs.gov(link sends email).


CRITERIA #3 - CLEAR REMEDIATION GUIDANCE

CISA adds known exploited vulnerabilities to the catalog when there is a clear
action for the affected organization to take. The remediation action referenced
in BOD 22-01 requires federal civilian executive branch (FCEB) agencies to take
the following actions for all vulnerabilities in the KEV, and CISA strongly
encourages all organizations 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: CISA relies on stakeholder feedback to improve its services to the
cybersecurity community. To provide feedback on the KEV catalog criteria and
process, email CISA.JCDC@CISA.DHS.GOV(link sends email).

Return to top
 * Topics
 * Spotlight
 * Resources & Tools
 * News & Events
 * Careers
 * About

Cybersecurity & Infrastructure Security Agency
 * Facebook
 * Twitter
 * LinkedIn
 * YouTube
 * Instagram

CISA Central 888-282-0870 central@cisa.dhs.gov(link sends email)
DHS Seal
CISA.gov
An official website of the U.S. Department of Homeland Security
 * About CISA
 * Accessibility
 * Budget and Performance
 * DHS.gov
 * FOIA Requests
 * No FEAR Act
 * Office of Inspector General
 * Privacy Policy
 * Subscribe
 * The White House
 * USA.gov
 * Website Feedback