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”:
Identify whether your organization is impacted:
Get a list of vulnerable products: This is a growing list, so that’s not as easy as it sounds. One such list can be found here, but is not guaranteed to be complete, and there are many others. It is notable that some systems, such as the Epiphany Intelligence Platform, while using this library, are not susceptible to the vulnerability based on several factors.
Get an internal asset/application inventory: Many organizations have enormous difficulty learning what really is in their environment. Plus, what if there are connected devices running in your environment that leverage this library? There could be a repeat of a hack starting with something as benign as a fish tank temperature sensor, which occurred at a casino several years ago.
Patch the affected assets:
It’s not just as simple as installing the latest version ofLog4j (lest you risk breaking something). Many of the vulnerable assets require that the manufacturers release a patch for their product or application. At the minimum it means:
Waiting for the patch
Testing the patch in your test environment
Scheduling and emergency patch window
Preparing for possible rollback procedures if the patch breaks something (which often includes some sort of lengthy backup. But let’s be honest, patches never break things ☺ )
Validating efficacy of the patch deployment
Validating proper function of the patched asset
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.
Why you must have an Epiphany
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.
The platform can help you locate the assets that are using a specific package, such as Log4j (using the app name (apps=VulnerableApp OR Log4j*) and the device path indicator (in_path=True).
Additionally, you can designate assets with the Log4j library as exploitable in the platform. What this does is allows the Epiphany Intelligence Platform to develop paths an attacker can use to get to those assets (or through them to something more valuable).
Lastly, you could do nothing. By default, the Epiphany Intelligence Platform automatically analyzes vulnerability scanner and endpoint data for the Log4j package. It then identifies the level of exploitability, mapping out attack paths that can be used to compromise assets designated as “The Crown Jewels” of the organization. Moreover, it prioritizes the attack paths based on factors such as friction via presence of security tools or other countermeasures. In this case our platform would automatically see the Log4j package as a vulnerability and take that into account, displaying this in the portal along with any exploitable attack paths that could exist as a result.
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.