Log4J – Reflection and Progression

Open any social media platform or pull up any mainstream media and undoubtably, you have seen many posts/articles talking about the log4j vulnerability. If you haven’t seen this, here is a quick link to catch up https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/.

This post is not going to be about log4j, nor is it going to go into any of the details the thousands of others articles out there would go through. Instead, I want to discuss this at a higher level. Log4j is just an example of the risks of using 3rd party components and should be pushing a broader discussion within your organization and team.

The use of Vulnerable and Outdated Components – https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ – Is ranked 6th on the OWASP Top 10.

If you have already started dealing with this (and if you haven’t, you should be), you have probably had similar questions as others out there. The biggest question probably every organization and security team had was “Am I vulnerable?”.

This is a great question, but how easy is it to answer?

Am I vulnerable?

If you had one application with minimal dependencies, maybe this is a quick answer. Maybe it is not a quick answer. As a developer, you may just have responsibility for your application. You also might be able to quickly answer to what version of what dependencies exist in your application. Well, maybe high level dependencies.

As an organization, it may not just be custom in-house applications that we are worried about. What about other applications you use within your organization that could be vulnerable to this. Are you using Software as a Service that could be vulnerable? As we start to pull on these different strings, they start to get tangled together.

What are some of the things you need to know?

What applications are you using? For years, an application inventory has been highly recommended, but rarely implemented. It is another one of those things that rolls off the tongue easily, but a good implementation is often a struggle. If you don’t know what applications you have, it is really difficult to then verify whether or not your are potentially vulnerable.

Knowing the applications is the first step. The next step is understanding the make up of those applications. There are multiple solutions around determine these answers. Recently, there was a big push for a SBOM, or Software Bill of Materials. The idea behind the SBOM is that it will list out all the components that make up your application. While not necessarily a new idea, it is become a point of emphasis with the release of the executive order on Improving the Nation’s Cybersecurity – https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

SBOM sounds good, but do you have one, or even know how to generate one? What about for external applications, are those providing an SBOM? For this article, I want to focus a bit more on internal development. I won’t go into the generation of an SBOM, we can save that for another time. The point here is to raise the issue.

SBOMs are an output, not a tool. Typically, they are generated by some tool. There are plenty of tools out there that can generate a list of application dependencies. In many cases, you may be creating an SBOM out of those tools (looks like many of the vendors are building this output capability in), but these tools can also be a source of truth for what you are running. No two tools are created equally, so capabilities differ between them.

So lets say you have a tool that can scan your applications for dependencies. You have the ability to search for said affected component to identify the risk. Are you asking how well your coverage is with that tool? Does it cover every application, script, code your organization creates?

Just like the Application Inventory, component inventory is only as good as the coverage it has and the rulesets it runs with. Are you only scanning some applications? What is missing? This should be an opportunity to look at your coverage.

What is your plan if vulnerable?

Identifying that you have the potential vulnerability is just the first step. Next, you have to have a plan for how to respond. This requires more than just fixing the vulnerability. In the case of dependencies, hopefully it is just patching the component, but we all know it always isn’t that easy. Is there a patch available? Are there other mitigating factors that you can implement to reduce the risk until a patch is available? Unfortunately, sometimes you are at the mercy of the component developer to fix the issue which can be fast or slow.

In addition, how do you then communicate your situation with customers or others. We can’t just patch silently and hope no one asks. Transparency is usually a positive attribute, but it requires proper planning. Communication may include discussions with legal, marketing, security and other groups. This step should not be overlooked. You can be assured that customers are going to want answers, and most likely sooner rather than later. It is best to have a plan in place to be ready to handle these types of events.

While Log4j was a catalyst for starting to ask these questions, it is not the only time we will see this issue. As we move forward in our programs we have to be considering how we track this information so when the next occurrence happens, we have a plan in place to quickly identify and potentially patch the issue.

Whether the log4j event affected you or not, this should be a call to action to look at your programs and better understand your strategies around these types of components.