The U.S. Cybersecurity and Infrastructure Security Agency (CISA) released the first report of the Cyber Safety Review Board (CSRB), formed in February as directed under President Biden’s May 2021 cybersecurity executive order. The public-private board comprises top cybersecurity personnel in the federal government and selected private sector information security professionals.
The board’s first task was to examine the Log4j crisis that emerged late last year. That crisis centered on a vulnerability in the open-source, Java-based Log4j logging utility used by tens of thousands of organizations globally. That flaw allowed attackers to engage in remote execution on the underlying servers running the vulnerable applications.
The CSRB thoroughly reviewed public reports, conducted interviews, issued requests for information from 60 organizations, and met with representatives from 40 organizations to produce a detailed 52-page report. The report lays out the facts surrounding the Log4j crisis, presents conclusions and observations, and offers recommendations on how organizations can address the continued risks of Log4j and better position themselves for similar vulnerabilities in the future.
The board’s work was challenging because of the crisis’s chaotic and rapidly evolving nature. As the report notes, “Unlike comparable studies of incidents in other sectors (such as transportation), we had no crash site or damaged vehicle to inspect, no stress tests to perform on failed equipment, and no wiring diagrams to review.” Moreover, “The Log4j event is not over. Log4j remains deeply embedded in systems, and even within the short period available for our review, community stakeholders have identified new compromises, new threat actors, and new learnings.”
The facts of Log4j
The primary starting point of the crisis came on November 24, 2021, when a security engineer from the Alibaba Cloud Security team within the People’s Republic of China (PRC) reported a vulnerability in the Java Naming and Directory Interface (JNDI) feature to the Apache Software Foundation (ASF). Despite public reporting to the contrary, no evidence of malicious exploitation of the flaw was found before its exploitation on December 9.
The Chinese government informed the CSRB that Alibaba notified the Ministry of Industry and Information (MIIT) of the vulnerability on December 13, 2021, 19 days after the Alibaba engineer reported it to ASF and 17 days after a deadline stipulated in Article 7.2 of MIIT’s Regulations on the Management of Security Vulnerabilities of Network Products, which would have obligated Alibaba to report vulnerabilities in its products that incorporate Log4j. In addition, several media reports said that MIIT suspended Alibaba from a cybersecurity threat information sharing platform partnership for failing to promptly report the Log4j vulnerability to MIIT, which the CSRB could not confirm.
According to the report, “The pace, pressure, and publicity compounded the defensive challenges.” As a result, researchers found additional vulnerabilities in Log4j, contributing to confusion and “patching fatigue,” and “responders found it difficult to find authoritative sources of information on how to address the issues. This frenetic period culminated in one of the most intensive cybersecurity community responses in history.” At the same time, responders were beset by information overload, with reports about the event coming from various sources.
The few organizations that responded effectively to the event “understood their use of Log4j and had technical resources and mature processes to manage assets, assess risk, and mobilize their organization and key partners to action. Most modern security frameworks call out these capabilities as best practices.”
Log4j exploitation was lower than expected
The board says it is unaware of any significant Log4j-based attacks on critical infrastructure systems, and “generally speaking, exploitation of Log4j occurred at lower levels than many experts predicted, given the severity of the vulnerability.”
A fog still hovers over the event because, “No authoritative source exists to understand exploitation trends across geographies, industries or ecosystems. Many organizations do not even collect information on specific Log4j exploitation, and reporting is still largely voluntary. Most importantly, however, the Log4j event is not over.”
The ongoing nature of the event leads the Board to conclude that Log4j is an “endemic vulnerability and that vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer. Significant risk remains.”
How organizations can address continued Log4j risks
The report’s most meaningful section offers 19 detailed recommendations on how organizations can address the continued risks of Log4j and improve their cybersecurity operations. It delves into the details of the following four broadly themed sets of recommendations:
- Address continued risks of Log4j by promoting continued vigilance in addressing Log4j vulnerabilities for the long term. Among the steps outlined in the report are:
- Organizations should be prepared to address Log4j vulnerabilities for years to come.
- Organizations should continue to report (and escalate) observations of Log4j exploitation.
- CISA should expand its capability to develop, coordinate, and publish authoritative cyber risk information.
- Federal and state regulators should drive the implementation of CISA guidance through their regulatory authorities.
- Drive existing best practices for security hygiene by adopting industry-accepted practices and standards for vulnerability management and security hygiene. The steps outlined under this recommendation are:
- Invest in capabilities to identify vulnerable systems.
- Develop the capacity to maintain an accurate IT asset and application inventory.
- Have a documented vulnerability response program.
- Have a documented vulnerability disclosure and handling process.
- Software developers and maintainers should implement secure software practices.
- Build a better software ecosystem by driving a transformation in the software ecosystem to move to a proactive model of vulnerability management:
- Open-source software developers should participate in community-based security initiatives.
- Invest in training software developers in secure software development.
- Improve software bill of materials (SBOM) tooling and adoptability.
- Increase investments in open-source software security.
- Pilot open-source software maintenance support for critical services
- Invest in the future by researching possible cultural and technology shifts necessary to solve for the nation’s digital security:
- Explore a baseline requirement for software transparency for federal government vendors.
- Examine the efficacy of a cyber safety reporting system (CSRS).
- Explore the feasibility of establishing a software security risk assessment center of excellence (SSRACE).
- Study the incentive structures required to build secure software.
- Establish a government-coordinated working group to improve the identification of software with known vulnerabilities.
The CSRB report garnered strong positive reviews from the industry and the head of the department under which CISA operates. “The Cyber Safety Review Board’s report on Log4j is a thorough account of what transpired during December 2021, and we applaud its constructive analysis,” former Google security engineer and now CEO of Chainguard Dan Lorenc said in a written statement. “The report is packed with information and specific ideas on what can be done to prevent or mitigate the next Log4j.”
The Department of Homeland Security Director Alejandro N. Mayorkas said that “The CSRB’s first-of-its-kind review has provided us – government and industry alike – with clear, actionable recommendations that DHS will help implement to strengthen our cyber resilience and advance the public-private partnership that is so vital to our collective security.”