Webinar: Why Cloud-Native Applications and APIs Are at Risk

Address the Zero Day Log4J Vulnerability

How are you going to address the Log4J issue?

The recent major exploit around Log4J (CVE-2021-44228) is a big deal and all over the press.  But how are you planning on finding every instance of Log4J in your very complex application? Missing even one instance of Log4J versions 2.0 to 2.14.1 could be a disaster for your organization.

Where to start

The big challenge organizations are dealing with right now is that they have literally thousands of vulnerable services, and they need to know where they should focus their remediation efforts first.

There are plenty of application security tools that can identify these types of vulnerabilities. But they tend to focus on the detection and testing of individual components and lack the business context required to prioritize remediation efforts.

At Bionic, we’re capable of scanning your entire portfolio of Java applications using an agentless approach so we can reverse engineer and blueprint each of them into a software bill of materials (SBOM).

This allows Bionic to identify every instance of Log4J in your application portfolio and tell you what type of data or services it’s connected to using a simple query.

This insight gives you real application and business context so that you can quickly identify and prioritize services for remediation.

Teams worldwide are currently scrambling to get in front of this significant exploit, and time is of the essence.

Questions you are being asked right now

Question: How bad is this for us in terms of scale?

Answer: A simple query in Bionic will show you every application or service that is using Log4J* and/or a specific version of it.

  • in:libraries and name:”log4j*” and not((version:”2.12.2*” or version:”2.16*”))

Question: How should we prioritize what to fix first?

Answer: A slightly adjusted query in Bionic will show every application or services that use Log4J* that is either internet-facing or touches PII data.  Start with these first.

  • in:services and libraries:(name:”Log4J*” and not((version:”2.12.2*” or version:”2.16*”))) and connections:((type:”InternetFacing*” or type:”*PII*”))

Question: How do we know if Log4J is reintroduced to our apps?

Answer: By integrating Bionic into your CI/CD pipeline every deployed new version is automatically rescanned, and older versions of Log4J are automatically flagged as ‘drift’ to catch regressions.

Question: How will we handle this if it happens to another common package?

Answer: Bionic has all your application metadata because we base our reverse engineering scans on the compiled code, not the network, cloud, or container. If say ANTR is now deemed vulnerable you can reuse the same type of queries to discover, prioritize, and verify other vulnerabilities.

Show me how?

By running a simple query in Bionic you will see every deployed instance of Log4J. In addition, you will be able to see the applications or services where these Log4J instances live. If it is your application code Bionic will find it. The result of the query looking for Log4J will look like this:

The result of the query looking for Log4J that touches PII data will look like this:

You can then investigate the exact location of the Log4J instances in the architecture map:

Log4j Bionic Scan

What if I don’t have Bionic?

Like me, you have probably read about 100 articles on the Log4Shell vulnerability to understand it better. I have seen approaches to fixing Log4Shell focused on everything from the network to the cloud, to containers.

In the end, this is a code issue in your applications. In order to identify every instance of Log4J, you need to focus on the code. The code does not lie. By reverse-engineering the compiled Java code Bionic provides you a complete SBOM and architectural blueprint to visualize what services and data Log4J interacts with.

Final Thoughts

New security issues are being identified all the time. The best defense is to identify risk within your applications by proactively understanding the application architecture and the services and how they communicate.

But what happens when a service or API that was thought to be secure suddenly becomes vulnerable?

Without a complete architectural view or blueprint of all services, data flows, and communication protocols, it can be complicated to identify every instance of the newly identified risky entity. Missing just one instance can lead to disaster.

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

Share on linkedin
Share on twitter
Share on email
Share on facebook

See a Live Demo of the Bionic Platform