SEC10-BP05 Pre-provision access
Verify that incident responders have the correct access pre-provisioned in AWS to reduce the time needed for investigation through to recovery.
Common anti-patterns:
-
Using the root account for incident response.
-
Altering existing accounts.
-
Manipulating IAM permissions directly when providing just-in-time privilege elevation.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
AWS recommends reducing or eliminating reliance on long-lived credentials wherever
possible, in favor of temporary credentials and just-in-time privilege escalation
mechanisms. Long-lived credentials are prone to security risk and increase operational
overhead. For most management tasks, as well as incident response tasks, we recommend you implement identity federation
We recommend the use of temporary privilege escalation in the majority of incident response scenarios. The correct way to do this is to use the AWS Security Token Service and session policies to scope access.
There are scenarios where federated identities are unavailable, such as:
-
Outage related to a compromised identity provider (IdP).
-
Misconfiguration or human error causing broken federated access management system.
-
Malicious activity such as a distributed denial of service (DDoS) event or rendering unavailability of the system.
In the preceding cases, there should be emergency break glass access configured to allow investigation and timely remediation of incidents. We recommend that you use a user, group, or role with appropriate permissions to perform tasks and access AWS resources. Use the root user only for tasks that require root user credentials. To verify that incident responders have the correct level of access to AWS and other relevant systems, we recommend the pre-provisioning of dedicated accounts. The accounts require privileged access, and must be tightly controlled and monitored. The accounts must be built with the fewest privileges required to perform the necessary tasks, and the level of access should be based on the playbooks created as part of the incident management plan.
Use purpose-built and dedicated users and roles as a best practice. Temporarily escalating user or role access through the addition of IAM policies both makes it unclear what access users had during the incident, and risks the escalated privileges not being revoked.
It is important to remove as many dependencies as possible to verify that access can be gained under the widest possible number of failure scenarios. To support this, create a playbook to verify that incident response users are created as users in a dedicated security account, and not managed through any existing Federation or single sign-on (SSO) solution. Each individual responder must have their own named account. The account configuration must enforce strong password policy and multi-factor authentication (MFA). If the incident response playbooks only require access to the AWS Management Console, the user should not have access keys configured and should be explicitly disallowed from creating access keys. This can be configured with IAM policies or service control policies (SCPs) as mentioned in the AWS Security Best Practices for AWS Organizations SCPs. The users should have no privileges other than the ability to assume incident response roles in other accounts.
During an incident it might be necessary to grant access to other internal or external individuals to support investigation, remediation, or recovery activities. In this case, use the playbook mechanism mentioned previously, and there must be a process to verify that any additional access is revoked immediately after the incident is complete.
To verify that the use of incident response roles can be properly monitored and audited, it is essential that the IAM accounts created for this purpose are not shared between individuals, and that the AWS account root user is not used unless required for a specific task. If the root user is required (for example, IAM access to a specific account is unavailable), use a separate process with a playbook available to verify availability of the root user sign-in credentials and MFA token.
To configure the IAM policies for the incident response roles, consider using IAM Access Analyzer to generate policies based on AWS CloudTrail logs. To do this, grant administrator access to the incident response role on a non-production account and run through your playbooks. Once complete, a policy can be created that allows only the actions taken. This policy can then be applied to all the incident response roles across all accounts. You might wish to create a separate IAM policy for each playbook to allow easier management and auditing. Example playbooks could include response plans for ransomware, data breaches, loss of production access, and other scenarios.
Use the incident response accounts to assume dedicated incident response IAM roles in
other AWS accounts. These roles must be configured to only be assumable by users in the
security account, and the trust relationship must require that the calling principal has
authenticated using MFA. The roles must use tightly-scoped IAM policies to control access.
Ensure that all AssumeRole requests for these roles are logged in CloudTrail and alerted
on, and that any actions taken using these roles are logged.
It is strongly recommended that both the IAM accounts and the IAM roles are
clearly named to allow them to be easily found in CloudTrail logs. An example of this would be to
name the IAM accounts <USER_ID>-BREAK-GLASSBREAK-GLASS-ROLE.
CloudTrail is used to log API activity in your AWS accounts and should be used to configure
alerts on usage of the incident response rolesAssumeRole events related to the incident response IAM role:
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
As the incident response roles are likely to have a high level of access, it is important that these alerts go to a wide group and are acted upon promptly.
During an incident, it is possible that a responder might require access to systems which are not directly secured by IAM. These could include Amazon Elastic Compute Cloud instances, Amazon Relational Database Service databases, or software-as-a-service (SaaS) platforms. It is strongly recommended that rather than using native protocols such as SSH or RDP, AWS Systems Manager Session Manager is used for all administrative access to Amazon EC2 instances. This access can be controlled using IAM, which is secure and audited. It might also be possible to automate parts of your playbooks using AWS Systems Manager Run Command documents, which can reduce user error and improve time to recovery. For access to databases and third-party tools, we recommend storing access credentials in AWS Secrets Manager and granting access to the incident responder roles.
Finally, the management of the incident response IAM accounts should be added to your Joiners, Movers, and Leavers processes and reviewed and tested periodically to verify that only the intended access is allowed.
Resources
Related documents:
Related videos:
Related examples:
