Log4j Reveals Cybersecurity's Dirty Little Secret

Once the dust settles on Log4j, many IT teams will brush aside the need for the fundamental, not-exciting need for better asset and application management.

Mark Manglicmot, Vice President of Security Services, Arctic Wolf

December 22, 2021

5 Min Read
Image denoting security
Source: Sergey Nivens via Adobe Stock

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.

About the Author

Mark Manglicmot

Vice President of Security Services, Arctic Wolf

Mark Manglicmot leads the Security Services team at Arctic Wolf. A US Air Force Veteran and experienced consultant, his experience is concentrated in enterprise security strategy, APT incident response, adversary hunting tactics, security operation center (SOC) formation, red teaming, and security analytics. Manglicmot's USAF service of nine years included over five years in the Air Force Computer Emergency Response Team (AFCERT), where he was certified as a "Combat Mission Ready" Crew Commander and Assistant Director of Operations to direct real-time cyber-response actions across the Department of Defense. He has taught USAF course lectures and college seminars on network warfare and is a published author.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights