Checks

You should not use outdated/insecure TLS versions for encryption. You should be using TLS v1.2+.

Data can be read if the Athena Database is compromised. Athena databases and workspace result sets should be encrypted at rests. These databases and query sets are generally derived from data in S3 buckets and should have the same level of at rest protection.

Clients can ignore encryption requirements without enforced configuration. Athena workgroup configuration should be enforced to prevent client side changes to disable encryption settings.

Block devices should be encrypted to ensure sensitive data is held securely at rest.

You should limit the provision of public IP addresses for resources. Resources should not be exposed on the public internet, but should have access limited to consumers required for the function of your application.

You should configure CloudFront Access Logging to create log files that contain detailed information about every user request that CloudFront receives

You should configure a Web Application Firewall in front of your CloudFront distribution. This will mitigate many types of attacks on your web application.

Plain HTTP is unencrypted and human-readable. This means that if a malicious actor was to eavesdrop on your connection, they would be able to see all of your data flowing back and forth. You should use HTTPS, which is HTTP over an encrypted (TLS) connection, meaning eavesdroppers cannot read your traffic.

You should not use outdated/insecure TLS versions for encryption. You should be using the latest TLS policies available. Note: that setting minimum_protocol_version = "TLSv1.X" is only possible when cloudfront_default_certificate is false (eg. you are not using the cloudfront.net domain name). If cloudfront_default_certificate is true then the Cloudfront API will only allow setting minimum_protocol_version = "TLSv1", and setting it to any other value will result in a perpetual diff in your terraform plan's. The only option when using the cloudfront.net domain name is to ignore this rule.

Activity could be happening in your account in a different region. When creating Cloudtrail in the AWS Management Console the trail is configured by default to be multi-region, this isn't the case with the Terraform resource. Cloudtrail should cover the full AWS account to ensure you can track changes in regions you are not actively operating in.

Using AWS managed keys does not allow for fine grained control. Using Customer managed keys provides comprehensive control over cryptographic keys, enabling management of policies, permissions, and rotation, thus enhancing security and compliance measures for sensitive data and systems.

Illicit activity could be removed from the logs. Log validation should be activated on Cloudtrail logs to prevent the tampering of the underlying data in the S3 bucket. It is feasible that a rogue actor compromising an AWS account might want to modify the log data to remove trace of their actions.

CloudWatch log groups are encrypted by default, however, to get the full benefit of controlling key rotation and other KMS aspects a KMS CMK should be used.

All artifacts produced by your CodeBuild project pipeline should always be encrypted

Sources that aren't covered by the aggregator are not include in the configuration. The configuration aggregator should be configured with all_regions for the source. This will help limit the risk of any unmonitored configuration in regions that are thought to be unused.

Document DB does not have auditing by default. To ensure that you are able to accurately audit the usage of your DocumentDB cluster you should enable export logs.

Unencrypted sensitive data is vulnerable to compromise. Encryption of the underlying storage used by DocumentDB ensures that if their is compromise of the disks, the data is still protected.

Using AWS managed keys does not allow for fine grained control. Encryption using AWS keys provides protection for your DocumentDB underlying storage. To increase control of the encryption and manage factors like rotation use customer managed keys.

Data can be freely read if compromised. Amazon DynamoDB Accelerator (DAX) encryption at rest provides an additional layer of data protection by helping secure your data from unauthorized access to the underlying storage.

DynamoDB tables should be protected against accidentally or malicious write/delete actions by ensuring that there is adequate protection. By enabling point-in-time-recovery you can restore to a known point in the event of loss of data.

Using AWS managed keys does not allow for fine grained control. DynamoDB tables are encrypted by default using AWS managed encryption keys. To increase control of the encryption and control the management of factors like key rotation, use a Customer Managed Key.

By enabling encryption on EBS volumes you protect the volume, the disk I/O and any derived snapshots from compromise if intercepted.

Encryption using AWS keys provides protection for your EBS volume. To increase control of the encryption and manage factors like rotation use customer managed keys.

IMDS v2 (Instance Metadata Service) introduced session authentication tokens which improve security when talking to IMDS.

By default <code>aws_instance</code> resource sets IMDS session auth tokens to be optional.

To fully protect IMDS you need to enable session tokens by using <code>metadata_options</code> block and its <code>http_tokens</code> variable set to <code>required</code>.