What Log4j can teach us about cloud security

Log4j is causing a bottleneck among cybersecurity professionals, but it should also be a wake-up call to improve their organization’s overall cloud security posture.

Right now, we’re all busy fighting 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 spreading the ubiquitous 404 error message to routine event logging.

What makes this vulnerability so alarming is the widespread use of Log4j in all sorts of applications. It’s in popular games like Minecraft and cloud server infrastructure including Amazon Web Services (AWS) and Apple iCloud.

Since the flaw was discovered in December 2021, hundreds of attempts to use it to attack systems were being recorded every minute, according to some defenders monitoring the situation. Jen Easterly, director of the government’s Cybersecurity and Infrastructure Security Agency, called it youthe most serious security flaw she saw in her career and suggested it could take years to completely fix it.

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

We have to accept that there are almost certainly similar unknown vulnerabilities lurking, and learn to live with that uncertainty. By paying more attention to the secure configuration of our cloud environments, we can make it more difficult for malicious actors to exploit these vulnerabilities.

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

Best Practices for Better Cloud Defense

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

Phasing out permanent credentials

Static credentials were established as key access vector for attackers looking to break into cloud environments. It didn’t take long for bad actors to exploit the Log4j vulnerability to harvest cloud credentials for their own uses. Identity-based attacks using compromised credentials are particularly dangerous when systems rely on persistent 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 for, which isn’t much. They’re convenient, and replacing them would be a hassle, so organizations only see the downside, but that’s nothing compared to the pain of a major incursion.

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

It takes work to get rid of persistent credentials in an entire environment, but if there’s even the slightest chance that those credentials could be harvested by attackers, as seen in this latest incident , then it’s worth it. 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

Keep track of third-party access and compliance

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

There is often a slight layer of control applied to third-party access, although this is an increasingly attractive attack vector for breaches. When third-party access is not handled properly, the consequences can be devastating, as Log4j has demonstrated.

To stay on top of things, start by following vendor posting advisories regarding the Log4j vulnerability. Contact suppliers and ask directly if they have been exposed and how they are handling this exposure. This should remind all companies to pay close attention to the safety and security of their suppliers. monitor the third-party identities used to access their environment and their rights.

You should too Examine your environment’s configurations, permissions, and logs for information about threats that may arise. And look for abnormal behavior by analyzing logs to detect malicious activity and prevent attacks before the damage accumulates. For example, a privilege escalation that exceeds the user’s role should be flagged as abnormal and trigger an alert to defenders.

Limit excessive permissions

Review whether third parties need permanent user access keys to your organization’s environment and resources. Although this may be convenient, it is not advised. A more secure practice is to switch these users to a service that grants them access using a third-party role and an external ID, and then deactivate these permanent access keys.

Also, rsmall permissions. This can reduce the lateral movements of an attacker using a compromised ID and limit the damage. Monitoring the permissions and activity logs of 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

Strengthen defenses

Assessing and remediating exposure to the Log4j vulnerability is an opportunity for organizations to strengthen defenses at all levels. Use it to reassess the controls and assess the security of your organization’s cloud environment to improve your posture before the next vulnerability becomes known to defenders or, more importantly, attackers.

About the Author:

Shai Morag, CEO, Ermetic

Source link

Steven L. Nielsen