Why the Log4j vulnerability is worse (and more difficult to fix) than you think.
Unless you have been disconnected from the world, you’ve seen recent headlines about Apache Log4j. The problem is that while many now have heard of it and have seen the term ‘Log4Shell’, the depth and breadth of the risk is still not fully known by most.
As the situation develops, Epiphany Systems is committed to helping you assess the potential impact to your organization. If you’re a customer of Epiphany Systems, we will identify inventory data about which applications might be impacted.
Log4J is a library written in Java which allows developers rich event and error logging features. While this sounds simple and benign, creating good logging is not as simple as one would think — moreover, the level of privilege required to monitor an environment to create useful logs is quite high. To provide an overly simplified example, consider the concept of needing to monitor the details of how a mission critical process is running. In order to audit this process, you need to operate within the same security ring. If said processes are fundamental components of a hypervisor, such as VMware (which is susceptible to this vulnerability), this means if you can exploit a weakness in the logging library, you are effectively running at the same permission level as the most critical components within the hypervisor.
In addition to hypervisors, backup systems, phone systems, uninterruptible power supplies, network devices, and even security appliances use this library, making several of them vulnerable and exploitable.
Now that you have context of the gravity of the risk, how do you address it?
I challenge you to find an article that doesn’t say “patch everything, yesterday!”, which is the common industry response that has caused many sleepless nights for security teams but has not done much to actually reduce the risk to your organization. Consider these “simple steps”:
If you are running multi-tiered applications where you have more direct input into the libraries, you will have to test the updated Log4j library against the application in a test environment and go through an exhaustive validation process to ensure functionality hasn’t been lost.
While it’s a prudent practice to patch all vulnerabilities, the Epiphany Intelligence Platform has many ways to help you focus on the paths that matter most by allowing you to locate systems that are in direct danger of exploitation. Epiphany builds attack paths and finds risks to help you assess where to focus your efforts to respond to something like Log4j. It dramatically simplifies the landscape and provides you with decision intelligence — which, among other things, affords you the insight as to what to patch first.
As with any vulnerability, Epiphany seeks to find attack paths to valuable targets that could create a material event for an organization. So, even if Log4j is on a system, if it can’t be used to reach a valuable asset and create a material event, no attack path exists. The platform will however keep a list of the vulnerable systems so you can continue to differentiate between vulnerability and exploitability. Starting with what’s exploitable versus what’s vulnerable is the key to optimizing your security operations activities.
There are many ways Epiphany Systems can help, not only with Log4j but other security issues that are sure to make future news cycles. Please contact us to learn how.