The Cyber Safety Review Board released its first-ever report, detailing its investigation into the incident’s timeline, response efforts and needed interventions. Its findings draw on interviews and comments from nearly 80 individuals and organizations, as well as available literature and public and private information sources.
The Log4j crisis saw public and private sectors come together to try to contain the danger and share warnings and advice. But the event also revealed weaknesses in the U.S.’ cybersecurity landscape.
“A vulnerability in such a pervasive and ubiquitous piece of software has the ability to impact companies and organizations (including governments) all over the world,” the board wrote. “As such, the Log4j event drives home the urgency with which we must move to a culture of shared responsibility around managing cyber threats.”
The report detailed 19 actions it recommends government and private sector take. These included seeing federal government encourage more secure software development practices, better support the open source community and launch new groups and studies.
HOW BAD IS IT?
Open source software, like Log4j, is often used as basic building blocks of other proprietary or open source software. As a result, Log4j is widely infused throughout a variety of software and end users may be unaware that it is part of their systems. Compounding the problem, the groups behind open source software are powered by unpaid volunteers with limited resources.
Around the time Apache issued a Log4j patch December 2021, there were already “almost 7,000 open source projects leverage[ing] Log4j as a dependency,” per the report. Many of the U.S.’ critical infrastructure and government systems use it as well, the board said.
It’s difficult to know how often hackers exploited the Log4j vulnerability because there aren’t strong practices or standards for reporting this. There’s no central repository for recording Log4j-related incidents or requirements that organizations tell anyone if they were hit due to it or even collect this information, the report notes.
Observers documented that many hackers scanned for instances of the vulnerable piece of software and attempted to exploit it. But the actual damage was less than feared.
“The board is not aware of any significant Log4j-based attacks on critical infrastructure systems,” the report states. “The board also found that to date, generally speaking, exploitation of Log4j occurred at lower levels than many experts predicted.”
One lasting harm, however, may be that the stress of responding to such a high-scale, prolonged cyber crisis may have exhausted professionals, prompting many to abandon the industry at a time when their talent is in high demand.
“The force exerted on the urgent response and the challenges in managing risk also contributed to professional ‘burnout’ among defenders that may, compounded with the generally intense pace of many cybersecurity jobs, have a long-term impact on the availability of cybersecurity talent,” the report stated.
Another side effect: organizations had to dedicate a lot of time and resources to finding and addressing vulnerable Log4j instances in their systems, which took away from handling other vulnerabilities.
WHAT SHOULD WE DO?
Stay Alert and Aware: The Log4j vulnerability will remain a threat for years to come, and the board advised organizations to continue searching out and upgrading instances of that software. The federal government also needs a clear understanding of the situation, and so entities also should report about significant cyber incidents stemming from the Log4j weakness. CISA, meanwhile, should speed up efforts to enact a March 2022 law that, once implemented, will require critical infrastructure to report cyber incidents.
The board found that a variety of public and private organizations rushed to push out the latest news and tips as the Log4j crisis broke and the situation developed. This flurry of activity helped spread the word but also produced an overwhelming amount of information.
To help provide a clear voice, CISA should continue to establish itself as the federal government’s point player in gathering and pushing out reliable information and should expand this work. Meanwhile, state and federal regulators should help CISA’s advice have impact by pushing entities to follow it.
Adopt Best Practices: Vulnerability management and security best practices are especially important for organizations trying to minimize their risks from Log4j and other issues. That means taking steps to help detect weaknesses on their systems, including by keeping up-to-date inventories of their IT assets and applications, and scanning for vulnerabilities.
Organizations should also establish practices they can refer to for how to respond once they find potential vulnerabilities. These may differ depending on whether the weakness is in software maintained by the organization or by another party.
Software bills of materials (SBOMs) could also help — although changes may be needed first. The board noted that no respondents reported using SBOMs to find vulnerable Log4j implementations. Lack of standardization among today’s SBOMs is one major hurdle, in part because it prevents automating their use.
Make Software Safe: Making software safer from the get-go can head off problems. This can include steps like making secure software development part of computer science education and providing the open source community with more resources to help with maintaining and securing their software.
Because open source software is made by volunteers, end users — not developers — tend to have more responsibility for maintaining it. The report suggested that public-private collaborations could ease this work with various supports, including providing maintenance cost estimates and identifying funding opportunities.
New Groups, New Studies?: The report also suggested that a cyber safety reporting system might be created to incentivize — and anonymize — reporting about vulnerabilities that affect important projects, software libraries and code bases.
Additionally, a Software Security Risk Assessment Center of Excellence could be established to handle various tasks like keeping track of where the federal government is using open source software to support critical work.
Other efforts could research “incentive structures” for encouraging secure software development and ways to make it easier to find software that has known vulnerabilities.
