Beyond The Security Alert Dance: Learn Some Useful Steps

I’m sure you’ve heard about the Logj4 vulnerability. It is one of the major security events that has shaped security discussions over the past few months. It’s been in the news, running the rounds of what I call the “fear, uncertainty and doubt lifecycle.” This means we state the problem, and then try to sell something based on that problem. A colleague of mine, Chris Cochran, calls these moves the “security alert dance.” That’s a shame, because the Log4j vulnerability should be taken very seriously.

What Is Log4j?

Log4j is a powerful logging facility used to monitor and track system calls in web servers (and other tools) to log activities. The Log4j code is created by an open-source project managed by the Apache Software Foundation.

The code is deeply embedded in systems and tools that we all use every day. It is as ubiquitous as it is obscure. While you may have never heard of it until December 2021, it has been – and will continue to be – used by millions of web servers, gaming platforms and other services on the internet. It is found in Apache Tomcat web servers, the Minecraft gaming platform, Apple iCloud, Amazon Web Services (AWS) and beyond.

Organizations that use Apache Tomcat include millions of people. We’re talking about virtually every government, large company and small business in every vertical market. Major banks and manufacturers use services that employ Log4j day in and day out. It represents a major attack surface, with implications across every sector, from finance to the manufacturing supply chain.

Why Is the Log4j Vulnerability a Big Deal?

The Logj4 vulnerability is a highly significant event. It is a serious vulnerability and threat spawning real exploit software and leading to actual security incidents. But it’s significant for two more reasons, as it is:

1. The first major instigator of security alert fatigue
2. An opportunity for the IT and developer community to make a few changes 

Log4j and The Big Five Conditions

A vulnerability like Log4j becomes a major problem when it satisfies the following conditions:

1. Ubiquity: If you’re an attacker, you usually want to exploit code found everywhere.
2. Impact: Attackers love code that allows them to execute random code, at will. In this case, it is possible to use the Log4j exploit to execute some powerful attacks, including the ability to steal data, manipulate data or conduct DDoS attacks.
3. Ease of use: Once an attacker identifies Log4j, it is relatively easily to create code to exploit it.
4. Scalability: It is possible to automate scans and Log4j attacks using either simple scripts or sophisticated AI-enabled scans.
5. Obscurity: With the log4j vulnerability, the problem occurs in an obscure logging facility deeply embedded in a web server. This particular vulnerability isn’t as visible or as easily recognized as, say, the EternalBlue vulnerability, which was more easily linked to specific Windows operating systems. With Log4j, the issue is more difficult to characterize, isolate and remove.

Given the above factors, the scope of the vulnerability led to a lot of legitimate worries. It has also led to a lot of fear, uncertainty and doubt in addition to the typical security dance moves, that many tried to exploit.

The Typical Security Dance Moves

Whenever a vulnerability is found, the first dance move is to blame someone. Over the years, this move looked something like:

• The company or project that made the software is to blame
• Open source is the culprit
• Closed source is the culprit
• It’s a supply chain problem
• People who don’t update are the problem
• Buy something to solve the problem

  It’s time to move beyond these simple dance steps and into some unique moves.

Going Beyond Fear, Uncertainty and Doubt

If your organization is relatively mature and has a few of the above in place already, then it is possible to monitor and mitigate this issue. The problem is, not every organization has mature processes, and even worse, a lot of organizations think they have mature processes, but do not. I’ve found that stepping away from the security alert dance involves short-term, long-term and even longer-term solutions.

Short-term Solutions Include the Ability to:

• Monitor and visualize: We need security analysts who know how to look for indicators of compromise. That’s more important than patching software or updating intrusion detection systems. Sophisticated monitoring and response are the most effective ways to counter the attacks that stem from vulnerabilities we’re bound to keep finding in obscure, but useful, software.
• Patch: Yes, we’ve got to keep patching. But it’s not the only solution.

• Automate: We need workers that know how to quickly automate both the patching process and the security alerting process.

  Long-term Solutions Include:

• Micro-segmentation: I’m not talking about merely using virtual LANs or using typical Web Application Firewall (WAF) solutions. Micro-segmentation allows organizations to create more granular inspection opportunities into applications and data. It improves upon and matures monitoring and visualization.
• More rigorous testing: We need good pen testers and security analysts to engage in fuzzing and testing of applications to find these deeply hidden software faults.

More Mature Longer-term Solutions

The more sophisticated solution is to mature the development lifecycle. We need to gain control over the software development process. This, of course, can take some time.

The fact that most developers either don’t know security or aren’t given enough time during projects to conduct secure coding practices is the problem. Overlooking this dynamic has created the vast majority of our current security nightmares.

Years ago, Eric Raymond gave us Linus’s Law in his book The Cathedral and the Bazaar. It states, “Given enough eyes, all bugs are shallow.” In this case, it appears some open-source project leaders didn’t devote enough eyes to their code.

But developers don’t really know what to look for. Their eyes just aren’t educated enough to really recognize what they are seeing. Security analysts have a tough time visualizing what is going on as well.

This is why more developers are now receiving security training. Recent research into CompTIA security certifications shows that more developers than ever before have taken CompTIA Security+, for example. Why? Because it’s vital for developers to understand the security and privacy implications of the decisions they make as they code.

This longer-term solution allows security analysts, vulnerability assessment and pen testing (VAPT) specialists, developers and operations specialists to work together more efficiently. When that happens, we’ll finally be in a position to avoid taking part in the security alert dance.

Get more articles like this right in your inbox with CompTIA’s IT Career Newsletter. Subscribe today.