Must-have AWS security monitoring & alerting [Cheat Sheet]

AWS SSK monitoring and alerting for security

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.

AWS SSK directory and files

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:

SSK Makefile parameters to edit

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:

cfn-local from SSK
cfn-local.yml resources launched

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.

cfn-global.yml resources launched

Another addition has been made to the SSK project that now also enabled 3 security measures by default:

  1. Block public access for S3
  2. Region-level default encryption for EBS volumes
  3. Account-level restriction on public sharing of AMIs

This is how it does that:

	@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-sharingCode 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 \

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 🙂

Want more cheat sheets like this? Check them out here.

Related Articles


Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.