Log4j: Getting From Stopgap Remedies to Long-Term Solutions

While the worst of Log4Shell may be behind us and much work remains, let's say "Well done" to the security engineers and managers who labored in the trenches in recent weeks. But if you thought the Log4j vulnerability was last year's problem, think again. In 2022, this vulnerability will require care and attention to fully remediate and detect permutations.

Log4j fears centered on the pervasive use of the Java logging library and how easily an unauthenticated attacker could leverage the exploit for remote code execution (RCE). We have implemented updated configurations, and feel prepared to mitigate the suite of Log4j exploits — for now. However, permutations of this exploit are already emerging and long-term solutions involving full upgrades to core infrastructure are likely pending at your organization.

Because of subsequent emerging common vulnerabilities and exposures (CVEs) and how hastily many teams made config changes and scanned assets for vulnerable software, it will be months before Log4j is truly behind us and under control. Many organizations are stuck in either the discovery phase trying to fully map where their systems use Java or Log4j or in remediation as operational or system limitations restrict their ability to roll out full patches.

Be prepared to execute a full remediation process because initial configuration changes become inadequate and the vulnerability permutates. The following best practices/focus points will help ready your security team and colleagues.

Using Asset Management At Scale
Security teams scrambled to find and prioritize entire fleets with many thousands of assets in the wake of the Log4j vulnerability. The communal outcry was for quick, scalable ways to find Java and Log4j instances. We have so many detection tools available, yet many security organizations lacked the most fundamental building block: an up-to-date software asset inventory.

It's crucial to capture and address every asset.  Security teams need real-time answers to questions like: Which Linux servers are running Log4j? Which VMs are using Java? 

Strong asset management enables faster patching cycles. When new permutations of Log4j emerge, they require new patches immediately. Teams with stronger asset inventory capabilities responded more effectively to Log4j. They were able to identify vulnerable Java instances faster and monitor operational impact from patching.

Best Defense: Faster Patching Cycles 
Installing patches is the best way to address emerging threats, but threat actors quickly incorporate new CVEs into attack suites. Upgrading to the latest version is the most reliable way to mitigate these attacks and protect your systems. Relying on manual configuration changes leads to gaps in your system over time as vulnerabilities like Log4j evolve. Merely changing a true/false flag is insufficient.

Check Your Configuration
To harden asset management practices, implement configuration checks. When new CVEs appear, assets require further updates and config changes. Ensure that you can track new CVEs from Log4j as they emerge. This vulnerability management plan starts with which channels your team will monitor for future threats. You need a reliable process for sourcing high-priority threats. Don't rely on the grapevine or Twitter; establish a proactive process.

Addressing Legacy Systems
If your organization is using legacy software that doesn't play nice with updated versions of Java, it's time to act. Push your leadership (and vendors) toward strong software asset inventory and recurring patching cycles. Handling technical debt, including unpatched legacy software, consumes undue amount of resources and bandwidth, with increased monitoring and compensating controls. The security community has an amplified voice in the wake of Log4j, and the time is ripe to plan upgrades to legacy systems.

Don't Overlook Intranet and Air-Gapped Systems 
Air-gapped and internal devices are often considered safe because if attackers can't reach the system, we assume they cannot exploit it. Log4j is too dangerous to rely on this assumption because unauthenticated requests — even if passed through other applications — can still lead to RCE. Treat air-gapped and intranet assets like Internet-facing assets; plan full upgrades and track their configuration over time.

Secure Auto-Scaling and Deployments
Identify assets in your cloud environment that may be spun up using an auto-deploy or auto-scale solution. Ensure that these configurations are secure and any future deployments are not reliant on outdated versions of Java or the Log4j library. Work with your dev teams to ensure these secure configurations are incorporated into future builds.

The collective effort to protect organizations relies on multiple teams and vendor checks. Let's ensure all our colleagues have the tools to keep the worst of Log4j behind us. If you have questions about implementing this road map or tackling emerging security threats this year, contact your vendors.