CISA Emergency Directive Requires Immediate Mitigation of Log4j Vulnerabilities

On December 17, 2021, the Cybersecurity and Infrastructure Security Agency (“CISA”) issued Emergency Directive 22-02 (the “Directive”) instructing civilian federal agencies to mitigate a series of vulnerabilities in Apache Log4j, a Java-based logging library, by 5 p.m. EST on December 23 and to provide a report to CISA about vulnerable applications by December 28.

The Directive requires agencies to update off-the-shelf applications, with priorities given to “solution stacks” (connected hardware, firmware, and software requiring no other IT technologies to provide a service) that accept data input from the internet – or otherwise to remove them from their networks.

The regimented approach outlined in the Directive sets out objectives with two critical deadlines:

• By 5 p.m. EST, December 23, 2021:
  • Identify the universe of solution stacks accepting data input from the internet;
  • Cross-check all software assets in identified solution stacks against the CISA-managed GitHub repository to determine whether a Log4j vulnerability exists;
  • For all software assets affected by CVE-2021-44228 (the Log4j remote code execution vulnerability dubbed “Log4Shell”), update assets with available patches, mitigate the risk of exploitation, or remove affected software assets from agency networks; and
  • For solution stacks with affected software, continuously investigate and monitor for signs of malicious activity and anomalous traffic patterns.
• By 5 p.m. EST, December 28, 2021:
  • Report all identified affected software applications; and
  • Confirm with CISA by emailing vulnerability@cisa.dhs.gov that internet-accessible IP addresses on file with CISA are up-to-date, as required by CISA Binding Operational Directive 19-02.

To assist with achieving these objectives, CISA established dedicated websites outlining Apache Log4j vulnerability guidance as well as recommended mitigation measures.

Background

Found in Apache (a free, open source, and reliable web server framework that likely powers over two-thirds of the internet’s web servers), Log4j has for many years been an extremely popular Java library that allows application developers to keep track of what is happening on internet-enabled applications. The barrier to entry for exploitation of the Log4j vulnerability is very low: a single, well-crafted line of code is sufficient to execute malicious remote code on any vulnerable system.

Because a great number of Java developers relied on the Log4j library for both external and internal applications, many organizations may not know whether the vulnerability affects them and must take immediate steps to assess the risk. According to statistics by Check Point Research, between the first reporting of the issue on December 9, 2021 and December 13, 2021, over 800,000 attack attempts on network security were noted across the globe. Several sources also report that advanced threat actors, including the well-known ransomware gang, Conti, as well as China and Iran, have already exploited the Log4j vulnerability.

Impact & CISA Advice

In a statement by about the Apache Log4j vulnerabilities, CISA Director Jen Easterly perceives the vulnerabilities as posing “an unacceptable risk to federal network security” requiring the protection of agency networks with “internet-facing devices that pose the greatest immediate risk.” CISA encourages non-federal entities to similarly take steps outlined in the Directive to protect their network security.

The Directive comes as a response to the (i) current exploitation of these vulnerabilities by threat actors in external network environments, (ii) the likelihood of the vulnerabilities being further exploited, (iii) the prevalence of the affected software in the federal enterprise, (iv) the high potential for a compromise of agency information systems, and (v) the potential impact of a successful compromise.

Organizations both public and private may want to consider taking several steps to manage Log4j vulnerabilities:

• Scan, isolate, patch, and monitor.
  • Scan. Organizations should hunt within their environments for applications affected by the Log4j vulnerability, with an emphasis on identifying external, third-party applications.
  • Isolate. Vulnerable systems should be isolated through network segmentation or other logical means, with egress capabilities limited.
  • Patch. Organizations should update and patch any affected applications. If patches are unavailable, organizations should consider implementing temporary mitigation measures that Apache recommended.
  • Monitor. Consider enhanced network monitoring for anomalous activity with particular attention to applications establishing remote connections.
• Address third-party risk. For all applications affected by the Log4j vulnerability, organizations should collect and review contracts and MSAs with applicable vendors, developers, or partners. Organizations may have the right to more security-related information than they think, including updates about patches, remediation, and exploitation of the counterparty’s software. Based on that information, organizations may wish to remote applications from its environment and terminate services. Vendors should similarly review the contracts to understand their obligations.
• Consider a Zero Trust model. With regard to network segments on which vulnerable systems reside, organizations should consider taking steps to implement a Zero Trust architecture – a cybersecurity approach that rejects implicit trust and continuously validates every stage of a digital interaction. In these instances, all users are continuously validated to maintain access to applications and data.

Crowell & Moring is adept at navigating cybersecurity issues and provides additional guidance in a recent webinar in which panelists discussed the current state of the Log4j vulnerabilities, strategies for management of third party and vendor risk, and approaches for remediating and patch management issues of the vulnerabilities.