When tech media starts reporting that the “internet is on fire,” you know you have a significant situation on your hands. Over time, the severity, scope, and impact of the Log4j vulnerability, also known as Log4Shell, has only increased. The US Cybersecurity and Infrastructure Security Agency is recommending immediate action, as is its UK counterpart, and modern tech’s household names are among those we know are immediately — and gravely — vulnerable to one of the most significant zero-day threats in years.
Downstream, millions of devices and networks are at critical risk, and attackers are coming up with new obfuscation tactics to exploit this logging vulnerability just as quickly as fixes are released. Put another way, it’s bad. Really bad.
ICYMI: On Dec. 9, security researchers published a proof-of-concept exploit code for CVE-2021-44228, a remote code execution vulnerability in Log4j, a commonly used Java logging library used in a significant number of Internet applications — especially ubiquitous enterprise systems.
In the immediate aftermath, every organization is rapidly attempting to identify and mitigate the exploit in the vast array of tools and services that drive modern business and connectivity. This situation exploits a weakness in such a fundamental part of widely adopted logging software that makes it almost impossible to comprehend how widely this vulnerability is hiding.
Meanwhile, security research and threat intelligence teams are in a frenzy to release information, patches, resources, and guides to help businesses assess their risk. At the same time, multiple campaigns have since emerged, exploiting Log4Shell against vulnerable public-facing systems to deploy a variety of malware, ranging from cryptominers to Trojan backdoors. We’re still just a few days into this crisis against nefarious threat actors who are adapting fast.
Are We Learning From Past Exploits and Preparing for the Next One?
Somewhere between the aftershocks of past attacks like WannaCry and SolarWinds, and having their names forever cemented in the library of cybersecurity-gone-wrong, there are conversations about what can be done to prevent this type of scramble next time. So many organizations remain underprepared for this type of action and are stuck in the dark in terms of what’s in their technology stack. Applying patches to affected systems is usually the pathway to threat mitigation, but if IT teams don’t have a full view of what’s in their network to begin with, taking swift and decisive action is all but impossible.
An attack of this magnitude and speed also underscores the critical importance of asset inventory and management, which can often fall through the cracks between IT ops and security teams. In the immediate wake of the Log4j vulnerability, CISOs everywhere were asking their teams, “What’s our exposure?” If security teams don’t have an accurate catalog of devices and software, it’s impossible to fully answer the question. While this is difficult and an often forgotten element of the security operations framework, the evolving and severe Log4j situation illustrates the significance of having a complete view to apply patches everywhere they need to go — and quickly.
Another significant challenge is the trickle-down impact on small and midsize businesses and resource-constrained IT and security teams. Major tech players, rightfully so, were the first to act on this vulnerability — deploying fleets of experts, researchers, and developers to identify and cascade updates to their vast web of tools and services. But the average small–business IT leader, with more than a few responsibilities, will struggle to keep up with the volume of tools to patch multiplied by the number of patches necessary.
So, here’s the dirty little secret: Once the dust settles on Log4j, many IT teams will quickly go back to their long list of other duties and once again brush aside the need for the fundamental, not-exciting need for better asset and application management. They’ll consider things a success if they avoided an attack in this current cycle but will struggle to look around the corner to be better prepared for next time. They’ll continue to be overwhelmed with the sheer volume of tools, alerts, and patches and they’ll fall behind in the time and resources needed to stay vigilant and stay protected. It’s a vicious cycle that we’ve seen time and time again, but it doesn’t have to be that way. We can — and should — demand more.
What Can Be Done?
Here’s a better approach: Use this opportunity to definitively assess and catalog which third-party tech vendors touch your systems. Identify and eliminate rogue tech and hold vendors accountable for protecting themselves to protect you. In the end, having fewer trusted vendors is better than a vast and nebulous array of tools and services that aren’t centrally managed.
See this situation as an opportunity to also assess who is communicating proactively versus who is less forthcoming. Are tech providers offering updates and insights? Are they confident in their (and your) security posture? Experiences and validation now fortify trust moving forward.
And finally, a good incident response plan and playbook — including how to interact with outside partners — is only strengthened over time and use. Document what works well and what needs improvement, early and often. And make sure the message is understood by the entire organization.
Demand Better
Cybersecurity is a team sport requiring vigilance, communication, and trust among a broad network of software makers and service providers that connect the world. But there are also fundamental flaws in how the game is played, which leads to too much noise, too much confusion, too many tools, and not enough resources to get the job done.
Log4j has revealed a large vulnerability in such a small, fundamental piece of code with a cascading effect that will take years to unravel. It’s another sobering reminder of how fragile technology can be if exploited. But if organizations and IT leaders leverage the situation to address the issues that have long plagued our field, we can use this situation to finally improve ourselves and our approach to cybersecurity. We can regain the advantage against threat actors and finally break the cycle in a very unfair fight.
