Detecting Log4j (Log4Shell): Mitigating the impact on your organization

The holes in the Swiss cheese

As aviation safety enthusiasts say, an incident or accident occurs when the holes in the Swiss cheese line up. That is to say, we have multiple layers of protections and controls that should stop the worst-case scenarios from manifesting. Known catastrophic events occur only when all those controls fail to perform. Cybersecurity is no different, and we’ve been talking about defense in depth forever, too.

Here are six factors that, when combined, should help mitigate the impact and protect the Friday of every CISO.

• Vulnerability notification and remediation of the Log4j component. This is the obvious muscle to flex, and it essentially breaks down to several actions.
  • Minimize the lead time from vulnerability discovery to your team becoming aware
  • Maximize the ability to respond and identify which applications utilize the component
  • Streamline the ability to recover—quickly patch the affected applications or put compensating controls in place
• Susceptibility to exploitation: input and output validation. Successful exploitation of this vulnerability requires that you’ve ignored several secure coding principles. Data from untrusted sources (i.e., user-controlled input) should generally not be concatenated into log files without sanitization. This is especially true when the data is from an unauthenticated origin, whether human users or other applications. Data flowing into sensitive areas such as databases and logs that may be rendered to others should be subjected to output validation. Not doing so is a log injection vulnerability in itself, which has long been known and categorized as CWE 117, as well as being described in the CERT Java coding rules. So our first line of defense is making sure our applications are free from these kinds of flaws.
• Network architecture and network-level access controls. Successfully achieving the next stage of exploitation requires that an attacker can transfer a payload or exfiltrate data to or from an external system. This might include transferring some code to execute a shell, or even some crypto mining malware. Initiating communication with outside hosts should always be locked down to the bare minimum. Guidelines from the Center for Internet Security (CIS) cover this, as do many other control frameworks including MITRE ATT&CK, which has a whole category of mitigations in M1037 covering network filtering. For client-side applications, using sandboxing technology—even if only the built-in OS and JVM functionality—could further mitigate the range of exploitation paths available.
• Application architectural risk. In a worst-case scenario, such as unauthenticated external users accessing application elements that must be exposed for the application to function, there are obvious defensive programming techniques that apply. Why does your login page need to allow a $ and { character anyway? Although it might make sense for free-text search fields to allow a wide range of characters, a well-designed application should know what type and range of information to expect and lock down server-side input filtering to limit the accepted data to just those values. A password could contain special characters, but allowing sensitive data such as passwords to propagate into logs is a no-no in itself, and this eventuality should be eliminated elsewhere, too. Interactive analysis tools can help visualize the application dataflow—including across application and microservices boundaries—so you can find out what data needs to go where and make sure appropriate filtering exists.
• Logging, monitoring, and anomaly detection. No, this isn’t irony. Anomaly detection routines should spot an application doing something unusual. That could be attempting to connect to hosts it shouldn’t, or launching processes or accessing files that it doesn’t usually interact with. There is a long list of other layers of defensive and detective controls that could be configured as part of a sandbox environment to limit the impact of any successful exploitation or make real-world exploitation practically impossible. Or, if exploitation does occur, being able to show what was accessed and support the breach investigation team in determining the true business impact will be invaluable when you get to that stage.
• Software component transparency, vendor management, and mature open source adoption. This brings us to the topic of how we address this kind of risk for software that we did not develop ourselves, including software embedded in products we use every day. For some companies, the disclosure of a software Bill of Materials (SBOM) is already routinely requested and received. Such a listing of software components helps streamline a response and investigation, since it identifies exactly who is using Log4j (either directly or indirectly), and which products or vendors to engage with for remediation. But there’s a second aspect to this story: mature management of open source. As Tim Mackey, principal security strategist at Black Duck Cybersecurity Research Center (CyRC), likes to say, “There is no such vendor as open source.” In the case of Log4j, it appears that the library was still actively maintained and supported as part of a broader community initiative via the Apache Foundation. But many libraries are developed without the support of specific groups or even just individuals, and then they are abandoned or forgotten about. Looking at the provenance of open source components, including aspects such as community support and maintenance, provides an indicator of where this kind of latent risk may manifest. This data can help developers choose which components to trust. What would have happened if, instead of Log4j, the affected component had been abandoned several years ago and the last maintainer could no longer be contacted?

Finally, beyond scrambling to fix the underlying component, there are three reasons why you shouldn’t be affected. Good code hygiene, good network architecture, and confidence that centralized security and engineering teams have integrated appropriate security checks into CI/CD pipelines and provided actionable information to developers should protect you, and help you avoid security, quality, and safety risks for every software delivery. Static code checkers, including Coverity®, can find log injection vulnerabilities, and in the case of modern infrastructure-as-code configurations, overly permissive network rules can be caught by automated analysis.

In a well-orchestrated AppSec program, determining whether your team or built-in automation ran the tools, and if they fixed the findings, should be a couple of clicks on the application security orchestration and correlation (ASOC) dashboard.

Furthermore, as we see increased adoption of SBOMs, championed recently by Executive Order 14028, software component information should flow more seamlessly between product vendors and their customers. Instead of calling every single supplier to confirm component information, the task now becomes a straightforward database search. Although users of software composition analysis products such as Black Duck already benefit from internal SBOM information for software that they develop in-house, we are on the cusp of broad SBOM adoption and distribution between organizations. Once established, this will be another powerful tool for mitigating and managing risk, and support more rapid response (perhaps even automated response) in these scenarios.