Step 1 Get Stable Access |
- Confirm access to the account and embed our own user to avoid losing access:
- Log in with the email and password provided to determine if you're using the root account
- If the credentials are not the
root credentials, contact AWS support to regain that access - Change the
root credentials immediately - If SSO is not currently setup, create a new IAM user and add the
Administrator managed IAM policy to it - Enable MFA for your new user
|
Step 2 Stop Using the Root User |
- Log in as the
root user - Determine if anyone/anything is using the
root account, by checking the root user's security credentials - If you find keys that have not been used in a reasonable timeframe, delete them
- Enable MFA on the
root user account. Take a screenshot of the QR code key material and save it to Vault
|
Step 3 Update Billing Information |
- Once you get the correct billing info, make sure to add it and then remove all other payment methods including bank accounts and credit cards
- If the account is a member of an existing AWS Organization (and you can confirm it's not one owned by your company), leave the Organization
- If billing must be handled through the Organization, you'll need to discuss adding the account to the Organization
|
Step 4 Enable CloudTrail Logging and Monitoring |
- Open the CloudTrail console and determine if an existing trail is configured
- If it is, verify that the logs are being sent to a location you have access to
- If you don't recognize the location, modify the trail to send its logs to your organization's centralized S3 bucket used for log collection
- Enable CloudTrail's encryption at-rest and file validation
- Setup basic alerts for critical security activity within the account (CloudTrail and IAM changes at a minimum)
- Other security services: Security Hub, GuardDuty, Config, Macie, Inspector, Detective
|
Step 5 Cleanup IAM Entities |
- Cleanup users that have not been used in awhile:
- Download the IAM Credential Report for your account
- Start with the easiest users to delete: those who have neither a password nor access keys or attached certificates
- Next, tackle users that do not have passwords but may have access keys used sufficiently long ago
- Next, tackle users who don't have access keys, but do have passwords used sufficiently long ago
- For users who need console access:
- First check the IAM Password Policy for the account and check all the applicable boxes per your organization’s password policy
- Ensure passwords that have not been reset within the expiration period are reset
- MFA is enabled for their account
- Their attached IAM policies are necessary for their job function
- Track Down Access Keys:
- For scripts, tracking down where the scripts are running
- For users, the goal is to transition them to using IAM roles, deprecate the access keys, and delete the users:
- If the keys cannot be deleted, the next best option is scope their policies to just the services they need access to
- Use
Access Advisor to see if the policies being granted to the user are actually being used - Use CloudTrail to see specific API calls, source data, and other details to determine if all permissions are necessary
|
Step 6 Locate Exposed Services |
- Check services that are improperly configured to allow traffic from public endpoints:
- S3 Buckets set to allow public access
- EC2 and RDS instances and ELB/ALB/NLBs in public subnets with security groups allowing traffic from 0.0.0.0/0
- ElastiCache instances configured with public access enabled, especially if a password is not set
- EBS volumes, RDS backups, AMIs, and other storage backups that are shared with large numbers of accounts
- KMS keys, SNS topics, SQS queues, and other services configured with global or cross-account access
- Your biggest objectives should be:
- Closing ports and security group rules that are exposed publicly
- Locating S3 buckets that have insecure ACLs and/or bucket policies that allow public or global access
- Removing wildcards in access policies for AMIs, EBS backups, and other objects
- Configure CloudWatch metrics based on CloudTrail logs to monitor for unintended access
|
Step 7 Lock Down Your Domains |
- Configure transfer locks on all of your supported domains
- Remove domains that may be pointing to non-existent resources
- Update technical details and contacts
- Configure domains to auto-renew
|
Step 8 Find Expiring Certificates |
- Locate all certificates that are currently in use
- Rotate expiring certificates
- Associate that the new certificate with the correct EC2 instance, CloudFront distribution, AWS API Gateway, ELB, or other resource fronting the endpoint
|
Step 9 Untangle The Web of Services |
- Check every region for usage
- Map relationships between VPCs, security groups, NACLs, and other networking resources
- Start adding tags to resources to help you identify relationships in the future
- Develop (or adopt) a naming convention for resources and rename ones you can
- Check for potentially-compromised secrets
- Locate potentially-compromised resources, such as EC2 instances, by looking at usage patterns
- Take inventory of everything
|
Step 10 Monitor and Migrate |
- Migrate or deprecate services in this account as quickly as possible, with the eventual goal of full termination
|