Log4J Vulnerability – Reaches Endemic

The Log4Shell vulnerability in open-source library Log4j has reached endemic proportions and the aftershock could reverberate for a decade or longer.

The report by the Cyber Safety Review Board (CSRB) established in February 2022 by the DHS provided 19 recommendations for how organizations and government agencies can bolster their networks and applications against the threat.

The public-private initiative is tasked with reviewing serious cybersecurity events and delivering strategic recommendations to government, industry, and the information security community.

The Log4Shell vulnerability, which surfaced in December 2021, offers a potent combination of super-criticality – notching a maximum CVSS severity score of 10 – and enormous attack surface given Log4j’s near-ubiquity in providing Java-based logging to myriad applications.

The Apache Software Foundation, which maintains Log4j, was praised for its well-established software development lifecycle” and “for recognizing the criticality of the problem in quickly issuing patches.

Further down the supply chain, organizations still struggled to respond to the event, and the hard work of upgrading vulnerable software is far from complete across many organizations.

The report also hailed the rapid production of effective guidance, tools, and threat information by vendors and governments.

Recommendations

1. Organizations should be prepared to address Log4j vulnerabilities for years to come.
2. Organizations should continue to report (and escalate) observations of Log4j exploitation.
3. CISA should expand its capability to develop, coordinate, and publish authoritative cyber risk information.
4. Federal and state regulators should drive implementation of CISA guidance through their own regulatory authorities.
5. Organizations should invest in capabilities to identify vulnerable systems.
6. Develop the capacity to maintain an accurate IT asset and application inventory.
7. Organizations should have a documented vulnerability response program.
8. Organizations should have a documented vulnerability disclosure and handling process.
9. Software developers and maintainers should implement secure software practices.
10. Open-source software developers should participate in community-based security initiatives.
11. Invest in training software developers in secure software development.
12. Improve SBOM tooling and adoptability.
13. Increase investments in open-source software security.
14. Pilot open-source software maintenance support for critical services.
15. Explore a baseline requirement for software transparency for federal government vendors.
16. Examine the efficacy of a Cyber Safety Reporting System (CSRS).
17. Explore the feasibility of establishing a Software Security Risk Assessment Center of Excellence (SSRACE).
18. Study the incentive structures required to build secure software.
19. Establish a government-coordinated working group to improve identification of software with known vulnerabilities.