AWS Security Configurations You May [Probably] Have Overlooked

Instance Metadata Service (IMDS) – This AWS component makes metadata about your EC2 instances available to the command line and code including information such as instance-id, instance-type, IAM role, profile and security credentials. This type of information can be invaluable to a threat actor performing reconnaissance on your AWS infrastructure as outlined in the MITRE ATT&CK framework Cloud Infrastructure Discover technique found here: https://attack.mitre.org/techniques/T1580/ . The default for AWS instances is a selection of either IMDS v1 or IMDS v2 - v1 however is unauthenticated and v2 has many security benefits primarily around session-oriented token requests. Additional details on why to use IMDS v2 found here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

Public S3 buckets – Making an S3 bucket public is easy. You can accomplish it in one of 4 ways as outlined by AWS here: https://aws.amazon.com/premiumsupport/knowledge-center/read-access-objects-s3-bucket/ However, publicly accessible S3 buckets can expose your data to the entire world and if you don’t have tight control on how S3 buckets are created such as a robust change management process for cloud components, you could already be exposing sensitive information. The good news is that Amazon has made it equally easy to resolve. The first step is to check the permissions on your S3 buckets. If you don’t have too many it’s an easy task accomplished using the AWS Console, however, if you have many S3 buckets, run the access analyzer: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html which can automate that process. If you find any publicly accessible S3 buckets, you can explicitly deny access by following this procedure and keep other permissions as opposed to taking the S3 bucket offline: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html For more details on your S3 Access Control lists to ensure you are implementing least privilege across your S3 infrastructure be sure to check out the following: https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html

Key Management – just like S3 bucket creation, keys to access your AWS infrastructure are easy to create and therefore easy to get out of control. Managing keys therefore can come with some significant overhead. Case in point, here is the long list of AWS topics for managing keys: https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html However the first thing you want to do is review the AWS key management best practices found here: https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html and to summarize those best practices the key *wink* items are to ensure:

1. Not using your root access keys for routine tasks. See details here: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials

2. Delete unused keys – incorporating Key Management into an existing Change Management process is even better.

3. Rotate Keys – stale keys are like leaving a spare key under the pot in front of your house after you returned from vacation 2 years ago. Instead, enroll in automatic key rotation at least annually – details also in the best practices linked above.