Standard controls in AMS Accelerate
The following are the standard controls in AMS:
| 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 to 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, permission management, or tagging) in the customer account must not be created without risk acceptance. However, S3 object-level write permissions are allowed without risk acceptance as long as the specific buckets are in the scope. |
| 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": "*" over "Resource": "*" 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 from 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. |
| 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. |
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+ 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. |
The following is the standard control for X004 - Penetration Testing
AMS doesn't support pentest infrastructure. It's the customer's responsibility. For example, Kali is not a AMS supported distribution of Linux.
Customers need to adhere to Penetration Testing
. AMS to be pre-notified 24hrs in advance in the case when the customer would like to perform infrastructure penetration testing within accounts.
AMS will provision customer pentesting infrastructure per customer requirements explicitly stated in the change request or service request by the customer.
Identity management for customer pentesting infrastructure is the responsibility of the customer.
The following is the standard control for X005 - GuardDuty
GuardDuty must be enabled in all the customer accounts at all times.
GuardDuty alerts must be stored within the same account or any other managed account under the same organization.
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.
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. |
