Who’s in charge of security in the public cloud?
It may sound like an odd question, but when working with a cloud provider such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform, it’s important to understand that security is a shared responsibility.
Public cloud providers offer customers a great deal of flexibility in how they build their cloud environments. The consequence of all this flexibility, however, is that providers don’t offer complete protection for virtual networks, virtual machines or data that’s in the cloud.
That shared responsibility model means cloud providers ensure security of the cloud, while the organization (the cloud provider’s customer, i.e. you) is responsible for anything run in the cloud. Now, admins don’t always know what the cloud provider takes care of, and the security controls they themselves must apply. This, as you can imagine, leads to exposed data, file, database and hard drive snapshots.
You might have heard of S3 bucket breaches – of which there have been many! But, this article series aims to break down the other big security-breach risks and how to protect against them, starting with the most common of all…
Public Amazon S3 bucket exposure (with a new twist)
You won’t have to look far to find stories of S3-related data breaches caused by misconfiguration, where S3 security settings were left set to “Public.” AWS has even released an update to help customers from running afoul of this, one of the biggest causes of cloud data breaches.
Reading about the thousands of cases out there, you’d be forgiven for thinking that attackers are only after an organization’s sensitive data in these attacks. Unfortunately, you’d be wrong.
In addition to financial and PII data, one of the main uses of cloud storage accounts like Amazon S3 buckets is to host static website content like HTML files, JavaScript and Style Sheets (CSS). Attacks targeting those resources aren’t targeting exposed data. Instead, they look to modify website files maliciously to steal user financial information.
A fork in the (attacker’s) road
Both attack chains look the same at the start, with attackers scanning the internet for misconfigured S3 buckets using automated S3 scanners. But this is where our attack paths diverge.
In your typical S3 data breach, attackers now list and sync the valuable contents to local disk and access all the data that was misconfigured in “public” mode.
In the case of our data modification attack: once access is gained, attackers look for JavaScript content and modify it to include malicious code. Now, when a user visits the infected website, the malicious JavaScript code loads, logging all credit and debit card details entered to payment forms. This data is then sent to the criminal’s server.
How to identify and prevent S3 bucket Exposure (both kinds)
Accidental or malicious changes to the S3 storage configurations that leave organizations exposed are all too common. Cloud Optix makes it simple to quickly identify any publicly accessible data or website files and make them private. It adds an additional level of security to these critical services with Guardrails, ensuring no configuration changes are made without permission.
Cloud Optix alerts you to exposed S3 buckets within minutes, providing contextual alerts that group the affected resources, provide a description of the issue, and remediation steps. These steps include the ability to auto-remediate – updating resource read/write permissions where S3 storage has been left open to the public internet.
Going the extra mile with AI capabilities to detect suspicious user login events, Cloud Optix alerts organizations if the contents of an S3 bucket is modified from an unusual location – suggesting that shared or stolen user credentials are being used remotely.
Whatever the end goal of an S3 service breach, these simple steps in Cloud Optix makes it simple to stay one step ahead of attackers.
