eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Log4j is causing a logjam of concern among cybersecurity professionals, but it should also be a wake-up call to improve their organization’s overall cloud security posture.
By now, we’re all busy addressing threats that exploit vulnerabilities found in the Apache Log4j library, which is an open source software that’s used to communicate diagnostic messages to system administrators and network users. These vulnerabilities can include everything from serving the omnipresent 404 error message to logging routine events.
What makes this vulnerability so alarming is the widespread use of Log4j across all kinds of applications. It’s in popular games like Minecraft and in the infrastructure of cloud servers, including Amazon Web Services (AWS) and Apple iCloud.
Since the flaw came to light in December 2021, hundreds of attempts to use it to attack systems were being logged every minute, according to some defenders monitoring the situation. Jen Easterly, the director of the government’s Cybersecurity and Infrastructure Security Agency, called it the most serious security flaw she’s seen in her career and suggested it could take years to fully address.
Apache has released several patches to address the issue since it was first spotted, but beyond updates and patches, Log4j exposes the risks and responsibilities associated with the cloud’s Shared Responsibility Model.
We need to accept that there are almost certainly similar unknown vulnerabilities lurking out there and learn to live with this uncertainty. By placing more attention on securely configuring our cloud environments, we can make it more difficult for bad actors to exploit these vulnerabilities.
Also see: The Successful CISO: How to Build Stakeholder Trust
Best Practices for Improved Cloud Defense
Any enterprise trying to step up their cloud defenses in light of the Log4j attacks needs to implement the following best practices:
Phase Out Permanent Credentials
Static credentials have been established as a key access vector for attackers looking to breach cloud environments. It didn’t take long for bad actors to exploit the Log4j vulnerability to scrape cloud credentials for their own uses. Identity-based attacks using compromised credentials are especially dangerous when systems rely on permanent credentials such as IAM (identity and access management) user access keys.
That’s why the discovery of this vulnerability is a good opportunity to reconsider what those permanent credentials are good for—which is not much. They are convenient, and replacing them would be a headache, so organizations only see the inconvenience, but that is nothing compared to the pain of a major incursion.
There are many good solutions; in AWS for example, access keys for command-line interface (CLI) can be replaced with AWS single sign-on (SSO) or saml2aws, a tool that lets users login and retrieve temporary credentials. In a pinch, the system can use a vault for storing and accessing AWS credentials securely in the operating system’s keychain.
It takes work to get rid of permanent credentials in an entire environment, but if there’s the slightest chance that those credentials could be harvested by attackers, as seen in this latest incident, then it’s worth the effort. And going forward, avoiding any kind of static credentials when possible should become a best practice.
Also see: Secure Access Service Edge: Big Benefits, Big Challenges
Keep Track of Third-Party Access and Compliance
Supply chain attacks are a trending topic for a reason: They represent a serious threat but are often overlooked.
There is often a light layer of control applied to third-party access, even though it’s an increasingly attractive attack vector for breaches. When third-party access is not managed correctly, the consequences can be devastating, as Log4j demonstrated.
To maintain control, start by keeping track of vendor release notices regarding the Log4j vulnerability. Contact vendors and ask directly if they were exposed and how they are addressing that exposure. This should serve as a reminder to all enterprises to pay close attention to their vendors’ security and monitor third-party identities being used to access their environment and their entitlements.
You should also review your environment’s configurations, permissions, and logs to gain insights on the threats that could arise. And look for anomalous behavior by analyzing logs to detect malicious activity and head off attacks before damage mounts. For example, an escalation of privileges that’s beyond the user’s role should be flagged as anomalous and trigger an alert to defenders.
Limit Excessive Permissions
Reconsider whether third parties need permanent user access keys to your organization’s environment and resources. While this may be convenient, it is not advisable. A more secure practice is to switch those users to a service that grants them access using a third-party role and external ID, then disabling those permanent access keys.
Also, right-size permissions. This can reduce the lateral moves of an attacker using a compromised credential and limit the damage. Monitoring each identity’s permissions and activity logs will help generate least privilege policy recommendations, so they are limited to performing only the functions they need without harming productivity.
Also see: Best Website Scanners
Stepping Up Defenses
Assessing and remediating exposure to the Log4j vulnerability is an opportunity for organizations to step up defenses across the board. Use it to reevaluate controls and gauge the security of your organization’s cloud environment to improve your posture before the next vulnerability becomes known—to defenders or, more importantly, to attackers.
About the Author:
Shai Morag, CEO, Ermetic