CSRB report not aware of any significant Log4j-based attacks on critical infrastructure systems
The Cyber Safety Review Board (CSRB) said that organizations who responded most effectively to the Log4j event understood their use of Log4j and had technical resources and mature processes to manage assets, assess risk, and mobilize their organization and critical partners to action. However, few organizations could execute this kind of response or the speed required during this incident, causing delays in their assessment of the risk and their management of it.
The CSRB’s mandate was to review the events surrounding this significant vulnerability, report lessons learned, and make independent, strategic, and actionable recommendations to the Secretary of Homeland Security. With the data collected from extensive interviews and requests for information, the report has been framed into three sections – factual Information covering facts describing what happened, findings and conclusions with an analysis of the facts, and recommendations.
“To reduce recurrence of the introduction of vulnerabilities like Log4j, it is essential that public and private sector stakeholders create centralized resourcing and security assistance structures that can support the open source community going forward,” the CSRB report said in its initial report.
It also added that “at the time of writing, the Board is not aware of any significant Log4j-based attacks on critical infrastructure systems. Somewhat surprisingly, the Board also found that to date, generally speaking, exploitation of Log4j occurred at lower levels than many experts predicted, given the severity of the vulnerability. It has been difficult to arrive at this conclusion.”
While cybersecurity vendors were able to provide some anecdotal evidence of exploitation, no authoritative source exists to understand exploitation trends across geographies, industries, or ecosystems, according to the CSRB report. It also added that many organizations do not collect information on specific Log4j exploitation, and reporting is still largely voluntary. “Most importantly, however, the Log4j event is not over. The Board assesses 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,” it added.
On Nov. 24, 2021, a security engineer from the Alibaba Cloud Security team within the People’s Republic of China (PRC) reported a vulnerability in the JNDI feature to the Apache Software Foundation (ASF). This non-profit corporation provides support for the Log4j project. “While ASF was working to understand the issue and devise a fix, another party disclosed the vulnerability before ASF made an upgrade available to the general public. Such disclosure of a significant vulnerability in any widely used piece of the software immediately triggers a race between defense and offense: a race to apply upgrades before threat actors exploit vulnerable systems. The Log4j vulnerability was no exception,” according to the report.
Defenders faced a particularly challenging situation; the vulnerability impacted virtually every networked organization, and the threat’s severity required fast action. The fact that there is no comprehensive ‘customer list’ for Log4j, or even a list of where it is integrated as a sub-system, hindered defender progress. Enterprises and vendors scrambled to discover where they used Log4j.
“The pace, pressure, and publicity compounded the defensive challenges: security researchers quickly found additional vulnerabilities in Log4j, contributing to confusion and ‘patching fatigue,’ defenders struggled to distinguish vulnerability scanning by bona fide researchers from threat actors, and responders found it difficult to find authoritative sources of information on how to address the issues,” according to the CSRB report. “This culminated in one of the most intensive cybersecurity community responses in history. Responders, spanning the public and private sectors, the open source community, and researchers globally, collaborated and communicated in a dedicated fashion, working through weekends and the December holidays.”
The Board also noted high levels of cooperation, extensive use of social media for rapid sharing of mitigation advice, innovative response actions from the Department of Homeland Security’s (DHS) Cybersecurity and Infrastructure Security Agency (CISA), and the creation of new shared community resources.
The report said that the Board found that software developers, maintainers, vulnerability response teams, and the U.S. government commonly made risk trade-offs about software use and integration. “For example, organizations made the decision to use Log4j, rather than develop a logging framework from scratch. Similarly, organizations make decisions to use software from an established organization (e.g., ASF) based on its mature and vetted processes.”
The Log4j event highlighted fundamental adoption gaps in vulnerability response practices and overall cybersecurity hygiene. The CSRB said that these gaps highlighted challenges in raising awareness within organizations, coordinating trusted and authoritative sources of information, mitigating at scale, measuring the enormity of the risk, and synchronizing the understanding of threats and corresponding defensive action.
CSRB identified several factors that amplified the vulnerability’s scale, complexity, and risk level. These include Log4j is routinely embedded in other software components, often unknown at later integration or system operation levels, making it a difficult vulnerability to identify using common scanning approaches. Additionally, the Log4j framework is incorporated into thousands of software components globally, and many of the nation’s critical infrastructure and government systems rely on it; consistent with industry convention, the Log4j and ASF teams do not manage or know who uses the software they produce, or how it is eventually used. Furthermore, the Log4j vulnerability is easy for attackers to exploit and affords a high degree of system control to an attacker once exploited.
The CSRB broke down its recommendations into four categories. The first set address the continued risks of Log4j to bring about continued vigilance in addressing Log4j vulnerabilities for the long term. Organizations should be prepared to address Log4j vulnerabilities for years to come and continue to report (and escalate) observations of Log4j exploitation. Additionally, CISA should expand its capability to develop, coordinate, and publish authoritative cyber risk information. At the same time, the federal and state regulators should drive the implementation of CISA guidance through their own regulatory authorities.
The next set of recommendations focused on driving existing best practices for security hygiene by adopting industry-accepted practices and standards for vulnerability management and security hygiene. The CSRB advised organizations to invest in capabilities to identify vulnerable systems and develop the capacity to maintain accurate information technology (IT) asset and application inventory. Additionally, organizations should have a documented vulnerability response program and a documented vulnerability disclosure and handling process. Software developers and maintainers should also implement secure software practices.
The CSRB also suggested building a better software ecosystem, 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, and improve Software Bill of Materials (SBOM) tooling and adoptability. Furthermore, they should increase investments in open source software security and pilot open source software maintenance support for critical services.
The last guidance set focused on future investments that pursue cultural and technological shifts necessary to solve the nation’s digital security in the long run. For example, it called for organizations to explore a baseline requirement for software transparency for federal government vendors, examine the efficacy of a Cyber Safety Reporting System (CSRS), and explore the feasibility of establishing a Software Security Risk Assessment Center of Excellence (SSRACE). Furthermore, the report called for studying the incentive structures required to build secure software and establishing a government-coordinated working group to improve the identification of software with known vulnerabilities.
Commenting on the CSRB report, Thomas Pace, former DoE and CEO of XIoT cybersecurity firm NetRise said that ICS operators rarely know what software is running on their XIoT devices, let alone know if there are instances of Log4j that can be exploited. “Just because these attacks have not been detected does not mean that they haven’t happened. We know for a fact that threat actors are exploiting known vulnerabilities across industries. Critical infrastructure is no different,” he added in an emailed statement.
“The Cyber Safety Review Board’s assessment of lower tier Log4j exploits in critical infrastructure is one piece of information, but CISOs need to take into account that critical infrastructure operators may not know the number of Log4j instances within their software supply chain and if those instances have been exploited,” Dan Murphy, distinguished architect at Invicti, wrote in an emailed statement. “As we have seen in financial services and other more mature sectors, Log4j is difficult to detect and still at risk for exploit by attackers and nation-state threat actors. It’s important for infrastructure operators to continue to keep their eyes on Log4j as it could have potential to be exploited.”
“Preventing another Log4j from occurring is possible, but it is going to require a fundamental shift in several critical areas by many, including a collective approach to support the open source community through resources and defining security standards across the industry and increased focus by the private and public sector organizations to build security into their software development process and define how they assess risk in the management of that software,” Dan Lorenc, CEO of Chainguard, wrote in an emailed statement. “Luckily there is progress being made. There’s industry movement towards building security ‘checkpoints’ and tools into the software development process, often referred to as ‘security by default.’”
Lorenc said that the CSRB report calls out this direction and calls on both the open source community and commercial companies to prioritize these practices. “We believe this is the future of software security and that developers and maintainers will reap the benefits of more time to build and innovate, while companies will save tremendous costs in mitigation and tools acquisition,” he added.
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
