As mentioned in previous blogs, the “Log4shell” zero-day is an ever-moving target and this, in part, is due to the scale of the issue. Log4j is very popular and its usage is extremely widespread. Its popularity significantly multiplies the usual challenges faced when dealing with any zero-day exploits. So, what are those challenges, and how are the team at Options dealing with them?

  1. Determining the size of the problem – First of all, knowing what to look for and where to look is critical. Once you have identified what you are looking for, you can then systematically and repeatedly scan and report on the systems that need to be patched, fixed, or removed.
  1. Tackling the problem – Once you have identified what needs to be done, you need to create a strategy to execute this. This involves taking the (often vast amounts of) data and parsing it to know what and how to prioritise and/or what to ignore.

With 10’s of log4j versions, 100’s of clients, 1000’s of applications embedded with log4j, and 10,000’s of devices to scan you can see the scale of the issue companies across the globe are facing. At Options, we have relied heavily on our DevOps and Software teams to automate the process of defining, building, scheduling, and implementing the scan jobs.

Applying the right logic to this data set is the key. For example, we know there are multiple versions of log4j in the wild, some are deemed vulnerable, some are not (but this is complicated as they are so old they are likely to be vulnerable in other ways) and some have different mitigation strategies.

We see little or no pattern in terms of the spread of versions, but we often see multiple versions installed on a single host. One of the major strengths and weaknesses of Java (depending on your point of view) is its portability and as such we also find .jar files (and in particular log4j-xxx.jar files) littered all around the file system – knowing which are actively in use by applications is a challenge.

By applying a deep learning model to this data, we can make useful predictions on where log4j is actively in use and which is the best mitigation strategy to be deployed.

This is, without doubt, a serious global vulnerability (“It is by far the single biggest, most critical vulnerability ever.” – Amit Yoran, Tenable (source: The Next Wave of Log4J Attacks Will Be Brutal | WIRED)) and we are using teamwork, automation and AI to supercharge our response.

To learn more about Options Managed Security offering, click here.

  • Options InfoSec Committee.

You are currently viewing <strong>Log4Shell – Log4j Exploit – Team Work, Automation and AI</strong>