April 8, 2022
CISA has closed ED 22-02 and transitioned required actions for Log4J vulnerability to CISA’s BOD 22-01 Reducing the Significant Risk or Known Exploited Vulnerabilities. Please refer to updated guidance on the Apache Log4j Vulnerability Guidance page. BOD 22-01 still requires agencies to fully remediate the Log4j vulnerabilities wherever updates are available across all impacted software. Agencies should leverage the updated guidance to tailor their internal temporary mitigation efforts going forward.
December 17, 2021
This page contains a web-friendly version of the Cybersecurity and Infrastructure Security Agency’s Emergency Directive 22-02, “Mitigate Apache Log4j Vulnerability”.
Section 3553(h) of title 44, U.S. Code, authorizes the Secretary of Homeland Security, in response to a known or reasonably suspected information security threat, vulnerability, or incident that represents a substantial threat to the information security of an agency, to “issue an emergency directive to the head of an agency to take any lawful action with respect to the operation of the information system, including such systems used or operated by another entity on behalf of an agency, that collects, processes, stores, transmits, disseminates, or otherwise maintains agency information, for the purpose of protecting the information system from, or mitigating, an information security threat.” 44 U.S.C. § 3553(h)(1)–(2). Section 2205(3) of the Homeland Security Act of 2002, as amended, delegates this authority to the Director of the Cybersecurity and Infrastructure Security Agency. 6 U.S.C. § 655(3). Federal agencies are required to comply with these directives. 44 U.S.C. § 3554 (a)(1)(B)(v). These directives do not apply to statutorily defined “national security systems” nor to systems operated by the Department of Defense or the Intelligence Community. 44 U.S.C. § 3553(d), (e)(2), (e)(3), (h)(1)(B).
A series of vulnerabilities in the popular Java-based logging library Log4j are under active exploitation by multiple threat actors.
Exploitation of one of these vulnerabilities allows an unauthenticated attacker to remotely execute code on a server. Successful exploitation can occur even if the software accepting data input is not written in Java; such software is able to pass malicious strings to other (back end) systems that are written in Java.
CISA has determined that this vulnerability poses an unacceptable risk to Federal Civilian Executive Branch agencies and requires emergency action. This determination is based on the current exploitation of this vulnerability by threat actors in the wild, the likelihood of further exploitation of the vulnerability, the prevalence of the affected software in the federal enterprise, and the high potential for a compromise of agency information systems.
This Emergency Directive does not affect or supersede related requirements imposed by Binding Operational Directives 22-01 or 19-02 except as noted in Action 3 below. As defined by BOD 22-01, CVE-2021-44228 has been added to CISA’s catalog of known exploited vulnerabilities (KEVs). CISA will continue to add KEVs related to this vulnerability as needed. Off-the-shelf applications must be updated in accordance with BOD 22-01 requirements as updates become available for various software products.
While the current version of this emergency directive prioritizes solution stacks accepting data input from the internet, CISA strongly recommends the same actions against the entirety of agencies’ infrastructure. For the purposes of this directive, a solution stack is defined as a collection of connected IT technologies (hardware, firmware, and software) that require no other IT technologies to provide a service. As this is an evolving situation, CISA will issue supplemental direction applicable to broader agency-owned information technologies (IT) and operational technologies (OT).
By 5 pm EST on December 23, 2021:
- Enumerate all solution stacks accepting data input from the internet.
- Evaluate all software assets in identified solution stacks against the CISA-managed GitHub repository (https://github.com/cisagov/log4j-affected-db) to determine whether Log4j is present in those assets and if so, whether those assets are affected by the vulnerability.
- If the software product is not listed in the repository, request addition by submitting a “pull” request using the link on the GitHub page.
- For all software assets that agencies identify as affected by CVE-2021-44228:
- Update assets for which patches have been provided. Remediation timelines prescribed in BOD 22-01 “may be adjusted in the case of grave risk to the Federal Enterprise.” Given the criticality of CVE-2021-44228, agencies must immediately patch any vulnerable internet-facing devices for which patches are available, under an emergency change window.
- Mitigate the risk of vulnerability exploitation using one of mitigating measures provided at: ED 22-02: Apache Log4j Recommended Mitigation Measures | CISA.
- Remove affected software assets from agency networks.
- For all solution stacks containing software that agencies identified as affected: assume compromise, identify common post-exploit sources and activity, and persistently investigate and monitor for signs of malicious activity and anomalous traffic patterns (e.g., JDNI LDAP/RMI outbound traffic, DMZ systems initiating outbound connections).
By 5 pm EST on December 28, 2021:
- Report all affected software applications identified in (3) above using the provided template, including:
- Vendor name
- Application name and version
- Action taken (e.g. updated, mitigated, removed from agency network)
- Confirm with firstname.lastname@example.org that your agency’s Internet-accessible IP addresses on file with CISA are up to date, as required by CISA Binding Operational Directive 19-02.
These required actions apply to agency applications in any information system, including an information system used or operated by another entity on behalf of an agency, that collects, processes, stores, transmits, disseminates, or otherwise maintains agency information (i.e. all applications in agency ATO boundaries).
For federal information systems hosted in third-party environments (such as cloud) each agency is responsible for maintaining an inventory of its information systems hosted in those environments (FedRAMP Authorized or otherwise), conducting all necessary reporting to CISA accounting for such systems, and working with service providers directly for status updates pertaining to, and to ensure compliance with, this Directive.
- CISA will continue to work with our partners to monitor for active exploitation associated with these vulnerabilities and will notify agencies and provide additional guidance, as appropriate.
- CISA will provide technical assistance to agencies who are without internal capabilities sufficient to comply with this Directive.
- By February 15, 2022, CISA will provide a report to the Secretary of Homeland Security and the Director of the Office of Management and Budget (OMB) identifying cross-agency status and outstanding issues.
This Emergency Directive remains in effect until CISA determines that all agencies operating affected software have performed all required actions from this Directive or the Directive is terminated through other appropriate action.
Visit Directives | CISA or contact the following for:
- General information, assistance, and reporting – CyberDirectives@cisa.dhs.gov
- Reporting indications of potential compromise – https://us-cert.cisa.gov/report
Frequently Asked Questions
Version updated on February 7, 2022
- What is meant by solution stack? Why can’t we just focus on internet-facing assets?
- Is software that receives online updates considered a solution stack that receives input from the internet?
- If an update is not available for a vulnerable product, what mitigations should be taken? Is there a middle ground on when an agency would not have to remove a “solution stack” if an asset was not patched?
- What is the best way to enumerate all affected instances? Can we just run regular scans?
- What is the guidance for instances of Log4j version 1 or versions outside of the affected software outlined in the CVE?
- Why is there an Emergency Directive if this CVE was already added to CISA’s catalog of known exploited vulnerabilities and federal agencies are required to update?
In the context of BOD 22-01, an IT solution stack is a collection of connected IT resources that directly support an internet-facing information system that accepts data input. These vulnerabilities are not limited to internet exposed assets; therefore, CISA introduced the concept of solution stacks to help agencies prioritize their remediation efforts. For example, a solution stack supporting a web server may include databases, storage, application firewalls, identity and authentication services, etc.
Exploitation of the Log4j vulnerabilities allows an unauthenticated attacker to remotely execute code on a server. Successful exploitation can occur even if internet-facing software is not written in Java, because it can still pass data to other systems that are written in Java. Any application that is using Log4j and supports any part of a solution stack above can be vulnerable.
If an update is not available for a vulnerable product, what mitigations should be taken? Is there a middle ground on when an agency would not have to remove a “solution stack” if an asset was not patched?
If an update is available, it must be applied immediately. The only other acceptable long-term remediation is removal from the network. If a product cannot be removed, you must apply the temporary mitigation measures from the list at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures.
What is the best way to enumerate all affected instances? Can we just run regular scans?
Agencies need to perform comprehensive analysis to fully enumerate all Log4j vulnerabilities. This should include scanning (network and host) and comparing installed software with software listed in CISA’s Log4j vulnerable software database. Agencies need to use all the tools at their disposal to fully enumerate all solution stacks accepting data input from the internet, including manual enumeration, static code analysis, etc.
What is the guidance for instances of Log4j version 1.x or versions outside of the affected software outlined in the CVE?
While still a concern, Log4j version 1.x has been unsupported since August 5, 2015, and your agency and vendors should already have a plan in place to upgrade or replace any technology that still uses this end-of-life product.
For the purposes of this Directive, agencies should prioritize applications using 2.x version of the library. Versions on 1.x should still be updated as soon as possible but this is a secondary priority. Only report stacks running vulnerable 2.x versions when reporting to CISA.
For more information on the use of products that have reached end of support, see CISA’s guidance on Bad Practices.
Why is there an Emergency Directive if this CVE was already added to CISA’s catalog of known exploited vulnerabilities and federal agencies are required to update?
Urgent action is required, because multiple threat actors are leveraging the Log4j vulnerabilities to exploit web-facing and back-end systems now. This is a complex vulnerability that exists in a library that is used across many different products. While an update for the library has already been released, organizations depend on vendors to develop updates for their individual products, and many of the products are still vulnerable. The goal of the emergency directive is to help federal agencies prioritize their remediation efforts, focus on those assets that carry the highest risks, and provide guidance for mitigations where updates are still not available.
This version prioritizes solution stacks accepting data input from the internet. This is a rapidly evolving situation, and CISA may issue supplemental direction applicable to broader agency-owned information technologies (IT) and operational technologies (OT). CISA strongly recommends that agencies perform the actions in the ED against all of their infrastructure, regardless of technology or where it resides.
Creating a pull request - GitHub Docs, https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request