Why the FTC is telling companies to patch Log4j vulnerabilities

For cybersecurity workers, 2021 ended with a bang. On Dec. 9, a severe zero-day vulnerability was publicly disclosed in Log4j, a widely used Java logging utility. Dubbed Log4Shell, the flaw allowed an attacker to remotely gain control of a vulnerable device that used the utility. Given Java’s ubiquity, this meant that hundreds of millions of devices were at risk, ranging from servers for enterprise software, cloud hosting, and web applications, to consumer devices such as smart TVs and internet-connected security cameras. What’s more, the flaw was easy to exploit, rendering it accessible to bad actors with no need for high levels of skill, sophistication, or resources. The head of the U.S. Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, called the Log4j flaw one of the most serious vulnerabilities she’d ever seen.

As 2022 begins, the crisis shows no sign of abating. Remediation efforts continue, while attackers are probing systems looking for Log4j vulnerabilities. On Jan. 3,  security experts at Microsoft wrote that they expect this issue “to have a long tail for remediation, requiring ongoing, sustainable vigilance.” The company has already observed state-backed hackers from China, Iran, and North Korea attempting to exploit the Log4j vulnerability, and Easterly foresees that attackers will keep doing so “well into the future.” The coming year is likely to see more attacks on critical infrastructure, more ransomware attacks against public and private networks—and increased risk to the security of Americans’ personal, financial, and other sensitive data. That’s because, like it or not, private-sector companies hold vast amounts of information about us, on systems whose security is beyond our control. Yet the United States doesn’t yet have a generally applicable federal law that would impose minimum data security requirements on the private sector. So how will our government defend Americans’ data security against the Log4j threat?

In the absence of broad data-security rules, several U.S. regulators are stepping up to address Log4j. CISA, for example, has mandated that the sprawling array of civilian federal computer networks be updated to address the Log4j vulnerability. The deadline to do so was Dec. 23, but the work is ongoing. The Federal Trade Commission, for its part, is engaging with the private sector by warning companies that they could be subject to legal action if they fail to remediate the Log4j vulnerability.

On Jan. 4, the FTC published a blog post reminding companies that they have a legal “duty to take reasonable steps to mitigate known software vulnerabilities.” It threatened to bring the full force of the agency’s authority against “companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.” The warning cited the $700 million it cost Equifax to settle multiple enforcement actions stemming from a 2017 data breach that affected 147 million people due to the company’s failure to patch a known security vulnerability.

You might be wondering: why the FTC? And why Jan. 4, almost four weeks after Log4Shell’s public disclosure? CISA has been all over the Log4j vulnerabilities since at least Dec. 11. Indeed, the FTC’s post encourages companies to consult CISA’s guidance on mitigating them. What’s the use of this somewhat belated contribution to the conversation?

The reason is that the FTC has enforcement powers over private-sector wrongdoing that CISA doesn’t. By law, CISA’s remit is limited to the federal government and critical infrastructure, even though its alerts and guidance are used by others outside of those sectors too. Controversially, the young agency has little in the way of enforcement authority outside of the federal government; proposed expansions thereof still focus on critical infrastructure, not the private sector writ large. By contrast, the FTC has over 80 years of experience acting as the nation’s consumer protection watchdog. Federal law gives it the power to police and punish “unfair or deceptive acts or practices in or affecting commerce.” In recent years, the agency has relied on that authority to assume the mantle of Americans’ data-security defender. This application of its authority was challenged in court, but the agency prevailed. It’s brought multiple enforcement actions in the area of data security since then under both the “unfair” and “deceptive” prongs of the law. At this point, it’s well-established that shoddy cybersecurity is within the scope of the FTC’s enforcement powers.

In evaluating companies’ data security practices, the agency uses “reasonableness” as its touchstone. The trouble is that what’s “reasonable” or “unreasonable” is hard to pin down. Best practices change over time as both technology and threats evolve. A cybersecurity program that’s reasonable for a tiny company might be unreasonable for a huge one. And even otherwise comparable companies may not be similarly situated in a particular circumstance such as the Log4j issue: There’s a difference between companies that make the conscious decision not to patch Log4j and just accept the risk (to themselves and their customers), those that can’t patch for whatever reason, and those that don’t patch because they don’t even realize they use Log4j. The FTC’s blog post doesn’t draw these distinctions, but they should factor into any FTC analysis of whether to institute enforcement proceedings over Log4j lapses.

If a company has no way of knowing that the FTC considers a particular security practice “unreasonable,” that’s a problem for the agency. An important concept in U.S. law is that of “notice”: Everyone has the right to know, in advance, what conduct will subject them to government punishment, so they can conform their behavior accordingly. It’s not OK for the government to penalize conduct which it hadn’t put the public “on notice” was illegal.

