Log4j Isn’t the Once-in-a-Decade Risk That Was Initially Feared

After more than a month of intense research since the critical Log4Shell/Log4j vulnerability (CVE-2021-44228) was first disclosed, we now have a clear understanding of the magnitude of this new exposure in the mid-market. At-Bay has concluded that, despite the widespread popularity of the Java library, Log4j is NOT a once-in-a-decade vulnerability capable of causing catastrophic loss, as was initially feared. 

Early estimates projected as many as 58% of all organizations to be using a system vulnerable to Log4j.

However, after identifying the practical risk of Log4j in our portfolio, we determined that only 0.5% of the mid-market is vulnerable.

Identifying Practical Risk

As an insurance MGA we are interested in reducing the most risk for the most organizations. In the mid-market, cyber criminals are not targeting specific organizations; they’re running internet-wide scans looking for critical vulnerabilities and then attacking what’s found. So, when looking at the risk presented by Log4j, we consider how many organizations could be identified and exploited by an attacker specifically seeking to use a Log4j exploit.

While it may be true that more than half of all organizations use a system that runs Log4j, the practical risk presented by the Log4j vulnerability shrinks if we only account for organizations that can be identified and exploited by an attacker outside the network perimeter.

Soon after the disclosure of Log4j, we built a new capability into At-Bay’s network perimeter scan to identify if an organization can be exploited by the Log4j vulnerability. Based on the exposure in our portfolio, we estimate 0.5% of organizations in the mid-market to be vulnerable.

The exposure rate of 0.5% is still significant and comparable to other critical vulnerabilities we regularly manage in our underwriting process, such as ProxyLogon and EternalBlue, and will be classified similarly. Remediating any system vulnerable to Log4j is crucial, but organizations must not divert attention from other common attack vectors. Remote Desktop Protocol (RDP) remains the leading cause of ransomware incidents, responsible for nearly 50% of all attacks — and we do not anticipate this changing anytime soon.

Larger Organizations Face Greater Risk

The data clearly shows that the larger an organization is, the greater its likelihood of exposure to the Log4j vulnerability. Organizations with more than $100 million in revenue are 5.5 times more likely to be exposed to Log4j compared to the average.

This finding is not surprising, as larger organizations tend to have larger technology stacks and, thus, a greater chance of using a system that is both vulnerable to Log4j and identifiable through external scans. 

Educational Services is the Most Vulnerable Industry

We discovered Educational Services is, by far, the industry most exposed to Log4j — twice as likely to be vulnerable as the next industry. Organizations in Educational Services (schools, colleges, training centers, etc. NAICS: 61) are 6 times more likely to be exposed to Log4j compared to the average, while organizations in the Information industry (publishing, broadcasting, telecommunications, etc. NAICS: 51) are 3 times more likely to be exposed.

Log4j Attack Vectors

Exploits have been published for 11 software products to date, all of which can be detected by our scans. These products are at the highest risk of exploitation, even amateur hackers target these products in an attack, since an exploit has already been proven and published. Therefore, we are concerned that many instances of those products are still unpatched in the mid-market a month after disclosure of the vulnerability. 

Our approach to Log4j going forward

Log4j isn’t as big of a risk as first thought. The number of available targets in the mid-market for hackers to exploit is relatively low, which presents less opportunity for cyber criminals and explains why there have been few reports of breaches to date.

At-Bay is now automatically scanning every organization for vulnerability to Log4j at the time of issuing an insurance quote. Any organization that is vulnerable will be required to mitigate the issue prior to purchasing the policy, similar to other critical vulnerabilities.

Importantly, we are not adding any coverage restrictions related to Log4j that would detract from quality of coverage, nor will we add any additional burden on the insured company or its broker in the form of new questions or application requirements.

The majority of organizations we see in the mid-market do not have the technical understanding or resources to accurately attest to whether they are using a system running a vulnerable version of Log4j and whether they have taken all required steps to remediate. This half-measure is what most cyber insurance carriers are asking of their customers in their insurance application post-Log4j. Furthermore, attempting to exclude claims that originate from a Log4j vulnerability is perhaps even more unrealistic and will only result in extensive litigation, if it’s even enforced, as attack origination is nearly impossible to confirm with certainty. 

Log4j remains a critical vulnerability for the companies that are exposed, and we are actively working with our portfolio companies to mitigate those at risk. Through our active risk monitoring services, we have already confirmed 66% of vulnerable companies we insure have patched, and we are actively working to help the remaining update.

The operating system we built specifically to manage risks like Log4j worked exactly as intended. Within a matter of days, we were able to both identify and start mitigating the exposure on our book and start screening for vulnerable organizations during the underwriting process. 

We are ready for the next Log4j.

For inquiries regarding research and methodology, please contact Jackie Gray at jackieg@at-bay.com.