Policy Owner: Principal Engineer
...
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
...
Version | Date | Description | Author | Approved by |
1.0 | 2023-03-28 | First Version | Ryan Heathcote | Tony Erskine |
| Anchor | ||
|---|---|---|
|
...
|
...
|
...
: Incident Collection Form
General Information | ||||
Incident Detector’s Information | ||||
Name: | Date and Time Detected: | |||
Title: | ||||
Phone: | Location Incident Detected From: | |||
E-mail: | ||||
Additional Information: | ||||
...
| 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 | ||
|---|---|---|
|
...
|
...
|
...
: - Preparedness Testing
At least once every 12 months, CloudCard shall test the IRP with a tabletop exercise to validate the IRP and organizational and system preparedness. Incident response plan testing should address:
...