A look back at Log4j shows fast reaction, slow remediation

It’s perhaps no surprise that when somebody comes up with a great fix in life, few people actually use it—many a Scrub Daddy, Squatty Potty, and Rapid Ramen Cooker stay sealed and unopened, despite being upgrades to their predecessors.

In the security space, better versions of products are released all the time, at high speeds, and customers still need to be convinced to adopt them.

When a security engineer in late 2021 discovered a vulnerability in the open-source Java-based logging framework known as Log4j, the response was swift. A fix was up for review five days after the November 24 finding, and the Log4j upgrade was available by December 10.

That’s prompt patch-making, but a number of organizations have taken a slower approach to deploy the update. Log4j is integrated into millions of computer systems, including ones used by governments, but many companies still lack asset management and patch-testing practices that remediate the security threats caused by outdated versions of Log4j—or any outdated software, for that matter.

“We’re not stuck on the identification of a problem. We’re really stuck on configuration and change management, and then creating a process there for teams that allows them to do that in a reasonable timeframe,” said Rick McElroy, principal cybersecurity strategist at VMware.

Collaboration congratulation. As for the identification of the problem, the Cybersecurity and Infrastructure Security Agency (CISA) praised early Log4j support efforts. In its July 2022 report, the department lauded vendors’ rapid advancement of threat information and the nonprofit Apache Software Foundation’s well-established software development cycle.

Yet organizations struggled to respond, said CISA, citing a slow response as companies weighed a classic IT debate: patch deployment vs. possible downtime. “The hard work of upgrading vulnerable software is far from complete across many organizations,” reads CISA’s research.

Read the rest here.