Organizations can expect risks associated with Log4j vulnerabilities for “a decade or longer,” according to the US Department of Homeland Security.
The DHS’ Cyber Safety Review Board‘s inaugural report [PDF] dives into the now-notorious vulnerabilities discovered late last year in the Java world’s open-source logging library.
The bugs proved to be a boon for cybercriminals as Log4j is so widely used, including in cloud services and enterprise applications. And because of this, miscreants soon began exploiting the flaws for all kinds of illicit activities including installing coin miners, stealing credentials and data, and deploying ransomware.
Could have been a lot worse
Luckily, and perhaps surprisingly, the cyber review board “is not aware of any significant Log4j-based attacks on critical infrastructure systems,” according to the report. Some industrial security professionals, however, remain skeptical.
“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,” Thomas Pace, a former Department of Energy cybersecurity lead and current CEO NetRise, told The Register.
NetRise bills itself as an “extended IoT” (xIoT) security firm.
“Just because these attacks have not been detected does not mean that they haven’t happened,” Pace continued. “We know for a fact that threat actors are exploiting known vulnerabilities across industries. Critical infrastructure is no different.”
The report also added that, “generally speaking,” criminals exploited the security holes “at lower levels than many experts predicted, given the severity of the vulnerability,” which seems to be a fair assessment of Log4j.
But still pretty costly
That said, it still cost organizations a lot of money and human resources to, first, identify their usage of the logging library in their own products and then in their suppliers’ software, and then mitigate the risk. One federal cabinet department spent 33,000 hours on its Log4j response to protect its own networks, the report said.
“These costs, often sustained over many weeks and months, delayed other mission-critical work, including the response to other vulnerabilities,” according to the dossier.
Additionally, dealing with Log4j also contributed to cybersecurity professionals’ burnout — an ongoing and well-documented problem even before the bugs.
Unfortunately, this particular risk is going to plague companies and federal agencies for the foreseeable future, the report warns. “The Log4j event is not over,” it said. “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.”
In other words: security teams can look forward to getting some sleep around 2032. Maybe.
The good news is that the report provides 19 recommendations for organizations on how they can address ongoing Log4j risks. Some of these are fairly common sense. Businesses should proactively monitor for and upgrade vulnerable versions, and report any Log4j exploits to CISA, it says.
How to secure open-source software
Also: invest in tools such as automation and scanning that identify vulnerable systems in real time and keep a complete inventory of IT assets and applications.
Of course, the nature of software dependencies and supply-chain attacks like Log4j — or even the earlier SolarWinds and Kaseya attacks — can make this a daunting task.
“With Log4j, preventing the entire class of bugs that cause it is going to be hard with today’s technology, but stuff like fuzzing and safe-by-default language/library design can help a lot,” software supply chain security shop Chainguard CEO Dan Lorenc told The Register.
“But the full exploit still required the library to be running in an environment with significant permissions, many of which were unlikely needed,” he added.
“The exploit required little used JVM features to be enabled,” Lorenc said. “The full RCE version required external network access. If you don’t need either of these, and disabled them, you’d be fine.”
The report also recommends measures to secure the larger open-source software ecosystem, and points to organizations including OpenSSF, Open Web Application Security Program and The Open Source Software Security Mobilization Plan that provide training, audits, developer tools and other services to assess projects’ risk.
Google Cloud VP of Infrastructure Eric Brewer said this section, in particular, resonates and is an area where Google has invested heavily.
“The vast majority of modern software development makes use of open source software, including that incorporated across critical infrastructure and global security systems,” Brewer told The Register. “Collectively securing open source across the entire community has never been more important, especially with the importance of digital infrastructure.”
Automation, frameworks and more money
He recommends enterprises identify a critical open source package list to better prioritize their security-related investments, and then set security, maintenance and provenance goals for critical projects.
Additionally companies should develop automated scorecards to measure progress toward these goals and frameworks for attestations — conveniently, Google already has one such supply-chain security framework called SLSA.
Finally, Brewer and the cyber review board say industry and the federal government need to invest more resources in open source security and project maintenance. ®
Discussion about this post