That’s why the FTC must give notice of what business acts or practices are “unfair” under the law. It can do this by formally promulgating rules or by litigating on a case-by-case basis to establish an act or practice as “unfair.” In the cybersecurity context, companies targeted by the FTC have sometimes argued that the agency hadn’t given fair notice that their security practices were unreasonable. Sometimes the courts have rejected this argument, as in the FTC’s case against Wyndham Hotels, which had been hacked three times and had used security practices that the FTC had specifically denounced in its prior guidance and adjudications. Since the agency hasn’t batted a thousand in court, however, in the last few years it’s made an effort to improve its data security guidance to companies.

It’s this history that underlies the Jan. 4 missive, which the FTC’s chief technologist’s office posted to the “Tech@FTC” blog and disseminated on social media. I interpret this as the FTC’s attempt to put the country on notice that failure to patch the Log4j vulnerabilities risks subjecting a company to punishment. That said, as one cybersecurity law scholar observed, a blog post by the chief technologist’s office does leave something to be desired in terms of formality. That could leave the FTC open to the argument that the blog post doesn’t provide sufficient notice, unlike, say, official agency rulemaking. Nevertheless, should any company subsequently claim it didn’t know it was supposed to patch a flaw that’s typically been described in terms that “border on the apocalyptic,” the FTC can point to this warning, together with its other, formal past actions such as the Equifax proceeding, to refute that assertion.

It shouldn’t take an FTC warning to induce recalcitrant companies to finally do something about Log4Shell, and this missive may be mostly preaching to the choir. When the whole world is freaking out about a vulnerability, it doesn’t require a keen legal mind or nuanced technical understanding to realize that choosing to sit on your hands may very well be unreasonable. This vulnerability is serious enough that any company inclined to care about its own and its customers’ data security had probably already acted in the several weeks before the FTC spoke up.

And yet the FTC’s Equifax example makes it foreseeable that some companies will indeed fail to patch Log4j, perhaps even big, sophisticated ones with full-fledged IT departments. Since it can foresee the need to go after them later, the FTC is laying the groundwork now, as the government-savvy hacker Mudge noted on Twitter (where he’s currently head of security). Put another way, the Jan. 4 warning may be intended less as an urgent news flash and more as a belt-and-suspenders measure to paper up the foundation for a successful enforcement action if and when the time comes.

The warning should help to ensure that if any companies cry “no notice” in future FTC proceedings over Log4j, the outcome won’t be in question. What does remain to be seen, however, is how many American consumers will suffer harm due to critical but remediable security vulnerabilities in the interim. Some of that harm may stem from flagrant dereliction of duty by certain companies, and the FTC would be justified in making examples of them.

But some consumer harm may be born more of haplessness than recklessness. Businesses need a process to identify, prioritize, and address known flaws in the software and systems they use, plus a mechanism to contractually require the same of their vendors and other third-party partners. Sophisticated companies have these things in place already, but in a business landscape full of small- and medium-size firms, not everyone operates on that level, and some of the inevitable failures to patch Log4j will happen because of this.

The FTC should respond to Log4j by increasing the assistance it provides to companies for prevention of harm, not just by punishing lapses after the fact. The agency maintains multiple free resources for businesses, such as the “Start with Security” guide from 2015, which synthesizes lessons learned from the agency’s past data-security cases, and the Cybersecurity for Small Business resource center, developed in partnership with several other federal agencies. Similarly, the FTC could partner with CISA and/or other relevant agencies to develop a set of lessons learned from Log4j. Valuable insights may arise from agency discussions with companies that struggle to remediate Log4j. Working to understand why some companies struggled is more productive, in the long run, than lumping everyone who doesn’t patch together with the truly reckless shirkers.

In short, the Log4j incident is a learning opportunity for the FTC, not just for companies. The blog post seems to recognize as much, ending with the note that the agency is working “to address the root issues that endanger user security.” Yes, companies that knowingly play fast and loose with consumers’ data, even after the FTC’s warning, deserve to be investigated. But an ounce of prevention is worth a pound of cure. The agency can make the best of a bad situation by turning what it learns from this cybersecurity incident into actionable guidance that can help companies weather the next one. Use your Log4j response as a chance to help, not just to warn—that’s my New Year’s resolution for the FTC.

Riana Pfefferkorn is a research scholar at the Stanford Internet Observatory.

Microsoft provides financial support to the Brookings Institution, a nonprofit organization devoted to rigorous, independent, in-depth public policy research.