Right now, everyone is busy patching — locking their proverbial doors and windows to prevent the Log4j security vulnerability from being exploited. The rush to patching is understandable, but what many don't realize is that it's already too late. That doesn't mean, however, that it's too bad for organizations running Log4j. In this article, I'll explain what you need to know — and do — to mitigate Log4j damage.

First, it's important to understand why patching Log4j is so complex. For one thing, it's hard to determine the extent of your exposure because it's impossible to immediately determine how many assets are exposed — both your own and those in third-party components. Also, it's not easy to identify the organization's risk. To do so, you need to know not only whether your organization uses the Log4j package, but also how it is related to your crown jewels — the assets that are most critical to accomplishing your organization's mission.

The patching process in general is complex and resource intensive. It's similar to a Pareto distribution, or the 80-20 rule: Once a patch is available, 80% of the loopholes might be fixed with just 20% of your time and effort. To fix the remaining 20% of loopholes, you need to expend 80% of your efforts. Meanwhile, an attacker needs just one way in.

Understanding Your Blind Spots
Right now, two things are happening: Your organization is at risk, and you are aware of a previous blind spot. The rapid releases of patches for Log4j vulnerabilities create momentum for identifying and patching vulnerable components, but that's not enough. You also need to understand that attackers don't wait for a vulnerability notification to try to get into your system. The vulnerability in the code existed long before the patch, so a door has been open for months or even years. You may have already been compromised, unknowingly. Unfortunately, patching does not magically evict cybercriminals from your environment.

The true blind spot in the industry right now is the time between when the vulnerability entered the codebase and when the vulnerability is disclosed. The industry typically thinks of a zero-day vulnerability as the time between disclosure and when a patch is available — T1 in the timeline below. As evident from the patching frenzy related to Log4Shell, criminals race to exploit zero-day vulnerabilities to gain access to your systems before you apply all the necessary patches.

This isn't the right approach. You really need to think of zero-days in terms of when the vulnerability entered the codebase. That means T3 in the timeline — a much longer period. This is a time of unknown attacks, when the vulnerability exists, but white-hat hackers aren't aware of it yet. During that window of time, cyberattackers can exploit a vulnerability, creating backdoors that let them exfiltrate data, execute a ransomware attack, or otherwise compromise your systems. During T3, hackers are preparing for a future attack or already conducting one, waiting to move out of stealth until it will cause the greatest chaos to your business and maximize their chances of getting what they want.

The Challenges to Focus On
There are three key challenges for the software industry in responding to Log4j:

There is a vast amount of information available about what needs to be done to prevent environments from being hacked by a Log4j vulnerability, and yet more about how to detect an ongoing attack with this vulnerability. This is all helpful and valuable information, but it misses the question of what you need to do to see if your organization has already been hacked using the vulnerability in Log4j.

Conclusion
Cybercriminals are making the most of this Log4j gift. Given the current complexities with patching — and the fact that many organizations have likely been vulnerable for quite some time — it's important to patch quickly but carefully. And, most importantly, assume that you will be attacked. The time you spend getting ready for that possibility will increase your resilience and reduce the severity of impact if — or, more likely, when — attackers make use of the back doors they have opened.