The Log4j lessons: what IS vulnerability management?

CTO Lieuwe Jan Koning and Lead Architect Rob Maas

In our first Log4j lessons blog, we focused on the necessity of becoming very, very good at patching, and making it a well-documented and automated routine in your IT-environment. This might sound obvious, but many organizations hit serious hurdles in their initial Log4j handling because their patch machine did not start cold.

Our main takeaway was that you should not wait on a major security incident to ‘practice’ software updates. When your IT-department is confronted with a serious threat such as Log4j, you should be able to focus on problems that precede the question of whether you should and can patch or not.

Questions, questions…

In the case of Log4j, you were probably asking yourself questions like:

• Where is Log4j in my infrastructure?
• Where can I get a listing of applications and devices that are built with vulnerable Log4j versions, and what is the exact nature of this vulnerability?
• What’s the status of the different vendor updates? Have they acknowledged vulnerability due to Log4j? Is there a patch available?
• Do I need to use scanning tools to scan for Log4j vulnerabilities? Which tools for which environments?
• Which mitigating actions have the most priority, and how do I implement them?

You can almost hear a CISO say: “If only we had our vulnerability management in order, we wouldn’t have to worry about Log4j”

At first sight, these types of questions seem to fall in the generic category of vulnerability management. By defining this segment in the first place, technology vendors suggest that there is a vulnerability management tool or set of cloud services you can buy to get the answers to all of the above questions even before they arise. You can almost hear a CISO say: “If only we had our vulnerability management in order, we wouldn’t have to worry about Log4j”.

Unfortunately, the reality of cybersecurity rarely conforms to the perfect world portrayed in datasheets, white papers, and marketing brochures.

The perfect tool?

Let’s just, for the sake of argument, assume that such an all-compassing vulnerability management tool really exists. Let’s use this definition from the Wikipedia article on the subject:

Vulnerability management is the “cyclical practice of identifying, classifying, prioritizing, remediating, and mitigating” software vulnerabilities.

You would expect this wonderful tool to give you real-time answers to the above questions and probably many more. It would have to be a fully automated real-time repository of all your software and cloud assets, with versioning information and dependencies. It would obviously include an up-to-date software bill of materials (SBOM): the list of components in a piece of software.

Just like there is no all-encompassing Zero Trust product, there is no integral vulnerability management tool.

It would have to offer all the threat intel, vendor updates, mitigating measures in minutes after they become available. Preferably, it should also facilitate the ideal patch machine we talked about earlier, and help you manage mitigating actions, such as implementing block-lists, updating firewall rules, signatures, and possibly behavioral rules.

It would be nice if it could use all the available telemetry and sensors to evaluate if the proper actions have indeed been taken, and to detect susceptible traffic related to a particular vulnerability. In other words: it should also continuously validate the rules and policies in the cybersecurity technologies we employ

You only need to google for vulnerability management tools to find out for yourself that the vendors in this category address limited and different aspects of all the requirements we demand. Just like there is no all-encompassing Zero Trust product, there is no integral vulnerability management tool.

Different tools take care of specific functions to effectively manage your resilience to cyberthreats, just like a Zero Trust strategy consumes technological solutions for identity management, 2FA, or traffic inspection.

So, what is vulnerability management?

So, can we define vulnerability management? The closest we will come: vulnerability management is the strategic, tactical, and operational use of technology, processes, and people to build an effective and preferably proactive answer to threats exploiting the vulnerabilities in our infrastructure. But wait, this is in essence a large part of the mission of cybersecurity departments and their SOCs. It is what ON2IT as an MSSP aspires to do for our customers.

So, if there is an important lesson to learn from Log4j, it is that organizations have become more acutely aware (again) that they need quick and effective answers and measures when confronted with a threat as dangerous and widespread as Log4J.

A single product will never fill that void. And different tactical tools are required in different situations. Some of our customers had little or no visibility into their software assets. We found that a fast onboarding of Palo Alto Networks’ Cortex XDR Pro can be a very effective tool to speed up response to Log4j. Extremely helpful, but only a piece of the puzzle.

Don’t overlook the end-to-end validation of your vulnerability management strategy. Automated validation technologies (such as Pentera) that both test and verify if internal and external vulnerabilities can be exploited are helpful for organizations. This helps both security professionals as well as ops teams to discover Log4j-like design risks.

So, if there is an important lesson to learn from Log4j, it is that organizations have become more acutely aware (again) that they need quick and effective answers and measures when confronted with a threat as dangerous and widespread as Log4j.

And you will only get those answers through a practice-proven and agile operationalization of a long-term strategic approach to cybersecurity. Focus on a sound strategy and execution capabilities first, rather than on technology and tools. If you label this approach vulnerability management, that’s fine by us.

What about unknown threats?

We end with an often neglected but critical question: what is our answer to unknown vulnerabilities? This is really one of the key belief articles in a Zero Trust approach: to help build resilience against vulnerabilities we are not yet aware of. In the next blog in this Log4j series, we’ll zoom in on the ability of a Zero Trust approach to counter not only publicized but also unknown threats.

Lieuwe Jan Koning, CTO and Rob Maas, Lead Architect