Learnings from Log4j: Don’t Rush into Remediation

Most of us, sharing the trait of being human beings, have experienced what’s commonly referred to as “fight or flight”—an  often intense autonomic physical reaction manifesting with a racing heart, tense muscles, and sweaty palms. A sense of panic can accompany the reaction, as well as a decision paralysis that renders our ability to think logically virtually non-existent.

Business has its own version of this response, developed and honed over years of responding to threatening digital situations.

The risk for business is similar to that of the risk to human beings. For humans, overly frequent, intense, or inappropriate activation of the fight or flight response is implicated in a range of clinical conditions. That’s an abbreviated way of saying they can cause real physical damage. On the business side, the invocation of frequent, intense, or potentially inappropriate activation of a digital fight or flight response can be detrimental to the health of business—particularly in the domain of security.

Much like the well-known “stages of grief,” we’ve noted the emergence of “stages of security reactions” over decades of working to mitigate application and infrastructure-related threats.  

The Importance of Choosing the Right  Response

Rushing to remediation can be one of those reactions that, in the long run, doesn’t turn out to be the best response. Consider that the first released patch for Log4j from Apache was also vulnerable, so organizations that rushed to remediation basically had to start over and re-patch all of their systems again.

It’s at this point where I stop and strongly state that not rushing into remediation doesn’t mean ignoring the risk or erring on the side of inaction.

This is particularly important to remember because failing to responsibly steward the data that drives a digital business has real-world consequences. In the wake of Log4j, The US Federal Trade Commission (FTC) “warned it would come after private sector firms that failed to protect consumer data exposed as a result of Log4j.” (ZDNet)

Why Mitigation Comes First

Mitigation comes before remediation for a reason, not the least of which is to address the human instinct to “do something” and rush to remediation. Rapid mitigation also addresses the need to be responsible stewards of customer data by protecting it from exfiltration while formulating the right remediation action plan.  

Mitigation should be the first action taken, especially when dealing with such a pervasive vulnerability that will require in-depth software supply chain exploration. The ubiquity and difficulty of uncovering just where vulnerable packages and components might be hiding is likely behind the finding that “vulnerable downloads for #log4shell still hit 46% overall” on Jan 4. (Sonatype)

The reality of a digital-as-default world is that new and traumatic security vulnerabilities will continue to disrupt business and strain already overwhelmed resources. Because of the robust nature of an enterprise application portfolio—often spanning five generations of application architectures spread across core, cloud, and edge—we should assume that remediation will consume the bulk of time and energy. That’s why fast mitigation is so important. It relieves the pressure and allows for a more deliberate and comprehensive approach to remediation—an approach that includes verifying released patches are safe and enabling developers to update, patch, and test in line with existing release cycles.

Organizations should ensure they have control points across all environments that support mitigation. Web and API protection, content inspection, and blocking capabilities at strategic points of control provide a “platform” of sorts for mitigation in the face of these kinds of pervasive vulnerabilities. These same points of control can also provide valuable information in the form of exposing attempts to exploit such vulnerabilities.  

Conclusion

Most of us will remember the fire-drills of our childhood, where we practiced how to safely exit the school in the event of a fire. I also practiced tornado drills, and I’m guessing it’s likely there are children around the world that have practiced preparation for earthquakes or tsunamis. Having a plan, and knowing how to execute on it, can be critical in reducing how much time is spent in panic mode when news of a significant vulnerability hits the wire.

So don’t panic. Make use of strategic control points and focus on fast mitigation so you can execute purposeful remediation.

And remember, practice reduces panic. Planning and executing a “security fire drill” of your own is not a bad idea at all.