FTC words of warning: Remediate recent Log4j vulnerabilities or face consequences

In an unusual and noteworthy move, the Federal Trade Commission (FTC) issued an early warning to companies that haven’t yet patched recent Log4j vulnerabilities: remediate or risk legal and financial consequences.

As noted by the FTC, the recent Log4j vulnerabilities are still being actively exploited by malicious actors, posing “severe risk” to the thousands of organizations and agencies running applications that use the affected library. The warning, though ominous, brings much-needed attention to the serious impacts of recent Log4j vulnerabilities and the need for continuous application security.

A brief history of the Log4j vulnerabilities

For the range of its impact alone, the recent Log4j CVE-2021-44228 vulnerability might be the worst software flaw we’ve ever seen. First reported on December 9th, 2021, the vulnerability is incredibly easy to exploit with just a few steps. Once an attacker is in, they may further escalate the attack to install ransomware, steal precious data, and even jump from server to server.

Sometimes referred to as Log4Shell, the flaw impacts Apache Log4j, an extremely popular Java logging library that has been in use since 2001. NIST’s National Vulnerability Database has the flaw categorized as critical, meaning it is a high-severity vulnerability that requires immediate action.

When this Log4j vulnerability hit the news and set off shockwaves through the industry, it prompted an emergency directive from the Cybersecurity & Infrastructure Security Agency, which encouraged mitigation. This comes on the tailwind of additional efforts from the United States Government to improve the nation’s security posture, such as the Biden administration’s EO on cybersecurity the FISMA update.

Unpacking the FTC’s tale of caution

It’s a bit unusual for the FTC to step in on repercussions for software vulnerabilities, but a precedent for such legal action exists. Following the Equifax breach in 2019, all 50 U.S. states, the Federal Trade Commission, and the Consumer Financial Protection Bureau reached a settlement when it came to light that Equifax failed to properly secure their network.

That failure, the settlement said, stemmed from a lack of basic measures outlined by the Gramm-Leach-Bliley Act’s Safeguards Rule for protecting customer data. At the end of the day, data breaches are costly – money, time, and brand trust can quickly swirl down the drain when you’re caught with a dangerous flaw like Log4Shell in your code.

If you don’t yet have a handle on the Log4j vulnerability, don’t panic. The FTC has guidelines for checking on whether or not you use the impacted library in your applications, and what to do if you find it. First and foremost, you need to update the Log4j software package to ensure you’re running the most recent version, and inform end users so that they’re aware you’re monitoring the situation and updating impacted software.

The FTC also recommends you pay close attention to tips outlined by CISA, which include deeper guidance on mitigating this flaw and conducting security reviews to determine whether your application data has been compromised. From there, it’s all about improving your response time and crafting a more effective security strategy for the future.

Cover your bases with Invicti

Invicti has a handle on Log4j: Netsparker and Acunetix allow for configuration of a scan policy that contains Log4j security checks to help you find and fix the issue fast. We’re assisting customers as they figure out a plan and decide how to start looking for this flaw, plus we offer up simple tips for customers configuring Netsparker and Acunetix scans to find vulnerable Log4j implementations.

Invicti’s powerful platform of scanning and reporting tools helps development, security, and operations teams cover every corner of every app, which becomes a huge time-saver when you have thousands of web assets in your inventory. Opting for continuous AppSec with complete coverage is important, with the tools and processes in place to quickly react when the next flaw hits the news.

To stay one step ahead of new threats like the recent Log4j vulnerabilities, implement a discovery service that scans all known web-facing assets across company domains and subdomains. Having insight into that central inventory is the first step to knowing what you need to scan, and how often you need to do it. Once you’ve identified your attack surface, you can automate scanning for all of your applications, in development and production. One thing that Log4j has taught us is that software that is deemed secure one day may not be so secure the next. Accurate, automated and continuous testing is required to minimize the risk of data breaches.

As you formulate your own Log4j response strategy, we’re here to help. Browse our Log4j resource center for the most recent news and resources around handling this flaw, including a helpful FAQ that can answer common questions.