# Security management in AMS Accelerate Security management AWS Managed Services uses multiple controls to protect your information assets and to help you keep your AWS infrastructure secure. AMS Accelerate maintains a library of AWS Config Rules and remediation actions to ensure that all your accounts comply with industry standards for security and operational integrity. AWS Config Rules continuously tracks the configuration change among your recorded resources. If a change violates any rule conditions, AMS reports its findings, and allows you to remediate violations automatically or by request, according to the severity of the violation. AWS Config Rules facilitate compliance with standards set by: the Center for Internet Security (CIS), the National Institute of Standards and Technology (NIST) Cloud Security Framework (CSF), the Health Insurance Portability and Accountability Act (HIPAA), and the Payment Card Industry (PCI) Data Security Standard (DSS). In addition, AMS leverages Amazon GuardDuty to identify potentially unauthorized or malicious activity in your AWS environment. AMS monitors GuardDuty findings 24x7. AMS collaborates with you to understand the impact of the findings and identify remediation based on best practice recommendations. AMS also uses Amazon Macie to protect your sensitive data such as personal health information (PHI), personally identifiable information (PII) and financial data. **Note** Amazon Macie is an optional service and is not enabled by default. AMS Accelerate provides a range of operational services to help you achieve operational excellence on AWS. To learn more about how AMS helps your teams achieve overall operational excellence in AWS Cloud with AMS key operational capabilities including 24x7 helpdesk, proactive monitoring, security, patching, logging, and backup, see [AMS Reference Architecture Diagrams](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/AWS-managed-services-for-operational-excellence-ra.pdf). **Topics** + [ # Use the Log4j SSM Document to discover occurrences in Accelerate ](acc-lm-log4j.md) + [ # Infrastructure security monitoring in AMS ](acc-sec-infra-sec.md) + [ # Data protection in Accelerate ](acc-sec-data-protect.md) + [ # AWS Identity and Access Management in AMS Accelerate ](acc-sec-iam.md) + [ # Security Incident Response in AMS ](security-incident-response.md) + [ # Security event logging and monitoring in Accelerate ](acc-sec-log-mon.md) + [ # Configuration compliance in Accelerate ](acc-sec-compliance.md) + [ # Incident response in Accelerate ](acc-sec-incident.md) + [ # Resilience in Accelerate ](acc-sec-resilience.md) + [ # Security control for end-of-support operating systems ](ams-eos-sec-controls-os.md) + [ # Security best practices in Accelerate ](acc-sec-best-practice.md) + [ # Change request security reviews ](acc-sec-change-request-review.md) + [ # Security FAQ ](security-access-faq.md) # Use the Log4j SSM Document to discover occurrences in Accelerate Using the Log4j SSM Document to discover occurrences The Log4j AWS Systems Manager document (SSM document) assists you with searching for the Apache Log4j2 library within ingested workloads. The automation document provides a report of the Process ID of the Java application(s) that the Log4j2 library is active in. The report includes information about the Java Archives (JAR Files), found within the specified environment that contains the JndiLookup class. It's a best practice to upgrade the discovered libraries to the latest available version. This upgrade mitigates the Remote Code Execution (RCE) identified through CVE-2021-44228. Download the latest version of the Log4j library from Apache. For more information, see [Download Apache Log4j 2](https://logging.apache.org/log4j/2.x/download.html). The document is shared to all the Regions onboarded to Accelerate,. To access the document, complete the following steps: 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, choose **Documents**. 1. Choose **Shared with me**. 1. In the search box, enter **AWSManagedServices-GatherLog4jInformation**. 1. Use [rate control](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-working-targets-and-rate-controls.html) to run the document at scale. The AWSManagedServices-GatherLog4jInformation document gathers the following parameters: + **InstanceId**: (Required) ID of your EC2 instance. + **S3Bucket**: (Optional) The S3 pre-signed URL or S3 URI (s3://BUCKET\$1NAME) to upload the results to. + ** AutomationAssumeRole**: (Required) The ARN of the role that allows the autoomation to perform actions on your behalf. It's a best practice to run this document using rate control. You can set the rate control parameter to be the **InstanceId**, and assign either a list of instances to it, or apply a tag-key combination to target all EC2 instances that have a certain tag. AWS Managed Services also recommends that you provide an Amazon Simple Storage Service (Amazon S3) bucket to upload the results to, so that you can build a report from the data stored in S3. For an example of how to aggregate the results in S3, see [EC2 Instance Stack \$1 Gather Log4j Information](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-ec2-instance-stack-gather-log4j-information.html). If you are unable to upgrade the package, follow the guidelines outlined by AWS Security at [ Using AWS security services to protect against, detect, and respond to the Log4j vulnerability](https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/). To mitigate vulnerabilities by removing the JndiLookup class functionality, run the Log4j hot patch inline with your Java application(s). For more information about the hot patch, see [Hotpatch for Apache Log4j](https://aws.amazon.com/fr/blogs/opensource/hotpatch-for-apache-log4j/). For questions about the output of the automation or how to proceed with additional mitigations, submit a service request. # Infrastructure security monitoring in AMS Infrastructure security monitoring When you onboard to AMS Accelerate, AWS deploys the following AWS Config baseline infrastructure and set of rules, AMS Accelerate uses these rules to monitor your accounts. + **AWS Config service-linked role**: AMS Accelerate deploys the service-linked role named **AWSServiceRoleForConfig**, which is used by AWS Config to query the status of other AWS services. The **AWSServiceRoleForConfig** service-linked role trusts the AWS Config service to assume the role. The permissions policy for the **AWSServiceRoleForConfig** role contains read-only and write-only permissions on AWS Config resources and read-only permissions for resources in other services that AWS Config supports. If you already have a role configured with AWS Config Recorder, AMS Accelerate validates that the existing role has an AWS Config managed-policy attached. If not, AMS Accelerate replaces the role with the service-linked role **AWSServiceRoleForConfig**. + **AWS Config recorder and delivery channel**: AWS Config uses the configuration recorder to detect changes in your resource configurations and capture these changes as configuration items. AMS Accelerate deploys the configuration recorder in all service AWS Regions, with continuous recording of all resources. AMS Accelerate also creates the config delivery channel, an Amazon S3 bucket, that's used to record changes that occur in your AWS resources. The config recorder updates configuration states through the delivery channel. The config recorder and delivery channel are required for AWS Config to work. AMS Accelerate creates the recorder in all AWS Regions, and a delivery channel in a single AWS Region. If you already have a recorder and delivery channel in an AWS Region, then AMS Accelerate doesn't delete the existing AWS Config resources, instead AMS Accelerate uses your existing recorder and delivery channel after validating that they are properly configured. For more information on how to reduce AWS Config costs, see [Reduce AWS Config costs in Accelerate](acc-sec-compliance.md#acc-sec-compliance-reduct-config-spend). + **AWS Config rules**: AMS Accelerate maintains a library of AWS Config Rules and remediation actions to help you comply with industry standards for security and operational integrity. AWS Config Rules continuously tracks configuration changes among your recorded resources. If a change violates any rule conditions, AMS reports its findings, and allows you to remediate violations automatically or by request, according to the severity of the violation. AWS Config Rules facilitate compliance with standards set by: the Center for Internet Security (CIS), the National Institute of Standards and Technology (NIST) Cloud Security Framework (CSF), the Health Insurance Portability and Accountability Act (HIPAA), and the Payment Card Industry (PCI) Data Security Standard (DSS). + **AWS Config aggregator authorization**: An aggregator is an AWS Config resource type that collects AWS Config configuration and compliance data from multiple accounts and multiple Regions. AMS Accelerate onboards your account to a config aggregator from which AMS Accelerate aggregates your account's resource configuration information and config compliance data and generates the compliance report. If there are existing aggregators configured in the AMS-owned account, AMS Accelerate deploys an additional aggregator and the existing aggregator is not modified. **Note** The Config aggregator is not set up in your accounts; rather, it is set up in AMS-owned accounts and your account(s) are onboarded to it. To learn more about AWS Config, see: + AWS Config: [What Is Config?](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) + AWS Config Rules: [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) + AWS Config Rules: [ Dynamic Compliance Checking: AWS Config Rules – Dynamic Compliance Checking for Cloud Resources](https://aws.amazon.com/blogs/aws/aws-config-rules-dynamic-compliance-checking-for-cloud-resources/) + AWS Config Aggregator: [ Multi-Account Multi-Region Data Aggregation](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html) For information on reports, see [AWS Config Control Compliance report](acc-report-config-control-compliance.md). # Using service-linked roles for AMS Accelerate Using service-linked roles AMS Accelerate uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role (SLR) is a unique type of IAM role that is linked directly to AMS Accelerate. Service-linked roles are predefined by AMS Accelerate and include all the permissions that the service requires to call other AWS services on your behalf. A service-linked role makes setting up AMS Accelerate easier because you don’t have to manually add the necessary permissions. AMS Accelerate defines the permissions of its service-linked roles, and unless defined otherwise, only AMS Accelerate can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes**in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. ## Deployment toolkit service-linked role for AMS Accelerate Deployment toolkit SLR AMS Accelerate uses the service-linked role (SLR) named **AWSServiceRoleForAWSManagedServicesDeploymentToolkit** – this role deploys AMS Accelerate infrastructure into customer accounts. **Note** This policy has recently been updated; for details, see [Accelerate updates to service-linked roles](#slr-updates). ### AMS Accelerate deployment toolkit SLR Deployment toolkit SLR The AWSServiceRoleForAWSManagedServicesDeploymentToolkit service-linked role trusts the following services to assume the role: + `deploymenttoolkit.managedservices.amazonaws.com` The policy named [AWSManagedServicesDeploymentToolkitPolicy](security-iam-awsmanpol.html#security-iam-awsmanpol-DeploymentToolkitPolicy) allows AMS Accelerate to perform actions on the following resources: + `arn:aws*:s3:::ams-cdktoolkit*` + `arn:aws*:cloudformation:*:*:stack/ams-cdk-toolkit*` + `arn:aws:ecr:*:*:repository/ams-cdktoolkit*` This SLR grants Amazon S3 permissions to create and manage the deployment bucket used by AMS to upload resources, like CloudFormation templates or Lambda asset bundles, into the account for component deployments. This SLR grants CloudFormation permissions to deploy the CloudFormation stack that defines the deployment buckets. For details or to download the policy, see [AWSManagedServices\$1DeploymentToolkitPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-DeploymentToolkitPolicy). You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [ Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*. ### Creating an deployment toolkit SLR for AMS Accelerate Creating an deployment toolkit SLR You don't need to manually create a service-linked role. When you Onboard to AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate creates the service-linked role for you. **Important** This service-linked role can appear in your account if you were using the AMS Accelerate service before June 09, 2022, when it began supporting service-linked roles, then AMS Accelerate created the AWSServiceRoleForAWSManagedServicesDeploymentToolkit role in your account. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you Onboard to AMS, AMS Accelerate creates the service-linked role for you again. ### Editing an deployment toolkit SLR for AMS Accelerate Editing an deployment toolkit SLR AMS Accelerate does not allow you to edit the AWSServiceRoleForAWSManagedServicesDeploymentToolkit service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ### Deleting an deployment toolkit SLR for AMS Accelerate Deleting an deployment toolkit SLR You don't need to manually delete the AWSServiceRoleForAWSManagedServicesDeploymentToolkit role. When you Offboard from AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate cleans up the resources and deletes the service-linked role for you. You can also use the IAM console, the AWS CLI or the AWS API to manually delete the service-linked role. To do this, you must first manually clean up the resources for your service-linked role and then you can manually delete it. **Note** If the AMS Accelerate service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again. **To delete AMS Accelerate resources used by the AWSServiceRoleForAWSManagedServicesDeploymentToolkit service-linked role** Delete `ams-cdk-toolkit` stack from all Regions your account was onboarded to in AMS (you might have to manually empty the S3 buckets first). **To manually delete the service-linked role using IAM** Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAWSManagedServicesDeploymentToolkit service-linked role. For more information, see [ Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Detective controls service-linked role for AMS Accelerate Detective controls SLR AMS Accelerate uses the service-linked role (SLR) named **AWSServiceRoleForManagedServices\$1DetectiveControlsConfig** – AWS Managed Services uses this service-linked role to deploy config-recorder, config rules and S3 bucket detective controls.. Attached to the **AWSServiceRoleForManagedServices\$1DetectiveControlsConfig** service-linked role is the following managed policy: [AWSManagedServices\$1DetectiveControlsConfig\$1ServiceRolePolicy](security-iam-awsmanpol.html#security-iam-awsmanpol-DetectiveControlsConfig). For updates to this policy, see [Accelerate updates to AWS managed policies](security-iam-awsmanpol.md#security-iam-awsmanpol-updates). ### Permissions for detective controls SLR for AMS Accelerate Permissions for detective controls SLR The AWSServiceRoleForManagedServices\$1DetectiveControlsConfig service-linked role trusts the following services to assume the role: + `detectivecontrols.managedservices.amazonaws.com` Attached to this role is the `AWSManagedServices_DetectiveControlsConfig_ServiceRolePolicy` AWS managed policy (see [AWS managed policy: AWSManagedServices\$1DetectiveControlsConfig\$1ServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-DetectiveControlsConfig) The service uses the role to create configure AMS Detective Controls in your account, which requires deployment of resources like s3 buckets, config rules and an aggregator. You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *AWS Identity and Access Management* User Guide. ### Creating a detective controls SLR for AMS Accelerate Creating a detective controls SLR You don't need to manually create a service-linked role. When you Onboard to AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate creates the service-linked role for you. **Important** This service-linked role can appear in your account if you were using the AMS Accelerate service before June 09, 2022, when it began supporting service-linked roles then AMS Accelerate created the AWSServiceRoleForManagedServices\$1DetectiveControlsConfig role in your account. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you Onboard to AMS, AMS Accelerate creates the service-linked role for you again. ### Editing a detective controls SLR for AMS Accelerate Editing a detective controls SLR AMS Accelerate does not allow you to edit the AWSServiceRoleForManagedServices\$1DetectiveControlsConfig service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [ Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ### Deleting a detective controls SLR for AMS Accelerate Deleting a detective controls SLR You don't need to manually delete the AWSServiceRoleForManagedServices\$1DetectiveControlsConfig role. When you Offboard from AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate cleans up the resources and deletes the service-linked role for you. You can also use the IAM console, the AWS CLI or the AWS API to manually delete the service-linked role. To do this, you must first manually clean up the resources for your service-linked role and then you can manually delete it. **Note** If the AMS Accelerate service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again. **To delete AMS Accelerate resources used by the AWSServiceRoleForManagedServices\$1DetectiveControlsConfig service-linked role** Delete `ams-detective-controls-config-recorder`, `ams-detective-controls-config-rules-cdk` and `ams-detective-controls-infrastructure-cdk` stacks from all Regions your account was onboarded to in AMS (you might have to manually empty the S3 buckets first). **To manually delete the service-linked role using IAM** Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForManagedServices\$1DetectiveControlsConfig service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Amazon EventBridge rule service-linked role for AMS Accelerate Amazon EventBridge rule SLR AMS Accelerate uses the service-linked role (SLR) named **AWSServiceRoleForManagedServices\$1Events**. This role trusts one of the AWS Managed Services service principals (events.managedservices.amazonaws.com) to assume the role for you. The service uses the role to create Amazon EventBridge managed rule. This rule is the infrastructure required in your AWS account to deliver alarm state change information from your account to AWS Managed Services. ### Permissions for EventBridge SLR for AMS Accelerate Permissions for EventBridge SLR The AWSServiceRoleForManagedServices\$1Events service-linked role trusts the following services to assume the role: + `events.managedservices.amazonaws.com` Attached to this role is the `AWSManagedServices_EventsServiceRolePolicy` AWS managed policy (see [AWS managed policy: AWSManagedServices\$1EventsServiceRolePolicy](security-iam-awsmanpol.md#EventsServiceRolePolicy)). The service uses the role to deliver alarm state change information from your account to AMS. You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *AWS Identity and Access Management User Guide*. You can download the JSON AWSManagedServices\$1EventsServiceRolePolicy in this ZIP: [EventsServiceRolePolicy.zip](samples/EventsServiceRolePolicy.zip). ### Creating an EventBridge SLR for AMS Accelerate Creating an EventBridge SLR You don't need to manually create a service-linked role. When you Onboard to AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate creates the service-linked role for you. **Important** This service-linked role can appear in your account if you were using the AMS Accelerate service before February 7, 2023, when it began supporting service-linked roles then AMS Accelerate created the AWSServiceRoleForManagedServices\$1Events role in your account. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you Onboard to AMS, AMS Accelerate creates the service-linked role for you again. ### Editing an EventBridge SLR for AMS Accelerate Editing an EventBridge SLR AMS Accelerate does not allow you to edit the AWSServiceRoleForManagedServices\$1Events service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ### Deleting an EventBridge SLR for AMS Accelerate Deleting an EventBridge SLR You don't need to manually delete the AWSServiceRoleForManagedServices\$1Events role. When you Offboard from AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate cleans up the resources and deletes the service-linked role for you. You can also use the IAM console, the AWS CLI or the AWS API to manually delete the service-linked role. To do this, you must first manually clean up the resources for your service-linked role and then you can manually delete it. **Note** If the AMS Accelerate service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again. **To delete AMS Accelerate resources used by the AWSServiceRoleForManagedServices\$1Events service-linked role** **To manually delete the service-linked role using IAM** Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForManagedServices\$1Events service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Contacts service-linked role for AMS Accelerate Contacts managed policy AMS Accelerate uses the service-linked role (SLR) named **AWSServiceRoleForManagedServices\$1Contacts** – This role facilitates automated notifications when incidents occur by allowing the service to read the existing tags of the affected resource and retrieve the configured email of the appropriate point of contact. This is the only service that uses this service-linked role. Attached to the **AWSServiceRoleForManagedServices\$1Contacts** service-linked role is the following managed policy: [AWSManagedServices\$1ContactsServiceRolePolicy](security-iam-awsmanpol.html#ContactsServiceManagedPolicy). For updates to this policy, see [Accelerate updates to AWS managed policies](security-iam-awsmanpol.md#security-iam-awsmanpol-updates). ### Permissions for Contacts SLR for AMS Accelerate Permissions for Contacts SLR The AWSServiceRoleForManagedServices\$1Contacts service-linked role trusts the following services to assume the role: + `contacts-service.managedservices.amazonaws.com` Attached to this role is the `AWSManagedServices_ContactsServiceRolePolicy` AWS managed policy (see [AWS managed policy: AWSManagedServices\$1ContactsServiceRolePolicy](security-iam-awsmanpol.md#ContactsServiceManagedPolicy)). The service uses the role to read the tags on any AWS resource and find the email contained in the tag, of the appropriate point of contact for when incidents occur. This role facilitates automated notifications when incidents occur by allowing AMS to read that tag on an affected resource and retrieve the email. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *AWS Identity and Access Management* User Guide. **Important** Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. AMS uses tags to provide you with administration services. Tags are not intended to be used for private or sensitive data. The role permissions policy named AWSManagedServices\$1ContactsServiceRolePolicy allows AMS Accelerate to complete the following actions on the specified resources: + Action: Allows the Contacts Service to read the tags specifically set up to contain the email for AMS to send incident notifications on any AWS resource. You can download the JSON AWSManagedServices\$1ContactsServiceRolePolicy in this ZIP: [ContactsServicePolicy.zip](samples/ContactsServicePolicy.zip). ### Creating a Contacts SLR for AMS Accelerate Creating a Contacts SLR You don't need to manually create a service-linked role. When you Onboard to AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate creates the service-linked role for you. **Important** This service-linked role can appear in your account if you were using the AMS Accelerate service before February 16, 2023, when it began supporting service-linked roles then AMS Accelerate created the AWSServiceRoleForManagedServices\$1Contacts role in your account. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you Onboard to AMS, AMS Accelerate creates the service-linked role for you again. ### Editing a Contacts SLR for AMS Accelerate Editing an Contacts SLR AMS Accelerate does not allow you to edit the AWSServiceRoleForManagedServices\$1Contacts service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ### Deleting a Contacts SLR for AMS Accelerate Deleting a Contacts SLR You don't need to manually delete the AWSServiceRoleForManagedServices\$1Contacts role. When you Offboard from AMS in the AWS Management Console, the AWS CLI, or the AWS API, AMS Accelerate cleans up the resources and deletes the service-linked role for you. You can also use the IAM console, the AWS CLI or the AWS API to manually delete the service-linked role. To do this, you must first manually clean up the resources for your service-linked role and then you can manually delete it. **Note** If the AMS Accelerate service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again. **To delete AMS Accelerate resources used by the AWSServiceRoleForManagedServices\$1Contacts service-linked role** **To manually delete the service-linked role using IAM** Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForManagedServices\$1Contacts service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Supported regions for AMS Accelerate service-linked roles Supported regions for SLRs AMS Accelerate supports using service-linked roles in all of the regions where the service is available. For more information, see [AWS regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html). ## Accelerate updates to service-linked roles Updates for SLRs View details about updates to Accelerate service-linked roles since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the Accelerate [Document history for AMS Accelerate User Guide](doc-history.md) page. | Change | Description | Date | | --- | --- | --- | | Updated policy – [Deployment Toolkit](#slr-deploy-acc) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/using-service-linked-roles.html) | April 4, 2024 | | Updated policy – [Deployment Toolkit](#slr-deploy-acc) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/using-service-linked-roles.html) | May 09, 2023 | | Updated policy – [Detective Controls](#slr-deploy-detect-controls) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/using-service-linked-roles.html) | April 10, 2023 | | Updated policy – [Detective Controls](#slr-deploy-detect-controls) | Updated the policy and added the permissions boundary policy. | March 21, 2023 | | New service-linked role – [Contacts SLR](#slr-contacts-service) | Accelerate added a new service-linked role for the Contacts service. This role facilitates automated notifications when incidents occur by allowing the service to read the existing tags of the affected resource and retrieve the configured email of the appropriate point of contact. | February 16, 2023 | | New service-linked role – [EventBridge](#slr-evb-rule) | Accelerate added a new service-linked role for an Amazon EventBridge rule. This role trusts one of the AWS Managed Services service principals (events.managedservices.amazonaws.com) to assume the role for you. The service uses the role to create Amazon EventBridge managed rule. This rule is the infrastructure required in your AWS account to deliver alarm state change information from your account to AWS Managed Services. | February 7, 2023 | | Updated service-linked role – [Deployment Toolkit](#slr-deploy-acc) | Accelerate updated AWSServiceRoleForAWSManagedServicesDeploymentToolkit with new S3 permissions. These new permissions were added: 
"s3:GetLifecycleConfiguration",
"s3:GetBucketLogging",
"s3:ListBucket",
"s3:GetBucketVersioning",
"s3:PutLifecycleConfiguration",
"s3:GetBucketLocation",
"s3:GetObject*"
| January 30, 2023 | | Accelerate started tracking changes | Accelerate started tracking changes for its service-linked roles. | November 30, 2022 | | New service-linked role – [Detective Controls](#slr-deploy-detect-controls) | Accelerate added a new service-linked role to deploy Accelerate detective controls. AWS Managed Services uses this service-linked role to deploy config-recorder, config rules and S3 bucket detective controls. | October 13, 2022 | | New service-linked role – [Deployment Toolkit](#slr-deploy-acc) | Accelerate added a new service-linked role to deploy Accelerate infrastructure. this role deploys AMS Accelerate infrastructure into customer accounts. | June 09, 2022 | # AWS managed policies for AMS Accelerate AWS managed policies An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. For a table of changes, see [Accelerate updates to AWS managed policies](#security-iam-awsmanpol-updates). ## AWS managed policy: AWSManagedServices\$1AlarmManagerPermissionsBoundary AlarmManagerPermissionsBoundary AWS Managed Services (AMS) uses the `AWSManagedServices_AlarmManagerPermissionsBoundary` AWS managed policy. This AWS-managed policy is used in the AWSManagedServices\$1AlarmManager\$1ServiceRolePolicy to restrict permissions of IAM roles created by AWSServiceRoleForManagedServices\$1AlarmManager. This policy grants IAM roles created as part of [How Alarm Manager works](acc-mem-tag-alarms.md#acc-mem-how-tag-alarms-work), permissions to perform operations like AWS Config evaluation, AWS Config read to fetch Alarm Manager configuration, and creation of necessary Amazon CloudWatch alarms. The `AWSManagedServices_AlarmManagerPermissionsBoundary` policy is attached to the `AWSServiceRoleForManagedServices_DetectiveControlsConfig` service-linked role. For updates to this role, see [Accelerate updates to service-linked roles](using-service-linked-roles.md#slr-updates). You can attach this policy to your IAM identities. **Permissions details** This policy includes the following permissions. + `AWS Config` – Allows permissions to evaluate config rules and select resource configuration. + `AWS AppConfig` – Allows permissions to fetch AlarmManager configuration. + `Amazon S3` – Allows permissions to operate AlarmManager buckets and objects. + `Amazon CloudWatch` – Allows permissions to read and put AlarmManager managed alarms and metrics. + `AWS Resource Groups and Tags` – Allows permissions to read resource tags. + `Amazon EC2` – Allows permissions to read Amazon EC2 resources. + `Amazon Redshift` – Allows permissions to read Redshift instances and clusters. + `Amazon FSx` – Allows permissions to describe file systems, volumes and resource tags. + `Amazon CloudWatch Synthetics` – Allows permissions to read Synthetics resources. + `Amazon Elastic Kubernetes Service` – Allows permissions to describe Amazon EKS cluster. + `Amazon ElastiCache` – Allows permissions to describe resources. You can download the policy file in this ZIP: [RecommendedPermissionBoundary.zip](samples/RecommendedPermissionBoundary.zip). ## AWS managed policy: AWSManagedServices\$1DetectiveControlsConfig\$1ServiceRolePolicy Detective controls config managed policy AWS Managed Services (AMS) uses the `AWSManagedServices_DetectiveControlsConfig_ServiceRolePolicy` AWS managed policy. This AWS-managed policy is attached to the [`AWSServiceRoleForManagedServices_DetectiveControlsConfig` service-linked role](using-service-linked-roles.html#slr-deploy-detect-controls), (see [Detective controls service-linked role for AMS Accelerate](using-service-linked-roles.md#slr-deploy-detect-controls)). For updates to the `AWSServiceRoleForManagedServices_DetectiveControlsConfig` service-linked role, see [Accelerate updates to service-linked roles](using-service-linked-roles.md#slr-updates). The policy allows the service-linked role to complete actions for you. You can attach the AWSManagedServices\$1DetectiveControlsConfig\$1ServiceRolePolicy policy to your IAM entities. For more information, see [Using service-linked roles for AMS Accelerate](using-service-linked-roles.md). **Permissions details** This policy has the following permissions to allow AWS Managed Services Detective Controls to deploy and configure all necessary resources. + `CloudFormation` – Allows AMS Detective Controls to deploy CloudFormation stacks with resources like s3 buckets, config rules and config-recorder. + `AWS Config` – Allows AMS Detective Controls to create AMS config rules, configure an aggregator and tag resources. + `Amazon S3` – allows AMS Detective Controls to manage its s3 buckets. You can download the JSON policy file in this ZIP: [DetectiveControlsConfig\$1ServiceRolePolicy.zip](samples/DetectiveControlsConfig_ServiceRolePolicy.zip). ## AWS managed policy: AWSManagedServicesDeploymentToolkitPolicy Deployment toolkit managed policy AWS Managed Services (AMS) uses the `AWSManagedServicesDeploymentToolkitPolicy` AWS managed policy. This AWS-managed policy is attached to the [`AWSServiceRoleForAWSManagedServicesDeploymentToolkit` service-linked role](using-service-linked-roles.html#slr-deploy-acc), (see [Deployment toolkit service-linked role for AMS Accelerate](using-service-linked-roles.md#slr-deploy-acc)). The policy allows the service-linked role to complete actions for you. You can't attach this policy to your IAM entities. For more information, see [Using service-linked roles for AMS Accelerate](using-service-linked-roles.md). For updates to the `AWSServiceRoleForManagedServicesDeploymentToolkitPolicy` service-linked role, see [Accelerate updates to service-linked roles](using-service-linked-roles.md#slr-updates). **Permissions details** This policy has the following permissions to allow AWS Managed Services Detective Controls to deploy and configure all necessary resources. + `CloudFormation` – Allows AMS Deployment Toolkit to deploy CFN stacks with S3 resources required by CDK. + `Amazon S3` – allows AMS Deployment Toolkit to manage its S3 buckets. + `Elastic Container Registry` – allows AMS Deployment Toolkit to manage its ECR repository that is used to deploy assets needed by AMS CDK apps. You can download the JSON policy file in this ZIP: [AWSManagedServicesDeploymentToolkitPolicy.zip](samples/AWSManagedServices_DeploymentToolkitPolicy.zip). ## AWS managed policy: AWSManagedServices\$1EventsServiceRolePolicy Events service managed policy AWS Managed Services (AMS) uses the `AWSManagedServices_EventsServiceRolePolicy` AWS managed policy. This AWS-managed policy is attached to the [`AWSServiceRoleForManagedServices_Events` service-linked role](using-service-linked-roles.html#slr-evb-rule). The policy allows the service-linked role to complete actions for you. You can't attach this policy to your IAM entities. For more information, see [Using service-linked roles for AMS Accelerate](using-service-linked-roles.md). For updates to the `AWSServiceRoleForManagedServices_Events` service-linked role, see [Accelerate updates to service-linked roles](using-service-linked-roles.md#slr-updates). **Permissions details** This policy has the following permissions to allow Amazon EventBridge to deliver alarm state change information from your account to AWS Managed Services. + `events` – Allows Accelerate to create Amazon EventBridge managed rule. This rule is the infrastructure required in your AWS account to deliver alarm state change information from your account to AWS Managed Services. You can download the JSON policy file in this ZIP: [EventsServiceRolePolicy.zip](samples/EventsServiceRolePolicy.zip). ## AWS managed policy: AWSManagedServices\$1ContactsServiceRolePolicy Contacts managed policy AWS Managed Services (AMS) uses the `AWSManagedServices_ContactsServiceRolePolicy` AWS managed policy. This AWS-managed policy is attached to the [`AWSServiceRoleForManagedServices_Contacts` service-linked role](using-service-linked-roles.html#slr-contacts-service), (see [Creating a Contacts SLR for AMS Accelerate](using-service-linked-roles.md#slr-contacts-service-create)). The policy allows the AMS Contacts SLR to look at your resource tags, and their values, on AWS resources. You can't attach this policy to your IAM entities. For more information, see [Using service-linked roles for AMS Accelerate](using-service-linked-roles.md). **Important** Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. AMS uses tags to provide you with administration services. Tags are not intended to be used for private or sensitive data. For updates to the `AWSServiceRoleForManagedServices_Contacts` service-linked role, see [Accelerate updates to service-linked roles](using-service-linked-roles.md#slr-updates). **Permissions details** This policy has the following permissions to allow the Contacts SLR to read your resource tags to retrieve resource contact information that you have set up ahead of time. + `IAM` – Allows Contacts service to look at tags on IAM Roles and IAM users. + `Amazon EC2` – Allows Contacts service to look at tags on Amazon EC2 resources. + `Amazon S3` – Allows Contacts Service to look at tags on Amazon S3 buckets. This action uses a Condition to ensure AMS accesses your bucket tags using the HTTP Authorization header, using the SigV4 signature protocol, and using HTTPS with TLS 1.2 or greater. For more information, see [Authentication Methods](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html#auth-methods-intro) and [Amazon S3 Signature Version 4 Authentication Specific Policy Keys](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html). + `Tag` – Allows Contacts service to look at tags on other AWS resources. + "iam:ListRoleTags", "iam:ListUserTags", "tag:GetResources", "tag:GetTagKeys", "tag:GetTagValues", "ec2:DescribeTags", "s3:GetBucketTagging" You can download the JSON policy file in this ZIP: [ContactsServicePolicy.zip](samples/ContactsServicePolicy.zip). ## Accelerate updates to AWS managed policies Policy updates View details about updates to AWS managed policies for Accelerate since this service began tracking these changes. | Change | Description | Date | | --- | --- | --- | | Updated policy – [Deployment Toolkit](#security-iam-awsmanpol-DeploymentToolkitPolicy) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/security-iam-awsmanpol.html) | April 4, 2024 | | Updated policy – [Deployment Toolkit](#security-iam-awsmanpol-DeploymentToolkitPolicy) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/security-iam-awsmanpol.html) | May 9, 2023 | | Updated policy – [Detective Controls](#security-iam-awsmanpol-DetectiveControlsConfig) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/security-iam-awsmanpol.html) | April 10, 2023 | | Updated policy – [Detective Controls](#security-iam-awsmanpol-DetectiveControlsConfig) | The `ListAttachedRolePolicies` action is removed from the policy. The action had Resource as wildcard (\$1). As "list" is a non-mutative action, it is given access over all resources, and the wildcard is disallowed. | March 28, 2023 | | Updated policy – [Detective Controls](#security-iam-awsmanpol-DetectiveControlsConfig) | Updated the policy and added the permissions boundary policy. | March 21, 2023 | | New policy – [Contacts Service](#ContactsServiceManagedPolicy) | Accelerate added a new policy to look at your account contact information from your resource tags. Accelerate added a new policy to read your resource tags so that it can retrieve the resource contact information that you have set up ahead of time. | February 16, 2023 | | New policy – [Events Service](#EventsServiceRolePolicy) | Accelerate added a new policy to deliver alarm state change information from your account to AWS Managed Services. Grants IAM roles created as part of [How Alarm Manager works](acc-mem-tag-alarms.md#acc-mem-how-tag-alarms-work) permissions to create a required Amazon EventBridge managed rule. | February 07, 2023 | | Updated policy – [Deployment Toolkit](#security-iam-awsmanpol-DeploymentToolkitPolicy) | Added S3 permissions to support customer offboarding from Accelerate. | January 30, 2023 | | New policy – [Detective Controls](#security-iam-awsmanpol-DetectiveControlsConfig) | Allows the service-linked role, [Detective controls service-linked role for AMS Accelerate](using-service-linked-roles.md#slr-deploy-detect-controls), to complete actions for you to deploy Accelerate detective controls. | December 19, 2022 | | New policy – [Alarm Manager](#security-iam-awsmanpol-AlarmManagerPermissionsBoundary) | Accelerate added a new policy to allow permissions to perform alarm manager tasks. Grants IAM roles created as part of [How Alarm Manager works](acc-mem-tag-alarms.md#acc-mem-how-tag-alarms-work) permissions to perform operations like AWS Config evaluation, AWS Config read to fetch alarm manager configuration, creation of necessary Amazon CloudWatch alarms. | November 30, 2022 | | Accelerate started tracking changes | Accelerate started tracking changes for its AWS managed policies. | November 30, 2022 | | New policy – [Deployment Toolkit](#security-iam-awsmanpol-DeploymentToolkitPolicy) | Accelerate added this policy for deployment tasks. Grants the service-linked role [AWSServiceRoleForAWSManagedServicesDeploymentToolkit](using-service-linked-roles.md#slr-deploy-acc) permissions to access and update deployment-related Amazon S3 buckets and CloudFormation stacks. | June 09, 2022 | # Data protection in Accelerate Data protection AMS Accelerate leverages native AWS services such as Amazon GuardDuty, Amazon Macie (optionally), and other internal proprietary tools and processes, to continuously monitor your managed accounts. After an alarm triggers, AMS Accelerate assumes responsibility for the initial triage and response to the alarm. AMS response processes are based on NIST standards. AMS Accelerate regularly tests response processes using Security Incident Response Simulation with you to align your workflow with existing customer security response programs. When AMS Accelerate detects a violation, or imminent threat of a violation, of AWS or your security policies, Accelerate gathers information, including impacted resources and any configuration-related changes. AMS Accelerate provides 24/7/365 follow-the-sun support with dedicated operators that actively review and investigate monitoring dashboards, incident queues, and service requests across all of your managed accounts. Accelerate investigates the findings with internal security experts to analyze the activity and notify you through the security escalation contacts listed in your account. Based on the findings, Accelerate proactively engages with you. If you find that the activity is unauthorized or suspicious, AMS works with you to investigate and remediate or contain the issue. There are certain finding types generated by GuardDuty that require you to confirm the impact before Accelerate takes any action. For example, the GuardDuty finding type **UnauthorizedAccess:IAMUser/ConsoleLogin**, indicates that one of your users has logged in from an unusual location; AMS notifies you and asks that you review the finding to confirm if this behavior is legitimate. ## Monitor with Amazon Macie **Important** AMS Accelerate doesn't support monitoring with Amazon Macie in the Asia Pacific (Malaysia) Region. AMS Accelerate supports, and it's a best practice to use, Amazon Macie to detect a large and comprehensive list of sensitive data, such as personal health information (PHI), personally identifiable information (PII), and financial data. You can configure Macie to run periodically on any Amazon S3 bucket. This automates the evaluation of new or modified objects within a bucket over time. As security findings are generated, AMS notifies you and works with you to remediate findings as needed. For more information, see [Analyzing Amazon Macie findings](https://docs.aws.amazon.com/macie/latest/user/findings.html). ## Monitor with GuardDuty GuardDuty is a continuous security monitoring service that uses threat intelligence feeds, such as lists of malicious IP addresses and domains, and machine learning to identify unexpected and potentially unauthorized and malicious activity within your AWS environment. This might include issues such as escalations of privileges, use of exposed credentials, or communication with malicious IP addresses, or domains. GuardDuty monitors AWS account access behavior for signs of compromise, such as unauthorized infrastructure deployments, instances deployed in a, AWS Region you've never used. GuardDuty also detects unusual API calls, such as a password policy change to reduce password strength. For more information, see the [GuardDuty User Guide](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html). To view and analyze your GuardDuty findings, complete the following steps: 1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/). 1. Choose **Findings**, and then select a specific finding to view details. The details for each finding differ depending on the finding type, resources involved, and nature of the activity. For more information on available finding fields, see [GuardDuty finding details](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings-summary.html). ### Use GuardDuty suppression rules to filter findings A suppression rule is a set of criteria that consists of a filter attribute paired with a value. You can use suppression rules to filter low-value findings that you don't intend to act on, such as false positive findings, or known activities. Filtering your findings helps make it easier to recognize the security threats that might have the most impact to your environment. To filter findings, suppression rules automatically archive new findings that match your specified criteria. Archived findings aren't sent to AWS Security Hub, Amazon S3, or CloudTrail Events. So, suppression filters reduce unactionable data if you consume GuardDuty findings through Security Hub or a third-party SIEM alerting and ticketing application. AMS has a defined set of criteria to identify suppression rules for your managed accounts. When a managed account meets this criteria, AMS applies the filters and creates a service request (SR) to you that details the deployed suppression filter. You can communicate with AMS through an SR to modify or revert the suppression filters. **View archived findings** GuardDuty continues to generate findings even when those findings match your suppression rules. Suppressed findings are marked as **archived**. GuardDuty stores archived finding for 90-days. You can view archived findings in the GuardDuty console for those 90 days by selecting **Archived** from the findings table. Or, view archived findings through the GuardDuty API using the [ListFindings](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API with a **findingCriteria** of **service.archived equal** to **true**. **Common use cases for suppression rules** The following finding types have common use cases for applying suppression rules. + **Recon:EC2/Portscan**: Use a suppression rule to automatically archive findings when using an authorized vulnerability scanner. + **UnauthorizedAccess:EC2/SSHBruteForce**: Use a suppression rule to automatically archive findings when it is targeted to bastion instances. + **Recon:EC2/PortProbeUnprotectedPort**: Use a suppression rule to automatically archive findings when it is targeted to intentionally exposed instances. ## Monitor with Amazon Route 53 Resolver DNS Firewall Amazon Route 53 Resolver responds recursively to DNS queries from AWS resources for public records, Amazon VPC-specific DNS names, and Amazon Route 53 private hosted zones, and is available by default in all VPCs. With Route 53 Resolver DNS Firewall, you can filter and regulate outbound DNS traffic for your virtual private cloud (VPC). To do this, you create reusable collections of filtering rules in DNS Firewall rule groups, associate the rule groups to your VPC, and then monitor activity in DNS Firewall logs and metrics. Based on the activity, you can adjust the behavior of DNS Firewall accordingly. For more information, see [Using DNS Firewall to filter outbound DNS traffic](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html). To view and manage your Route 53 Resolver DNS Firewall configuration, use the following procedure: 1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Under **DNS Firewall**, choose **Rule groups**. 1. Review, edit, or delete your existing configuration, or create a new rule group. For more information, see [How Route 53 Resolver DNS Firewall works](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-overview.html). ### Amazon Route 53 Resolver DNS Firewall monitoring and security Amazon Route 53 DNS Firewall uses the concepts of rule associations, rule action, and rule evaluation priority. A domain list is a reusable set of domain specifications that you use in a DNS Firewall rule, inside a rule group. When you associate a rule group with a VPC, DNS Firewall compares your DNS queries against the domain lists that are used in the rules. If DNS Firewall finds a match, then it handles the DNS query according to the matching rule's action. For more information about rule groups and rules, see [DNS Firewall rule groups and rules](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-groups.html). Domain lists fall into two main categories: + Managed domain lists, that AWS creates and maintains for you. + Your own domain lists, that you create and maintain. Rule groups are evaluated based on their association priority index. By default, AMS deploys a baseline configuration that consists of the following rule and rule group: + One rule group named `DefaultSecurityMonitoringRule`. The rule group has the highest association priority that's available at the time of creation for each existing VPC in each enabled AWS Region. + One rule named `DefaultSecurityMonitoringRule` with priority **1** within the `DefaultSecurityMonitoringRule` rule group, using the `AWSManagedDomainsAggregateThreatList` Managed Domain list with action **ALERT**. If you have an existing configuration, the baseline configuration is deployed with lower priority than your existing configuration. Your existing configuration is the default. You use the AMS baseline configuration as a catch-all if your existing configuration doesn't provide a higher priority instruction on how to handle query resolution. To alter or remove the baseline configuration, do one of the following: + Contact your Cloud Service Delivery Manager (CSDM) or Cloud Architect (CA). + Create a service request. ## Data encryption in AMS Accelerate Data encryption AMS Accelerate uses several AWS services for data encryption. Amazon Simple Storage Service offers several object encryption options that protect data in transit and at rest. Server-side encryption encrypts your object before saving it on disks in its data centers and then decrypts it when you download the objects. As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects. For more information, see [Data protection in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html). # AWS Identity and Access Management in AMS Accelerate AWS Identity and Access Management AWS Identity and Access Management is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources. During AMS Accelerate onboarding, you are responsible for creating cross-account IAM administrator roles within each of your managed accounts. In AMS Accelerate, you're responsible for managing access to your AWS accounts and their underlying resources, such as access management solutions, access policies, and related processes. This means that you manage your user lifecycle, permissions in directory services, and federated authentication system, to access the AWS console or AWS APIs. To help you manage your access solution, AMS Accelerate deploys AWS Config rules that detect common IAM misconfigurations, and delivers remediation notifications. For more information, see [AWS Config Managed Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html). ## Authenticating with identities in AMS Accelerate AMS uses IAM roles, which are a type of IAM identity. An IAM role is similar to a user, in that it is an identity with permissions policies that determine what the identity can and can't do in AWS. However, a role doesn't have credentials associated with it and, instead of being uniquely associated with one person, is assumable by anyone who needs it. An IAM user can assume a role to temporarily take on different permissions for a specific task. Access roles are controlled by internal group membership, which is administered and periodically reviewed by Operations Management. AMS uses the following IAM roles. **Note** AMS access roles allow AMS operators to access your resources to provide AMS capabilities (see [Service description](acc-sd.md)). Altering these roles can inhibit our ability to provide these capabilities. If you need to alter AMS access roles, consult your Cloud Architect. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sec-iam.html) **Note** This is the template for the ams-access-management role. It's the stack that cloud architects (CAs) manually deploy in your account at onboarding: [management-role.yaml](https://ams-account-access-templates.s3.amazonaws.com/management-role.yaml). This is the template for the different access roles and access levels: ams-access-read-only, ams-access-operations, ams-access-admin-operations, ams-access-admin: [accelerate-roles.yaml](https://ams-account-access-templates.s3.amazonaws.com/accelerate-roles.yaml). To learn more about AWS Cloud Development Kit (AWS CDK) (AWS CDK) identifiers, including hashes, see [UniqueIDs](https://docs.aws.amazon.com/cdk/latest/guide/identifiers.html#identifiers_unique_ids). AMS Accelerate feature services assume the **ams-access-admin** role for programmatic access to the account, but with a session policy scoped down for the respective feature service (for example, patch, backup, monitoring, and so forth). AMS Accelerate follows industry best practices to meet and maintain compliance eligibility. AMS Accelerate access to your account is recorded in CloudTrail and also available for your review through change tracking. For information about queries that you can use to get this information, see [Tracking changes in your AMS Accelerate accounts](acc-change-record.md). ## Managing access using policies Various AMS Accelerate support teams such as Operations Engineers, Cloud Architects, and Cloud Service Delivery Managers (CSDMs), sometimes require access to your accounts in order to respond to service requests and incidents. Their access is governed by an internal AMS access service that enforces controls, such as business justification, service requests, operations items, and support cases. The default access is read-only, and all access is tracked and recorded; see also [Tracking changes in your AMS Accelerate accounts](acc-change-record.md). ### Validation of IAM resources The AMS Accelerate access system periodically assumes roles in your accounts (at least every 24 hours) and validates that all of our IAM resources are as expected. In order to protect your accounts, AMS Accelerate has a "canary" that monitors and alarms on the presence and status of the IAM roles, as well as their attached policies, mentioned above. Periodically, the canary assumes the **ams-access-read-only** role and initiates CloudFormation and IAM API calls against your accounts. The canary evaluates the status of the AMS Accelerate access roles to make sure they are always unmodified and up-to-date. This activity creates CloudTrail logs in the account. The AWS Security Token Service (AWS STS) session name of the canary is **AMS-Access-Roles-Auditor-\$1uuid4()\$1** as seen in CloudTrail and the following API calls occur: + Cloud Formation API Calls: `describe_stacks()` + IAM API Calls: + `get_role()` + `list_attached_role_policies()` + `list_role_policies()` + `get_policy()` + `get_policy_version()` + `get_role_policy()` # Security Incident Response in AMS Security Incident Response Security is the top priority at AWS Managed Services (AMS). AMS deploys resources and controls in your accounts to manage them. AWS has a shared responsibility model: AWS manages the security of the cloud, and you are responsible for security in the cloud. AMS protects your data and assets and helps keep your AWS infrastructure secure by using security controls and active monitoring for security issues. These capabilities help you establish a security baseline for applications running in the AWS Cloud. AMS collaborates with you through Security Incident Response to assess the effect, and then carry out containment and remediations based on best practice recommendations. When a deviation from the baseline occurs, such as by a misconfiguration or a change in external factors, you need to respond and investigate. To successfully do so, you need to understand the basic concepts of Security Incident Response within your AMS environment. You must also understand the requirements to prepare, educate, and train cloud teams before security issues occur. It is important to know the controls and capabilities that you can use, prepare response plans for common security issues such as a user account compromise or a misuse of privileged accounts, and identify remediation methods that use automation to improve response speed and consistency. Additionally, you need to understand your compliance and regulatory requirements as they relate to building a Security Incident Response program to fulfill those requirements. Security Incident Response can be complex, but by implementing an iterative approach you can simplify the process and allow the incident response team to keep asset stakeholders satisfied by providing early and continuous detection and response. In this guide, we provide you with the methodology that AMS uses for incident response, the AMS responsibility matrix (RACI), how you can be prepared for a security event, how to engage AMS during security incidents, and some of the incident response runbooks that AMS uses. # How AMS Security Incident Response works How it works AWS Managed Services aligns to the NIST 800-61 [Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) for Security Incident Response. By aligning to this industry standard, we provide a consistent approach to security event management and adhere to best practices in securing and responding to security incidents in your cloud. ![\[Incident response lifecycle\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/images/sec-inc-response-1.png) **Incident response lifecycle** When detection identifies and generates a security alert, or you request security assistance, the AWS Managed Services Operations team makes sure that there is a timely investigation, executes automations to perform data collection, triages and analyzes, informs you of the analysis, performs investigation and any containment activities, and then posts event analysis. The data collection, triage, analysis, and containment activities performed during the incident response vary depending on the type of security event being investigated. Example Security Incident Response workflows for select scenarios are at the end of this document. During incidents, AMS determines the correct course of action dynamically, which might result in documented steps being re-ordered or bypassed as appropriate to make sure that the right outcome occurs. # Prepare Prepare As the threat landscape evolves, AMS continues to expand detection and response capabilities. As new detections are added, AMS incorporates the alerts from these new detections into the detection and response platform. AMS security responders are trained to investigate and partner with you throughout the Security Incident Response lifecycle. Because of this partnership approach, it's important that your security and application teams are prepared to engage with AMS to handle security events as these events occur. This documentation explains what to expect during a security event and helps you prepare for rapid response when a security incident occurs. This documentation uses the NIST 800-61 definition of an **event** as any observable occurrence in a system or network and an **incident** as a violation or imminent threat of violation of policies, acceptable use policies, or standard security practices. ## Preparation checklist Preparation checklist Work through the following checklist with your AMS cloud solution delivery manager (CSDM) and AMS cloud architect (CA): + Understand what workloads are running in which accounts. + Understand what internal teams are responsible for the various workloads and tag them appropriately in the workloads. + Maintain contact details internally for other teams who might be required during a security event investigation and for containment decisions. + Confirm that security contacts are up to date and added to all managed AWS accounts. The contacts are managed on a per account basis. + Know how to raise security incident to AMS, and be familiar with the severity and expected response times. + Make sure that when security notifications are received, they are routed to the appropriate people and systems such as pagers or your security operations center. + Understand what log sources are available to you, where these are stored in your accounts and who has access to them. + Understand how to use CloudWatch Insights to Query Logs during investigations. + Understand the containment options available to you by resource (EC2, IAM, S3, and son on) and the consequences on your workload availability when in containment. # Detect Detect During the management of your AWS accounts, AMS monitors for anomalies in user behavior, account activities and potential security events using data collected from detection sources and controls including but not limited to Amazon CloudWatch, Amazon GuardDuty, VPC Flow Logs, Amazon Macie, AWS Config and Amazon internal Threat Intelligence feeds. AMS uses both native AWS services and other detection technologies to respond to security events created by: + Config Conformance Finding Types + GuardDuty Finding Types + Macie Finding Types + Amazon Route 53 Resolver DNS Firewall Events + AMS Security events (cloud watch alarms) Additional findings are added as services, products and threat ecosystems evolves. ## Report security events to AMS Report security events Raise an incident through the AMS Support Portal or Support Center to notify AMS of a security incident or to request investigations. # Analyze Analyze After a security event is identified and reported, the next step is to analyze whether the reported event is a false positive or a real incident. AMS uses automation and manual investigative techniques to handle security events. The analysis includes investigation of logs from different detection sources such as network traffic logs, host logs,CloudTrail events, AWS service logs and so on. The analysis also looks for patterns that show an anomalous behavior by correlation. Your partnership is required to understand context specific to the account environment and to establish what is normal for your account and workloads. This helps AMS identify an anomaly faster and to an accelerated incident response. ## Handle communications from AMS about security events Communications from AMS AMS keeps you informed during the investigation by engaging your security contacts through an incident ticket. Your AMS cloud service delivery manager (CSDM) and AMS cloud architect (CA) are the point of contacts to reach out to for any communication during an active security investigation. Communication includes automated notification when a security alert is generated, communication after event analysis, establishing call bridges and the ongoing delivery of artifacts such as log files, snapshot of infected resources, and getting investigation results to you during the security event. Standard fields included in AMS security alert notifications are listed below. These fields provide you with information so that you can route events to the appropriate teams within your organization for remediation. + Finding Type + Finding Identifier (Where relevant) + Finding Severity + Finding Description + Finding created Date & Time + AWS Account Id + Region (Where relevant) + AWS Resources (IAM user/role/policy, EC2, S3, EKS) Additional fields are provided depending on the Finding Type, for example EKS Findings include Pod, Container, and Cluster details. # Contain Contain AMS's approach to containment is partnership with you. You understand your business and the workload impacts that might occur from containment activities, such as network isolation, IAM user or role de-provisioning, instance re-building, and so forth. An essential part of containment is decision-making. For example, shut down a system, isolate a resource from the network, or turn off access or end sessions. These decisions are easier to make if there are predetermined strategies and procedures to contain the incident. AMS provides the containment strategy and then implements the solution after you have considered the risk involved with implementing the containment actions. There are different containment options depending on the resources under analysis. AMS expects multiple types of containment to be simultaneously deployed during an incident investigation. Some of these examples include: + Apply protection rules to block unauthorized traffic (Security group, NACL, WAF Rules, SCP rules, Deny listing, setting signature action to quarantine or block) + Resource Isolation + Network Isolation + Disabling IAM users, roles and policies + Modifying/Reducing IAM user, role privilege + Terminating / Suspending / Deleting compute resources + Restricting public access from affected resource + Rotating access keys, API keys, and passwords + Scrubbing disclosed credentials and sensitive information AMS encourages you to consider the type of containment strategies for each major incident type that is within their risk appetite, with criteria clearly documented to help with decision making in the event of an incident. Criteria to determine the appropriate strategy include: + Potential damage to resources + Preservation of evidence + Service unavailability (for example, network connectivity, services provided to external parties) + Time and resources needed to implement the strategy + Effectiveness of the strategy (For example, partial containment, full containment) + Permanence of the solution (For example, one-way door vs two-way door decisions) + Duration of the solution (For example, emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution). + Apply security controls that you can turn on to lower the risk and allow time to define and implement a more effective containment. The speed of containment is critical, AMS advises a staged approach to achieve efficient and effective containment by strategizing short-term and long-term approaches. Use this guide to consider your containment strategy that involves different techniques based on the resource type. + Containment Strategy + Can AMS identify the scope of the security incident? + If yes, identify all the resources (users, systems, resources). + If no, investigate in parallel with executing the next step on identified resources. + Can the resource be isolated? + If yes, then proceed to isolate the affected resources. + If no, then work with system owners and managers to determine further actions necessary to contain the problem. + Are all affected resources isolated from non-affected resources? + If yes, then continue to the next step. + If no, then continue to isolate affected resources until short-term containment is accomplished to prevent the incident from escalating further. + System Backup + Were backup copies of affected systems created for further analysis? + Are the forensic copies encrypted and stored in a secure location? + If yes, then continue to the next step. + If no, encrypt the forensic images, then store them in a secure location to prevent accidental usage, damage, and tampering. # Eradicate Eradicate After an incident is contained, eradication might be necessary to eliminate sources of threat altogether to secure the system before you proceed to the next recovery stage. Eradication steps might include deleting malware and removing compromised user accounts, as well as identifying and mitigating all vulnerabilities that were exploited. During eradication, it's important to identify all affected accounts, resources, and instances within the environment so that they can be remediated.  It's a best practice that eradication and recovery is done in a phased approach so that remediation steps are prioritized. For large-scale incidents, recovery might take months. The intent of the early phases must be to increase the overall security with relatively quick (days to weeks) high value changes to prevent future incidents. The later phases must focus on longer-term changes (for example, infrastructure changes) and ongoing work to keep the enterprise as secure as possible. For some incidents, eradication is either not necessary or is performed during recovery.  Consider the following: + Can the system be re-imaged and then hardened with patches or other countermeasures to prevent or reduce the risk of attacks? + Are all malware and other artifacts left behind by the attackers removed and the affected systems hardened against further attacks? # Recover Recover AMS partners with you to restore systems to normal operation, confirm that the systems are functioning normally, and (as applicable) remediate vulnerabilities to prevent similar incidents. Consider the following: + Are the affected system(s) patched and hardened against the recent attack and possible future attacks? + What day and time is feasible to restore the affected systems back into production? + What tools will you use to test, monitor, and verify that the systems that you restore to production aren't vulnerable to the initial attack techniques? # Post Incident Report Post Incident Report Post event, AMS runs an investigation review process for all security incidents. And, AMS initiates a correction of error (COE) process to address security incidents caused by a system or a procedural miss that plausibly has room for improvement. AMS partners with you to continuously-improve security investigation experience. The COE process helps AMS identify the contributing factors of customer-impacting events and connects those causes to next actions items that can prevent similar events from recurring, or helps mitigate the duration or level of impact. The investigation review process for security incidents addresses the following items to identify opportunities for improvement: + What was the elapsed time from the beginning of the incident to incident discovery, to the initial impact assessment, and to each stage of the incident handling process (for example, containment, recovery)? + How long did it take the incident response team to respond to the initial report of the incident? + How long did it take to do an initial impact analysis? + Was this preventable and how? Is there a tool or process that could have prevented this? + Could we have detected this sooner and how? + What could have made the investigation go faster? + Were the documented Incident Response Procedures followed? Were they adequate? + Was the information sharing with other stakeholders done in a timely manner How could it be improved? + Was the collaboration with other teams (AWS Security, account teams, AWS Development team and customer security team's) effective? If not, what could be improved? + What preparation steps were missing that might have helped, escalation matrices, RACI’s, shared responsibility models, and so on? Is there a need to update any Runbooks? + What was the difference between the initial impact assessment and the final impact assessment? What can we do to improve accuracy of assessments earlier in the incident response? + What are the Action Items from the Lessons Learned? # Security Incident Response Runbooks in AMS Security Incident Response Runbooks This section contains two runbooks: + [Response to root user activity](sir-root-user.md) + [Response to malware events](sir-malware.md) # Response to root user activity Response to root user activity The  [root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) is the superuser within your AWS account. Note that AMS monitors root usage. It's a best practice to use the root user only for the few tasks that require it, such as to change your account settings, activate AWS Identity and Access Management (IAM) access to billing and cost management, change your root password, and turn on multi-factor authentication (MFA). For more information, see  [Tasks that require root user credentials](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root). For more information on how to inform AMS of planned root usage, see [When and how to use the root account in AMS](https://docs.aws.amazon.com/managedservices/latest/userguide/how-when-to-use-root.html). When root user activity is detected, either failed attempts to login that might indicate a brute force attack or activity in the account after a successful login, an event generates and an incident sent to your defined security contacts. AWS Managed Services Operations investigates unplanned root user activity, perform data collection, triage and analysis, and perform containment activities at your direction, followed by post event analysis. If you have the AMS Advanced operating model, you receive additional communications from AMS CSDM and AMS Ops engineers that confirm unplanned root user activity due AMS's responsibility to secure root user credentials. AMS investigates root user activity until you confirm a path forward. ## Prepare Prepare Advise AMS of any planned use of root user by submitting an AMS service request with data and times of planned event to prevent unnecessary incident response activities. Periodically conduct GameDays with AMS to validate AMS's customer incident response processes, people and systems are current, and build muscle memory with responsible individuals to achieve faster incident response. ## Phase A: Detect Phase A: Detect AMS monitors for root activity in the accounts through detection sources including GuardDuty and AMS monitoring. If you have AMS Accelerate, the operating model responds to the incident requesting investigation for unexpected root user activity. When this occurs, AMS Operations initiates the Compromised Account runbook. If you have AMS Advanced, the operating model responds to the incident, or informs the CSDM of any planned root user activity to terminate an active Account Compromise investigation. ## Phase B: Analyze Phase B: Analyze AMS performs a thorough investigation of the root user events when it's determined that the activity isn't authorized. Using both automations and AMS security response team, logs and events are analyzed for anomalies and unexpected behavior for root users. Logs are provided to you to help determine if the activity is unknown, or if it's an authorized root user event, or if it requires further investigation. Some examples of the information provided during the investigation to support internal checks includes: + Account information: What account was the root account used on? + E-mail address for root user: Each root user is associated with an e-mail address from your organization + Authentication details: Where and when did the root user access your environment from? + Activity records: What did the user do when logged in as root? These records are in the form of CloudWatch events. Understanding how to read these logs aids in investigation. It's a best practice that you are prepared to receive the analysis information and have a plan for how to reach authorized points of contact for accounts within your organization. Because root users aren't named as individuals, determining who has access to the root e-mail address used for the account within your organization helps to quickly route questions internally. ## Phase C: Contain and Eradicate Phase C: Contain and Eradicate AMS partners with your security teams to perform containment at the direction of your authorized Customer Security contacts. Containment options include: + Rotating appropriate credentials and keys. + Terminating active sessions to accounts and resources. + Eradicating resources created. During the containment activities AMS works closely with your security team to ensure any disruption to your workloads are minimized and the root credentials are appropriately secured. After the containment plan is completed, you work with AMS Operations team for any recovery actions as required. ## Post Incident Report Post Incident Report As required, AMS initiates the investigation review process to identify any lessons learned. As part of completing a COE, AMS communicates any relevant findings to affected customers to help them improve their incident response process. AMS documents all final details of the investigation, collects appropriate metrics, and then reports the incident to any AMS internal teams that require information, including your assigned CSDM and CA. # Response to malware events Response to malware events Amazon EC2 instances are used to host a variety of workloads including third-party software and custom-developed software deployed by application teams within organizations. AMS provides and encourages you to deploy your workloads on images that are patched and maintained on an ongoing basis by AMS. During the operation of instances, AMS monitors for anomalies in behavior or activity through a variety of security detection controls, including Amazon GuardDuty, Network Traffic, and Amazon internal Threat Intelligence feeds. AMS also monitors GuardDuty Malware Findings. These are available on both AMS Advanced and AMS Accelerate, if enabled. See [Malware Protection in Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html) for more information. **Note** If you opted for [Bring Your Own EPS](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-byoeps.html), then the process for incident response differs from what's outlined on this page. For more information, see the referenced documentation. When malware is detected, an incident is created and you are notified of the event. This notification is followed by any remediation activities that occurred. AMS Operations investigates, performs data collection, triage and analysis, and then performs containment activities at your direction, followed by post event analysis. ## Phase A: Detect Phase A: Detect AMS monitors for events on instances with GuardDuty. AMS determines the appropriate enrichment and triage activities to help you make containment or risk acceptance decisions based on the finding or alert type. Data collection is performed based on the finding type. Data collection involves querying multiple data sources both inside and outside of the affected account to build a picture of the activity observed or the configurations of concern. AMS performs correlation of the finding with any other alarms and alerts or telemetry from any impacted accounts or AMS threat intelligence platforms. ## Phase B: Analyze Phase B: Analyze After data is collected, it's analyzed to identify any activity or indicators of concern. During this phase of the investigation, AMS partners with you to integrate business and domain knowledge of the instances and workloads to help understand what's expected and what's out of the ordinary. Some examples of the information provided during the investigation to support internal checks includes: + Account Information: What account was the malware activity observed on? + Instance Details: What instance(s) are implicated with the malware events? + Event timestamp: When did the alert trigger? + Workload Information: What is running on the instance? + Malware details, if relevant: Families of malware and Open Source information about the malware. + Users or Role Details: What users or roles are affected by and involved in the activity? + Activity Records: What activities are recorded on the instance? These are in the form of CloudWatch events, and system events from the instance. Understanding how to read these logs will aid you in investigation + Network Activity: What endpoints are connecting to the instance, what the instance is connecting to, and what is the traffics analysis? It's a best practice to be prepared to receive investigation information, and have a plan about how to contact the appropriate points of contact for accounts, instances and workloads within your organization. Understanding your network topology and expected connection can help accelerate impact analysis. Knowledge of planned penetration testing in the environment and recent deployments performed by application owners can also speed up the investigation. If you determine that the activity is planned and authorized, then the incident is updated and the investigation ends. If compromise is confirmed, then you and AMS determine the appropriate containment plan. ## Phace C: Contain and Eradicate Phase C: Contain and Eradicate AMS partners with you to determine appropriate containment activities based on the data collected and information known. Containment options include but are not limited to: + Preserving data through snapshots + Modifying network rules to limit traffic in or out of instances + Modifying SCP, IAM user and role policies to limit access + Terminating, Suspending or Turning off Instances + Terminating any persistent connections + Rotating appropriate credentials/keys If you opt to perform eradication activity against the instance, then AMS supports you in achieving this. Options include, but are not limited to: + Removing any unwanted software + Rebuilding the instance from a clean fully patched image and redeploying applications and configuration + Restoring the instance from a previous backup + Deploying applications and services on to another instance within your account that might be suitable to host the workloads. It's important to determine how the malware was delivered and run on the instance before restoration of service to make sure that any additional controls are applied to prevent reoccurrence of the malware on the instance. AMS provides additional insights or information to your forensics partners or teams as necessary to support forensics. At this point, you work with AMS Operations for the recovery activities. AMS works closely with you to minimize disruption to the workloads and secure the instances. ## Post Incident Report Post Incident Report As required, AMS initiates the investigation review process to identify lessons learned. As part of completing a COE, AMS communicates relevant findings to you to help you improve your incident response process. AMS documents the final details of the investigation, collects appropriate metrics, and reports the incident to AMS internal teams that require information, including your assigned CSDM and CA. # Security event logging and monitoring in Accelerate Security event logging and monitoring Accounts enrolled in AMS Accelerate are configured with a baseline deployment of CloudWatch [Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) and [Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) that have been optimized to reduce noise and to identify indications of a true incident. AMS Accelerate also employs GuardDuty for account monitoring. For more information, see [Monitor with GuardDuty](acc-sec-data-protect.md#acc-sec-data-protect-gd). # Configuration compliance in Accelerate Configuration compliance AMS Accelerate helps you configure your resources to high standards for security and operational integrity, and comply with the following industry standards: + Center for Internet Security (CIS) + National Institute of Standards and Technology (NIST) Cloud Security Framework (CSF) + Health Insurance Portability and Accountability Act (HIPAA) + Payment Card Industry (PCI) Data Security Standard (DSS) We do this by deploying our entire compliance AWS Config rule set to your account, see [AMS Config Rule library](#acc-sec-compliance-rules). An AWS Config rule represents desired configurations for a resource and is evaluated against configuration changes on the settings of your AWS resources. Any configuration change triggers a large number of rules to test compliance. For example, suppose you create an Amazon S3 bucket, and configure it to be publicly readable, in violation of NIST standards. The [ams-nist-cis-s3-bucket-public-read-prohibited rule](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited.html) detects the violation and labels your S3 bucket **Noncompliant** in your Configuration Report. Because this rule belongs to the **Auto Incident** remediation category, it immediately creates a Incident Report, alerting you to the issue. Other more severe rule violations might cause AMS to automatically remediate the issue. See [Responses to violations in Accelerate](#acc-sec-compliance-responses). **Important** If you want us to do more, for example, if you want AMS to remediate a violation for you, regardless of its remediation category, submit a Service Request that asks AMS to remediate the noncompliant resources for you. In the Service Request, include a comment such as "As part of the AMS config rule remediation, please remediate non-complaint resources *RESOURCE\$1ARNS\$1OR\$1IDs*, config rule *CONFIG\$1RULE\$1NAME* in the account" and add the required inputs to remediate the violation. If you want us to do less, for example, if you don't want us to take action on a particular S3 bucket that requires public access by design, you can create exceptions, see [Creating rule exceptions in Accelerate](#acc-sec-compliance-config-reports-exception). ## AMS Config Rule library Accelerate deploys a library of AMS config rules to protect your account. These config rules begin with `ams-`. You can view rules within your account, and their compliance state, from either the AWS Config console, AWS CLI, or the AWS Config API. For general information about using AWS Config, see [ ViewingConfiguration Compliance](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_view-compliance.html). **Note** For opt-in AWS Regions, and gov cloud Regions, we only deploy a subset of the config rules due to Region restrictions. Check the rule availability in Regions by checking the link associated to the identifier in the AMS Accelerate config rules table. You cannot remove any of the deployed AMS Config Rules. ### Table of Rules Download as [ams\$1config\$1rules.zip](samples/ams_config_rules.zip). **AMS Configuration Rules** | Rule Name | Service | Trigger | Action | Frameworks | | --- | --- | --- | --- | --- | | [ams-nist-cis-guardduty-enabled-centralized](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-enabled-centralized.html) | GuardDuty | Periodic | Remediate | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 2.2,3.4,8.2.1; | | [ams-nist-cis-vpc-flow-logs-enabled](https://docs.aws.amazon.com/config/latest/developerguide/vpc-flow-logs-enabled.html) | VPC | Periodic | Remediate | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-5,PR.PT-1; HIPAA: 164.308(a)(3)(ii)(A),164.312(b); PCI: 2.2,10.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6; | | [ams-eks-secrets-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/eks-secrets-encrypted.html) | EKS | Periodic | Incident | CIS: NA; NIST-CSF: NA; HIPAA: NA; PCI: NA; | | [ams-eks-endpoint-no-public-access](https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html) | EKS | Periodic | Incident | CIS: NA; NIST-CSF: NA; HIPAA: NA; PCI: NA; | | [ams-nist-cis-vpc-default-security-group-closed](https://docs.aws.amazon.com/config/latest/developerguide/vpc-default-security-group-closed.html) | VPC | Config Changes | Incident | CIS: CIS.11,CIS.12,CIS.9; NIST-CSF: DE.AE-1,PR.AC-3,PR.AC-5,PR.PT-4; HIPAA: 164.312(e)(1); PCI: 1.2,1.3,2.1,2.2,1.2.1,1.3.1,1.3.2,2.2.2; | | [ams-nist-cis-iam-password-policy](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html) | IAM | Periodic | Incident | CIS: NA; NIST-CSF: PR.AC-1,PR.AC-4; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(A),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 7.1.2,7.1.3,7.2.1,7.2.2; | | [ams-nist-cis-iam-root-access-key-check](https://docs.aws.amazon.com/config/latest/developerguide/iam-root-access-key-check.html) | IAM | Periodic | Incident | CIS: CIS.16,CIS.4; NIST-CSF: PR.AC-1,PR.AC-4,PR.PT-3; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(A),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 2.2,7.1.2,7.1.3,7.2.1,7.2.2; | | [ams-nist-cis-iam-user-mfa-enabled](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-mfa-enabled.html) | IAM | Periodic | Incident | CIS: CIS.16; NIST-CSF: PR.AC-1,PR.AC-4; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(A),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 2.2,7.1.2,7.1.3,7.2.1,7.2.2; | | [ams-nist-cis-restricted-ssh](https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html) | Security Groups | Config Changes | Incident | CIS: CIS.16; NIST-CSF: PR.AC-1,PR.AC-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 2.2,7.2.1,8.1.4; | | [ams-nist-cis-restricted-common-ports](https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html) | Security Groups | Config Changes | Incident | CIS: CIS.11,CIS.12,CIS.9; NIST-CSF: DE.AE-1,PR.AC-3,PR.AC-5,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,2.2,1.2.1,1.3.1,1.3.2,2.2.2; | | [ams-nist-cis-s3-account-level-public-access-blocks](https://docs.aws.amazon.com/config/latest/developerguide/s3-account-level-public-access-blocks.html) | S3 | Config Changes | Incident | CIS: CIS.9,CIS.12,CIS.14; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.2.1,1.3,1.3.1,1.3.2,1.3.4,1.3.6,2.2,2.2.2; | | [ams-nist-cis-s3-bucket-public-read-prohibited](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited.html) | S3 | Config Changes | Incident | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,2.2,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-s3-bucket-public-write-prohibited](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-write-prohibited.html) | S3 | Config Changes | Incident | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,2.2,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-s3-bucket-server-side-encryption-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-server-side-encryption-enabled.html) | S3 | Config Changes | Incident | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(c)(2),164.312(e)(2)(ii); PCI: 2.2,3.4,10.5,8.2.1; | | [ams-nist-cis-securityhub-enabled](https://docs.aws.amazon.com/config/latest/developerguide/securityhub-enabled.html) | Security Hub | Periodic | Incident | CIS: CIS.3,CIS.4,CIS.6,CIS.12,CIS.16,CIS.19; NIST-CSF: PR.DS-5,PR.PT-1; HIPAA: 164.312(b); PCI: NA; | | [ams-nist-cis-ec2-instance-managed-by-systems-manager](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html) | EC2 | Config Changes | Report | CIS: CIS.2,CIS.5; NIST-CSF: ID.AM-2,PR.IP-1; HIPAA: 164.308(a)(5)(ii)(B); PCI: 2.4; | | [ams-nist-cis-cloudtrail-enabled](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-enabled.html) | CloudTrail | Periodic | Report | CIS: CIS.16,CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-5,PR.MA-2,PR.PT-1; HIPAA: 164.308(a)(3)(ii)(A),164.308(a)(5)(ii)(C),164.312(b); PCI: 10.1,10.2.1,10.2.2,10.2.3,10.2.4,10.2.5,10.2.6,10.2.7,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6; | | [ams-nist-cis-access-keys-rotated](https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html) | IAM | Periodic | Report | CIS: CIS.16; NIST-CSF: PR.AC-1; HIPAA: 164.308(a)(4)(ii)(B); PCI: 2.2; | | [ams-nist-cis-acm-certificate-expiration-check](https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-expiration-check.html) | Certificate Manager | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.AC-5,PR.PT-4; HIPAA: NA; PCI: 4.1; | | [ams-nist-cis-alb-http-to-https-redirection-check](https://docs.aws.amazon.com/config/latest/developerguide/alb-http-to-https-redirection-check.html) | ALB | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-2; HIPAA: 164.312(a)(2)(iv),164.312(e)(1),164.312(e)(2)(i),164.312(e)(2)(ii); PCI: 2.3,4.1,8.2.1; | | [ams-nist-cis-api-gw-cache-enabled-and-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-cache-enabled-and-encrypted.html) | API Gateway | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4; | | [ams-nist-cis-api-gw-execution-logging-enabled](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-execution-logging-enabled.html) | API Gateway | Config Changes | Report | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.PT-1; HIPAA: 164.312(b); PCI: 10.1,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6,10.5.4; | | [ams-nist-autoscaling-group-elb-healthcheck-required](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-group-elb-healthcheck-required.html) | ELB | Config Changes | Report | CIS: NA; NIST-CSF: PR.PT-1,PR.PT-5; HIPAA: 164.312(b); PCI: 2.2; | | [ams-nist-cis-cloud-trail-encryption-enabled](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-encryption-enabled.html) | CloudTrail | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 2.2,3.4,10.5; | | [ams-nist-cis-cloud-trail-log-file-validation-enabled](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-log-file-validation-enabled.html) | CloudTrail | Periodic | Report | CIS: CIS.6; NIST-CSF: PR.DS-6; HIPAA: 164.312(c)(1),164.312(c)(2); PCI: 2.2,10.5,11.5,10.5.2,10.5.5; | | [ams-nist-cis-cloudtrail-s3-dataevents-enabled](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-s3-dataevents-enabled.html) | CloudTrail | Periodic | Report | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-5,PR.PT-1; HIPAA: 164.308(a)(3)(ii)(A),164.312(b); PCI: 2.2,10.1,10.2.1,10.2.2,10.2.3,10.2.5,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6; | | [ams-nist-cis-cloudwatch-alarm-action-check](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html) | CloudWatch | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: NA; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4; | | [ams-nist-cis-cloudwatch-log-group-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-log-group-encrypted.html) | CloudWatch | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: NA; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4; | | [ams-nist-cis-codebuild-project-envvar-awscred-check](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-envvar-awscred-check.html) | CodeBuild | Config Changes | Report | CIS: CIS.18; NIST-CSF: PR.DS-5; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 8.2.1; | | [ams-nist-cis-codebuild-project-source-repo-url-check](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-source-repo-url-check.html) | CodeBuild | Config Changes | Report | CIS: CIS.18; NIST-CSF: PR.DS-5; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 8.2.1; | | [ams-nist-cis-db-instance-backup-enabled](https://docs.aws.amazon.com/config/latest/developerguide/db-instance-backup-enabled.html) | RDS | Config Changes | Report | CIS: CIS.10; NIST-CSF: ID.BE-5,PR.DS-4,PR.IP-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(A),164.308(a)(7)(ii)(B); PCI: NA; | | [ams-nist-cis-dms-replication-not-public](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-not-public.html) | DMS | Periodic | Report | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-dynamodb-autoscaling-enabled](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-autoscaling-enabled.html) | DynamoDB | Periodic | Report | CIS: NA; NIST-CSF: ID.BE-5,PR.DS-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(C); PCI: NA; | | [ams-nist-cis-dynamodb-pitr-enabled](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-pitr-enabled.html) | DynamoDB | Periodic | Report | CIS: CIS.10; NIST-CSF: ID.BE-5,PR.DS-4,PR.IP-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(A),164.308(a)(7)(ii)(B); PCI: NA; | | [ams-nist-dynamodb-throughput-limit-check](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-throughput-limit-check.html) | DynamoDB | Periodic | Report | CIS: NA; NIST-CSF: NA; HIPAA: 164.312(b); PCI: NA; | | [ams-nist-ebs-optimized-instance](https://docs.aws.amazon.com/config/latest/developerguide/ebs-optimized-instance.html) | EBS | Config Changes | Report | CIS: NA; NIST-CSF: NA; HIPAA: 164.308(a)(7)(i); PCI: NA; | | [ams-nist-cis-ebs-snapshot-public-restorable-check](https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-public-restorable-check.html) | EBS | Periodic | Report | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-ec2-instance-detailed-monitoring-enabled](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-detailed-monitoring-enabled.html) | EC2 | Config Changes | Report | CIS: NA; NIST-CSF: DE.AE-1,PR.PT-1; HIPAA: 164.312(b); PCI: NA; | | [ams-nist-cis-ec2-instance-no-public-ip](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-no-public-ip.html) | EC2 | Config Changes | Report | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-ec2-managedinstance-association-compliance-status-check](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-association-compliance-status-check.html) | EC2 | Config Changes | Report | CIS: CIS.12,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-ec2-managedinstance-patch-compliance-status-check](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-patch-compliance-status-check.html) | EC2 | Config Changes | Report | CIS: CIS.2,CIS.5; NIST-CSF: ID.AM-2,PR.IP-1; HIPAA: 164.308(a)(5)(ii)(B); PCI: 6.2; | | [ams-nist-cis-ec2-stopped-instance](https://docs.aws.amazon.com/config/latest/developerguide/ec2-stopped-instance.html) | EC2 | Periodic | Report | CIS: CIS.2; NIST-CSF: ID.AM-2,PR.IP-1; HIPAA: NA; PCI: NA; | | [ams-nist-cis-ec2-volume-inuse-check](https://docs.aws.amazon.com/config/latest/developerguide/ec2-volume-inuse-check.html) | EC2 | Config Changes | Report | CIS: CIS.2; NIST-CSF: PR.IP-1; HIPAA: NA; PCI: NA; | | [ams-nist-cis-efs-encrypted-check](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html) | EFS | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-nist-cis-eip-attached](https://docs.aws.amazon.com/config/latest/developerguide/eip-attached.html) | EC2 | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-nist-cis-elasticache-redis-cluster-automatic-backup-check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html) | ElastiCache | Periodic | Report | CIS: CIS.10; NIST-CSF: ID.BE-5,PR.DS-4,PR.IP-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(A),164.308(a)(7)(ii)(B); PCI: NA; | | [ams-nist-cis-opensearch-encrypted-at-rest](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-encrypted-at-rest.html) | OpenSearch | Periodic | Report | CIS: CIS.14,CIS.13; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-nist-cis-opensearch-in-vpc-only](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-in-vpc-only.html) | OpenSearch | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-nist-cis-elb-acm-certificate-required](https://docs.aws.amazon.com/config/latest/developerguide/elb-acm-certificate-required.html) | Certificate Manager | Config Changes | Report | CIS: CIS.12,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-elb-deletion-protection-enabled](https://docs.aws.amazon.com/config/latest/developerguide/elb-deletion-protection-enabled.html) | ELB | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-2; HIPAA: 164.312(a)(2)(iv),164.312(e)(1),164.312(e)(2)(i),164.312(e)(2)(ii); PCI: 4.1,8.2.1; | | [ams-nist-cis-elb-logging-enabled](https://docs.aws.amazon.com/config/latest/developerguide/elb-logging-enabled.html) | ELB | Config Changes | Report | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.PT-1; HIPAA: 164.312(b); PCI: 10.1,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6,10.5.4; | | [ams-nist-cis-emr-kerberos-enabled](https://docs.aws.amazon.com/config/latest/developerguide/emr-kerberos-enabled.html) | EMR | Periodic | Report | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.PT-1; HIPAA: 164.312(b); PCI: 10.1,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6,10.5.4; | | [ams-nist-cis-emr-master-no-public-ip](https://docs.aws.amazon.com/config/latest/developerguide/emr-master-no-public-ip.html) | EMR | Periodic | Report | CIS: CIS.14,CIS.16; NIST-CSF: PR.AC-1,PR.AC-4,PR.AC-6; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(A),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 7.2.1; | | [ams-nist-cis-encrypted-volumes](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html) | EBS | Config Changes | Report | CIS: CIS.12,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-guardduty-non-archived-findings](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-non-archived-findings.html) | GuardDuty | Periodic | Report | CIS: CIS.12,CIS.13,CIS.16,CIS.19,CIS.3,CIS.4,CIS.6,CIS.8; NIST-CSF: DE.AE-2,DE.AE-3,DE.CM-4,DE.DP-5,ID.RA-1,ID.RA-3,PR.DS-5,PR.PT-1; HIPAA: 164.308(a)(5)(ii)(C),164.308(a)(6)(ii),164.312(b); PCI: 6.1,11.4,5.1.2; | | [ams-nist-iam-group-has-users-check](https://docs.aws.amazon.com/config/latest/developerguide/iam-group-has-users-check.html) | IAM | Config Changes | Report | CIS: NA; NIST-CSF: PR.AC-4,PR.AC-1; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(A),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 7.1.2,7.1.3,7.2.1,7.2.2; | | [ams-nist-cis-iam-policy-no-statements-with-admin-access](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-admin-access.html) | IAM | Config Changes | Report | CIS: CIS.16; NIST-CSF: PR.AC-6,PR.AC-7; HIPAA: 164.308(a)(4)(ii)(B),164.308(a)(5)(ii)(D),164.312(d); PCI: 8.2.3,8.2.4,8.2.5; | | [ams-nist-cis-iam-user-group-membership-check](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-group-membership-check.html) | IAM | Config Changes | Report | CIS: CIS.16,CIS.4; NIST-CSF: PR.AC-1,PR.AC-4,PR.PT-3; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(a)(2)(i); PCI: 2.2,7.1.2,7.2.1,8.1.1; | | [ams-nist-cis-iam-user-no-policies-check](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-no-policies-check.html) | IAM | Config Changes | Report | CIS: CIS.16; NIST-CSF: PR.AC-1,PR.AC-7; HIPAA: 164.308(a)(4)(ii)(B),164.312(d); PCI: 8.3; | | [ams-nist-cis-iam-user-unused-credentials-check](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html) | IAM | Periodic | Report | CIS: CIS.16; NIST-CSF: PR.AC-1,PR.AC-4,PR.PT-3; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(A),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1); PCI: 2.2,7.1.2,7.1.3,7.2.1,7.2.2; | | [ams-nist-cis-ec2-instances-in-vpc](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instances-in-vpc.html) | EC2 | Config Changes | Report | CIS: CIS.11,CIS.12,CIS.9; NIST-CSF: DE.AE-1,PR.AC-3,PR.AC-5,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(3)(ii)(B),164.308(a)(4)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(B),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,2.2,1.2.1,1.3.1,1.3.2,2.2.2; | | [ams-nist-cis-internet-gateway-authorized-vpc-only](https://docs.aws.amazon.com/config/latest/developerguide/internet-gateway-authorized-vpc-only.html) | Internet Gateway | Periodic | Report | CIS: CIS.9,CIS.12; NIST-CSF: NA; HIPAA: NA; PCI: NA; | | [ams-nist-cis-kms-cmk-not-scheduled-for-deletion](https://docs.aws.amazon.com/config/latest/developerguide/kms-cmk-not-scheduled-for-deletion.html) | KMS | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: NA; PCI: 3.5,3.6; | | [ams-nist-lambda-concurrency-check](https://docs.aws.amazon.com/config/latest/developerguide/lambda-concurrency-check.html) | Lambda | Config Changes | Report | CIS: NA; NIST-CSF: NA; HIPAA: 164.312(b); PCI: NA; | | [ams-nist-lambda-dlq-check](https://docs.aws.amazon.com/config/latest/developerguide/lambda-dlq-check.html) | Lambda | Config Changes | Report | CIS: NA; NIST-CSF: NA; HIPAA: 164.312(b); PCI: NA; | | [ams-nist-cis-lambda-function-public-access-prohibited](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-public-access-prohibited.html) | Lambda | Config Changes | Report | CIS: CIS.12,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,2.2.2; | | [ams-nist-cis-lambda-inside-vpc](https://docs.aws.amazon.com/config/latest/developerguide/lambda-inside-vpc.html) | Lambda | Config Changes | Report | CIS: CIS.12,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,2.2.2; | | [ams-nist-cis-mfa-enabled-for-iam-console-access](https://docs.aws.amazon.com/config/latest/developerguide/mfa-enabled-for-iam-console-access.html) | IAM | Periodic | Report | CIS: CIS.16; NIST-CSF: PR.AC-7; HIPAA: 164.312(d); PCI: 2.2,8.3; | | [ams-nist-cis-multi-region-cloudtrail-enabled](https://docs.aws.amazon.com/config/latest/developerguide/multi-region-cloudtrail-enabled.html) | CloudTrail | Periodic | Report | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-5,PR.MA-2,PR.PT-1; HIPAA: 164.308(a)(3)(ii)(A),164.312(b); PCI: 2.2,10.1,10.2.1,10.2.2,10.2.3,10.2.4,10.2.5,10.2.6,10.2.7,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6; | | [ams-nist-rds-enhanced-monitoring-enabled](https://docs.aws.amazon.com/config/latest/developerguide/rds-enhanced-monitoring-enabled.html) | RDS | Config Changes | Report | CIS: NA; NIST-CSF: PR.PT-1; HIPAA: 164.312(b); PCI: NA; | | [ams-nist-cis-rds-instance-public-access-check](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-public-access-check.html) | RDS | Config Changes | Report | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-rds-multi-az-support](https://docs.aws.amazon.com/config/latest/developerguide/rds-multi-az-support.html) | RDS | Config Changes | Report | CIS: NA; NIST-CSF: ID.BE-5,PR.DS-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(C); PCI: NA; | | [ams-nist-cis-rds-snapshots-public-prohibited](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html) | RDS | Config Changes | Report | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-rds-storage-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html) | RDS | Config Changes | Report | CIS: CIS.13,CIS.5,CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-1,PR.PT-1; HIPAA: 164.312(a)(2)(iv),164.312(b),164.312(e)(2)(ii); PCI: 3.4,10.1,10.2.1,10.2.2,10.2.3,10.2.4,10.2.5,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6,8.2.1; | | [ams-nist-cis-redshift-cluster-configuration-check](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-configuration-check.html) | RedShift | Config Changes | Report | CIS: CIS.6,CIS.13,CIS.5; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-1,PR.PT-1; HIPAA: 164.312(a)(2)(iv),164.312(b),164.312(e)(2)(ii); PCI: 3.4,8.2.1,10.1,10.2.1,10.2.2,10.2.3,10.2.4,10.2.5,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6; | | [ams-nist-cis-redshift-cluster-public-access-check](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-public-access-check.html) | RedShift | Config Changes | Report | CIS: CIS.12,CIS.14,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-redshift-require-tls-ssl](https://docs.aws.amazon.com/config/latest/developerguide/redshift-require-tls-ssl.html) | RedShift | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-2; HIPAA: 164.312(a)(2)(iv),164.312(e)(1),164.312(e)(2)(i),164.312(e)(2)(ii); PCI: 2.3,4.1; | | [ams-nist-cis-root-account-hardware-mfa-enabled](https://docs.aws.amazon.com/config/latest/developerguide/root-account-hardware-mfa-enabled.html) | IAM | Periodic | Report | CIS: CIS.16,CIS.4; NIST-CSF: PR.AC-7; HIPAA: 164.312(d); PCI: 2.2,8.3; | | [ams-nist-cis-root-account-mfa-enabled](https://docs.aws.amazon.com/config/latest/developerguide/root-account-mfa-enabled.html) | IAM | Periodic | Report | CIS: CIS.16,CIS.4; NIST-CSF: PR.AC-7; HIPAA: 164.312(d); PCI: 2.2,8.3; | | [ams-nist-cis-s3-bucket-default-lock-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-default-lock-enabled.html) | S3 | Config Changes | Report | CIS: CIS.14,CIS.13; NIST-CSF: ID.BE-5,PR.PT-5,RC.RP-1; HIPAA: NA; PCI: NA; | | [ams-nist-cis-s3-bucket-logging-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-logging-enabled.html) | S3 | Config Changes | Report | CIS: CIS.6; NIST-CSF: DE.AE-1,DE.AE-3,PR.DS-5,PR.PT-1; HIPAA: 164.308(a)(3)(ii)(A),164.312(b); PCI: 2.2,10.1,10.2.1,10.2.2,10.2.3,10.2.4,10.2.5,10.2.7,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.3.6; | | [ams-nist-cis-s3-bucket-replication-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-replication-enabled.html) | S3 | Config Changes | Report | CIS: CIS.10; NIST-CSF: ID.BE-5,PR.DS-4,PR.IP-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(A),164.308(a)(7)(ii)(B); PCI: 2.2,10.5.3; | | [ams-nist-cis-s3-bucket-ssl-requests-only](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-ssl-requests-only.html) | S3 | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-2; HIPAA: 164.312(a)(2)(iv),164.312(c)(2),164.312(e)(1),164.312(e)(2)(i),164.312(e)(2)(ii); PCI: 2.2,4.1,8.2.1; | | [ams-nist-cis-s3-bucket-versioning-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-versioning-enabled.html) | S3 | Periodic | Report | CIS: CIS.10; NIST-CSF: ID.BE-5,PR.DS-4,PR.DS-6,PR.IP-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i),164.308(a)(7)(ii)(A),164.308(a)(7)(ii)(B),164.312(c)(1),164.312(c)(2); PCI: 10.5.3; | | [ams-nist-cis-sagemaker-endpoint-configuration-kms-key-configured](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-endpoint-configuration-kms-key-configured.html) | SageMaker | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-nist-cis-sagemaker-notebook-instance-kms-key-configured](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-endpoint-configuration-kms-key-configured.html) | SageMaker | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-nist-cis-sagemaker-notebook-no-direct-internet-access](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-no-direct-internet-access.html) | SageMaker | Periodic | Report | CIS: CIS.12,CIS.9; NIST-CSF: PR.AC-3,PR.AC-4,PR.AC-5,PR.DS-5,PR.PT-3,PR.PT-4; HIPAA: 164.308(a)(3)(i),164.308(a)(4)(ii)(A),164.308(a)(4)(ii)(C),164.312(a)(1),164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,1.3.4,1.3.6,2.2.2; | | [ams-nist-cis-secretsmanager-rotation-enabled-check](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-rotation-enabled-check.html) | Secrets Manager | Config Changes | Report | CIS: CIS.16; NIST-CSF: PR.AC-1; HIPAA: 164.308(a)(4)(ii)(B); PCI: NA; | | [ams-nist-cis-secretsmanager-scheduled-rotation-success-check](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-scheduled-rotation-success-check.html) | Secrets Manager | Config Changes | Report | CIS: CIS.16; NIST-CSF: PR.AC-1; HIPAA: 164.308(a)(4)(ii)(B); PCI: NA; | | [ams-nist-cis-sns-encrypted-kms](https://docs.aws.amazon.com/config/latest/developerguide/sns-encrypted-kms.html) | SNS | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 8.2.1; | | [ams-nist-cis-vpc-sg-open-only-to-authorized-ports](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html) | VPC | Config Changes | Report | CIS: CIS.11,CIS.12,CIS.9; NIST-CSF: DE.AE-1,PR.AC-3,PR.AC-5,PR.PT-4; HIPAA: 164.312(e)(1); PCI: 1.2,1.3,1.2.1,1.3.1,1.3.2,2.2.2; | | [ams-nist-vpc-vpn-2-tunnels-up](https://docs.aws.amazon.com/config/latest/developerguide/vpc-vpn-2-tunnels-up.html) | VPC | Config Changes | Report | CIS: NA; NIST-CSF: ID.BE-5,PR.DS-4,PR.PT-5,RC.RP-1; HIPAA: 164.308(a)(7)(i); PCI: NA; | | [ams-cis-ec2-ebs-encryption-by-default](https://docs.aws.amazon.com/config/latest/developerguide/ec2-ebs-encryption-by-default.html) | EC2 | Periodic | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 2.2,3.4,8.2.1; | | [ams-cis-rds-snapshot-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshot-encrypted.html) | RDS | Config Changes | Report | CIS: CIS.13,CIS.14; NIST-CSF: PR.DS-1; HIPAA: 164.312(a)(2)(iv),164.312(e)(2)(ii); PCI: 3.4,8.2.1; | | [ams-cis-redshift-cluster-maintenancesettings-check](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-maintenancesettings-check.html) | RedShift | Config Changes | Report | CIS: CIS.5; NIST-CSF: PR.DS-4,PR.IP-1,PR.IP-4; HIPAA: 164.308(a)(5)(ii)(A),164.308(a)(7)(ii)(A); PCI: 6.2; | ## Responses to violations in Accelerate Responses to violations All Config Rule violations appear in your Configuration Report. This is a universal response. Depending on the *Remediation Category* (severity) of the rule, AMS might take additional actions, summarized in the following table. For details on how to customize the *Action Code* for certain rules, see [Customized findings responses](custom-findings-responses.md). **Remediation Actions** | Action Code | AMS Actions | | --- |--- | | Report | [Add to Config Report](#acc-sec-compliance-response-universal) | | Incident | [Add to Config Report](#acc-sec-compliance-response-universal) [Automatic incident report in Accelerate](#acc-sec-compliance-response-incident) | | Remediate | [Add to Config Report](#acc-sec-compliance-response-universal) [Automatic incident report in Accelerate](#acc-sec-compliance-response-incident) [Automatic remediation in Accelerate](#acc-sec-compliance-response-autoremediate) | **Requesting Additional Help** **Note** AMS can remediate any violation for you, regardless of its remediation category. To request help, submit a Service Request, and indicate which resources you want AMS to remediate with a comment such as "As part of the AMS config rule remediation, please remediate non-complaint resources *RESOURCE\$1ARNS\$1OR\$1IDs*resource ARNs/IDs>, config rule *CONFIG\$1RULE\$1NAME*in the account" and add the required inputs to remediate the violation. AMS Accelerate has a library of AWS Systems Manager automation documents and runbooks to assist in remediating noncompliant resources. ### Add to Config Report AMS generates a Config Report that tracks the compliance status of all rules and resources in your account. You can request the report from your CSDM. You can also review compliance status from the AWS Config console, AWS CLI, or AWS Config API. Your Config Report includes: + The top, noncompliant resources in your environment, to discover potential threats and misconfigurations + Compliance of resources and config rules over time + Config rule descriptions, severity of rules, and recommended remediation steps to fix noncompliant resources When any resource goes into a noncompliant state, the resource status (and rule status) becomes **Noncompliant** in your Config Report. If the rule belongs to the **Config Report Only** remediation category, by default, AMS takes no further action. You can always create a Service Request to request additional help or remediation from AMS. For more details, see [AWS Config Reporting](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/on-request-reporting.html#acc-report-config-control-compliance). ### Automatic incident report in Accelerate Automatic incident report For moderately severe rule violations, AMS automatically creates an Incident Report to notify you that a resource has gone into a noncompliant state, and asks which actions you would like to be performed. You have the following options when responding to an incident: + Request that AMS remediate the noncompliant resources listed in the incident. Then, we attempt to remediate the noncompliant resource, and notify you once the underlying incident has been resolved. + You can resolve the noncompliant item manually in the console or through your automated deployment system (for example, CI/CD Pipeline template updates); then, you can resolve the incident. The noncompliant resource is re-evaluated as per the rule’s schedule and, if the resource is evaluated as noncompliant, a new incident report is created. + You can choose to not resolve the noncompliant resource and simply resolve the incident. If you update the configuration of the resource later, AWS Config will trigger a re-evaluation and you will again be alerted to evaluate the noncompliance of that resource. ### Automatic remediation in Accelerate Automatic remediation The most critical rules belong to the **Auto Remediate** category. Noncompliance with these rules may strongly impact the security and availability of your accounts. When a resource violates one of these rules: 1. AMS automatically notifies you with an Incident Report. 1. AMS starts an automated remediation using our automated SSM documents. 1. AMS updates the Incident Report with success or failure of the automated remediation. 1. If automated remediation failed, an AMS engineer investigates the issue. ## Creating rule exceptions in Accelerate Creating rule exceptions The AWS Config Rules resource exception feature allows you to suppress reporting of specific, noncompliant resources for a specific rules. **Note** The exempted resources still show up as **Noncompliant** in your AWS Config Service console. The exempted resources appear with a special flag in Config Reports (resource\$1exception:True). Your CSDMs can filter out those resources according to that column when generating reports. If you have resources that you know are not compliant, you can eliminate a specific resource for a specific config rule in their Config Reports. To do this: Submit a service request to Accelerate against your account, with a list of the config rules and resources that to be exempted from report. You must provide an explicit business justification (such as, no need to report that *resource\$1name\$11* and *resource\$1name\$12* are not backed up because we do not want them backed up). For help submitting an Accelerate service request, see [Creating a service request in Accelerate](creating-a-sr.md). Paste into the request the following inputs (for every resource add a separate block with all the required fields, as shown), and then submit: ``` [ { "resource_name": "resource_name_1", "config_rule_name": "config_rule_name_1", "business_justification": "REASON_TO_EXEMPT_RESOURCE", "resource_type": "resource_type" }, { "resource_name": "resource_name_2", "config_rule_name": "config_rule_name_2", "business_justification": "REASON_TO_EXEMPT_RESOURCE", "resource_type": "resource_type" } ] ``` ## Reduce AWS Config costs in Accelerate Reduce AWS Config costs You can reduce AWS Config costs by using the option to periodically record the `AWS::EC2::Instance` resource type. Periodic recording captures the latest configuration changes of your resources once every 24 hours, reducing the number of changes delivered. When enabled, AWS Config only records the latest configuration of a resource at the end of a 24-hour period. This allows you to tailor configuration data to specific operational planning, compliance, and audit uses cases that don’t require continuous monitoring. This change is recommended only if you have applications that depend on ephemeral architectures, meaning you constantly scale the number of instances up or down. To opt in to periodic recording for the `AWS::EC2::Instance` resource type, contact your AMS Delivery Team. # Customized findings responses Customized findings responses You can choose how you want AMS Accelerate to respond to some findings (non-compliant Config rules). You can configure AMS to respond to findings it by remediating the finding, asking for your approval to remediate, or just reporting to you in your next Monthly Business Review (MBR). You can change the default responses for AMS Accelerate Config rules. To see the rules, go to [Configuration Compliance > Table of rules](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sec-compliance.html) or download the rules table as a ZIP file [ams\$1config\$1rules.zip](samples/ams_config_rules.zip). Changing default responses helps you to increase the security and compliance state of your account by allowing more findings to be remediated. When you remediate more findings, you have fewer cases that need to wait for a manual review and approval. The extensive library of AMS remediation runbooks constantly fixes non-compliant resources and you are contacted only when required. Customized responses are used only with new resources or existing resources with new events. For example, a resource that became non-compliant after a change. This is because older resources tend to require a deeper inspection before remediation and it's easier to enforce the resource remediation as they are created or changed. To request remediation of the finding for any resource at any time, submit a service request. ## Requesting a change in the default responses Requesting a change in the default responses Cloud Architects (CAs) work with you during on-boarding to collect your preferences. CAs then setup the initial configuration on internal AMS systems. After onboarded, create a Service Request to request updates to your configurations. You can request configuration updates as many times as needed. Please note that Operations only updates configurations for the account in which the service request was created. If you need to update multiple accounts at the same time, contact your Cloud Architect. Your CA will ask you to cut a service request with your preferences for audit purposes. ## Changing default responses for your findings and accounts Changing default responses for your findings and accounts You always need a response preference for each account and finding. AMS provides a default response (see [Configuration Compliance](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sec-compliance.html)), so this configuration is optional. You can change the default responses for each finding to the following options: + Remediate: AMS manually or automatically remediates the finding. AMS reviews the remediation and lets you know if it fails. + Request approval: AMS creates an outbound case to notify you about the finding. Use this option when you want to to review the finding before approving its remediation or exempting it. AMS then executes the action you prefer. + No action (report only): AMS takes no action to remediate or escalate the finding. The findings might still appear on the console and reports presented during MBRs. **Note** You can't change the configuration of rules that must be remediated by AMS. For example, enabling Amazon GuardDuty and VPC Flow Logs. ## Changing default responses by resources Changing default responses by resources You can further configure the response to specific resources using tags. You can use your pre-existing tags or tag resources using Resource Tagger. For details, see [Accelerate Resource Tagger](acc-resource-tagger.md)). Configuration for resources with tags take precedence over the default action for the finding. When a resource has multiple tags with different associated configurations, AMS can't run customized remediations. Instead, AMS sends you an outbound Service Request to inform you of the situation. For example, for the [s3-bucket-server-side-encryption-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-server-side-encryption-enabled.html) finding you can: + Change the response to 'remediate' unencrypted S3 buckets with the tag key value pair "Regulated: True" + Change the response to 'no action' when unencrypted S3 buckets has the tags "Regulated: False", and + Change the default response of unencrypted S3 buckets to be 'ask for approval. This applies for all S3 buckets that don’t have the tags "Regulated: True" or "Regulated: False" You can also add the input required to run custom finding response. For example, for remediations that require an encryption key, you can provide your key IDs to AMS. You can change the input parameters of the remediation runbooks, but AMS doesn't support integration with custom runbooks. For a description of AMS remediation runbooks in the Config Report, see [AWS Config Control Compliance report](acc-report-config-control-compliance.md). # Incident response in Accelerate Incident response Upon receiving an alert, the AMS team uses automated and manual remediations to bring the resources back to a healthy state. If remediation fails, AMS starts the incident management process to collaborate with your team. You can change the baselines by updating the default configuration in a configuration file. ## Incident response and onboarding in AMS Accelerate Incident response and onboarding During onboarding, AMS Accelerate suppresses automatic incident creation for your existing noncompliant resources; instead, your Cloud Service Deliver Manager (CSDM) provides you with a report that contains all the noncompliance rules and resources for your review. After you have identified the rules that you want AMS to remediate, create a service request in the Support Center console indicating those rule and resources. The following Service Request template is an example of a customer request to AMS to manually remediate noncompliant resources. If AMS has additional questions, we work with you in the Service Request to gather the information required. ``` Hello, Please remediate the following resources for the Config Rule "ENCRYPTED_VOLUMES". Resource List: "Vol-12345678" "Vol-87654312" Thank you ``` After the onboarding process is completed, AMS Accelerate automatically creates an incident for each noncompliant resource for the rules marked as Automatic Incident. # Resilience in Accelerate Resilience The AWS global infrastructure is built around AWS Regions and availability zones. AWS Regions provide multiple physically separated and isolated availability zones, which are connected with low-latency, high-throughput, and highly redundant networking. With availability zones, you can design and operate applications and databases that automatically fail over between zones without interruption. availability zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and availability zones, see [AWS global infrastructure](https://aws.amazon.com/about-aws/global-infrastructure). For information about AMS Accelerate continuity management, see [Continuity management in AMS Accelerate](acc-backup.md). # Security control for end-of-support operating systems Operating systems that are outside of the general support period of the operating system manufacturer's "end-of-support" or EOS, and do not receive security updates, have an increased security risk. AWS offers some services to help with handling operation system end-of-support. For information about Windows end-of-support, see [ End-of-Support Migration Program for Windows Server](https://aws.amazon.com/emp-windows-server/). **Note** Additional information on this topic is available by accessing AWS Artifact reports. For more information, see [Downloading reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). To access AWS Artifact, you can contact your CSDM for instructions or go to [Getting Started with AWS Artifact](https://aws.amazon.com/artifact/getting-started). This information is not included in this user guide because it contains sensitive security content. # Security best practices in Accelerate Security best practices AMS Accelerate uses conformance packs, which provide a general-purpose compliance framework designed to enable you to create security, operational, or cost-optimization governance checks using managed or custom AWS Config Rules and AWS Config remediation actions. For information on how to best configure these conformance packs, see AWS Config's [Operational Best Practices for NIST CSF](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-nist-csf.html) and [Operational Best Practices for CIS Top 20](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-cis_top_20.html). # Change request security reviews The AWS Managed Services change request review process ensures that AMS performs a security review of the requested changes as they are implemented on your behalf in your account. [AMS Accelerate technical standards](acc-sec-technical-standards.md) define the minimum security criteria, configurations, and processes to establish the baseline security of your accounts. When AMS implements the requested changes, we follow these standards. AMS evaluates all change requests against the AMS technical standards. Any change that might lower your account's security posture by deviating from the technical standards goes through a security review process. During this process, relevant risk is highlighted by AMS and reviewed and approved by your authorised risk approver to balance security and business needs. # Customer Security Risk Management process The AMS Accelerate Customer Security Risk Management (CSRM) process helps to clearly identify and communicate risks to the right owners. This process minimizes the security risks in your environment and reduces ongoing operational overhead for identified risks. By default, when someone from your organization requests that AMS implement a change to your managed environment, AMS reviews the change to determine if the request falls outside of the technical standards, which might alter the security posture of your account. If there is a high or very high security risk, then your authorized security personnel accept or reject the change review. Requested changes are also evaluated for adverse effects on AMS's ability to operate the account. If the review finds possible adverse impacts, then additional reviews and approvals are required within AMS. ## Risk acceptance validity and review Risk acceptances are valid for one year from the date of approval. If a previously accepted risk scenario arises again after one year, the risk acceptance must be reviewed and re-approved before it can be applied. This annual review ensures that risk decisions remain aligned with current technical standards, regulatory requirements, and your organization's evolving risk profile. ## Opt-out You can opt-out from the approval based workflow in the CSRM process for high or very high risks. To change the CSRM option for specific accounts from **Standard CSRM** to **Notification Only**, work with your Cloud Service Delivery Managers to create a one-time risk acceptance. If you choose to proceed with the **Notification Only** option, then AMS implements the requested changes regardless of the risk category. AMS sends a risk notification to your authorized risk approvers instead of seeking approval prior to the change implementation. Speak with your Cloud Architects or Cloud Service Delivery Managers for more information about the AMS CSRM process, how to change the default CSRM option when onboarding new AMS accounts, or how to update existing accounts. **Note** AMS strongly recommends that you use the default option of **Standard CSRM** in all of your accounts. # AMS Accelerate technical standards The following are Accelerate technical standards categories: | ID | Category | | --- | --- | | AMS-STD-X002 | AWS Identity and Access Management | | AMS-STD-X003 | Network Security | | AMS-STD-X004 | Penetration Testing | | AMS-STD-X005 | Amazon GuardDuty | | AMS-STD-X007 | Logging | # Standard controls in AMS Accelerate The following are the standard controls in AMS: ## AMS-STD-X002 - AWS Identity and Access Management (IAM) | ID | Technical standard | | --- | --- | | 1.0 | Timeout Duration | | 1.1 | A federated user default timeout session is one hour and may be increased to up to four hours. | | 1.2 | RDP session timeout for Microsoft Windows Server is set to 15 minutes and can be extended based on use case. | | 2.0 | AWS Root Account Usage | | 2.1 | If there is a root account usage for any reason, Amazon GuardDuty must be configured to generate relevant findings. | | 2.2 | Access keys for root account must not be created. | | 3.0 | Users Creation and Modification | | 3.1 | IAM users/roles with programmatic access and with read only permissions can be created without any time-limited policy. However, the permission t o allow the reading of objects (for example, S3:GetObject) in all the Amazon Simple Storage Service buckets in the account are not permitted. | | 3.1.1 | IAM human users for console access and with read only permissions can be created with the time bound policy (up to 180 days) while the removal/renewal/extension of the time bound policy will result in the risk notification. However, the permission to allow the reading of objects (for example, S3:GetObject) in all the S3 buckets in the account are not permitted. | | 3.2 | IAM users and roles for console and programmatic access with any infrastructure-mutating permissions (write and permission management) in the customer account must not be created without risk acceptance. Exceptions exist for S3 object-level write permissions which are allowed without risk acceptance as long as the specific buckets are in the scope and tagging operations on non-AMS related tags. | | 3.3 | On Microsoft Windows Servers, only Microsoft group Managed Service Account (gMSA) must be created. | | 4.0 | Policies, Actions, and APIs | | 4.4 | A policy must not provide administrator access with a statement that is equivalent to "Effect": "Allow" with "Action": "\$1" over "Resource": "\$1" without risk acceptance. | | 4.6 | API calls against KMS key policies for AMS infrastructure keys in the customer IAM policies must not be permitted. | | 4.8 | Actions, which changes to the AMS infrastructure DNS records in Amazon Route 53 must not be permitted. | | 4.9 | IAM human users with console access created after following the due process, must not have any policies attached directly except trust policy, assume role, and time limited policy. | | 4.10 | Amazon EC2 instance profiles with read access to a specific secret or namespace in AWS Secrets Manager within the same account can be created. | | 4.12 | IAM policy must not include any action which includes action Allow logs:DeleteLogGroup and logs:DeleteLogStream on any AMS Amazon CloudWatch log group. | | 4.13 | Permissions to create multi-region keys must not be permitted. | | 4.14 | Access to S3 bucket ARN which are not yet created in the customer accounts can be provided by restricting the access to the buckets to the customer accounts through specifying the account number using service-specific S3 condition key s3:ResourceAccount. | | 4.15.1 | You can have view, create, list, and delete access to your S3 storage lens custom dashboard. | | 4.16 | SQL Workbench related full permissions can be granted to roles/users to work on Amazon Redshift databases. | | 4.17 | Any AWS CloudShell permissions can be granted to customer roles as an alternative of CLI. | | 4.18 | An IAM role with AWS service as a trusted principal also needs to be inline with the IAM technical standards. | | 4.19 | Service Linked Roles (SLRs) are not subject to AMS IAM technical standards, as they are built and maintained by IAM Service Team. | | 4.20 | IAM policy should not allow reading of objects (for example, S3:GetObject) in all the S3 buckets in the account. | | 4.21 | All the IAM permissions for resource type “savingsplan” can be granted to customers. | | 4.22 | AMS engineer is not permitted to copy or move customer data (files, S3 objects, databases etc) manually in any of the data storage services like Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, and so on, or in the OS file system. | | 6.0 | Cross Account Policies | | 6.1 | IAM roles trust policies between AMS accounts that belong to the same customer as per customer records, can be configured. | | 6.2 | IAM roles trust policies between AMS and non-AMS accounts must be configured only if the non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name). | | 6.3 | IAM roles trust policies between AMS accounts and third-party accounts must not be configured without risk acceptance. | | 6.4 | Cross-account policies to access any customer-managed CMKs between AMS accounts of the same customer can be configured. | | 6.5 | Cross-account policies to access any KMS key within a non-AMS account by an AMS account can be configured. | | 6.6 | Cross-account policies to access any KMS key within an AMS account by a third-party account must not be permitted without risk acceptance. | | 6.6.1 | Cross-account policies to access any KMS key within an AMS account by a non-AMS account can be configured only if the non-AMS account is owned by the same AMS customer. | | 6.7 | Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) between AMS accounts of the same customer can be configured. | | 6.8 | Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a non-AMS account from an AMS account with read-only access can be configured. | | 6.9 | Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) with write permissions f rom AMS to a non-AMS account (or a non-AMS to AMS account) must be configured only if the non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name). | | 6.10 | Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a third-party account from an AMS account with read only access can be configured. | | 6.11 | Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a third-party account from an AMS account with write access must not be configured without risk acceptance. | | 6.12 | Cross-account policies from third-party accounts to access an AMS customer S3 bucket or resources where data can be stored (such asAmazon RDS, Amazon DynamoDB, or Amazon Redshift) must not be configured without risk acceptance. | | 7.0 | User Groups | | 7.1 | IAM groups with readonly and non mutative permissions are permitted. | | 8.0 | Resource-based policies | | 8.4 | AMS infrastructure resources should be protected from management by unauthorized identities by the attachment of resource based policies. | | 8.2 | Customer resources should be configured with least-privilege resource-based policies, unless the customer explicitly specifies a different policy. | ## AMS-STD-X003 - Network Security The following is the standard control for X003 - Network Security: | ID | Technical standard | | --- | --- | | | Networking | | 1.0 | Reserved for future control | | 2.0 | Elastic IP on EC2 instances is permitted | | 3.0 | AMS control plane and by extension in data plane TLS 1.2\$1 must be used. | | 5.0 | A security group must not have source as 0.0.0.0/0 in the inbound rule if it is not attached to a load balancer as per 9.0 | | 6.0 | S3 bucket or objects must not be made public without risk acceptance. | | 7.0 | Servers management access on ports SSH/22 or SSH/2222 (Not SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 or 1604, LDAP/389 or 636 and RPC/135, NETBIOS/137-139 must not be permitted from outside the VPC through security groups. | | 8.0 | Database management access on ports (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) or on custom port must not be permitted from public IPs not routed to VPC over DX, VPC-peer, or VPN via security group. | | 8.1 | Any resource where customer data can be stored should not be exposed to public internet directly. | | 9.0 | Direct applications access over port HTTP/80, HTTPS/8443 and HTTPS/443 from the Internet is permitted only to load balancers, but not to any compute resources directly e.g. EC2 instances, ECS/EKS/Fargate containers, etc. | | 10.0 | Applications access over port HTTP/80 and HTTPS/443 from customer private IP range can be permitted. | | 11.0 | Any changes to the security groups which controls the access to the AMS infrastructure must not be permitted without risk acceptance. | | 12.0 | AMS Security will refer the standards every time a security group is requested to be attached to an instance. | | 14.0 | Cross account association of private hosted zones with VPCs from AMS to non-AMS account (or non-AMS to AMS account) must be configured only if non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organization account or by matching the email domain with the customer's company name) using internal tools. | | 15.0 | VPC peering connections between accounts that belong to the same customer can be permitted. | | 16.0 | AMS base AMIs can be shared with non-AMS account as long as both accounts are owned by the same customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name) using internal tools. | | 17.0 | FTP port 21 must not be configured in any of the security group without a risk acceptance. | | 18.0 | Cross account network connectivity via transit gateway is permitted as long as all the accounts are owned by the customer. | | 19.0 | Making a private subnet to public is not permitted | | 20.0 | VPC peering connections with a third party accounts (not owned by the customer) must not be permitted. | | 21.0 | Transit Gateway attachment with a third party account (not owned by the customer) must not be permitted. | | 22.0 | Any network traffic required for AMS to provide the services to customers must not be blocked at the customer network egress point. | | 23.0 | Inbound ICMP request to Amazon EC2 from the customer infra will require risk notification. | | 24.0 | Inbound request from public IPs routed to Amazon VPC over DX, VPC-peer, or VPN via security group is allowed. | | 25.0 | Inbound request from public IPs not routed to Amazon VPC over DX, VPC-peer, or VPN via security group would require a risk acceptance. | | 26.0 | Outbound ICMP request from Amazon EC2 to any destination is allowed. | | 27.0 | Security group sharing | | 27.1 | If a security group meets this security standard, then it can be shared between VPCs in the same account and between accounts in the same organization. | | 27.2 | If a security group does not meet this standard and a risk acceptance was previously required for this security group, then the use of the security group sharing feature between VPCs in the same account, or between accounts in the same organization, is not permitted without risk acceptance for that new that VPC or account. | ## AMS-STD-X004 - Penetration Testing The following is the standard control for X004 - Penetration Testing 1. AMS doesn't support pentest infrastructure. It's the customer's responsibility. For example, Kali is not a AMS supported distribution of Linux. 1. Customers need to adhere to [Penetration Testing](https://aws.amazon.com/security/penetration-testing/). 1. AMS to be pre-notified 24hrs in advance in the case when the customer would like to perform infrastructure penetration testing within accounts. 1. AMS will provision customer pentesting infrastructure per customer requirements explicitly stated in the change request or service request by the customer. 1. Identity management for customer pentesting infrastructure is the responsibility of the customer. ## AMS-STD-X005 - GuardDuty The following is the standard control for X005 - GuardDuty 1. GuardDuty must be enabled in all the customer accounts at all times. 1. GuardDuty alerts must be stored within the same account or any other managed account under the same organization. 1. Trusted IP list feature of GuardDuty must not be used. Instead auto-archiving can be used as an alternative, which is useful for audit purposes. ## AMS-STD-X007 - Logging The following is the standard control for X007 - Logging | ID | Technical standard | | --- | --- | | 1.0 | Log types | | 1.1 | OS Logs: All the hosts must log at minimum host authentication events, access events for all uses of elevated privileges and access events for all changes to access and privilege configuration including success and failure both. | | 1.2 | AWS CloudTrail: CloudTrail management event logging must be enabled and configured to deliver logs to an S3 bucket. | | 1.3 | VPC Flow Logs: All the network traffic logs must be logged via VPC Flow Logs. | | 1.4 | Amazon S3 Server Access Logging: AMS mandated S3 buckets that store logs must have server access logging enabled. | | 1.5 | AWS Config Snapshots: AWS Config must record configuration changes for all supported resources in all the regions and deliver the configuration snapshot files to S3 buckets at least once per day. | | 1.7 | Application Logs: Customers are empowered to enable logging in their applications and store in CloudWatch Logs log group or an S3 bucket. | | 1.8 | S3 Object level logging: Customers are empowered to enable object level logging in their S3 buckets. | | 1.9 | Service Logging: Customers are empowered to enable and forward logs for SSPS services like any core services. | | 1.10 | Elastic Load Balancing(Classic/Application Load Balancer/Network Load Balancer) Logs: Access and error log entries must be stored in the AMS 2.0-managed S3 buckets. | | 2.0 | Access control | | 2.3 | AMS-mandated S3 buckets that store logs must not allow third party accounts users as principles in the bucket policies. | | 2.4 | Logs from CloudWatch Logs log groups must not be deleted without explicit approval from the customer authorised security contact. | | 3.0 | Logs retention | | 3.1 | AMS-mandated CloudWatch Logs log groups must have a minimum retention period of 90 days on the logs. | | 3.2 | AMS-mandated S3 buckets that stores the logs must have a minimum retention period of 18 months on the logs. | | 3.3 | AWS Backup snapshots should be available with minimum retention of 31 days on the supported resources. | | 4.0 | Encryption | | 4.1 | Encryption must be enabled in all S3 buckets required by AMS Teams that stores logs. | | 4.2 | Any log forwarding from customer accounts to any other account must be encrypted. | | 5.0 | Integrity | | 5.1 | The log file integrity mechanism must be enabled. That means configure “Log file validation” in the AWS CloudTrail trails required by AMS teams. | | 6.0 | Logs forwarding | | 6.1 | Any log can be forwarded from one AMS account to another AMS account of the same customer. | | 6.2 | Any log can be forwarded from AMS to non-AMS account only if non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name and PAYER linked account) using internal tools. | # Changes that introduce high or very high security risks in your environment The following changes introduce high or very high security risk in your environment: **AWS Identity and Access Management** + High\$1Risk-IAM-001: Create access keys for root account + High\$1Risk-IAM-002: SCP policy modification to allow additional access + High\$1Risk-IAM-003: SCP policy modification that could break AMS infrastructure + High\$1Risk-IAM-004: Creation of a role/user with infrastructure mutating permissions (write, permission management or tagging) in customer account + High\$1Risk-IAM-005: IAM roles trust policies between AMS accounts and third-party accounts (not owned by the customer) + High\$1Risk-IAM-006: Cross-account policies to access any KMS key from an AMS account by a third-party account) + High\$1Risk-IAM-007: Cross-account policies from third-party accounts to access an AMS customer S3 bucket or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) + High\$1Risk-IAM-008: Assign the IAM permissions with any infrastructure mutating permission in customer account + High\$1Risk-IAM-009: Allow listing and reading on all the S3 buckets in the account **Network security** + High\$1Risk-NET-001: Open OS management ports SSH/22 or SSH/2222 (Not SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 or 1604, LDAP/389 or 636 and NETBIOS/137-139 from the internet + High\$1Risk-NET-002: Open database management ports MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433 or any management customer port from the internet + High\$1Risk-NET-003: Open application ports HTTP/80, HTTPS/8443 and HTTPS/443 on any compute resources directly. For example, EC2 instances, ECS/EKS/Fargate containers, and so on from the internet + High\$1Risk-NET-004: Any changes to the security groups which controls the access to the AMS infrastructure + High\$1Risk-NET-006: VPC peering with the third-party account (not owned by the customer) + High\$1Risk-NET-007: Adding customer firewall as egress point for all the AMS traffic + High\$1Risk-NET-008: Transit Gateway attachment with the third-party account is not allowed + High\$1Risk-S3-001: Provision or enable public access in the S3 bucket **Logging** + High\$1Risk-LOG-001: Disable CloudTrail. + High\$1Risk-LOG-002: Disable VPC Flow Logs. + High\$1Risk-LOG-003: Log forwarding via any method (S3 event notification, SIEM agent pull, SIEM agent push etc) from an AMS managed account to third party account (not owned by customer) + High\$1Risk-LOG-004: Use non-AMS trail for CloudTrail **Miscellaneous** + High\$1Risk-ENC-001: Disable encryption in any resource if it is enabled # Security FAQ Security FAQ AMS provides 24/7/365 follow-the-sun support through global operation centers. Dedicated AMS operations engineers actively monitor dashboards and incident queues. Usually, AMS manages your accounts through automation. In rare circumstances that require specific troubleshooting or deployment expertise, an AMS operations engineer might access your AWS accounts. The following are common questions about the security best practices, controls, access models, and audit mechanisms that AMS Accelerate uses when an AMS operations engineer or automation accesses your accounts. ## When do AMS operations engineers access my environments? AMS operations engineers don't have persistent access to your accounts or instances. Access to customer accounts is granted to AMS operators only for justifiable business use cases, such as alerts, incidents, change requests, and so on. Access is documented in AWS CloudTrail logs. For access justification, triggers, and trigger initiators, see [AMS customer account access triggers](access-justification.md#access-mgmt-triggers). ## What roles do AMS operations engineers assume when they access my accounts? In the rare cases (\$15%) that require human intervention in your environment, AMS operations engineers log in to your account with a default, read only access role. The default role doesn't have access to any content that's commonly stored in data stores, such as Amazon Simple Storage Service, Amazon Relational Database Service, Amazon DynamoDB, Amazon Redshift, and Amazon ElastiCache. For a list of roles that AMS operations engineers and systems require to provide services in your account, see [AMS customer account access IAM roles](access-justification.md#access-mgmt-iam-roles). ## How does an AMS operations engineer access my account? To access customer accounts, AMS operations engineers use an AWS internal AMS access service. This internal service is available only through a secure, private channel so that access to your accounts is secure and audited. 1. AMS operations engineers use the internal AMS access service authentication along with a two-factor authentication. And, operations engineer must provide a business justification (incident ticket or service request ID) that outlines the need to access your AWS account. 1. Based on the operation engineer’s authorization, the AMS access service provides the engineer with the appropriate role (Read-only/Operator/Admin) and login URL to your AWS console. Access to your account is short-lived and timebound. 1. To access Amazon EC2 instances, AMS operations engineers use the same internal AMS access service as the broker. After access is granted, AMS operations engineers use AWS Systems Manager Session Manager to access your instances with short-lived session credentials. To provide RDP access for Windows instances, the operations engineer uses Amazon EC2 Systems Manager to create a local user on the instance and establish port forwarding to the instance. The operations engineer uses local user credentials for RDP access to the instance. The local user credentials are removed at the end of the session. The following diagram outlines the process used by AMS operations engineers to access your account: ![\[AMS Accelerate console access method.\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/images/acc-op-console-access-method2.png) ## How do I track changes made by AMS in my AMS managed AWS accounts? **Account access** To help you track changes made by automation or by the AMS Accelerate operations team, AMS provides the **Change record** SQL interface in the Amazon Athena console and AMS Accelerate logs. These resources provide the following information: + Who accessed your account. + When the account was accessed. + What privileges were used to access your account. + What changes were made by AMS Accelerate in your account. + Why the changes were made in your account. **Resource configuration** View CloudTrail logs to track the configurations in your AWS resources for the past 90 days. If your configuration is older than 90 days, then access the logs in Amazon S3. **Instance logs** The Amazon CloudWatch Agent collects operating system logs. View the CloudWatch logs to see the login and other action logs that your operating system supports. For more information, see [Tracking changes in your AMS Accelerate accounts](acc-change-record.md). ## What are the process controls for AMS operations engineer access to my account? Prior to joining AMS, operations engineers go through a criminal background check. Because AMS engineers manage customer infrastructure, they also have a mandatory annual background check. If an engineer fails the background check, then access is revoked. All AMS operations engineers must complete mandatory security training, such as infrastructure security, data security, and incident response before they are granted access to resources. ## How is privileged access managed? A subset of users must complete additional training and maintain privileged access rights for elevated access. Access and usage is inspected and audited. AMS limits privileged access to exceptional circumstances or when least privilege access can't meet your request. Privileged access is also time bound. ## Do AMS operations engineers use MFA? Yes. All users must use MFA and Proof of Presence to provide services to you. ## What happens to their access when an AMS employee leaves the organization or changes job roles? Access to customer accounts and resources is provisioned through internal group membership. Membership is based on strict criteria including the specific job role, reporting manager, and employment status in AMS. If an operations engineer’s job family changes or their user ID is disabled, then access is revoked. ## What access controls govern AMS operation engineer access to my accounts? There are multiple layers of technical controls to enforce the “need to know” and “least privilege” principles for access to your environment. The following is a list of the access controls: + All operations engineers must be part of a specific internal AWS group to access customer accounts and resources. Group membership is strictly based on a need to know basis and automated with predefined criteria. + AMS practices “non-persistence” access to your environment. This means that access to your AWS accounts by AMS operations is "just-in-time" with short-lived credentials. Access to your accounts is provided only after an internal business case justification (service request, incident, change management request, and so on) is submitted and reviewed. + AMS follows the least privilege principle. So, authorized operations engineers assume Read-Only access by default. Write access is only used by engineers when changes to your environment are required due to an incident or a change request. + AMS uses standard, easily identifiable AWS Identity and Access Management roles that use the “ams” prefix to monitor and manage your accounts. All access is logged in AWS CloudTrail for you to audit. + AMS uses automated backend tooling to detect unauthorized changes to your account during the customer information validation phase of change executions. ## How does AMS monitor root user access? Root access always triggers the incident response process. AMS uses Amazon GuardDuty detection to monitor root user activity. If GuardDuty generates an alert, then AMS creates an event for further investigation. AMS notifies you if unexpected root account activity is detected, and the AMS Security team initiates an investigation. ## How does AMS respond to security incidents? AMS investigates security events that are generated from detection services such as Amazon GuardDuty, Amazon Macie, and from customer-reported security issues. AMS collaborates with your security response team to run the Security Incident Response (SIR) process. The AMS SIR process is based on the [NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide](https://csrc.nist.gov/pubs/sp/800/61/r2/final) framework and provides 24/7/365 follow-the-sun security response. AMS works with you to quickly analyze and contain security incidents. ## What industry standard certifications and frameworks does AMS adhere to? Like other AWS services, AWS Managed Services is certified for OSPAR, HIPAA, HITRUST, GDPR, SOC\$1, ISO\$1, FedRAMP (Medium/High), IRAP, and PCI. For more information about the customer compliance certifications, regulations, and frameworks that AWS aligns with, see [AWS Compliance](https://aws.amazon.com/compliance/). **Security guardrails** AWS Managed Services uses multiple controls to protect your information assets and to help you keep your AWS infrastructure secure. AMS Accelerate maintains a library of AWS Config rules and remediation actions to help you make sure that your accounts comply with industry standards for security and operational integrity. AWS Config rules continuously track configuration changes on your recorded resources. If a change violates a rule's conditions, then AMS reports its findings to you. You can remediate violations automatically or by request, according to the severity of the violation. AMS uses AWS Config rules to help meet the requirements of the following standards: + Center for Internet Security (CIS) + National Institute of Standards and Technology (NIST) Cloud Security Framework (CSF) + Health Insurance Portability and Accountability Act (HIPAA) + Payment Card Industry (PCI) Data Security Standard (DSS) For more information, see [Security management in AMS Accelerate](acc-sec.md) ## How can I get access to the latest reports on security certification, frameworks, and compliance on AWS? You can find current security and compliance reports for AWS services using the following methods: + You can use [AWS Artifact](https://aws.amazon.com/artifact/) to download the latest report on an AWS service's security, availability, and confidentiality. + For a list of most AWS services, including AWS Managed Services, that are compliant with global compliance frameworks, see [https://aws.amazon.com/compliance/services-in-scope/](https://aws.amazon.com/compliance/services-in-scope/). For example, select **PCI** and search for **AWS Managed Services**. You can search for "AMS" to find AMS specific security artifacts from an AMS managed AWS account. AWS Managed Services is in scope for [SOC 3](https://d1.awsstatic.com/whitepapers/compliance/AWS_SOC3.pdf). + The AWS SOC 2 (System and Organizations Controls) report is published to the AWS Artifact repository. This report evaluates the AWS controls that meet the criteria for security, availability, and confidentiality in the American Institute of Certified Public Accountants (AICPA) TSP section 100, Trust Services Criteria. ## Does AMS share reference architecture diagrams of different aspects of AMS features? To view AMS reference architecture, download the [AWS Managed Services for Proactive Monitoring PDF](samples/AWS-managed-services-for-operational-excellence-ra.zip). ## How does AMS track who access my accounts and what the business need is for access? To support service continuity and the security of your accounts, AMS accesses your account or instances only in response to proactive health or maintenance, health or security events, planned activity, or customer requests. Access to your accounts is authorized through AMS processes as outlined in the [access model for AMS Accelerate](acc-access-operator.md). These authorization flows contain guardrails to prevent inadvertent or inappropriate access. As part of the access flow, AMS supplies the authorization system with a business need. This business need might be a work item associated with your account, such as a case that you opened with AMS. Or, the business need might be an authorized workflow, such as the Patching solution. All access requires a justification that is validated, verified, and authorized in real time by internal AMS systems based on business rules to align access requests with a business need. AMS operations engineers aren't given a path to access your accounts without valid business needs. All account access and the associated business need are emitted to AWS CloudTrail entries inside your AWS accounts. This provides full transparency and the opportunity for you to perform your own audit and inspection. In addition to your inspection, AMS has automated inspections, and performs manual inspection as required, of access requests and performs audits of tooling and human access to review anomalous access. ## Do AMS engineers have access to my data stored in an AWS data storage services, such as Amazon S3, Amazon RDS, DynamoDB, and Amazon Redshift? AMS engineers don't have access to customer content stored in AWS services that are commonly used for data storage. Access to AWS APIs used to read, write, modify, or delete data in these services is restricted by an explicit IAM deny policy associated with IAM roles used for AMS engineer access. In addition, internal AMS guardrails and automations prevent AMS operations engineers from removing or modifying the deny conditions. ## Do AMS engineers have access to customer data that's stored in Amazon EBS, Amazon EFS and Amazon FSx? AMS engineers can log into Amazon EC2 instances as an administrator. Administrator access is required for remediation in certain scenarios that include, but are not limited to, operating system (OS) issues and patch failures. AMS engineers typically access the system volume to remediate detected issues. However, access for AMS engineers isn't limited or restricted to the system volume. ## How is access restricted or controlled for automation roles that have high privileges to my environments? The `ams-access-admin` role is used exclusively by AMS automation. These automations deploy, manage, and maintain the required resources used by AMS to deploy into your environments for telemetry, health, and security data collection to perform operational functions. AMS engineers can't assume automation roles and are restricted by role mapping in internal systems. At runtime, AMS dynamically applies a scoped down least privilege session policy to every automation. This session policy limits the capability and permissions of the automation. ## How does AMS implement the principle of least privilege as advocated in the AWS Well-Architected Framework for automation roles? At runtime, AMS applies a scoped down, least privilege session policy to every automation. This scoped down session policy limits the capability and permissions of the automation. Session policies that have permissions to create IAM resources also have a requirement to attach a permission boundary. This permission boundary reduces privilege escalation risk. Every team onboards a session policy that's used only by that team. ## What logging and monitoring systems are used to detect unauthorized access attempts or suspicious activities involving automation roles? AWS maintains centralized repositories that provide core log archival functionality for internal use by AWS service teams. These logs are stored in Amazon S3 for high scalability, durability, and availability. AWS service teams can then collect, archive, and view service logs in a central log service. Production hosts at AWS are deployed using master baseline images. The baseline images are equipped with a standard set of configurations and functions that include logging and monitoring for security purposes. These logs are stored and accessible by AWS security teams for root cause analysis in the event of a suspected security incident. Logs for a given host are available to the team that owns that host. Teams can search their logs for operational and security analysis. ## How are security incidents or breaches concerning the automation infrastructure handled, and what protocols help with swift response and mitigation? AWS contingency plans and incident response playbooks have defined and tested tools and processes to detect, mitigate, investigate, and assess security incidents. These plans and playbooks include guidelines for responding to potential data breaches in accordance with contractual and regulatory requirements. ## Are regular security assessments, vulnerability scans, and penetration tests conducted on the automation infrastructure? AWS Security performs regular vulnerability scans on the host operating systems, web applications, and databases in the AWS environment using a variety of tools. AWS Security teams also subscribe to news feeds for applicable vendor flaws and proactively monitor vendors’ websites and other relevant outlets for new patches. ## How is access to the automation infrastructure restricted to authorized personnel only? Access to AWS systems are allocated based on least privilege and approved by an authorized individual. Duties and areas of responsibility (for example, access request and approval, change management request and approval, change development, testing and deployment, and so on) are segregated across different individuals to reduce unauthorized or unintentional modification or misuse of AWS systems. Group or shared accounts aren't permitted within the system boundary. ## What measures are implemented to uphold security standards and prevent unauthorized access or data breaches in the automation pipeline? Access to resources, including services, hosts, network devices, and Windows and UNIX groups, is approved in the AWS proprietary permission management system by the appropriate owner or manager. The permissions management tool log captures requests for access changes. Job function changes automatically revoke the employee's access to resources. Continued access for that employee must be requested and approved. AWS requires two-factor authentication over an approved cryptographic channel for authentication to the internal AWS network from remote locations. Firewall devices restrict access to the computing environment, enforce computing clusters' boundaries, and restrict access to production networks. Processes are implemented to protect audit information and audit tools from unauthorized access, modification, and deletion. Audit records contain a set of data elements in order to support necessary analysis requirements. In addition, audit records are available to authorized users for inspection or analysis on demand, and in response to security-related or business-impacting events. User access rights to AWS systems (for example, network, applications, tools, etc.) is revoked within 24 hours of termination or deactivation. Inactive user accounts are disabled and/or removed at least every 90 days. ## Is anomaly detection or monitoring turned on for access or audit logging to detect privilege escalation or access misuse to proactively alert the AMS team? Production hosts at AWS are equipped with logging for security purposes. This service logs human actions on hosts, including log ons, failed log on attempts, and log offs. These logs are stored and accessible by AWS security teams for root cause analysis in the event of a suspected security incident. Logs for a given host are also available to the team that owns that host. A front end log analysis tool is available to service teams to search their logs for operational and security analysis. Processes are implemented to help protect logs and audit tools from unauthorized access, modification, and deletion. The AWS Security team performs log analysis to identify events based on defined risk management parameters. ## What types of customer data is extracted from AMS managed accounts, and how is this utilized and stored? AMS does not access or use your content for any purpose. AMS defines customer content as software (including machine images), data, text, audio, video, or images that a customer or any end user transfers to AWS for processing, storage, or hosting by AWS services in connection with a customer's account, and any computational results that a customer or their end user derives from the foregoing through their use of AWS services.