Prominent examples of misconfigurations from top cloud providers, and guidance to rectify them.
Details matter when it comes to keeping an organisation cyber-secure: security controls need to be consistent and robust down to the smallest detail. In contrast, exploitation of an enterprise’s defences only takes one or two weaknesses to gain a foothold. It’s no wonder adversaries keep finding ways in.
This is especially true in cloud environments, where the confluence of massive amounts of data and many users manipulating it can lead to misconfigurations that malicious parties can exploit to gain access to sensitive information.
Without vigilance, these security lapses can cause tremendous financial, reputational and collateral damage. Just this year, multiple high-profile data breaches stemming from the lack of multi-factor authentication (MFA) enforcement cost the affected companies tens of millions of dollars in ransomware payments. They also risked the exposure of more than 100 million customers’ information to the dark web.
While these exposures were extreme in scale, their causes are shockingly common. In fact, the 2024 Elastic Global Threat Report from Elastic Security Labs found that nearly half of security failures in Microsoft Azure and Google Cloud environments were due to encryption and account misconfigurations.
Some of these are easy to fix with configuration changes, while other findings indicate the need for more stringent policies and monitoring to prevent users from inadvertently increasing their risk of successful attack.
Google Cloud Platform – CMEK for BigQuery
The most common data exposure risk for companies using Google Cloud Platform (GCP) stems from the misconfiguration of encryption in BigQuery, a cloud offering used to store and search data for many use-cases. Organisations use BigQuery extensively to manage some of their most critical datasets, typically for the analysis of large datasets, running reports, and integrating them into machine learning models. Its widespread use, and often rich information makes it a prime target for attackers.
The overwhelming majority of failed security checks involving this service are linked to users running BigQuery tables without using customer-managed encryption keys (CMEK). CMEK is vital because it gives greater control over encryption key material leveraged in their cloud environment, specific to their dataset.
With CMEK, the customer can choose when to rotate, destroy or disable the encryption keys, adding an extra layer of security, and of course, manage the privacy of key material outside of the Cloud providers’ scope of control.
The first step to keeping data in GCP locked down is managing general access policies for BigQuery datasets, preventing anonymous or public access. To avoid the risk of exposure to BigQuery datasets, stringent organisational policies are needed to enforce the use of CMEK for as many supported services as possible.
GCP – CSEK for Virtual Machines
Another prevalent security misconfiguration in GCP involves virtual machines (VMs). As companies move more of their workloads to the cloud, VMs are growing in popularity as a way of scaling resources with greater elasticity, and also to provide isolated environments for code development and testing.
However, misconfigurations in virtual machine security and host policies can expose critical workloads to a variety of attacks, including unauthorised access. One of the most common mistakes is the failure to enable customer-supplied encryption keys (CSEK), a misconfiguration responsible for about half of the security failures in GCP virtual machines.
Like CMEK, CSEK’s are critical for data privacy because they restrict data access to the customer, giving them complete control over its encryption.
Again, CISOs must be steadfast in their policies to enforce CSEK, while securing virtual machines with up-to-date patching and updates and features like shielded VMs and disk encryption.
Amazon Web Services – MFA Delete in S3
One of the most commonly misconfigured components of Amazon Web Services (AWS) is its Simple Storage System (S3), an AWS object storage service that allows users to store and retrieve data. Enterprises use S3 for a wide variety of applications, including backup and restore, disaster recovery, archiving, data lakes and big data analytics, hybrid cloud storage and content distribution.
The most frequent security lapse in S3 configuration is the failure to enable MFA for delete privileges, making it easier for adversaries that have gained access to valid credentials to delete or modify content stored within the service.
In addition to this, many organisations fail to configure S3 buckets to block public access, exposing them and their potentially sensitive data to unauthorised users. While there are legitimate use cases where this is a requirement, ensuring policies are configured to least-privilege standards remains a priority.
Single-factor access is no longer an acceptable policy when it comes to enterprise cloud access. To maintain tight data security, CISOs must be adamant about enforcing MFA across their environment, with a particular focus on users with elevated privileges.
AWS – Remote Network Access
After S3 misconfigurations, the next most prominent security failure in AWS involves networking issues, and most prevalent among these is the misconfiguration of ingress access to networks hosted in AWS.
In these instances, the policies attached to resources permit traffic from any IP address or port, administrative or otherwise, to access virtual private cloud (VPC) networks, potentially exposing applications running on Amazon’s EC2 virtual servers.
CISOs must continue to take great care in ensuring network access is restricted to only trusted IP addresses and necessary ports to prevent threat actors from conducting vulnerability scans and fingerprinting web servers on which to run remote access breaches.
Microsoft Azure – Storage Account Misconfigurations
As is the case with AWS S3, the most common security-compromising misconfigurations in Microsoft Azure involve storage accounts, which serve as critical components of many enterprises’ cloud environments, providing scalable storage for a wide range of data. Unlike GCP and AWS, however, no single misconfiguration stands out as the primary culprit for vulnerability exposure.
Instead, there are numerous commonly misconfigured settings in Azure that threat actors can exploit to gain access. Chief among these are the failure to enable infrastructure encryption for each storage account, and not limiting storage account access to private endpoints.
CISOs in charge of Azure environments therefore should begin by ensuring their sensitive data at rest is protected with a second layer of encryption, as this serves as the last line of defense against intrusion and theft if other security measures are disabled. They must also restrict access to Azure virtual networks to only private and trusted endpoints.
Ultimately, each of these security shortcomings comes down to a matter of policy rigor. Every top cloud service provider offers the requisite safeguards to limit storage and network access privileges, and to empower users with all the authority to encrypt and decrypt their data. It’s up to CISOs to choose safety over convenience and enforce the strictest possible regulations on their platforms and their users.
Written by
Jake King
Chief Security Officer
Elastic