Full Report
The main challenge with Log4j is understanding your existing infrastructure, and identifying the location of all vulnerable Log4j libraries. Follow Wiz's recommendations to wrap it all before the Holidays!
Analysis Summary
# Best Practices: Log4j Vulnerability Management (CVE-2021-44832 and Predecessors)
## Overview
These practices address the identification, prioritization, and remediation of critical remote code execution (RCE) and denial of service (DoS) vulnerabilities present in the Apache Log4j Java logging library, including CVE-2021-44228 (Log4Shell), CVE-2021-44832, and related issues addressed in subsequent releases. The core challenge is effectively locating all instances of vulnerable libraries across complex infrastructure and prioritizing patching based on exploitability and exposure.
## Key Recommendations
### Immediate Actions
1. **Prioritize CVE-2021-44228 Remediation:** Immediately focus patching efforts on workloads vulnerable to the original Log4Shell (versions below 2.15.0), as this remains the easiest to exploit and is heavily targeted in the wild.
2. **Patch to Latest Secure Version:** Update Log4j libraries to the latest patched version available (e.g., 2.17.1 as of December 28, 2021) to address all known vulnerabilities concurrently.
3. **Identify Publicly Exposed Workloads:** Immediately locate and prioritize patching for any infrastructure assets (VMs, services) that are directly exposed to the internet, as these are prime targets for initial scanning and compromise.
### Short-term Improvements (1-3 months)
1. **Prioritize Highly Privileged Workloads:** After addressing public-facing assets, focus remediation on workloads possessing high privileges (e.g., those with extensive AWS IAM roles like `s3:*` access). Compromise here significantly increases blast radius.
2. **Scan and Locate All Vulnerable Libraries:** Deploy comprehensive scanning tools across all environments (VMs, containers, serverless) to definitively map the location of all files containing vulnerable `log4j-core` libraries, accounting for embedded or recursive dependencies.
3. **Vendor-Specific Remediation:** Follow the specific patching or mitigation steps provided by software vendors for affected third-party applications (e.g., Elastic, Kafka, Minecraft), as manual actions may be required even for managed services.
### Long-term Strategy (3+ months)
1. **Establish Deep Inventory:** Develop and maintain a detailed, real-time inventory of all software components, dependencies, and their contained libraries, especially for Java applications, to streamline future vulnerability response.
2. **Implement Continuous Monitoring:** Integrate dependency scanning into CI/CD pipelines and runtime environments to ensure new deployments or library updates do not inadvertently reintroduce vulnerable Log4j versions.
3. **Harden Log4j Configurations:** For any necessary legacy components that cannot be immediately upgraded, enforce configuration hardening, especially focusing on environments where CVE-2021-44832 is a risk (i.e., prevent modification of the Log4j configuration file by untrusted sources).
## Implementation Guidance
### For Small Organizations
- **Focus on External Footprint:** Limit initial deep scanning to internet-facing assets. Since resource constraints are common, direct 90% of effort toward public endpoints first.
- **Utilize Public Checklists:** Rely heavily on consolidated community resources (like NCSC-NL lists) to quickly cross-reference commercial off-the-shelf (COTS) software you use against known vulnerable versions.
- **Manual Software Checks:** If automated tools are unavailable, perform manual file system searches for `log4j-core` JARs on critical servers.
### For Medium Organizations
- **Deploy Comprehensive Scanning:** Implement or leverage existing security tools capable of scanning across VMs, containers, and potentially serverless functions to gain a unified view of Log4j presence.
- **Establish Prioritization Matrix:** Formally document the risk scoring based on *Exposure* (Public/Internal) and *Privilege* (High/Low) to guide the remediation queue for hundreds of vulnerable workloads.
- **Dedicated Cross-Functional Team:** Assign clear ownership between Development (for code updates) and Operations/IT (for patching infrastructure/third-party software).
### For Large Enterprises
- **Graph-Based Prioritization:** Utilize security graph tools to trace the effective pathways of compromise—focus on workloads exposing sensitive data or having high-privilege roles, even if they are otherwise internal.
- **Automate Detection Across Abstraction Layers:** Ensure your scanning covers infrastructure as code templates, running VMs, container images (in repositories), and application dependencies, including deeply nested ones.
- **Review Managed Service Provider (MSP) Contracts:** Verify the remediation SLAs and implementation proofs for third-party software supplied by vendors, as manual actions are sometimes required even in highly managed services.
## Configuration Examples
*Note: Specific configuration examples for Log4j itself were not detailed, but focus should be placed on environment controls:*
1. **Input Validation Focus:** Ensure all user-supplied input data that might be logged is aggressively sanitized or excluded entirely to prevent injection vectors for subsequent CVEs.
2. **Configuration File Hardening (CVE-2021-44832 mitigation):** Restrict write access to the Log4j configuration files (`log4j2.xml`, etc.) to the absolute minimum required service accounts to prevent post-exploitation modification that could trigger CVE-2021-44832.
## Compliance Alignment
- **NIST SP 800-53 (Identify/Protect/Detect/Respond):** Directly aligns with controls related to media access, configuration management, vulnerability management, and incident response procedures.
- **ISO/IEC 27001 (A.12.6.1):** Addresses the requirement for timely identification and remediation of vulnerabilities in systems and applications.
- **CIS Critical Security Controls:** Relates heavily to Controls 3 (Data Protection), 4 (Secure Configuration), and 7 (Vulnerability Management).
## Common Pitfalls to Avoid
- **Assuming "Managed Services" are Handled:** Do not assume cloud providers or SaaS vendors have fully patched *your* deployed components; always verify vendor communications and apply necessary patches/mitigations if requested.
- **Neglecting Non-Public Systems:** Focusing only on externally visible systems leaves internal, high-privilege assets exposed to lateral movement once an ingress point is found.
- **Only Patching Based on Initial CVE:** Failing to immediately update to the *latest* version (e.g., stopping at 2.15.0) leaves systems susceptible to subsequent, less obvious vulnerabilities (like DoS or RCE arising from configuration flaws in earlier patches).
- **Stopping at File Presence:** Merely locating `log4j-core` JARs is insufficient; deep analysis is required to rule out vulnerable transitive dependencies or embedded libraries within closed-source software.
## Resources
- **Apache Log4j Security Page:** For official release notes and security advisories (e.g., version 2.17.1). (Defanged URL: `https://logging.apache.org/log4j/2.x/security.html`)
- **NCSC-NL Software List:** A community-compiled list detailing affected software versions and required mitigation steps. (Defanged URL: `https://github.com/NCSC-NL/log4shell/tree/main/software`)
- **Wiz Security Graph (Internal/Customer Reference):** For prioritizing risk based on effective asset exposure and privilege across the cloud estate. (Defanged URL: `https://www.wiz.io/lp/log4shell-checklist`)