 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
It’s not like the four — count ’em, four — Log4j security vulnerabilities aren’t more than just trouble in and of themselves. Just check in with the Belgian defense ministry to see what they have to say about it. Now, the U.S. Federal Trade Commission (FTC) has issued a warning that it will punish companies that don’t fix the Java logging package Log4j security problems.
Specifically, if the Log4j (CVE-2021-44228) security hole leads to a “loss or breach of personal information, financial loss, and other irreversible harms,” the FTC may take legal action against your company. “The FTC intends to use its full legal authority to pursue 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.”
No pressure!
The FTC wants to make sure there’s not a repeat of the Equifax fiasco. In this security disaster, credit-giant Equifax lost over 100-million names, social security numbers, birthdates, and home addresses to a hack. The reason? Equifax hadn’t bothered to keep Apache Struts up-to-date with the latest security patches. As security expert SwiftOnSecurity said at the time it was a classic case of “Pretty much 99.99% of computer security incidents are oversights of solved problems.”
Log4j is different. While the patches came out in time, finding Log4j libraries in our source code or binaries isn’t trivial. There are scanning tools to find unpatched Log4j libraries, but none of them can spot all such insecure instances.
In the Equifax and Struts case, the blame was correctly put on the company. They simply did a crappy job of maintaining their software and got caught out by a nasty, but patched, security bug. In the end, this cost Equifax $700-million in fines.
With Log4j companies really can say they didn’t know that the problem existed until it was too late. Now, whether the FTC will listen to such an excuse is another question entirely.
If you aren’t already logging all your Log4j remediation efforts, now’s the time to start. Even if the FTC doesn’t come knocking on your door, it’s all too possible that if a customer gets burned by your software having an unfixed Log4j problem, their lawyers will come after your scalp.
What’s more concerning is that the FTC is also casting doubt on open source software itself. The Commission concluded:
“The Log4j vulnerability is part of a broader set of structural issues. It is one of thousands of unheralded but critically important open source services that are used across a near-innumerable variety of internet companies. These projects are often created and maintained by volunteers, who don’t always have adequate resources and personnel for incident response and proactive maintenance even as their projects are critical to the internet economy. This overall dynamic is something the FTC will consider as we work to address the root issues that endanger user security.”
That vital open source software needs more support is no news. If you’re a developer, you know the xkcd cartoon about the tiny, but vital program is being maintained by a person in Nebraska who’s been thanklessly maintaining it since 2003. To take care of such issues, the Linux Foundation‘s Open Source Security Foundation (OpenSSF) job is to find those little under-supported projects and make sure they get the help they need to keep the lights on and the code safe.
While this is a real problem, the reason why Log4j is such a big deal is that thanks to how Java packages its code it’s very difficult to find the vulnerable library to patch it.
