Log4j Vulnerability and the Complexity of Modeling Cyber Risk

The cybersecurity world has turned its focus to the discovery of a vulnerability in Log4j, a Java library for logging error messages in applications. Log4j is widely used in enterprise Java software, from well-known major vendor software applications and services to software developed in-house. Everyday users see Log4j in action when an application generates an error message, alerting the user to the error on screen, logging the error, and in some instances, giving feedback to the software vendor with details about how the error arose. These error logs are used by programmers to debug software and monitor operations or critical alerts.

Cybersecurity centers in countries across the globe have largely spoken with one voice about the seriousness of the Log4j vulnerability. This is an issue we can’t ignore right now, as highlighted by established players including Crowdstrike, Tenable, and Cloudflare. Headlines are saying: “The internet is on fire right now,” and “…the single biggest, most critical vulnerability of the last decade,” or “…hard-pressed to think of a company that’s not at risk.” How did it get to this?

What Is Log4j?

The vulnerability was first reported to Apache, the developers of the open-source software, on November 24 by a member of the Alibaba cloud-security team. Chen Zhaojun from Alibaba described how Log4j could be used for remote code execution (RCE), allowing an attacker to remotely take over a computer without the need for a password to access. At present, we’re talking about what security researchers are calling Log4Shell, and a vulnerability found in versions 2.0–2.14.1. The vulnerability can be exploited with carefully crafted messages by attackers and has a Common Vulnerability Scoring System (CVSS) score of 10.0: the worst category of all.

Exploits started from December 1 as botnets turned their attention to the vulnerability. Commentators are stating that there could be more than 100,000 applications that use Log4j, and the exploits are wide-ranging – here is a link listing the major impacted applications. Examples of how the vulnerability could be used include hacking into iPhones to change the person’s name on the device and switching a Minecraft server into one that plays Doom instead.

The volunteers that support the open-source Apache software have currently released two patches, but there is a mammoth task ahead to first identify and then roll out patches to every affected application. Due to the broad network exploitation and the nature of the vectors through which this vulnerability (CVE-2021-44228) can be exploited, applying remediations holistically across all platforms will take time. Many market vendors including Palo Alto, CrowdStrike, etc. are recommending looking out for signs of post-exploitation rather than fully relying just on prevention.

Implications for Cyber Insurers

For the insurance industry, there are many questions. How big is this problem, what does it mean for the industry, and how can cyber risk be modeled?

Let’s start with the size of the problem – how big is it? Java is a hugely popular application protocol, with Log4j probably the most popular logging tool used within this suite of tools and embedded into plenty of other tools from Apache. The tool (and vulnerability) is prevalent in many SaaS applications, server installations, corporate end-points – all the way to software commonly found on personal devices. Cybersecurity company Bitsight reports they have identified the vulnerability in around 34 percent of companies they have assessed. 

What does it mean for the insurance industry? Right now, it’s hard to say. The recovery is in progress, as corporations, software companies, and individuals are patching and remediating this exposure at a frantic pace. But there is a race with the criminal gangs and threat actors that are scanning the internet to find who is vulnerable, accomplish limited attacks, develop ransomware tools that can exploit it, and more worryingly, try to develop worms to carry out self-propagating attacks. 

It is inevitable that the insurance industry will carry loss for what is about to occur – but defining what is about to occur is currently unknowable. The longer it takes before material attacks are successful and/or a successful worm is developed and deployed, the more the event will be mitigated. If this takes some time, then the event will just be another driver of attritional claims, almost indivisible from the current wave of ransomware activity.

Whereas, if the exploits are weaponized into a worm, then soon enough this could well be the “Hurricane Andrew” moment that cyber (re)insurers have feared. To continue the hurricane analogy, this is similar to observing what could be the largest tropical depression on record forming near the Azores. It has the potential for enormous destruction, but if it doesn’t “make landfall” then there is limited concern or loss.

