Preparing For the Log4j Long Haul: How to Mitigate Log4Shell Risk

It has been several months since the discovery of the pervasive Apache Log4j / Log4Shell vulnerability, but the end of managing this threat is not yet in sight. Moderate estimates predict that security teams will continue to manage this vulnerability and the associated risk for years to come. Although software vendors have issued thousands of updates with patches to the vulnerability, there are potentially millions more instances where the flaw will likely take months and years to be patched—or never fixed at all. 

There are two main issues contributing to the longevity of this vulnerability: firstly, the broad-scale adoption of the Log4j open source Java logging library, and secondly, the difficulty of identifying where it is currently in use. Even security vendors are still discovering previously-unknown instances of Log4j layered within their products and the long list of unsupported software used by other developers offers no hope for security teams depending on updates alone. 

Making matters worse, the Log4j vulnerability enables remote code execution, providing easy access for attackers to gain control and carry out their goals. Unlike vulnerabilities that enable only a limited subset of attacks, Log4Shell exploits work like universal keys that will open up the door to anyone, adding to the bitter reality that unpatched instances of Log4j can still be found across nearly every organization in the world.  

Most security teams jumped on the response to the Log4j crisis when the news first came out and set about mitigating the Log4Shell flaw by scanning their environments, isolating discovered instances, and installing updates where applicable. If this sounds like your organization, kudos to you for all the hard work you’ve already done! But you are not in the clear yet, and unfortunately, there is still a hill of dark discoveries to climb before your SOC team will have full control over the situation. The many exploits we have seen so far will be followed by more sophisticated threats that will have a larger impact on the organizations they target. To prevent your organization from being compromised by this vulnerability, you’ll need to develop a strategy to mitigate risk and improve rapid detection, isolation, and response to these types of threats. Start by following these critical steps:

Establish a complete asset inventory

You must account for every asset to stay one step ahead of the most recent exploits by quickly installing the latest updates. In addition to continuously monitoring your external applications, you need to examine your in-house applications that use Log4j libraries and keep them updated, and look for scheduled batch jobs and other common sources that you may have missed during your initial scanning activities. A complete inventory of your assets will help you streamline the process of efficiently tracking and implementing new updates.

Develop a proactive plan

As you work to align your organization for the long-haul marathon to come, the highest imperative is to continuously identify and update all vulnerable systems and applications in your environment as quickly as possible. Assist your team in discovery by updating your SIEM rules and conducting regular threat hunting activities to detect new exploits and active threats and subscribe to trusted information sources for the latest notifications and best practices to help inform your strategy and improve your plan.

Implement zero trust 

Eliminating lateral movement to prevent adversaries from gaining an initial foothold from a vulnerable server (or pivoting to one from within) they can't progress to other aspects of the network. Transform your approach to perimeter security to become invisible to attackers and eliminate lateral movement by adopting zero trust policies. 

• Establish strong IAM policies with least-privileged access controls and MFA
• Connect users directly to applications, not the corporate network
• Minimize your attack surface
• Inspect all traffic (unencrypted and encrypted)

Use deception to mitigate risk

In case of zero-day attacks like Log4j, attackers tend to go after testbed applications commonly hosted on subdomains such as dev, test, uat, etc. These internet-facing assets are further down on the patch priority list, which makes them a likely target for adversaries exploiting a zero-day vulnerability. By creating decoys that mimic these vulnerable testbed applications, you can intercept attempts to exploit Log4Shell and feed containment actions. These also help to future-proof against any other zero-days, as the decoys deployed today will continue collecting telemetry and trigger when newer threats are disclosed.

Develop your long-term Log4j response strategy by joining our live event Managing the Long Tail of Log4j on March 1, at 11 a.m. PT. Learn how to create an effective SecOps plan for handling Log4j that includes a list of common sources you may have overlooked, how digital transformation can help you eliminate threat vectors, and best practices to proactively expose active threats. Register here.