Risk Management
Apache Log4j: Mitigating risks
Explore tactical measures and strategic guidance to mitigate ongoing risks caused by Apache Log4j (Log4Shell).
Save to Folio
Apache Log4j (Log4Shell) poses serious challenges for IT teams. In this article, I’ll discuss various tactical measures to navigate the current situation and provide strategic guidance for what to do after the immediate crisis abates.
The Problem
Log4j is a very useful tool incorporated in many Java code applications. There are so many places in code where a programmer wants to take some data and put it into a log, or some other kind of repository, for later action. Log4j does this — it takes a string and copies it from one place (i.e., the userid field in a login screen) and puts it somewhere else (i.e., the input area for an authentication process). Log4j does much more than a simple copy and paste, it also examines the string and interprets it.
Interpretation is generally risky, because unless the program sanitises the code, things can go quite wrong. Log4j does not sanitise inputs, leaving servers vulnerable to RCE, which can ultimately lead to your enterprise’s valuable data being exfiltrated and ransomed.
Source: https://xkcd.com/327/
How to mitigate risks
To stop the immediate crisis, it’s important to assess your exposure and to implement the proper security tools to discover which code and applications might have the vulnerability. Refer to trusted resources, such as the Cybersecurity and Infrastructure Security Agency (CISA), to identify effective vulnerability assessment tools.
At the code level, there are tools to scan for the presence of the string “log4j”in your source code libraries that have calls to the code.
Next, update and patch the effected libraries. The most current fixed version of Log4j is 2.17.0. Make sure you regularly check the Apache Foundation for the most current fix level. As the situation continues to evolve, manually patching and updating can become complex. Leverage a security tool with virtual patching capabilities and an effective intrusion prevention system (IPS) to continually monitor your network for malicious activities.
Lastly, security teams should start building a Software Bill of Materials (SBOM) listing all the components used to construct the application. A SBOM will help us diagnose tainted software beyond whatever we might learn from today’s Software Asset Management Database (SAMDB). Admittedly, many organisations do not have a comprehensive SAMDB today. Fixing that should become a greater priority considering the current problems.
Developing a long-term security strategy
After you’ve implemented measures to stop any immediate risks, consider creating a long-term plan in case something similar occurs in the future. Your plan should address:
- Who’s leading the response
- How will you assess your exposure?
- Enhancing visibility across software, servers, and shadow IT (assets not centrally managed)
- Timely communication with key providers about their efforts to mitigate risks
- Establishing a communication channel for reporting issues to make sure nothing is missed
- Updating your business continuity plans (BCP) to limit the impact on the organisation
- Preventing teams for burnout. It’s widely reported that IT teams are already experiencing burnout—events like Log4j only add more stress. Ensure that security teams feel adequately supported as remediation can take weeks, or months, depending on the size of your organisation.
Next Steps
There’s no shortage of news coverage for Log4j; the nonstop updates and news alerts can become overwhelming. Find a trusted adviser with deep cybersecurity knowledge to keep you appraised of the facts instead of turning to those who rely on sensationalism.
For security teams working around the clock in response to the log4j vulnerability, check out our free assessment tool.
Follow me on Twitter to continue the conversation: @WilliamMalikTM.