One of the major concerns when moving to the cloud is how to approach Amazon S3 security. Companies may have moved their workflows to Amazon, but are still cautious about moving their data warehouse.
And that is totally understandable. We have all heard about data breaches in companies like Facebook, GoDaddy, and Pocket. It’s important that access to information is done properly, in a limited and controlled fashion, to avoid such breaches.
In this article, we’ll cover how to enhance Amazon S3 security and how to enable CloudTrail audit events for this service. We’ll also explain how to perform AWS Thread Detection with Cloudtrail and introduce our free to use Sysdig Cloud Connector, so you can detect suspicious activity and react as soon as possible.
Why you need to secure Amazon S3 resources
One of the main benefits of moving storage to the cloud is that people can access and use that data via the Internet. Technology offers the perfect environment for data collaboration and monetization, because data sharing is considerably more difficult in non-cloud environments.
However, you need to be careful setting up the cloud services, as a misconfiguration may leave your data on the cloud unprotected. For example, checking the wrong box could change the access controls of your S3 resources unknowingly, making that data publicly accessible.
That’s why you need to continuously secure your data, and set up the proper tools, to keep incidents from becoming big security issues.
Supervise access control to your Amazon S3 resources
By default, all Amazon S3 resources like buckets, objects, and related subresources are private. That means that only the resource owner, the AWS account that created it, can access the resource.
However, there are cases where you may want to make your data public, like static files of a website. For that, Amazon S3 offers access policy options that resource owners can use to change access.
Access policy options are broadly categorized as:
- Resource-based policies: Access policies you attach to your resources (buckets and objects) are referred to as resource-based policies. For example, bucket policies and access control lists (ACLs) are resource-based policies.
- User policies: You can also attach access policies to users in your account.
You may choose to use resource-based policies, user policies, or a combination of these two to manage permissions over your Amazon S3 resources.
Unfortunately, some bucket access control lists (ACL) combinations make your resources very easily accessible publicly. Misconfigured ACLs are one of the biggest reasons why S3 data leaks are so widespread, which is why AWS recommends against using them.
Managing the access to Amazon S3 resources is the cornerstone of a strong cloud data storage security governance.
Record S3 events in CloudTrail
With AWS CloudTrail enabled, we can capture information on all requests made to an Amazon S3 resource, such as ListObjects, PutObject, GetObject, DeleteObject, and DeleteObjects. Every action taken over your infrastructure resources results in a registry in AWS CloudTrail.
These audit logs are the first step to detect suspicious activity involving our AWS resources, and implement Amazon S3 security.
Now, let’s see how to enable S3 CloudTrail events.
The following steps take on the assumption that you already have deployed CloudTrail and are monitoring the audit events. We recommend you try our AWS Workshop, where we offer tailored step-by-step instructions on how to use CloudTrail for cloud security.
The first step would be to create an S3 resource in your AWS account, if you haven’t already. Feel free to create a bucket, or upload a test file to your bucket.
The second step would be to enable data events for S3 resources in CloudTrail.
For that, edit your CloudTrail trail.
From there, mark the Data events checkbox and select S3 as the event source.
At the bottom, you can specify what buckets to audit. Whether to audit all buckets, or just those you want to control their access. You can also specify differentiated read and/or write access for each one.
Also, make sure your trail has enabled Management events and Data events, as well as Read and Write API activity.
Remember that when creating or editing a trail, it may take up to 10 minutes for new events to appear. But don’t worry; events during that period are buffered and not lost.
Now, we are set. When an authenticated user accesses the data in your bucket, CloudTrail will capture the event.
What do Amazon S3 events look like?
To validate the pipeline is working, you can simply list objects in the target bucket from AWS Web Console and wait for the event to appear.
Another quick example would be adding a new file to a S3 bucket. In that case, the consequent CloudTrail event would look like this in JSON format:
{
"eventVersion": "1.08",
"eventSource": "s3.amazonaws.com",
"eventName": "PutObject",
"awsRegion": "us-east-1",
"requestParameters": {
"bucketName": "test-s3-trail",
"key": "test-folder/test-file3.txt",
"resources": [
{
"type": "AWS::S3::Object",
"ARN": "arn:aws:s3:::test-s3-trail/test-folder/test-file3.txt"
},
{
"type": "AWS::S3::Bucket",
"ARN": "arn:aws:s3:::test-s3-trail"
}
],
}
Note how:
eventSourcetells us the event comes from S3.eventNameconfirms someone added a new file.bucketNameindicates in which bucket the file was added.keycontains the file name and path.
AWS threat detection with the Sysdig Cloud Connector
As your infrastructure grows, the amount of events and operational trails can become so huge that analyzing them is not manageable anymore.
This is a consequence of CloudTrail being so efficient in recording all the events happening in our AWS account. And this might become a problem as we may fail to react to a threat in a short time, deriving in major consequences.
Solving this challenge is precisely the goal of Sysdig Cloud Connector.
The Connector is capable of analyzing every CloudTrail entry in real time and then evaluating those events against a flexible set of security rules, providing AWS threat detection.
The installation process for Sysdig Cloud Connector is fairly simple, thanks to the power of CloudFormation templates.
Evaluating audit events with Falco rules and Sysdig Cloud Connector
After enabling CloudTrail for Amazon S3 and installing the Sysdig Cloud Connector in our account, we have all we need to start detecting abnormal behavior.
Now, let’s dig into how to detect problematic CloudTrail events, like Amazon S3 operations, with Falco rules.
Earlier, we showed what a CloudTrail event for a new S3 file looks like:
{
"eventVersion": "1.08",
"eventSource": "s3.amazonaws.com",
"eventName": "PutObject",
"awsRegion": "us-east-1",
"requestParameters": {
"bucketName": "test-s3-trail",
"key": "test-folder/test-file3.txt",
"resources": [
…
],
}
The following Falco rule would detect such an event:
- list: watched_bucket_events
items: [CreateBucket, DeleteBucket]
- rule: Operation on buckets
desc: Detect an operation on buckets.
condition:
not jevt.value[/errorCode] exists and
jevt.value[/eventName] in (watched_bucket_events)
output:
Detected an operation on buckets
( bucket name=%jevt.value[/requestParameters/bucketName]
operation=%jevt.value[/eventName],
object key=%jevt.value[/requestParameters/key],
requesting user=%jevt.value[/userIdentity/arn],
requesting IP=%jevt.value[/sourceIPAddress],
AWS region=%jevt.value[/awsRegion])
priority: WARNING
tags:
- cloud
- source=cloudtrail
- aws
- aws_s3
source: k8s_audit
Using jevt.value and a query in jsonpath format, we can reference parts of the audit event.
We use this in the condition part of the rule:
condition:
not jevt.value[/errorCode] exists and
jevt.value[/eventName] in (watched_bucket_events)
This filters events that were processed without an error and related to the S3 service.
The same is true for %jevt.value, which we use in the output part of the rule:
output:
Detected an operation on buckets
( bucket name=%jevt.value[/requestParameters/bucketName]
…
This output is used to provide context information, given the case that this rule ends up generating a security event.
Deploy the custom rule to Sysdig Cloud Connector
The Sysdig Cloud Connector uses an S3 bucket to store the active Falco rules.
To deploy a custom rule, you can sync a local folder with the S3 bucket. It would be a best practice if your local folder is a git repository, so you can keep track of the changes on the rules.
We’ll take a simpler route here:
First, create a rules folder.
Copy your rule to the rules folder.
From the parent folder, the one containing rules, execute the following commands:
cc_bucket=$(aws cloudformation list-stack-resources --stack-name CloudConnector --output json | jq '.StackResourceSummaries[] | select(.LogicalResourceId=="CloudConnectorBucket").PhysicalResourceId' | xargs) echo $cc_bucket aws s3 sync "./rules/" s3://$cc_bucket/rules --delete
This will sync your rules folder with your S3 bucket.
Keep in mind that for this to work, you’ll need to set up the AWS CLI in your machine and your token must have enough privileges.
After restarting Cloud Connector, you can check that new rule is added with:
task_id=$(aws ecs list-tasks --cluster CloudConnector --output json | jq '.taskArns[0]' | xargs | sed -E 's/.*\/(.+)/\1/') echo $task_id AWS_PAGER="" aws ecs stop-task --cluster CloudConnector --task $task_id
Wait for a minute, and then keep executing this command until a new log appears where the custom rule shows as loaded:
cc_log_stream=$(aws logs describe-log-streams --log-group-name cloud-connector --order-by LastEventTime --descending | grep -m1 "ecs/CloudConnector/" | sed 's/"\(.*\)".*"\(.*\)",/\2/' | xargs) echo $cc_log_stream aws logs filter-log-events --log-group-name cloud-connector --log-stream-names $cc_log_stream --filter-patter "-http-server -console-notifier"
We can now operate over the test S3 bucket and see relevant events on the CloudWatch alert logs, or inside the AWS Security Hub findings.
We can check the latest 5 alerts from the command line using:
aws logs get-log-events --log-group-name cloud-connector --log-stream-name alerts --no-start-from-head --limit 5
Wrapping Up
Cloud security is the highest priority for AWS, and that includes Amazon S3 security. However, it is also a shared responsibility between AWS and you, your company, and your DevOps teams. If your organization is not careful when securing S3 resources, and AWS environment in general, it’s possible they may end up having a data breach.
In this article, we shared tips to strengthen your S3 access control, prevent misconfigurations, and protect your workload. We also showed how AWS CloudTrail is the first stone of your security wall.
If you would like to find out more about Falco:
- Get started in Falco.org.
- Check out the Falco project in GitHub.
- Get involved with the Falco community.
- Meet the maintainers on the Falco Slack.
- Follow @falco_org on Twitter.
Leverage Sysdig Secure by deploying Sysdig Cloud Connector for CloudTrail and obtaining the runtime visibility you need to implement AWS thread detection. Its out-of-the-box set of Falco rules for CloudTrail minimizes the setup effort, response time, and resources needed for investigating security events.
If you do not have a Sysdig account, you can register today for a trial. Deploy Sysdig Cloud Connector in less than 10 minutes by following instructions in this article, and start having a secured AWS account today.
You can also find Sysdig on the AWS Marketplace.
