(ISC)2 study finds long remediation times for Log4Shell

Remediation of the critical Log4Shell vulnerability presented time-consuming challenges to many security professionals, according to a new study from (ISC)2.

The nonprofit published a survey this week that polled 269 cybersecurity practitioners to examine "the Log4j vulnerability and the human impact of efforts to remediate it."

Log4Shell is the name of a critical flaw in Log4j, a Java logging tool commonly used across many sectors and platforms. The vulnerability was first disclosed in December and was quickly exploited as a gateway for threat actors. The purpose of Log4j is to log files, but as infosec expert Michael Cobb pointed out for SearchSecurity, "Applications and systems log a lot of information, which means there are numerous vectors attackers can use to make a Log4j record the attack string."

Jon France, CISO of (ISC)2, said that while the vulnerabilities may be widespread, not every version of Log4j is the same and has the same vulnerability.

"Not all versions are vulnerable; only the Log4j-core JAR file and applications using only the Log4j-API JAR are impacted," France said. "Which version is in use and how it is deployed determines if the application is vulnerable. This adds complexity in the qualification of whether a particular deployment is vulnerable, especially if software is developed in-house, as it requires thorough inspection."

(ISC)2's report said while there is no exact timetable for "the fallout" of the Log4j exploitations or what the long-term impact will be, if cybersecurity teams are staffed well enough and have the resources, they should be able to handle the vulnerabilities.

But the organization acknowledged that not all companies have the same IT staffing and noted "the flaw is found in one of the most commonly used pieces of software, thus, it could potentially impact billions of devices."

The survey was broken down to the quantitative responses of the cybersecurity professionals and the qualitative ones they also provided.

One qualitative response provided in the report said Log4Shell represented a "wake-up call" for the infosec community because the Log4Shell software is so ubiquitous.

The "wake-up call" involved weeks of remediation, including overtime for many of the cybersecurity teams that responded to the poll. According to the (ISC)2, "52% of respondents said their team collectively spent weeks or more than a month remediating Log4j and nearly half (48%) of cybersecurity teams gave up holiday time and weekends to assist with remediation."

France described why it might take so long to patch Log4Shell.

"As with many vulnerabilities, evaluating where and how it will affect your business and systems is key," France said. "This discovery process is unique to each organization's architecture and deployment, so it can take some time. Identification of Log4j API across third-party SaaS was likely the most time-consuming part of the process for many organizations."

Complicating matters for security managers and network administrators was the fact that additional Log4J vulnerabilities were discovered after the Log4Shell disclosure. The issue caused by searching for and patching potential vulnerabilities was not just the time needed to be spent on Log4j, but the attention that was taken away from all the other areas that the security teams are responsible for.

According to the report "as a result of the reallocation of resources and the sudden shift in focus that was required, security teams report that many organizations were less secure during remediation (27%) and fell behind on their 2022 security priorities (23%)."

An issue raised by some of the respondents was how short-staffed their cybersecurity teams are.

"Several capabilities could be improved if their organizations weren't short-staffed, such as available time for risk assessment and management (30%) and speed to patch critical systems (29%)," the report said. "While cybersecurity teams need to prioritize activities to maximize the efficiency of their operations, a shortage in team resources can exacerbate the challenge of having many priorities at once."

While the threat of Log4Shell still looms, there were some positives in the survey results, as the poll found general confidence among the cybersecurity professionals in the overall response to the vulnerability. "According to the (ISC)2 poll, 64% of cybersecurity professionals believe their peers are taking the zero-day seriously."

France also outlined some best practices for IT security teams to be better prepared for another potential vulnerability stemming from Log4j and similar software.

"IT security teams must know where their assets and systems are -- you can't profile, protect or fix what you don't know exists," France said.  "It is also beneficial to have good relationships with your vendors and supply chain, alongside being on the lookout for patches and alerts for the software and services you use. Operate good hygiene within your estate [with] patching and scanning. There are general improvements in vulnerability scanning and DevSecOps SAST/ DAST programs and capabilities that enable you to detect these ahead of being placed into production. It's critical to have a well-exercised plan to deal with zero-day vulnerabilities, like Log4j. This is not about knowing where or when the next vulnerability may appear, but knowing how to approach and appropriately respond."