This phase is all about, well you guessed it, preparations. We need to prepare by getting our threat modeling done, shrinking the attack surface, and take whatever necessary proactive measures to prevent security incidents from occurring in the first place. We need to enable logging, monitoring, encryption and limit the blast radius.

Prepare by applying proactive measures:

1- Data classification: Identify data sensitivity level, owners, and security requirements.

2- Ownership: All resources should be tagged, it’s nice to know who owns a set of compromised resources, the least owners can offer you is information about the sensitivity level of the data store in resources or configuration that might have lead to the compromise. Hint: We should always tag our resources!

3- Risk Management: Identify threats, risk, and vulnerabilities, figure out what your risk appetite, then manage your risks and vulnerabilities according to the level of risk you’re willing to tolerate.

4- Resilience: Architect highly available, fault tolerate infrastructure.Hint: Use the AWS well architect tool and read the well-architect white paper.

5- Principle of least privilege: Use AWS IAM and resource policies to only grant limited access to those who need to access data or operate on your environment.

6- Test (Game days): Test your incident response plan. I am sure you will find shortcomings that you can address before a real security incident takes place.

Prepare by Logging everything:

There is no excuse for not enabling CloudTrail and other logging services on all account and regions. You won’t have the forensics to tell what had happened to your assets in the event of a breach.

When you enable CloudTrail, any AWS service you touch will record actions took against them in Cloudtrail which can also be integrated with CloudWatch and logs and will be stored in a centralized s3 bucket.

CloudWatch events can be consumed by AWS Lambda for real-time remediation, and by SNS for real-time notification. It does not matter if you use the SDK, console or the AWS CLI all actions will be recorded. Any action you take against AWS resource can be used against you :) I know this one is bad, I promise not to do it again. One last thing though, please don’t forget to enable ClouTrail log file validation.

CloudTrail WorkFlow

Prepare by Limiting the Blast Radius

Blast Radius

Use AWS Organizations and VPC, subnet NACLs, EC2 security groups, etc., to limit the blast radius by isolating AWS accounts and resources based on business units, products, etc..

This approach, when combined with principles like defense in depth, can provide greater protection against threats.

Prepare by Encrypting Everything:

Data privacy professionals would tell you, “treat your data as if everyone is looking at it all the time becasue they might be.”

Encryption is the process if masking data by using an encryption algorithm and an encryption key. If a robust encrypting algorithm is used, bad actors won’t be able to read your data as plaintext if they were able to intercept it in transit or access it at rest.

AWS gives you options to encrypt your data, including but not limited to KMS.

AWS KMS and other services that encrypt your data directly use a method called envelope encryption to provide a balance between performance and security. See below: