aws security automation concepts for beginners (s3).
Tags: security, aws, devops
Published: 2019-11-20 01:33:33

> I plan to make multiple posts with implementation later, lets get through some concepts first!

# whoami
Hey, I'm Nathan. I work in Canada and have a bunch of experience in security and AWS. I just wanna share some beginner tips and techniques/tools I use to help secure my organizations cloud environment.

## Automation Concepts
Let's be honest, responding to threats after they happen is much worse than being able to detect and respond as soon as they happen (or within a reasonable time). What can we do in AWS to make this a little bit more efficient? Well, lucky for us AWS CloudWatch offers a capability called events! This allows us to listen for events and launch responses as we wish. (You can also do this with systems manager but that isn't included). When using cloudwatch events, we want to listen for high security API calls. Stuff like:
- s3:CreateBucket
- s3:PutBucketPolicy
- ec2:RunInstance
- ec2:AuthorizeSecurityGroupIngress

For each one of these events we'd like to ensure they are called with the correct parameters. We wouldn't want someone to update the bucket policy and make the bucket public, or if someone launches an EC2 instance we want to make sure that ec2 instance isn't allowing ssh or rdp open to the world.

Lets take a look at s3! What are some possible security concerns around s3?
- Public buckets
Most of the time, when we see public buckets, it's normally a dev trying to do some testing, which isn't necessarily malicious, but having an open bucket can lead to unauthorized access or data leakage, depending whats in the bucket. We can use CloudWatch events to trigger a lambda when a bucket is created and when a bucket policy is updated. This lambda should have your code (leveraging boto3) and should grab the bucket name and look at the policy, if the policy exceeds what you want, use boto3 to set a new policy to remove public access.
[Updating Bucket Policy](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html#S3.Client.put_bucket_policy)

- Non-Encrypted buckets
Again, depending on your organizations requirements and risk apetite. You should always consider using encrypted buckets. Encrypting the data ensures that if assets get stolen from the AWS data center, they are encrypted. *This does not encrypt each object independently*. Like above, Use CloudWatch events and lambda to update the encryption status of the bucket.
[Updating Bucket Encryption](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html#S3.Client.put_bucket_encryption)

- No S3 access logging enabled
S3 Access logging is a pretty nice feature. It gives us apache like logs when people access s3 objects. This is pretty nice in incident response scenarios when you need to identify how many times an object was accessed, or which IP accessed an object, although this should not be used to identify a malicious actor. You will need more data to attribute someone to the activity. Just like with the above two, We can use CloudWatch events when a bucket is created to ensure S3 Access logging is enabled. Take a look at the docs below for lambda creation help.
[Put Bucket Logging](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html#S3.Client.put_bucket_logging)

## Thats it for now.
Stay tuned, I will be making more posts to detail the exact implementation of the above concepts. There will be more posts that talk about other services too!