Cloud Security

What Log4j can teach us about cloud security

What Log4j can teach us about cloud security
Written by ga_dahmani
What Log4j can teach us about cloud security

log4j is causing a logjam of concern among cybersecurity professionals, but it should also be a wake-up call to improve your organization’s overall cloud security posture.

At this point, we’re all busy addressing threats that exploit vulnerabilities found in the Apache Log4j library, which is open source software used to communicate diagnostic messages to system administrators and network users. These vulnerabilities can include everything from delivering the ubiquitous 404 error message to logging routine events.

What makes this vulnerability so alarming is the widespread use of Log4j in all kinds of applications. It’s in popular games like Minecraft and in cloud server infrastructure, 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 logged every minute, according to some advocates monitoring the situation. Jen Easterly, director of the government office Cybersecurity and Infrastructure Security Agencycall it youThe most serious security flaw he has seen in his career and suggested that it could take years to fully address it.

Apache has released several patches to address the issue since it was first discovered, but beyond updates and patches, Log4j exposes the risks and responsibilities associated with the cloud’s shared responsibility model.

We need to accept that similar unknown vulnerabilities are almost certainly lurking and learn to live with this uncertainty. By paying more attention to configuring our cloud environments securely, we can make it harder for bad actors to exploit these vulnerabilities.

See also: The Successful CISO: How to Build Stakeholder Trust

Best practices to improve defense in the cloud

Any company trying to increase their cloud defenses in light of Log4j attacks should implement the following best practices:

Permanent credential phase-out

Static credentials have been set as 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 AM (identity and access management) user passwords.

That’s why the discovery of this vulnerability is a good opportunity to reconsider what those permanent credentials are for, which isn’t much. They’re convenient and replacing them would be a headache, so organizations only see the inconvenience, but that’s nothing compared to the pain of a major raid.

There are many good solutions; in AWS, for example, access keys for the command line interface (CLI) can be replaced with AWS Single Sign-On (SSO) or saml2aws, a tool that allows users to log in and retrieve temporary credentials. In a pinch, the system can use a vault to store and access AWS credentials securely in the operating system keychain.

It takes work to get rid of persistent credentials across an entire environment, but if there’s even the slightest chance that attackers could harvest those credentials, as seen in this latest incident, then it’s worth the effort. And in the future, avoiding any kind of static credentials when possible should become a good practice.

See Also: Secure Access Service Edge: Big Benefits, Big Challenges

Track third-party access and compliance

Supply chain Attacks are a hot topic for a reason: they pose a serious threat, but are often overlooked.

A light layer of control is often applied to third-party access, although it is an increasingly attractive attack vector for breaches. When third-party access is not managed properly, the consequences can be devastating, as Log4j demonstrated.

To maintain control, start by keeping track of vendor release notices regarding the Log4j vulnerability. Contact providers and ask directly if they have been exposed and how they are addressing that exposure. This should serve as a reminder for all companies to pay close attention to the security of their suppliers and monitor the identities of third parties that are used to access your environment and your rights.

you should too review your environment’s configurations, permissions, and logs for information about threats that might arise. And look for abnormal behavior by analyzing logs to detect malicious activity and prevent attacks before damage is done. For example, an escalation of privilege that goes beyond the user’s role should be flagged as abnormal and trigger an alert for 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 recommended. A more secure practice is to switch those users to a service that grants them access via a third-party role and external ID, and then disable those permanent access keys.

as welllight size permissions. This can reduce the lateral movements of an attacker using a compromised credential and limit damage. Monitoring permissions and activity logs for each identity will help generate least-privilege policy recommendations, so they are limited to performing only the functions they need without hurting productivity.

See also: Best website scanners

Intensify defenses

Assessing and remediating exposure to the Log4j vulnerability is an opportunity for organizations to step up defenses across the board. Use it to reassess controls and measure the security of your organization’s cloud environment to improve your posture before the next vulnerability is known—to defenders or, more importantly, to attackers.

About the Author:

Shai Morag, CEO, hermetic

About the author


Leave a Comment