“Vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer,” the Cyber Safety Review Board (CSRB) has concluded.
Log4j exploitation: Risk and effects of remediation efforts
The report concentrates on Log4Shell and other vulnerabilities that were discovered (and exploited) last year in the open-source Log4j library.
While cybersecurity vendors continue to flag attacks involving Log4Shell exploitation, “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.”
Previously, cyber MGA At-Bay came to a similar conclusion, mostly because other critical vulnerabilities still present a better option for attack.
The effort organizations’ defenders went through to find and patch vulnerable Log4j instances was considerable, but it affected their cybersecurity readiness (and the defenders’ December holiday plans).
“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. This culminated in one of the most intensive cybersecurity community responses in history,” the Board noted.
Lessons learned
The CSRB, which gathers government and industry leaders, has been set up to “review and assess significant cybersecurity events so that government, industry, and the broader security community can better protect [US] networks and infrastructure.”
The CSRB’s analysis of the entire Log4j event has allowed them to formulate recommendations for various government and private sector stakeholders for:
- Addressing the continued risk of Log4j exploitation
- Improving vulnerability management and security hygiene
- Building a better software ecosystem, and
- Make necessary cultural and technological changes to improve US digital security in the long run
Luta Security CEO Katie Moussouris, a cybersecurity leader and member of the CSRB, has summarized the lessons organizations, software makers and open-source maintainers can learn from this report. Topically, she also offered her opinion on the adverse effect of government-mandated early vulnerability disclosure may have on the coordinated vulnerability disclosure process.
“The report is packed with information and specific ideas on what can be done to prevent or mitigate the next Log4j but perhaps the most important takeaway is that the Board concludes Log4j could’ve been prevented – and that is true – sort of,” Dan Lorenc, Co-founder and CEO of Chainguard, told Help Net Security.
“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.”
But the good news is that progress is being made.
“There’s industry movement towards building security ‘checkpoints’ and tools into the software development process, often referred to as ‘security by default.’ 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.
Source: https://www.helpnetsecurity.com/2022/07/15/log4j-risk/
