Log4j: A forcing function to adopt long-overdue continuous security

Like other unexpected exploits and big-time breaches, the recent Log4j discovery reminded us that serious threats can seemingly come out of nowhere and create significant new risk. It is another stark reminder that, despite the frequent occurrence of security breaches, many organizations are not adequately prepared to deal with zero-days.

While we don’t know the full impact of the Log4j issue just yet, it’s particularly noteworthy because it has three key ingredients that add up to a recipe for cybersecurity disaster:

• The impacted Log4j library is used in thousands of Java app frameworks and packages
• It’s easy to exploit
• It gives the attacker full control to steal data, install ransomware, and server-hop

Together, these ingredients make it probably the worst exploit we’ve ever seen. And it very well could be just the tip of the iceberg when it comes to threat discovery, especially for organizations that don’t have modern AppSec tools and processes in place. 

Complicating matters, once bad actors have entered an organization’s network, they can be very hard to find. Depending on their motive, attackers can immediately seek financial gain by installing ransomware or selling stolen data to the highest bidder. Or, they can stay hidden, listening in for months before taking action. The SolarWinds attack is an example; in that case, threat actors were inside for nearly nine months before the breach was discovered.

Log4j: One symptom of a deep-rooted ailment

Like any approach to health, good application security requires much more than checking for vulnerabilities once or situating security solely in development. To truly be ready to respond to a zero-day like with Log4j, an organization needs an always-on security posture that reaches all corners of its asset portfolio.

It’s time that every company, government agency, and organization heed the lesson from Log4j, and take two important steps to improve their readiness for the next zero-day:

• First: Develop and maintain an inventory of every app deployed – including component parts.
• Second: Embrace a continuous approach to AppSec that recognizes that an app that was secure yesterday may not be secure tomorrow.

Start with the SBOM

SBOM, or Software Bill of Materials, comes into play for step one. Let’s set the stage for the best-case scenario and rewind to the day of the Log4j discovery: security knocks on your door and asks if you’ve heard about the new exploit, and if you’re using the Log4j library anywhere. You have an SBOM to check every asset in your arsenal, and a quick scan tells you that there’s only one impacted application. Your team is able to refocus all of their energy on that single app without worrying that the exploit is lurking somewhere else. 

Unfortunately, a lot of organizations are still feeling the worst-case scenario days later. They don’t know exactly what they’re using for third party libraries and integrations, so they don’t know where to start and have to spend days checking everything. Setting up a process for implementing SBOMs is so critical that even the United States government is getting behind it – the Biden Administration’s 2021 executive order on cybersecurity strongly recommends the use of SBOMs for vendors dealing with federal agencies.

Whether you work with vendors in a federal capacity or not, cataloging each asset with a bill of materials means your security team knows the ingredient list and can find the source of an ailment much faster in worst-case scenarios. 

True AppSec is continuous and comprehensive

While SBOMs provide crucial clarity into internal processes and peace of mind for those who use your software every day, they’re one piece of the security puzzle. The other is implementing continuous and comprehensive application security. This means an approach to application security that leverages automation and speed to cover your entire attack surface, including proprietary code, open source code, and commercial software. If Log4j has taught us anything, it’s that partial protection is no protection at all.

Continuous security requires a mindset shift away from the belief that it’s sufficient to focus security resources only on flagship applications, and into the recognition that without the right tools and focus on security for the entire attack surface, your organization is not protected. Organizations need to build secure coding practices into their software development processes, test for vulnerabilities before new code is released, and then continuously scan in production. And they need the right tools – continuous security is only possible with high accuracy and automation, and with tools that can easily inventory and quickly scan everything.

In our experience, organizations that have already adopted continuous security measures have been the fastest to respond to the Log4j crisis. They recognize that code/apps that are secure today may not be secure tomorrow and thus the attack surface must be continuously tested. This approach should be the new standard, especially with web applications as the origin of 39% of all data breaches these days.

Log4j might be one for the record books, but our products are on hand to help you test your web applications so that you know where to start. As more organizations race to patch their Java apps and frameworks or apply temporary mitigations as a Band-Aid, it’s clear that there’s little room to simply hope all of your assets are protected against future exploits.

Threats aren’t slowing down anytime soon. Issues with the software supply chain and new exploits are going to continue bubbling up to the surface, but how prepared you are to face them and how quickly you can respond is what will matter most to the bad guys who might already be inside the house.

Learn more about continuous application security with Invicti.