Must-have AWS security monitoring & alerting [Cheat Sheet]
Most of us know that having visibility into our cloud accounts and resources is critical, but it can easily be overwhelming to implement. What should I monitor? How do I even do that without creating a flood of notifications? If my AWS account becomes compromised, would this be sufficient to detect it?
If these are the questions going through your head, then this post is for you.
AWS Security Monitoring & Alerting Cheat Sheet
We’ve created this cheat sheet that you can download and share to your heart’s content, that shows how to use a tool called the AWS Security Survival Kit, or SSK. Let’s break it down.
What is the AWS Security Survival Kit (SSK)
The AWS SSK sets up basic proactive monitoring and alerting for common suspicious activities in your AWS account. It provides a set of CloudFormation templates that sets up monitoring and alerting in your AWS account, and it’s complimentary to both CloudTrail and GuardDuty. It primarily uses EventBridge Rules and CloudWatch Metric Filters and Alarms to look for specific suspicious activities that could indicate acompromise so that you can investigate. Details get displayed in a CloudWatch Dashboard so you can quickly respond.
How to use SSK
The first step if you’d like to use the SSK is to download it from this repo.
Once downloaded, you’ll want to set the required parameters in the Makefile.
Open that with your favorite text editor, and set the following values:
AlarmRecipient
: Recipient for the alerts (email address)Project
: Name of the Project (e.g.: aws-security-survival-kit)Description
: Description of the Project (e.g.: Bare minimum …)LocalAWSRegion
: Region where your workloads and CloudTrail are located (e.g.:us-east-1
)CTLogGroupName
: CloudTrail CloudWatch LogGroup name
You can set those values here in the Makefile:
You can then run:
make deploy
This command will deploy two separate CloudFormation templates:
cfn-local.yml
cfn-global.yml
This is what launches the monitoring and alerting resources, which means you can modify those templates to include or remove anything you want, based on your specific needs. I’d recommend launching it as-is the first time, and then tweaking as you need.
What resources get launched by SSK?
The best way to find out is to look through the CloudFormation templates (cfn-global.yml
, cfn-local.yml
), but overall, this is some of what you can expect it to launch at the time of writing this article:
The cfn-local.yml
template is the template that you would want to launch for each region in which you have AWS resources. For example, if you only tend to use us-east-2
then you could just launch it in that region, but if you also use eu-west-1
then you would want to launch it there as well.
You don’t need to do that for the cfn-global.yml
template.
Another addition has been made to the SSK project that now also enabled 3 security measures by default:
- Block public access for S3
- Region-level default encryption for EBS volumes
- Account-level restriction on public sharing of AMIs
This is how it does that:
account_level_security:
@echo "==> Enable S3 Block Public Access (Account Level)"
aws s3control put-public-access-block \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true \
--account-id $(shell aws sts get-caller-identity --query Account --output text)
@if [ $$? -eq 0 ]; then echo "✅ S3 Block Public Access"; fi
@echo "==> Enable EBS Default Encryption (Region Level)"
aws ec2 enable-ebs-encryption-by-default --region ${LocalAWSRegion}
@if [ $$? -eq 0 ]; then echo "✅ EBS Default Encryption"; fi
@echo "==> Enable AMI Block Public Access (Account Level)"
aws ec2 enable-image-block-public-access \
--image-block-public-access-state block-new-sharing
@if [ $$? -eq 0 ]; then echo "✅ AMI Block Public Access"; fi
Code language: PHP (php)
Taking a closer look, for blocking public access for S3:
aws s3control put-public-access-block \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true \
--account-id $(shell aws sts get-caller-identity --query Account --output text)
Code language: JavaScript (javascript)
For enabling EBS default encryption per region:
aws ec2 enable-ebs-encryption-by-default --region ${LocalAWSRegion}
Code language: JavaScript (javascript)
For restricting publicly sharing AMIs:
aws ec2 enable-image-block-public-access \
--image-block-public-access-state block-new-sharing
Code language: PHP (php)
These settings get enabled by the SSK when you deploy, and they are recommended best practices for all AWS accounts. However, if you don’t like one of those changes, you can always delete/comment out the corresponding lines. Or, if you don’t want the SSK to take any of those actions and you just want the monitoring/alerting resources to get created, you can account_level_security
in the deploy action:
deploy: account_level_security
aws cloudformation deploy \
etc...
Destroying the resources
If you want to delete the resources launched by SSK, you can use
make tear-down
Which will run this:
@read -p "Are you sure that you want to destroy stack '${Project}'? [y/N]: " sure && [ $${sure:-N} = 'y' ]
aws cloudformation delete-stack --region ${LocalAWSRegion} --stack-name "${Project}-local" --profile ${Profile}
aws cloudformation delete-stack --region us-east-1 --stack-name "${Project}-global" --profile ${Profile}
Code language: JavaScript (javascript)
You can also run the command:
make clean
To clean up extra files and directories that were created by using SSK.
Conclusion and more cheat sheets
The AWS SSK is a fantastic starting point for AWS security monitoring and alerting, but I encourage you to take it a step further by customizing it to your needs.
If there’s anything that launches by default that produces too much noise and will result in alert fatigue, tweak it! We don’t want that to happen.
Or, if you feel it’s missing some important metrics to monitor, by all means, add it in 🙂
Responses