Full Report
Quarantining leaked credentials is not good enough
Analysis Summary
# Best Practices: Leaked Credential Response
## Overview
These practices address the critical security gap created by "soft" responses to compromised AWS credentials (such as the standard AWS Managed Quarantine Policy). The goal is to move from a reactive posture of "limiting damage" to a proactive posture of "denying all access" and ensuring credentials cannot be leveraged for lateral movement, data destruction, or cost-incurring activities.
## Key Recommendations
### Immediate Actions
1. **Deactivate, Don't Just Quarantine:** If a credential is known to be leaked, immediately **Deactivate** or **Delete** the access key. Do not rely on "Quarantine Policies" which may leave dangerous permissions (RDS, SSM, SES) open.
2. **Root Key Hardening:** If Root keys are active, immediately delete them and replace them with IAM users or Identity Center (SSO) roles. Root credentials should never have active access keys.
3. **Invalidate Active Sessions:** After rotating/deleting keys, use the IAM console to "Revoke active sessions" for that principal to ensure any existing STS tokens are invalidated.
### Short-term Improvements (1-3 months)
1. **Transition to OIDC/SSO:** Move away from long-lived IAM access keys. Implement OpenID Connect (OIDC) for GitHub Actions/CI-CD and AWS Identity Center for human access.
2. **Audit IAM Permissions:** Review all roles for the `sts:AssumeRole` permission. Ensure that a compromised principal cannot "hop" to a more privileged role that bypasses quarantine restrictions.
3. **Enable S3 Versioning & MFA Delete:** Protect against data destruction by requiring a physical MFA device to delete versions or change bucket states.
### Long-term Strategy (3+ months)
1. **Immutable Audit Logs:** Move CloudTrail logs to a separate, dedicated "Security/Logging" AWS account. Apply SCPs (Service Control Policies) that prevent anyone—including the root user of the member account—from stopping or deleting trails.
2. **Automated Remediations:** Deploy automated tools (like AWS Config Rules or EventBridge functions) that automatically delete any IAM access key as soon as it is detected on a public repository or via AWS Health events.
## Implementation Guidance
### For Small Organizations
- **Focus:** Elimination of IAM User keys.
- **Action:** Use `aws-vault` or AWS SSO for local development. Never hardcode credentials in code.
### For Medium Organizations
- **Focus:** Visibility and Guardrails.
- **Action:** Implement AWS Control Tower and apply Guardrails that prevent the modification of CloudTrail and GuardDuty settings by any local admin.
### For Large Enterprises
- **Focus:** Defense in Depth.
- **Action:** Implement Service Control Policies (SCPs) at the Organizational Unit (OU) level to explicitly deny high-risk actions (e.g., `s3:PutObjectLockConfiguration`, `backup:DeleteBackupVault`) unless performed by a specific "Break Glass" role.
## Configuration Examples
### Dangerous Permissions to Explicitly Deny
If you must use a quarantine policy, ensure it explicitly denies these commonly overlooked "lethal" permissions:
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"sts:AssumeRole",
"ssm:SendCommand",
"ssm:StartSession",
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"backup:DeleteRecoveryPoint",
"s3:PutObjectLockConfiguration",
"ses:SendEmail",
"rds:DeleteDBInstance",
"cloudformation:DeleteStack"
],
"Resource": "*"
}
]
}
## Compliance Alignment
- **NIST SP 800-53:** AC-2 (Account Management), IA-5 (Authenticator Management).
- **CIS AWS Foundations Benchmark:** 1.4 (Ensure no root user access key exists), 1.14 (Ensure IAM policies are attached only to groups or roles).
- **ISO/IEC 27001:** A.9.2.2 (User access provisioning).
## Common Pitfalls to Avoid
- **False Sense of Security:** Assuming the `AWSCompromisedKeyQuarantineV3` policy is a "silver bullet." As noted, it may still allow RDS manipulation, SSM session hijacking, and S3 ransomware-style locking.
- **Overlooking STS:** Forgetting that even if a key is deleted, a temporary session token (STS) generated *before* deletion may remain valid for up to 12 hours.
- **Audit Log Deletion:** Allowing the compromised principal to delete CloudTrail logs, effectively "wiping the security camera footage."
## Resources
- **AWS Managed Policy Reference:** `[h]ttps://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV3.html`
- **TruffleHog (Secret Scanning):** `[h]ttps://github.com/trufflesecurity/trufflehog`
- **AWS OIDC Documentation:** `[h]ttps://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html`