Policy Owner: Principal Engineer
...
If an AWS root account compromise is known or expected, refer to the playbook in Appendix D: PlayBook - Root Account Compromise.
Additional Requirements
Suspected and reported events and incidents shall be documented
Suspected incidents shall be assessed and classified as either an event or an incident
Incident response shall be performed according to this plan and any associated procedures.
All incidents shall be formally documented, and a documented root cause analysis shall be performed
Incident responders shall collect, store, and preserve incident-related evidence in accordance with industry guidance and best practices such as https://csrc.nist.gov/publications/detail/sp/800-86/final
Suspected and confirmed unauthorized access events shall be reviewed by the Incident Response Team. Breach determinations shall only be made by the Principal Engineer.
CloudCard shall promptly and properly notify customers, partners, users, affected parties, and regulatory agencies of relevant incidents or breaches in accordance with CloudCard policies, contractual commitments, and regulatory requirements, as determined by the Managing Director in consultation with legal counsel.
This Incident Response Plan shall be reviewed and formally tested at least annually, as described in Appendix C - Preparedness Testing. Results of IR plan testing activities including findings and lessons learned will be formally documented and maintained to support security, compliance and audit requirements
...
Location(s) of affected systems: | ||||
Date and time incident handlers arrived at site: | ||||
Describe affected information system(s) (one form per system is recommended): | ||||
Hardware Manufacturer: | ||||
Serial Number: | ||||
Is the affected system connected to a network? | Yes | No | ||
Describe the physical security of the location of affected information systems (locks, security alarms, building access, etc.): | ||||
Isolate affected systems: | ||||
Approval to removal from network? | Yes | No | ||
If YES, Name of Approver: | ||||
Date and Time Removed: | ||||
If NO, state the reason: | ||||
Backup of Affected System(s): | ||||
Last System backup successful? | Yes | No | ||
Name of persons who did backup: | ||||
Date and time last backups started: | ||||
Date and time last backups completed: | ||||
Backup Storage Location: | ||||
Incident Eradication: | ||||
Name of persons performing forensics: | ||||
Was the vulnerability (root cause) identified: | Yes | No | ||
Describe: | ||||
How was eradication validated: | ||||
| Anchor |
|---|
...
|
...
Incident Response Runbook – Root Usage
Objective
The objective of this runbook is to provide specific guidance on how to manage Root AWS account usage. This runbook is not a substitute for an in-depth Incident Response strategy. This runbook focuses on the IR lifecycle:
Establish control.
Determine impact.
Recover as needed.
Investigate the root cause.
Improve.
The Indicators of Compromise (IOC), initial steps (stop the bleeding), and the detailed CLI commands needed to execute those steps are listed below.
Assumptions
CLI configured and installed.
Reporting process is already in place.
Trusted Advisor is active.
Security Hub is active.
Indicators of Compromise
Activity that is abnormal for the account.
Creation of IAM users.
CloudTrail turned off.
Cloudwatch turned off.
SNS paused.
Step Functions paused.
Launching of new or unexpected AMIs.
Changes to the contacts on the account.
Steps to Remediate – Establish Control
AWS documentation for a possible compromised account calls out the specific tasks listed below. The documentation for a possible compromised account can be found at: What do I do if I notice unauthorized activity in my AWS account?
Contact AWS Support and TAM as soon as possible.
Change and rotate Root password and add an MFA device associated with Root.
Rotate passwords, access/secret keys, and CLI commands relevant to remediation steps.
Review actions taken by the root user.
Open the runbooks for those actions.
Close incident.
Review the incident and understand what happened.
Fix the underlying issues, implement improvements, and update the runbook as needed.
Further Action Items – Determine Impact
Review created items and mutating calls. There are may be items that have been created to allow access in the future. Some things to look at:
IAM Users.
S3 buckets.
Elastic Beanstalk Environments
RDS Clusters
Secrets Manager
QuickSight Dashboards
Route53
| Anchor | ||||
|---|---|---|---|---|
|
...