Authors: Aditya K Sood and Rehan Jalil
Overview
In recent years, the community has encountered a number of data exposure incidents in the cloud that could have resulted in significant security breaches, and thereby incurring financial losses to the organizations. One of the repetitive patterns of unauthorized data exposure is the availability of sensitive data through AWS S3 buckets. These data exposure incidents could be a result of erroneous approach by the employee, infrastructure misconfiguration, malicious insider attack or targeted attack by a remote adversary. In all cases, the sensitive data is found to be exposed on the Internet through AWS S3 buckets.
A number of serious data exposure incidents are highlighted below:
The incidents listed above are some of the critical ones in the recent times. Untracked cloud data movement and misconfigurations are playing crucial role in exfiltrating enterprise data from the cloud.
AWS S3 Buckets: Threat Model
Let’s quickly take a look at Simple Storage Solution (S3), which is heavily used by cloud companies for data storage. Generally, the buckets are deployed using S3 which are logical units for data storage in AWS. There is no limit on the number of objects that can be stored in the associated S3 bucket. The buckets hold the storage objects as primary data and associated meta data. The data transactions occur by moving data in and out of the system.
The question that comes to play is, how is this storage secured? AWS provides mechanism to restrict access by defining privileges using AWS policy generator by defining bucket policy. However, with the use of Identity Access Management (IAM) user policy in conjunction with bucket policy, explicit access controls can be deployed to restrict access to authorized users only. This security mechanism needs to be implemented at an infrastructure and application level.
AWS S3 buckets can be either public or private. If the bucket is private, the remote user will encounter “Access Denied,” otherwise a number of objects will be revealed if the buckets are public. A definitive S3 URL pattern exists that can be used to detect the access right on the buckets. More importantly, the critical point is that, AWS controls follow shared responsibility model in which it is expected that the customers should configure and deploy available security controls as per the configured network. The data exposure via AWS S3 buckets can be considered as a deviation in the secure deployment of shared security controls.
That being said, the adversaries can deploy different techniques to detect publicly exposed AWS S3 buckets. Figures shown below highlights how the S3 buckets (storage instances) can be detected in an automated manner:
The records (as example shown above) are found to be publicly exposed on the web and an attacker could have accessed the data using AWS S3 bucket fingerprinting techniques such as URL fuzzing or search engine dorking as shown above. It can be also seen that a number of buckets are throwing “Access Denied” notifications which means these buckets are not publicly available.
Data exposures via AWS S3 buckets raise a very practical problem that organizations are facing, which is how to secure data in the cloud. Considering the security incident above, apart from strong security access controls, additional questions need to be answered:
-
How are data transactions monitored from the AWS S3 buckets and associated user accounts?
-
How often is this data accessed and by whom and from which location?
-
Are there any policies configured to determine whether data transactions hit the threshold or not?
-
How can you make sure that data governance and compliance controls are followed even if the cloud app[s] are approved?
Cloud App Visibility Parameters
One of the most important considerations is to have visibility into data that is being uploaded and downloaded to cloud apps. The challenge of attaining visibility into data transactions in cloud apps is becoming a persistent problem in enterprises. As a result of this, data transactions in cloud apps are executing under a non-transparent hood and the associated transactions are not visible to enterprises. To unveil security risks associated with shadow data residing in cloud apps, extensive visibility is desired considering the following parameters:
-
Identity: To determine “Who” is performing data transactions in cloud apps
-
Timeline: To determine “When” data transactions are performed in cloud apps
-
Purpose: To determine “Why” data transactions are performed in cloud apps
-
Technique: To determine “Which” tactics are opted to perform data transactions in cloud apps
-
Movement: To determine “How” data transactions are performed in cloud apps
-
Classification: To determine “What” types of data transactions are performed in cloud apps
These are also called “Visibility Parameters.” Detection and monitoring of “Shadow Data” transmission from an enterprise to a public cloud is only possible with a Cloud Access Security Broker (CASB) like Symantec CloudSOC in place. For strengthening the security posture of cloud apps in enterprises, granular visibility into identity, timeline, purpose, technique and movement of data is needed.
A few quick tips to secure cloud apps are discussed below:
-
Discover Shadow Data / IT – apps and IT solutions used by employees without the company’s authorization.
-
Detect risky cloud app activities and users – zero in on threats without sifting through billions of data records. Symantec CloudSOC does this in a unique way by using advanced machine learning and data science to detect these activities.
-
Protect cloud apps – enforce policies across multiple cloud services at the same time. This allows you to prevent attacks and ensure corporate governance.
-
Perform post-incident investigations and forensic analysis – analyze all historical transactions for your cloud applications and services. This allows you to perform deep dive analysis for legal, compliance or HR initiatives, ensuring cloud-based data is no longer outside the sphere of enterprise analysis.