Highlights:

  • Log4j attacks and vulnerabilities can persist for around a decade or longer.
  • The report also makes recommendations on how organizations can address ongoing Log4j risks.

According to the US Department of Homeland Security, risks associated with Log4j vulnerabilities can go on for “a decade or longer.”

In its initial study, the DHS Cyber Safety Review Board analyzed the now-infamous vulnerabilities found late last year in the Java community’s open-source logging library. Because Log4j is used in a wide variety of contexts, including cloud services and enterprise applications, the bugs proved beneficial to hackers. As a result of this, malicious actors quickly began taking advantage of the vulnerabilities to engage in a wide variety of illegal activities, such as installing coin miners, stealing credentials and data, and deploying ransomware.

The Minimal Criminal Exploitation 

Surprisingly, the cyber review board “is not aware of any significant Log4j-based attacks on critical infrastructure systems,” stated the report. However, many security professionals are skeptical.

The report added, “generally speaking,” criminals took advantage of 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.

Costly Investment

Still, a substantial amount of money and time is required by businesses first to identify their use of the logging library in their products and, second, in the software of their suppliers, and then limit the risk. According to the report, one federal cabinet department spent more than 30,000 hours on its Log4j response to protect its networks.

The report states, “These costs, often sustained over many weeks and months, delayed other mission-critical work, including the response to other vulnerabilities.”

Having to cope with Log4j was another factor that contributed to burnout among cybersecurity specialists, which was an ongoing and well-documented problem before the problems were discovered.

Unfortunately, the report warns that this particular risk will plague companies and federal agencies for the foreseeable future. “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.”

The report concluded that the vulnerability associated with Log4j is endemic and that vulnerable instances of Log4j will continue to exist in systems for many years to come, most likely for a decade or even longer. “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.”

This means the danger is still present, and security teams must look forward to relaxing a bit around 2023. Maybe.

On the positive side, the report gives 19 recommendations for organizations on how they can address ongoing Log4j risks. All Log4j exploits should be reported to CISA, and businesses should perform active monitoring and version upgrades for vulnerable versions.

Ways To Secure Open-Source Software

It is prudent to invest in automation and scanning solutions that can discover susceptible systems in real-time and maintain a comprehensive inventory of IT assets and apps.

Nevertheless, software dependencies and supply-chain attacks, such as Log4j or the previous SolarWinds and Kaseya hacks, may make this endeavor difficult.

Software supply chain security shop Chainguard CEO Dan Lorenc, said, “The exploit required little used JVM features to be enabled. 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 suggests the adoption of measures to secure the larger open-source software ecosystem and point users to organizations such as OpenSSF, Open Web Application Security Program, and the Open-Source Software Security Mobilization Plan that offer training, audits, developer tools, and other services to assess the risk posed by individual projects.

Eric Brewer, Google Cloud VP of Infrastructure, said, “The vast majority of modern software development uses open-source software, including that incorporated across critical infrastructure and global security systems. Collectively securing open source across the entire community has never been more important, especially with the importance of digital infrastructure.”

More Security-related Investments

To better prioritize security-related investments, businesses must first identify a critical open source package list and then establish security, maintenance, and provenance objectives for essential projects.

In addition, businesses should establish automated scorecards to monitor their progress toward these goals, as well as frameworks for attestations. Conveniently, Google already possesses such a supply-chain security framework, and it is called SLSA.

In conclusion, Brewer and the cyber review board believe that the private sector and the federal government need to increase the number of resources they invest in maintaining open-source projects and ensuring their security.