S3 Bucket for CloudTrail
ACM.195 Creating a bucket with a server access logging bucket
Part of my series on Automating Cybersecurity Metrics and stories on AWS S3 Buckets. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
Phew. That last post was quite involved. I tested out my S3 CloudFormation template, fixed a bunch of bugs, created deployment scripts and a bucket naming convention, among other things.
Hopefully this post will be easier that than the last few posts. My post about how a generic bucket template can help you took longer to write than the posts with code. I had to think about how to explain it and revised it several times.
In this post we are going to use our same deployment scripts as the last post to deploy a bucket for CloudFormation. But for the CloudFormation bucket we are going to assign an S3 access log bucket.
Why you need to create your own CloudTrail
As a side note I ran across this great post on ransomware in the cloud which is related to both S3 and CloudTrail. I would love to see more posts like this that help people understand how to prevent similar incidents. Bravo to the person that wrote this!
As you can see from the above post, the following factors may have contributed to a successful ransomware attack:
- Long term credentials exposed (presumably no MFA).
- CloudTrail was not configured, so the first event in the compromise chain was outside the default window of available logs (90 days).
- Presumably there was no KMS Encryption key or if there was the compromised credentials had access to use it.
- The post also has some interesting insights about the user agent in CloudTrail logs. I wrote about user agents, user names, and IP addresses in CloudTrail logs in this post:
I may revisit that user agent topic more later but for now we want to get CloudTrail set up and the next step is to create our CloudTrail bucket.
Standard S3 server access log bucket name
After I set up my template and our server access log, I started thinking that I could standardize the name of the server access log bucket in each account that is allowed to create s3 buckets.
I explained what server access logs are and why you need them here.
Recall that I wanted to name my buckets as follows:
[profile]-[organization id]-s3accesslogs
[profile]-[organization id]-cloudtrail
Now, if every bucket is going to have a profile, an id, and then a suffix, do I really need to look up the account and organization ID? What if I just use the account ID instead and only pass in the profile and a suffix to my CloudFormation template? That would ensure my buckets are always consistently named.
Then, if the name is “s3accesslogs”, I know that there should be no access log bucket assigned, otherwise we will assign the standard s3 access log bucket.
I also might not want access logs in my dev environment to save money since I don’t have any sensitive data in that environment. We can create a condition to not assign an access log bucket in that case.
Let me show you what I mean.
Standard Bucket Names in an S3 CloudFormation Template
First I’m going to add a profile parameter with an allowed list of profiles. These need to be lowercase to use in our bucket name.
Next I’ll remove the parameters for the S3 access log bucket and prefix and rename the bucket name parameter to indicate it is a bucket name suffix.
I’ll create a condition to define when I do not want to assign a server access log configuration to a bucket.
I can use my parameters to formulate a bucket name.
If the condition to create server access logs is true then assign the server access log bucket and assign the bucket name as the prefix. Otherwise set it to no value.
I will also need to make some adjustments to the outputs. However, I also noticed in the AWS S3 documentation it now supports a few attributes it did not in the past. We can use those instead of concatenating strings. Thank you AWS!
Here’s the final template
And now my bucket function:
- Does not need to look up organization and account id
- Does not need to accept logging bucket parameters
- Does not need to optionally set log bucket parameters here
- I need to make sure the profile and bucket parameters passed to the CloudFormation template are lower case
Deploy the buckets (redeploy the access log bucket)
After making these changes I am going to redeploy the S3 access log bucket. Since the name is changing you’ll want to delete the existing stack so you don’t end up with an extraneous bucket or conflict.
I can add the CloudTrail bucket code now too which is pretty simple.
And now I can attempt to deploy the code and fix any bugs along the way.
Verify the stacks are successfully deployed.
Navigate to S3 and verify that the buckets are there with the correct names an configuration. This is the point where your QA team should be testing and validating your configuration rules with appropriate security and compliance test cases.
Click on the CloudTrail bucket.
Click on Properties.
Scroll down to Server Access Logging. It should be enabled.
Click on Edit. Verify the settings.
Notice the warning. The bucket has policy has been updated with some necessary permissions. Let’s take a look at the bucket policy.
Click Cancel.
Click Permissions.
Scroll down and look at the bucket policy. Hrrmmm. It is empty.
Navigate to the other S3 bucket we created for S3 access logs.
Repeat the steps above and look at the settings.
Ok here’s where it gets odd. I think I found a bug:
And because I can’t currently find a way to optionally set the server logging configuration, I added an additional condition:
And I added two bucket resources, one if logging is on and one if logging is off and I updated the outputs to use the conditions.
Yes that’s kind of hideous.
Now server access logging is disabled on the access log bucket but still enabled on the CloudTrail bucket instead of populating the service access log bucket with itself when it is set to AWS::NoValue in the template (the presumed bug.)
There may be a better way but perhaps AWS will fix the bug at some point. If anyone has a better solution, please submit as a GitHub issue on the repo. I’ll keep trying to figure out a better way.
I need to move on and get CloudFormation set up.
Note that this bucket tempate evolves throughout the series.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
