Log4j: We Have to Talk About This
By now compliance and audit professionals may have heard about the cybersecurity vulnerability called Log4j. This will foremost be a problem for IT security officers; but Log4j also illuminates a lot of challenges that audit, compliance, and risk management challenges will face in the 2020s. So let’s unpack the issues afoot here.
First, the background. Log4j is a piece of software that has existed in one form or another for 20 years. As the name implies, its purpose is to log activity on IT systems. A programmer might include Log4j in a larger piece of software — a website, an application, a device’s operating system — to log activity on that system and store those records somewhere else. Should that IT system later malfunction, you can then retrieve the activity logs to see what was happening.
Two other details are important. First, Log4j is open source software; that means it is freely available for any person or organization to use (and modify) as they see fit. Second, Log4j has been very popular over the years. It’s one of the most popular logging tools in the software business, embedded into everything from Microsoft to Minecraft, iCloud to IBM, and countless other apps and devices in between.
The crisis began in November, when a researcher at AliBaba in China discovered a flaw in Log4j code that had existed since 2013. To make a long story short: an attacker could feed a false string of text to a server that uses Log4j. Log4j would then log that text — but the text would actually be processed as a command to connect to a server under the attackers’ control.
With that connection in place, the attacker would be able to take control of your system that’s running Log4j. From there, the attacker could cause all manner of trouble: launch a ransomware attack, use your server for bitcoin mining, steal data, pass malware along to any visitors to your IT system, and so forth. Potentially, the attacker could even execute commands such as authorizing wire transfers overseas.
The AliBaba researcher took his discovery to Apache Software Foundation, the group that nominally “owns” the Log4j software code. Apache developed a patch for the vulnerability. Apache then released news of the vulnerability and the patch in mid-December.
Now there’s a race. On one side are the attackers, who know about the Log4j vulnerability and are probing every corporate IT system they can find, to see whether they can use the vulnerability before the target company installs the patch. On the other side are the corporate IT departments, racing to patch every instance of Log4j in their extended enterprise, before the attackers find and exploit a vulnerable system.
That’s where we are right now.
What Log4j Means to Compliance and Audit
As I mentioned at the start, Log4j is foremost an IT security problem, because corporate IT teams do the actual patch implementation. That said, it’s a compliance problem, too. Just this week the Federal Trade Commission published an alert warning companies that they must remediate Log4j, and could even face enforcement actions if they don’t. Specifically:
“The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act … 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.”
Um, yikes. That message is clear. Companies need to remediate Log4j, pronto. To do that, however, corporate enterprises will need to use a strategy that relies heavily on audit, compliance, and third-party risk management tactics.
For example, if you want to eradicate the Log4j threat from your enterprise, you’ll need to assure that all the cloud-based technology providers your company uses have implemented the Log4j patch. Well, how will you do that? What capabilities do you have to perform security audits on those providers? What assurances will you accept from them as proof that they’ve already addressed the problem?
Moreover, you’ll need to extract this assurance with individual third parties, and then manage all that assurance at scale — because most large organizations have hundreds of third parties (if not more) connected to their IT systems. Being able to prove that your company has tamed the Log4j threat will be critical to keeping customers, auditors, and regulators happy; but that means you’ll need sophisticated capabilities for vendor risk assessment, escalation, documentation, and related tasks.
You can see the issue here. Your company needs a clear set of policies, procedures, and tools to address third-party cybersecurity risks. Log4j is the risk of the moment, but others will follow in the future.
In a certain sense, then, while Log4j is a regulatory compliance issue right now (see Federal Trade Commission, above, sending out threatening news alerts), it can also help audit and compliance officers to have more productive conversations with boards and operating units about cybersecurity issues.
For example, you could use Log4j to impress upon the board that cybersecurity risk, third-party risk, and operational risk are now functionally all the same thing. The board and senior executives, therefore, should think more about how to manage this morass of risk holistically, for the long term and at an enterprise level, rather than dwelling on specific questions such as “Have we eradicated our Log4j risk?”
Likewise, you can impress upon operating units in the First Line of Defense that taming third-party cybersecurity risks is a competitive advantage. If you can efficiently document your governance over these challenges, and then pass along that evidence to any sales prospect who asks about Log4j or whatever comes next — that makes your company more attractive to customers. Your ability to govern third-party risks strengthens the sales closing process.
Emphasize that point. It’s not going away any time soon.