The high-profile Log4Shell exploit, which your organization should be aware of, offers a great reminder of the need to build a maintenance strategy.
When it comes to digital risks, it’s often the hangers-on that cause the biggest problems.
And a recent exploit involving a piece of software your association probably doesn’t realize it uses is a timely reminder of an organization’s fundamental responsibility to ensure its applications are being properly maintained.
What’s the Issue?
Recently, a “zero-day” (i.e., already in the wild) vulnerability in Log4j, a common Java-based logging tool found in many web-based hosts, emerged as a significant risk for many website owners. The exploit, known as Log4Shell, allows for the execution of arbitrary code by third parties. Many popular services, such as Amazon Web Services and Apple’s iCloud, were initially affected.
Because of its wide use in a diverse array of applications, the exploit is being called one of the worst in the history of the internet. And it’s putting organizations large and small on high alert.
“It’s a very, very serious issue,” said Justin Cappos, an associate professor at New York University’s Tandon School of Engineering, in comments to Yahoo Finance. “Since it’s part of the software supply chain, many different pieces of software can be affected.”
What’s the Lesson?
In cases like these, immediacy matters (and yes, you should take steps to fix this), but so does preventive maintenance. This issue became such a big problem for so many organizations because of a fundamental failure to understand the underlying technology they use.
This is an important lesson, but it’s not the first time it’s been taught. In 2014, for example, the tech world ran into a very similar problem with an exploit called Heartbleed—an exploit so significant it essentially became branded—which harmed the security protocol OpenSSL. But unlike using OpenSSL, it’s often not even transparent whether your technology stack uses Log4j, making it potentially even more insidious.
The job of associations here is to understand just what is lying under all those applications they use, and whether those applications have issues that could lead to security problems down the line.
What’s the Potential?
You can take practical actions to gain clarity around what exactly is in your software, so a problem like Log4Shell doesn’t catch your organization off guard. For example, using a software bill of materials, effectively an ingredients list for your applications, could help your organization ensure that industry partners are being forthright about the tools underscoring the applications they operate.
This type of detection can be automated as well, through tools such as firewalls.
But ultimately, as useful as a software bill of materials can be, it doesn’t take your organization off the hook in case of an exploit. After all, as a recent quiz of ours highlighted, the buck often stops with your association when privacy or data issues emerge—not with your vendors. As a result, your association needs to take these issues seriously and ensure it’s not guessing about whether your tools harbor a potential problem.
(NIRODESIGN/ISTOCK/GETTY IMAGES PLUS)