Help improve AWS Support Official channel in re:Post and share your experience - complete a quick three-question survey to earn a re:Post badge!
Remediation using AWS Trusted Advisor
0
Hi AWS, we have a list of security controls as mentioned below. We are preferring the use of AWS Trusted Advisor and the Remediator to remediate them, but I am not sure if the Trusted Advisor will remediate or prevent non-compliance? And also I need to deploy it across 25 AWS accounts so what is the ideal way of doing the deployment.
List of controls:
- Autoscaling.5 Amazon EC2 instances launched using Auto Scaling group launch configurations should not have Public IP addresses
- DynamoDB.4 DynamoDB tables should be present in a backup plan
- DynamoDB.6 DynamoDB tables should have deletion protection enabled
- EC2.13 Security groups should not allow ingress from 0.0.0.0/0 to port 22
- EC2.19 Security groups should not allow unrestricted access to ports with high risk
- IAM.19 MFA should be enabled for all IAM users
- IAM.19 MFA should be enabled for all IAM users
- IAM.6 Hardware MFA should be enabled for the root user
- IAM.9 MFA should be enabled for the root user
- Opensearch.2 OpenSearch domains should not be publicly accessible
- S3.2 S3 buckets should prohibit public read access
- S3.3 S3 buckets should prohibit public write access
- APIGateway.1 API Gateway REST and WebSocket API execution logging should be enabled
- Athena.1 Athena workgroups should be encrypted at rest
- AutoScaling.9 EC2 Auto Scaling groups should use EC2 launch templates
- Backup.1 AWS Backup recovery points should be encrypted at rest
- CloudTrail.1 CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events
- CloudTrail.2 CloudTrail should have encryption at-rest enabled
- CloudWatch.16 CloudWatch log groups should be retained for at least 1 year
- Config.1 AWS Config should be enabled
- EC2.15 EC2 subnets should not automatically assign public IP addresses
- EC2.18 Security groups should only allow unrestricted incoming traffic for authorized ports
- EC2.2 VPC default security groups should not allow inbound or outbound traffic
- EC2.21 Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
- EC2.23 EC2 Transit Gateways should not automatically accept VPC attachment requests
- EC2.3 Attached EBS volumes should be encrypted at-rest
- EC2.6 VPC flow logging should be enabled in all VPCs
- EC2.7 EBS default encryption should be enabled -- To be enabled or disabled
- EC2.8 EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)
- EC2.9 EC2 instances should not have a public IPv4 address
- ECS.5 ECS containers should be limited to read-only access to root filesystems
- EFS.2 Amazon EFS volumes should be in backup plans
- ES.4 Elasticsearch domain error logging to CloudWatch Logs should be enabled
- ES.5 Elasticsearch domains should have audit logging enabled
- ES.8 Connections to Elasticsearch domains should be encrypted using the latest TLS security policy
- KMS.1 IAM customer managed policies should not allow decryption actions on all KMS keys
- KMS.2 IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
- Opensearch.5 OpenSearch domains should have audit logging enabled
- Opensearch.8 Connections to OpenSearch domains should be encrypted using TLS 1.2
- RDS.10 IAM authentication should be configured for RDS instances
- RDS.11 RDS instances should have automatic backups enabled
- RDS.12 IAM authentication should be configured for RDS clusters
- RDS.13 RDS automatic minor version upgrades should be enabled
- RDS.25 RDS database instances should use a custom administrator username
- RDS.26 RDS DB instances should be protected by a backup plan
- RDS.3 RDS DB instances should have encryption at-rest enabled
- RDS.34 Aurora MySQL DB clusters should publish audit logs to CloudWatch Logs
- RDS.4 RDS cluster snapshots and database snapshots should be encrypted at rest
- RDS.9 Database logging should be enabled
- S3.1 S3 Block Public Access setting should be enabled
- S3.11 S3 buckets should have event notifications enabled
- S3.17 S3 buckets should be encrypted at rest with AWS KMS keys
- S3.5 S3 buckets should require requests to use Secure Socket Layer
- S3.6 S3 permissions granted to other AWS accounts in bucket policies should be restricted
- S3.8 S3 Block Public Access setting should be enabled at the bucket-level
- S3.9 S3 bucket server access logging should be enabled
- SNS.1 SNS topics should be encrypted at-rest using AWS KMS
- SQS.1 Amazon SQS queues should be encrypted at rest
- SageMaker.1 Amazon SageMaker notebook instances should not have direct internet access
- SageMaker.3 Users should not have root access to SageMaker notebook instances
- ACM.1 Imported and ACM-issued certificates should be renewed after a specified time period
- AutoScaling.3 Auto Scaling group launch configurations should configure EC2 instances to require Instance Metadata Service Version 2 (IMDSv2)
- CloudFront.7 CloudFront distributions should use custom SSL/TLS certificates
- DynamoDB.2 DynamoDB tables should have point-in-time recovery enabled
- EC2.10 Amazon EC2 should be configured to use VPC endpoints that are created for the Amazon EC2 service
- EC2.4 Stopped EC2 instances should be removed after a specified time period
- ECS.12 ECS clusters should use Container Insights
- ECS.2 ECS services should not have public IP addresses assigned to them automatically
- ELB.1 Application Load Balancer should be configured to redirect all HTTP requests to HTTPS
- ELB.12 Application Load Balancer should be configured with defensive or strictest desync mitigation mode
- ELB.4 Application load balancer should be configured to drop http headers
- ELB.5 Application and Classic Load Balancers logging should be enabled
- ELB.6 Application Load Balancer deletion protection should be enabled
- ES.6 Elasticsearch domains should have at least three data nodes
- ES.7 Elasticsearch domains should be configured with at least three dedicated nodes
- GuardDuty.1 GuardDuty should be enabled
- IAM.3 IAM users' access keys should be rotated every 90 days or less
- IAM.7 Password policies for IAM users should have strong configurations
- IAM.8 Unused IAM user credentials should be removed
- KMS.4 AWS KMS key rotation should be enabled
- Kinesis.1 Kinesis streams should be encrypted at rest
- Macie.1 Amazon Macie should be enabled
- Macie.1 Macie should be enabled
- Opensearch.4 OpenSearch domain error logging to CloudWatch Logs should be enabled
- Opensearch.6 OpenSearch domains should have at least three data nodes
- Opensearch.8 Connections to OpenSearch domains should be encrypted using the latest TLS security policy
- RDS.14 Amazon Aurora clusters should have backtracking enabled
- RDS.15 RDS DB clusters should be configured for multiple Availability Zones
- RDS.5 RDS DB instances should be configured with multiple Availability Zones
- S3.10 S3 buckets with versioning enabled should have lifecycle policies configured
- S3.15 S3 buckets should be configured to use Object Lock
- SNS.2 Logging of delivery status should be enabled for notification messages sent to a topic
- SSM.1 EC2 instances should be managed by AWS Systems Manager
- SecretsManager.1 Secrets Manager secrets should have automatic rotation enabled
- SecretsManager.3 Remove unused Secrets Manager secrets
- SecretsManager.4 Secrets Manager secrets should be rotated within a specified number of days
Tags
Language
English
asked 9 months ago329 views
1 Answer
- Newest
- Most votes
- Most comments
3
AWS Trusted Advisor inspects your AWS environment and provides recommendations to improve performance, security, and cost optimization.
AWS Trusted Advisor does not change any configuration of your infrastructure, so it is still your responsibility how you remediate those findings
Relevant content
- asked 8 months ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 9 months ago
Won't Trusted Advisor Remediator be used for remediate the findings https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/tr-supported-checks.html
Trusted Remediator creates recommendations when Trusted Advisor checks indicate opportunities for you to reduce costs, improve system availability, optimize performance, or close security gaps for your AWS accounts. With Trusted Remediator, you can address these security, performance, cost optimization, fault tolerance, and service limit recommendations in a safe, standardized way that uses established best practices. Trusted Remediator allows you to configure a remediation solution and runs automatically on a schedule that you create, simplifying the remediation process.
Automated remediation: Trusted Remediator runs the automation document and monitors the run. After the automation document completes, Trusted Remediator resolves the Opsitem.
So you can create any SSM Document you want and automatically execute it after the event from Trusted Advisor
https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/trusted-remediator.html#tr-how-it-works
Hi Oleksii Bebych, is it possible to have preventative controls i.e. SCPs for the list of controls I mentioned above and if not which should be the best option for auto remediation i.e.
AWS ConfigorAWS Trusted Advisor?it's not your case. SCP prevents from doing something, for example, disallow disabling AWS Config if it's enabled, but if it was not initially enabled, it does not help you. Detective controls or AWS Config rules should be used to detect the things from your list. AWS Config can also remediate those issues via native functionality or custom Lambda functions. https://docs.aws.amazon.com/config/latest/developerguide/setup-autoremediation.html