Log4Shell vulnerability discovery and mitigation require automatic and intelligent observability

Log4Shell has made applications and devices worldwide susceptible to attack. But many organizations have realized their traditional application security tools can’t address it. Log4Shell serves as a reminder that vulnerability monitoring in production must be a priority.

Since the Log4j vulnerability CVE-2021-44228—or Log4Shell—emerged in early December, security teams have faced great pressure to identify and remediate it.

Log4Shell is a software vulnerability in Apache Log4j 2, a popular Java library for logging error messages in applications. The vulnerability enables a remote attacker to take control of a device on the internet if the device runs certain versions of Log4j 2.

Log4Shell is categorized as a zero-day vulnerability, and malicious actors likely knew about and exploited it before experts did. Since it emerged, millions of applications and devices have been targets of cyberattacks seeking to exploit this vulnerability.

As soon as the Apache Foundation started issuing patches of Log4j on December 9, organizations have been scrambling to assess and remediate their highest-priority targets, including their web- or customer-facing applications.

Some organizations put a complete stop on developer activity and turned company codebases upside down to look for and patch Log4Shell. As soon as teams started, however, Apache found another critical vulnerability, CVE-2021-45046, and yet two others, CVE-2021-45105 and CVE-2021-44832, a few days later, which caused IT security pros to restart their process.

Three critical questions teams must answer about Log4Shell

There are three key questions that, while seemingly simple, have been difficult for most organizations to answer:

• Are we affected?
• At what scale?
• How do we prioritize where to start remediation—and quickly?

There are two ways to address these questions: the approach using traditional application security tooling, and the approach using automatic and intelligent observability in modern hybrid, multicloud environments.

Traditional application security approach to mitigating Log4Shell

The traditional approach to determining whether the Log4Shell vulnerability affects an organization is to perform static analysis, known as software composition analysis or SCA, on code repositories.

Are we affected?

SCA indicates whether an organization’s source code contains the vulnerable library. A simple way of conducting SCA analysis is with dependency scans that use open-source tools such as Gradle dependencies or the OWASP dependency check. See the OWASP Component Analysis site for more on SCA and a list of commercial tooling.

These checks indicate the extent to which Log4Shell affects source code or build artifacts, which enables developers to systematically remediate these vulnerable libraries. However, SCA solutions commonly produce many false positives, so teams should be prepared to investigate further before implementing remediation plans.

At what scale?

The traditional approach to mitigating a vulnerability is to look for the number of occurrences across repositories. While this is relevant, it does not reveal the impact or scale of these occurrences, or whether the vulnerable library exposes risk in production versus preproduction environment. Thus, the crux of the “Are we affected?” question is answered inconclusively.

How to prioritize where to start remediation?

Once teams have identified what is affected, they next need to prioritize which targets to address first. Teams might know which projects and repositories are most relevant, but with traditional application security approaches, it is almost impossible to get a unified, easy-to-digest overview of the priorities. This lack of precision can delay a team’s response and force them to use a best-guess approach and spend valuable time investigating, verifying, and prioritizing which systems are the most critical to patch first.

While this approach can work in less complicated environments, it also often results in delays and elevated risk as teams investigate and verify their vulnerability status and develop their priority focus areas, as well as mitigation plans.

The modern observability platform approach to mitigating Log4Shell

A modern cloud observability platform with integrated AIOps offers a more holistic approach. Going beyond simple scanning, it continuously monitors for vulnerabilities and automatically tracks dependencies. As a result, security and cloud architecture pros get access to a real-time topology model that maps all relationships between core assets in an IT environment and tracks key behavior. Integrated AIOps capabilities effortlessly help teams to prioritize the next actions to take in the face of threats or anomalies.

Are we affected?

With a real-time picture of loaded libraries in runtime environments and a continuously updated, end-to-end topology of their dependencies, teams can get a clear and immediate view of what systems are affected, whether they expose risk in production and their overall priority.

Now let’s look at the automatic and intelligent observability approach in action using Dynatrace. Only a few minutes after CVE-2021-44228 was published, the Dynatrace Application Security Module identified its presence in production environments around the world.

As depicted below, Dynatrace OneAgent automatically and continuously monitors any runtime for vulnerabilities and provides a conclusive answer to the question “Are we affected?”

At what scale?

If a team can identify this vulnerability with precision in a production or preproduction environment, they can determine the answer to the next question “How bad is it?” or “At what scale are we impacted?” Again, Dynatrace’s automatic and intelligent observability approach provides a conclusive answer, and immediately identifies how many JVMs have the vulnerable library loaded.

In the example depicted below, the remediation tracking view clearly identifies nine services affected by the vulnerability. Teams can drill down to learn more details about each affected service. This list also becomes a remediation manifest as teams resolve affected systems.

Having a live topology model, such as Dynatrace Smartscape, gives teams an instant overview of all components and dependencies related to the vulnerable runtimes.

The following example shows 32 entities related to the affected systems, including services, hosts, Kubernetes workloads, and clusters.

Teams can drill down into these entities to learn exactly what is affected and where. The following example shows a drill-down view of five related container images.

How to prioritize where to start remediation?

When focusing on a single vulnerability such as Log4Shell, the emphasis will naturally be on processes (JVMs) exposed directly or indirectly to the public internet, and which processes access sensitive data assets. Following the example from the “Process View Overview” screenshot (three images above), we would start with process group No. 7, Tomcat.

Security teams generally use the CVSS score to weigh the severity of a vulnerability. For Log4Shell, with the highest severity rating of 10, this means every affected system would be a top priority to fix. The Davis Security Score, on the other hand, automatically takes a system’s context and exposure risk into account and assigns a score based on real-time, run-time risk. This automatic scoring enables teams to easily prioritize their remediation strategy.

The example below clearly summarizes the most critical vulnerabilities to address first. Once you know which systems take priority, your teams can quickly identify the owner and route a ticket their way.

Why the Log4Shell vulnerabilities need modern observability

Organizations around the globe are spending an enormous amount of time and energy reacting to Log4Shell. Because the situation is still unfolding and Apache has issued additional patches for new vulnerabilities since the first one on December 9, teams will likely have to redo their efforts. The modern automatic and intelligent observability platform approach to application security helps facilitate this remediation cycle and tells you in an instant:

• Are we affected?
• To what extent?
• Where do we start?

To learn more about how the Log4Shell vulnerability works and how to mitigate it, check out the following resources:

• What is Log4Shell? The Log4Shell vulnerability explained (and what to do about it) blog
• Log4Shell: Identifying and minimizing production risk blog
• Log4Shell vulnerability: Identifying and minimizing production risk webinar
• Log4j vulnerability (Log4Shell) Dynatrace security alert
• Dynatrace Log4Shell resource center webpage