SEC10-BP05: Pre-provision access

Overview

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

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 alongside temporary escalation for administrative access. In this model, a user requests elevation to a higher level of privilege (such as an incident response role) and, provided the user is eligible for elevation, a request is sent to an approver. If the request is approved, the user receives a set of temporary AWS credentials which can be used to complete their tasks. After these credentials expire, the user must submit a new elevation request.

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.

Emergency Break Glass 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.

Pre-provisioned Dedicated Accounts

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.

Key Implementation Principles

Purpose-built and dedicated users and roles: Use dedicated accounts rather than modifying existing ones
Minimize dependencies: Remove as many dependencies as possible to ensure access under failure scenarios
Individual accountability: Each responder must have their own named account
Strong authentication: Enforce strong password policy and multi-factor authentication (MFA)
Principle of least privilege: Grant only the minimum permissions required
Comprehensive monitoring: Log and alert on all incident response role usage

Access Management Best Practices

Create incident response users in a dedicated security account
Do not manage through existing Federation or SSO solutions for break glass scenarios
Configure users with no privileges other than the ability to assume incident response roles
Use IAM Access Analyzer to generate policies based on CloudTrail logs
Implement separate IAM policies for each playbook scenario
Use Systems Manager Session Manager for EC2 access
Store credentials in AWS Secrets Manager for database and third-party access
Implementation Examples

Example 1: Comprehensive Break Glass Access Management System

Example 2: Just-in-Time Access with Session Policies

Resources

AWS Services for Access Management

AWS Identity and Access Management (IAM) - For user and role management
AWS Security Token Service (STS) - For temporary credentials
AWS Systems Manager Session Manager - For secure instance access
AWS Secrets Manager - For credential storage
AWS CloudTrail - For access logging and monitoring
Amazon CloudWatch - For alerting and monitoring
AWS Organizations - For multi-account management
AWS IAM Access Analyzer - For policy analysis and generation

Implementation Best Practices

Break Glass Account Setup:

Create dedicated security account for break glass users
Use descriptive naming convention (e.g., username-BREAK-GLASS)
Enforce strong password policies and MFA requirements
Disable access key creation for console-only users
Implement regular account review and cleanup processes

Role Design Principles:

Use least privilege principle for all roles
Implement permissions boundaries to limit maximum permissions
Require MFA for all role assumptions
Set appropriate session duration limits
Use separate roles for different incident types

Session Policy Implementation:

Scope permissions to specific resources when possible
Include time-based conditions for session validity
Implement explicit deny statements for high-risk actions
Use condition keys to restrict access by region or IP
Regular review and update of session policies

Monitoring and Auditing:

Enable CloudTrail logging for all accounts
Set up real-time alerts for break glass access usage
Implement automated session tracking and reporting
Regular audit of access patterns and usage
Maintain detailed logs for compliance requirements

Common Access Patterns

Investigation Phase:

Read-only access to logs and security services
CloudTrail event lookup and analysis
GuardDuty and Security Hub finding review
Resource configuration and status checking

Containment Phase:

Instance stop/terminate permissions
Security group modification rights
Access key disable/delete capabilities
Network isolation and blocking actions

Recovery Phase:

Resource restoration and configuration
Service restart and validation
Backup and snapshot operations
System hardening and patching

Forensics Phase:

Snapshot and image creation
Memory dump collection
Log export and preservation
Evidence chain of custody maintenance

Compliance Considerations

SOC 2: Implement proper access controls and monitoring
PCI DSS: Ensure cardholder data environment protection
HIPAA: Maintain audit trails for healthcare data access
GDPR: Document data access for privacy compliance
SOX: Implement segregation of duties for financial systems

Emergency Scenarios

Identity Provider Outage:

Pre-positioned break glass accounts in security account
Direct IAM user access with MFA requirements
Emergency contact procedures and approval workflows
Documented recovery procedures and role assumptions

Account Lockout:

Root user access procedures and safeguards
Cross-account emergency access roles
Out-of-band communication channels
Escalation procedures for critical incidents

Compromised Federation:

Immediate break glass activation procedures
Isolation of compromised identity systems
Alternative authentication mechanisms
Incident response team activation protocols

Testing and Validation

Regular Access Testing: Quarterly validation of break glass procedures
Tabletop Exercises: Scenario-based access requirement testing
Automated Validation: Continuous testing of role assumptions
Documentation Updates: Regular review and update of procedures
Training Programs: Regular training for incident responders