How Can Cyber Risk Be Modeled?

The (re)insurance industry is more than aware of the potential for huge systemic losses in cyber. This fear is one of the reasons why capacity has been slow in coming to this key market. Looking at systemic events from a modeling perspective can be interesting. Conceptually, cyber catastrophe events can be boiled down into single aggregating causes of loss. However, these single points are not easy to measure and distill into simple, single parameters and concepts. So, what the Log4j event teaches us before it has even unfolded is that cyber risk is highly complex and resists being boiled down to simple scenarios – but it is still very much modellable.   

This focus on a single point of failure does not capture all the risks present. Instead, we need to think more broadly about vulnerability-based cyber catastrophes. We can define four possible routes:

1.            There is a “classic” single point of failure event when a vulnerability is exploited in a single piece of software (such as in supply chain or worm-based attacks).

2.            The use of an exploit kit to leverage multiple vulnerabilities and widen the potential footprint of the attack surface. The exploit kit is the common element, though the vulnerability space might be multifaceted.

3.            There’s another take on the principle of the exploit kit, where multiple vulnerabilities are needed to gain access, escalate privileges, then achieve remote code execution. The exploit kit is once again the common node, and the footprint is the cross-section of the vulnerabilities required to make the attack. 

4.            As with Log4Shell, a vulnerability is found/attacked in a common component part of an application toolkit, meaning the vulnerability can be found in thousands of different software programs. This is still a common single route cause, but it’s hard to measure explicitly because it is a sub-component level.

These four routes to a cyber catastrophe highlight both the infancy of solving this problem and two different problems the (re)insurance industry faces:

• Building robust models that define the risk for the (re)insurance industry
• Using technographic data on insureds to achieve portfolio diversification

For the first problem, at RMS® we believe that the maturity exists for this to be achieved. Our modeling of vulnerability-based risk explicitly factors in these four causal routes of propagating malware. We use a treasure trove of data to calibrate our models, including how different combinations of vulnerabilities could be used to attack different sets of companies and how the capability and motivation come together with these vulnerabilities. Without factoring in all four of these routes, our view of the frequency and severity (and how they interplay) would be woefully under-considered.

We are not yet at the stage of pointing to a scenario in the RMS catalog of events and aligning one as the best representative of Log4j – any catastrophic attack on Log4j has yet to occur. But once it happens, we can look through our catalog of events and consider which one, or more, best represents the available population characterized by reality. And the longer this takes, then the more vulnerable systems will be patched and that available population will decrease – exactly as our models would behave.

Regarding the second problem, around diversification, at present, we do not believe the data requirements can be met to achieve this goal. As Log4j demonstrates, there are just too many potential avenues for a cyber catastrophe event to occur for us to explicitly measure all the pathways with the required level of confidence or meaning. Without this, we cannot achieve any significant measurement of diversification.   

If only the first route (as described above) existed for cyber catastrophes to propagate – and the data existed for us to confidently understand the technographic footprint of every organization – this could be boiled down into a measurable problem. However, neither one currently exists. Over-optimization of data and models is a very real problem in cyber right now. One needs to understand at what level the data and models are meaningful – and optimize to these outputs. Anything else risks dangerous decisions, with the added blow of thinking you’re doing the right thing while you’re actually doing the opposite.

The depth of data exists for us to build robust models that provide a useful and consistent framework for assessing the risk and capture the dynamics of how vulnerabilities emerge and are exploited. These models can be resolved to a sectoral/revenue-band level, but they cannot be meaningfully resolved at a level more precise than that – yet.

It pays to be realistic with regard to cyber risk modeling, and for Log4j – like the tropical depression out in the Atlantic – it pays to understand the best- and worst-case scenarios and revise as more information emerges. Find out more about RMS Cyber Risk Models.

RMS has reassured clients with regards to any potential exposure to Log4j, clients can access more information on RMS OWL.