# User tasks **Topics** + [Dashboard](dashboard.md) + [Managing my Incident Response Team](managing-my-incident-response-team.md) # Dashboard On the AWS Security Incident Response console, the dashboard provides you with an overview of your incident response team, your proactive response status, and a four-week rolling count of cases. Select **View incident response team** to access details of your incident response teammates. The *My Cases* section of the dashboard shows the number of opened and closed AWS supported cases, along with self-managed cases assigned to you within a defined period. It also shows the mean time it took to resolve the closed cases in hours. # Managing my Incident Response Team Your incident response teams contains stakeholders for the incident response process. You can configure up to ten stakeholders as part of your membership. Examples for internal stakeholders include members of your incident response team, security analysts, application owners, and your security leadership team. Examples for external stakeholders include individuals from independent software vendors (ISV) and managed service providers (MSP) that you want to include in an incident response process. **Note** Setting up your incident response team does not automatically grant teammates access to service resources such as membership and cases. You can use AWS managed policies for AWS Security Incident Response to grant read and write access to resources. [ Click here to learn more.](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html) Your incident response teammates specified on a membership level will be automatically added to any case. You can add or remove individual teammates at any time after a case has been created. The incident response team will receive an email notification on the events listed in [ communication preferences](https://docs.aws.amazon.com/security-ir/latest/APIReference/API_IncidentResponder.html#securityir-Type-IncidentResponder-communicationPreferences). # Communication preferences Configure your communication preferences to control how you receive notifications and interact with the incident response system during security incidents. You can configure communication preferences for individuals in your incident response team from the dashboard page. Follow these steps to manage team member communication settings: 1. Navigate to the incident response team page from your dashboard 1. Do one of the following: + To update an existing team member: Select the teammate whose communication preferences you want to modify, then choose **Edit** + To add a new team member: Choose **Add** 1. At the bottom of the form you will see Communications 1. Select the checkboxes for communications you want to receive 1. Clear the checkboxes for communications you do not want to receive ![\[alt text not found\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/CommPref.png) 1. Save your changes ![\[alt text not found\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/CommPreferencesDashboard.png) By default, incident response team members will have all communications enabled. You can modify these settings at any time using the steps above. Your communication preferences control how you interact with the incident response system and how notifications are delivered to you during security incidents. **Note** These preferences apply to all future communications within the Security Incident Response system. You can modify these settings at any time by repeating the steps above. # Account association to AWS Organizations When you enable AWS Security Incident Response, you will be given the option of selecting your entire organization or specific organizational units (OUs). If specific OUs are selected, your membership will only cover the accounts that fall under those selected OUs. If the entire organization is selected, then your membership will cover all the accounts within your organization. For more detail, please see [Managing AWS Security Incident Response accounts with AWS Organizations](https://docs.aws.amazon.com/security-ir/latest/userguide/security-ir-organizations.html). # Managing Your Membership Coverage You can change your membership coverage option at any time, including switching from organization-wide coverage to specific OUs. # Updating OU Associations To manage your membership coverage: 1. Navigate to the Account association settings page 1. Select **Add OUs** to select the OUs you want to associate with your membership 1. Select the OUs you want to associate with your membership 1. Click **Update Association** to save the OU association on your membership After updating your associations, you can return to the same page and remove any OUs that you would like to disassociate from your membership. This flexibility applies even if you initially selected your entire organization—you can later update your membership to cover only specific OUs without canceling and re-enabling the service. For more information, please see [Managing membership with organizational units (OUs)](https://docs.aws.amazon.com/security-ir/latest/userguide/managing-membership-with-ou.html). # Important Considerations **Accounts directly under the root**: When selecting specific OUs for your membership, accounts that are directly under the organization root (not part of any OU) will not be associated with your membership. To include these accounts in your membership coverage, you must first add them to an OU, then associate that OU with your membership. **Note** We are continuously improving the OU association user experience to make the process more intuitive and self-explanatory. # Monitoring and investigation AWS Security Incident Response reviews and triages security alerts from Amazon GuardDuty and AWS Security Hub CSPM, then configures suppression rules based on your environment to prevent unnecessary alerts. The AWS Security Incident Response Engineering (SIRE) team investigates findings and quickly escalates and guides your team to rapidly contain potential issues. If desired, you can grant AWS Security Incident Response permission to implement containment actions on your behalf. AWS Security Incident Response aligns to the NIST 800-61r2 [https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) for Security event Response. By aligning to this industry standard, AWS Security Incident Response provides a consistent approach to security event management and adhere to best practices in securing and responding to security events in your AWS environment. When AWS Security Incident Response identifies a security alert or you request security assistance, the AWS SIRE investigates. The team collects log events and service data such as GuardDuty alerts, triages and analyzes that data, performs remediation and containment activities, and provides post-incident reporting. **Topics** + [Prepare](prepare.md) + [Detect and Analyze](detect-and-analyze.md) + [AI Investigative Agent](ai-investigative-agent.md) + [Contain](contain.md) + [Eradicate](eradicate.md) + [Recover](recover.md) + [Post incident report](post-incident-report.md) # Prepare The AWS Security Incident Response team investigates and partners with you throughout the security event response lifecycle. It is recommended that you set up this team and assign the necessary permissions before a security event occurs. # Detect and Analyze **Reporting an Event** You can raise a security event through the AWS Security Incident Response portal. It's important not to wait during a security event. AWS Security Incident Response uses automated and manual techniques to investigate security events, analyze logs, and look for anomalous patterns. Your partnership and understanding of your environment accelerates this analysis. **Enabling supported sources of detection** **Note** AWS Security Incident Response service costs do not include usage and other costs and fees associated with supported sources of detection or use of other AWS services. Please refer to individual feature or service pages for cost details. *Amazon GuardDuty* To enable GuardDuty across your organization, please see the `Setting up GuardDuty` section of the [Amazon GuardDuty User Guide](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html#guardduty_enable-gd). We highly recommend that you enable GuardDuty in all supported AWS Regions. This enables GuardDuty to generate findings about unauthorized or unusual activity even in regions that you are not actively using. For more information, reference [Amazon GuardDuty Regions and endpoints](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_regions.html) Enabling GuardDuty provides AWS Security Incident Response access to critical threat detection data, enhancing its ability to identify and respond to potential security issues in your AWS environment. *AWS Security Hub CSPM* Security Hub CSPM can ingest security findings from several AWS services and supported third-party security solutions. These integrations can help AWS Security Incident Response monitor and investigate findings coming from other detection tools. To enable Security Hub CSPM with Organizations integration please refer to the [AWS Security Hub CSPM User Guide](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html#securityhub-orgs-setup-overviews). There are multiple ways of enabling integrations on Security Hub CSPM. For third-party product integrations, you may need to purchase the integration from the AWS Marketplace, and then configure the integration. The integration information provides links to complete these tasks. Learn more about [ how to enable AWS Security Hub CSPM integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integration-enable.html). AWS Security Incident Response can monitor and investigate findings from the following tools when they're integrated with AWS Security Hub CSPM: + [https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-crowdstrike-falcon](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-crowdstrike-falcon) + [https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-lacework](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-lacework) + [https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-trend-micro](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-trend-micro) By enabling these integrations, you can significantly enhance the scope and effectiveness of AWS Security Incident Response's monitoring and investigation capabilities. **Detection** If "Proactive Response" is enabled [https://docs.aws.amazon.com/security-ir/latest/userguide/setup-monitoring-and-investigation-workflows.html](https://docs.aws.amazon.com/security-ir/latest/userguide/setup-monitoring-and-investigation-workflows.html) AWS Security Incident Response ingests findings from Amazon GuardDuty and AWS Security Hub CSPM through Amazon EventBridge rules that are deployed to your accounts during onboarding. AWS Security Incident Response automatically archives Amazon GuardDuty findings that are determined during automated triage to be benign or associated with expected activity. You can view archived findings in the Amazon GuardDuty console by selecting Archived from the findings Status filter. For more information, see [Viewing generated findings in GuardDuty console](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_working-with-findings.html) in the *Amazon GuardDuty User Guide*. AWS Security Incident Response automatically archives Amazon GuardDuty findings that are determined during automated triage to be benign or associated with expected activity. This archiving occurs only for findings that have been triaged and have an outcome designated as "archive". Findings under active investigation remain visible in the Amazon GuardDuty console even after an investigation wraps up. You can view archived findings in the Amazon GuardDuty console by selecting **Archived** from the findings filter. For more information about working with archived findings, see [Working with findings](https://docs.aws.amazon.com/guardduty/latest/ug/findings_managing.html) in the *Amazon GuardDuty User Guide*. When AWS Security Hub CSPM ingests security findings, the system updates each finding with a note indicating that automated triage has begun. The workflow state changes from NEW to NOTIFIED, which removes the finding from the default AWS Security Hub CSPM findings view. If triage determines that a finding is benign or associated with expected activity, the system adds a note to the finding and updates the workflow state to SUPPRESSED. **Analysis: Automated Triage** AWS Security Incident Response automatically triages security findings. The triage process determines whether detected activity represents expected behavior, by analyzing data from multiple sources including the finding payload, AWS service metadata, AWS logging and monitoring data (such as AWS CloudTrail and VPC Flow Logs), AWS threat intelligence, and context that you are invited to provide about your AWS and on-premises environments. If automated triage determines that the detected activity is expected, the system takes no further investigative action. **Analysis: Incident Response Security Investigation** AWS Security Incident Response Engineering is a global, always-available team of security professionals with expertise in AWS and security incident response. If automated triage cannot determine that the activity is expected, AWS Security Incident Response Engineering is engaged to perform a security investigation. If the event was ingested from Security Hub, a note is posted to the related finding stating that AWS Security Incident Response Engineering's investigation is underway. AWS Security Incident Response Engineering conducts a hands-on security investigation by analyzing additional service metadata and threat intelligence, reviewing insights from past findings and investigations in your environment, and applying incident response expertise. Depending on your Containment preferences (see Contain) AWS Security Incident Response Engineering may engage your organization's Incident Response team through a Security Incident Response case in the AWS Security Incident Response console to verify whether the detected activity is expected and authorized [Responding to an AWS generated case](https://docs.aws.amazon.com/security-ir/latest/userguide/responding-to-an-aws-generated-case.html). **Communicate** AWS Security Incident Response keeps you informed during security investigations by engaging with your Incident Response team through a Security Incident Response case. Multiple AWS Security Incident Response Engineering members may support an investigation. Communication may include: acknowledgment or notification of the creation of a security investigation; establishing a call bridge; analysis of artifacts such as log files; requests for confirmation of expected activity; and sharing of investigation results. When AWS Security Incident Response proactively engages your Incident Response team, a case is created in your AWS Security Incident Response Membership account, which centralizes communication for all Organizational accounts in one place. These cases contain the "[Proactive case]" prefix in their title, which identifies them as initiated by AWS Security Incident Response. By actively engaging and providing timely responses to these communications, your Incident Response team can assist AWS Security Incident Response to do the following: + Ensure rapid response to genuine security incidents. + Understand your environment and expected behaviors. + Reduce false positive detections over time. The effectiveness of AWS Security Incident Response improves with your collaboration and results in a more effectively monitored and secure AWS environment. **Updating Findings** AWS Security Incident Response manages findings differently depending on their source and triage outcome. **Service Tuning** When your account service quotas permit, AWS Security Incident Response attempts to deploy an [Amazon GuardDuty suppression rule](https://docs.aws.amazon.com/guardduty/latest/ug/findings_suppression-rule.html) or an [AWS Security Hub CSPM automation rule ](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html). These rules suppress future findings matching the type and source of known authorized activity (for example, source IP address, ASN, identity principal, or resource). AWS Security Hub CSPM rules are deployed with priority 10, which allows you to override these automations with self-defined rules if needed. In this way, AWS Security Incident Response tunes detection sources based on expected behavior in your AWS environment. Your Incident Response Team is notified of modifications to these rule-sets, and changes are rolled-back upon request. # AI Investigative Agent ## Overview The AI-powered investigation agent works alongside customers and AWS Security Incident Response engineers to expedite security investigations. When a customer creates an AWS supported case, the agent automatically activates in parallel with Security Incident Response engineer engagement, reducing resolution time from days to hours. During customer escalations, Security Incident Response cases might be created by you or proactively by AWS Security Incident Response. When a new AWS supported case is created, the investigative agent automatically triggers. You can manage all cases through the console, API, or Amazon EventBridge integrations. **Key benefits** + **Parallel investigation** – The agent works simultaneously with responders—providing both AI-powered automation and human expertise. + **Automated evidence gathering** – Eliminates manual log analysis by automatically querying AWS CloudTrail, IAM, Amazon EC2, and Cost Explorer. + **Natural language interface** – Describe security concerns in plain language without needing expertise in AWS log formats. + **Faster response** – Investigation summaries available within minutes in the Investigation tab. + **Full auditability** – All agent actions are logged in AWS CloudTrail under the `AWSServiceRoleForSupport` role. **Important** This feature is only available for AWS-supported cases. Self-managed cases do not include AI investigation capabilities. ## How it works The AI investigation agent follows a structured workflow when analyzing AWS supported security cases: **Investigation workflow** 1. **Case creation** – Customer creates an AWS supported case in the Security Incident Response console describing the security concern. 1. **Parallel activation** + Security Incident Response engineers engage with the case. + Simultaneously, the AI agent begins its investigation workflow. 1. **Contextual questions (optional)** – The agent may ask clarifying questions to gather specific details: + Affected AWS account IDs + Involved IAM principals (users, roles, access keys) + Specific resource identifiers (S3 buckets, EC2 instances, ARNs) + Timeframe of suspicious activity 1. **Evidence gathering** – The agent automatically queries AWS data sources: + *AWS CloudTrail* – API calls and activities associated with the incident + *IAM* – User and role permissions, policy changes, and new identity creation + *Amazon EC2 Instance APIs* – Information about compute resources if involved + *Cost Explorer* – Cost and usage metrics for unusual resource consumption 1. **Analysis and correlation** – The agent correlates evidence across services, identifies patterns, and builds a timeline of events. 1. **Summary generation** – Within minutes, the agent presents a comprehensive investigation summary in the Investigation tab. **Note** All fields are optional. If no answer is provided within 10 minutes, the investigation starts automatically. In some cases, if sufficient information is already available, the agent may skip the optional questions entirely. **Accessing investigation results** To view the AI analysis: 1. Navigate to your case in the Security Incident Response console. 1. Select the **Investigation** tab. 1. Review the investigation summary with findings, timeline, and context. The AI investigative agent summary is automatically posted as a comment in the case's **Communication** section, making it easy to review alongside other case updates. **Data access and permissions** The AI investigation agent uses the `AWSServiceRoleForSupport` Service-Linked Role to access AWS resources. This role provides read-only permissions necessary for evidence gathering. All actions performed by the agent are logged in AWS CloudTrail, allowing customers to audit exactly what data was accessed during the investigation. In AWS CloudTrail logs, these actions are attributed to `AWSServiceRoleForSupport`. ## Prerequisites Before using the AI-powered investigation capabilities, ensure the following: **Required setup** + **AWS Security Incident Response enabled** – The service must be enabled through the AWS Organizations management account. + **AWSsupported case type** – AI investigation is only available for AWS supported cases (not self-managed cases). + **AWSServiceRoleForSupport** – This service-linked role is automatically created and provides necessary permissions for the investigation agent. **Required permissions** To create AWS supported cases and access investigation results, the IAM principal needs the following permissions: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "security-ir:CreateCase", "security-ir:GetCase", "security-ir:ListCases", "security-ir:UpdateCase" ], "Resource": "*" } ] } ``` ## Using the investigative agent The AI investigation agent activates automatically when creating an AWS-supported case. **To monitor AI investigation progress** 1. Open your case in the AWS Security Incident Response console. 1. Choose the **Investigation** tab. 1. View the investigation status (*In Progress* or *Completed*). 1. Once completed, review the comprehensive investigation summary with findings, timeline, and recommendations. **Responsible AI disclosure** Investigation summaries are generated using AWS Generative AI capabilities. You are responsible for evaluating AI-generated recommendations in your specific context, implementing appropriate oversight mechanisms, verifying findings independently, and maintaining human oversight of all security decisions. **Use of customer data** AI Investigative Agent does not use customer data for model training, and it does not share customer data with third parties. # Contain AWS Security Incident Response partners with you to contain events. You can configure the service to take proactive containment actions in your account in response to security findings. You can also perform containment yourself or in partnership with your third party relationships by using the [SSM documents](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html) described in [Supported Containment Actions.](https://docs.aws.amazon.com/security-ir/latest/userguide/supported-containment-actions.html) **Important** AWS Security Incident Response does not enable containment capabilities by default. Two steps are required to enable proactive containment capabilities: **Grant the necessary permissions** to the service using IAM roles. You can create these roles individually per account or across your entire organization by working with AWS CloudFormation stacksets, which create the required roles. **Define your containment preferences** per account or across your organization to authorize proactive containment actions. Account-level preferences supersede organization-level preferences. This may be done by creating an AWS Support Case (Technical: Security Incident Response Service/Other). The available containment preferences are: **Approval Required (default):** Do not perform proactive containment of any resource without explicit authorization on a case-by-case basis. **Contain Confirmed:** Perform proactive containment of a resource confirmed to be compromised. **Contain Suspected:** Perform proactive containment of a resource with a high likelihood of having been compromised, based on analysis performed by AWS Security Incident Response Engineering. # Containment Decision-Making An essential part of containment is decision-making, such as whether to shut down a system, isolate a resource from the network, turn off access, or end sessions. These decisions are made easier when there are predetermined strategies and procedures to contain the event. AWS Security Incident Response provides the containment strategy, informs you of potential impact, and guides you on implementing the solution only after you have considered and agreed to the risks involved. # Supported Containment Actions AWS Security Incident Response executes supported containment actions on your behalf to expedite response and reduce the time a threat actor has to potentially cause damage in your environment. This capability allows for faster mitigation of identified threats, minimizing potential impact and enhancing your overall security posture. There are different containment options depending on the resources under analysis. The supported containment actions are described in the below sub-sections. # EC2 Containment The `AWSSupport-ContainEC2Instance` containment automation performs a reversible network containment of an EC2 instance, leaving the instance intact and running, but isolating it from any new network activity and preventing it from communicating with resources within and outside your VPC. **Important** It is important to note that existing tracked connections won't be shut down as a result of changing security groups – only future traffic will be effectively blocked by the new security group and this SSM document. More information is available in the [ source containment](https://docs.aws.amazon.com/security-ir/latest/userguide/source-containment.html) section of the service technical guide. # IAM Containment The `AWSSupport-ContainIAMPrincipal` containment automation performs a reversible network containment of an IAM user or role, leaving the user or role in IAM, but isolating it from communicating with resources within your account. # S3 Containment The `AWSSupport-ContainS3Resource` containment automation performs a reversible containment of a S3 bucket, leaving the objects in the bucket, and isolating the Amazon S3 bucket or object by modifying its access policies. # Developing Containment Strategies AWS Security Incident Response encourages you to consider containment strategies for each major event type that fit within your risk appetite. Document clear criteria to help with decision-making during an event. Criteria to consider include: + Potential damage to resources + Preservation of evidence and regulatory requirements + Service unavailability (for example, network connectivity, services provided to external parties) + Time and resources needed to implement the strategy + Effectiveness of the strategy (for example, partial vs. full containment) + Permanence of the solution (for example, reversible vs. irreversible) + Duration of the solution (for example, emergency workaround, temporary workaround, permanent solution) Apply security controls that can lower risk and allow time to define and implement a more effective containment strategy. # Staged Containment Approach AWS Security Incident Response advises a staged approach to achieve efficient and effective containment, involving short-term and long-term strategies based on the resource type. # Containment Strategy **Can AWS Security Incident Response identify the scope of the security event?** + If yes, identify all the resources (users, systems, resources). + If no, investigate in parallel with executing the next step on identified resources. **Can the resource be isolated?** + If yes, then proceed to isolate the affected resources. + If no, then work with system owners and managers to determine further actions necessary to contain the problem. **Are all affected resources isolated from non-affected resources?** + If yes, then continue to the next step. + If no, then continue to isolate affected resources to complete short-term containment and prevent the event from escalating further. # System Backup **Were backup copies of affected systems created for further analysis?** **Are the forensic copies encrypted and stored in a secure location?** + If yes, then continue to the next step. + If no, encrypt the forensic images, then store them in a secure location to prevent accidental usage, damage, and tampering. # Submit containment preferences To configure containment preferences for your account or organization, create an [AWS Support case](https://repost.aws/knowledge-center/get-aws-technical-support). In your support case, specify the following information: + Your AWS Organizations ID or specific account IDs where containment actions should be authorized. + Your preferred containment option. When configured, AWS Security Incident Response executes executes the authorized containment actions during active security incidents to help protect your environment. **Note** AWS Security Incident Response executes containment actions only when configured with the appropriate preferences and after the required AWS CloudFormation StackSet is deployed to grant necessary permissions. # Eradicate During the eradication phase, it is important to identify and address all affected accounts, resources, and instances - such as by deleting malware, removing compromised user accounts, and mitigating any discovered vulnerabilities - to apply uniform remediation across the environment. It is a best practice to use a phased approach to eradication and recovery, and to prioritize remediation steps. The purpose of the early phases is to increase the overall security quickly (days to weeks) with high-value changes to prevent future events. The later phases can focus on longer-term changes (for example, infrastructure changes), and ongoing work to keep the enterprise as secure as possible. Each case is unique and AWS Security Incident Response engineers will work with you to assess necessary actions.  Consider the following: + Can you re-image the system and harden it with patches or other countermeasures to prevent or reduce the risk of attacks? + Can you replace the infected system with a new instance or resource, enabling a clean baseline while terminating the infected item? + Have you removed all malware and other artifacts left behind by the unauthorized use, and hardened the affected systems against further attacks? + Is there a requirement for forensics on the impacted resources? # Recover AWS Security Incident Response provides you guidance to help restore systems to normal operation, confirm they are functioning properly, and remediate any vulnerabilities to prevent similar events in the future. AWS Security Incident Response does not directly help with recovery of systems. Key considerations include: + Are the affected systems patched and hardened against the recent attack? + What is the feasible timeline to restore the systems to production? + What tools will you use to test, monitor, and verify the restored systems? # Post incident report AWS Security Incident Response provides a summary of the event after the conclusion of security activities between your team and ours. At the end of each month, the AWS Security Incident Response service will send monthly reports to the primary point of contact for each customer via email. The reports will be delivered in a PDF format using the metrics described below. Customers will receive one report per AWS Organizations. # Case metrics + Cases created + Dimension name: Type + Dimension values: AWS supported, self supported + Unit: Count + Description: The number of cases created. + Cases closed + Dimension name: Type + Dimension values: AWS supported, self-managed + Unit: Count + Description: A measure of the total number of cases closed. + Opened cases + Dimension name: Type + Dimension values: AWS supported, self supported + Unit: Count + Description: The number of open cases. # Triaging metrics + Findings received + Unit: Count + Description: The number of findings sent to triaging. + Findings archived + Unit: Count + Description: The number of findings archived after processed without manual investigation. + Findings Manually investigated + Unit: Count + Description: The number of findings with manual investigation performed. + Investigations archived + Unit: Count + Description: The number of manual investigations resulting in false positive and sent for archiving + Investigations escalated + Unit: Count + Description: The number of manual investigations resulting in a security incident # Cases AWS Security Incident Response allows you to create two types of cases - AWS supported or self-managed cases. # Create an AWS supported case You can create an AWS supported case for AWS Security Incident Response through the Console, the API, or the AWS Command Line Interface. AWS supported cases allow you to receive support from Security Incident Response engineers. **Important** Demo/simulation-cases are closing after a period of 90 days. **Note** AWS Security Incident Response engineers will respond to your case within 15 minutes. Response time is for a first response from AWS Security Incident Response engineers. We will make every reasonable effort to respond to your initial request within this time frame. This response time does not apply to subsequent responses. **Note** You can create AWS supported cases not only for active security incidents and investigations, but also for inquiries about AWS Security Incident Response capabilities. This includes questions about GuardDuty suppression rules, alert triaging configurations, proactive response workflows, and general guidance on security posture. Select the **Investigations and Inquiries** case type for these purposes. # When to contact AWS Security Incident Response You can contact AWS Security Incident Response for various purposes depending on your needs. The following table describes the different scenarios and the appropriate contact method for each. | Scenario | When to Use | Response Time | Case Type | | --- | --- | --- | --- | | **Active Security Incident** | You are experiencing an urgent security incident requiring immediate incident response support and services | 15 minutes (first response) | [Active Security Incident](https://docs.aws.amazon.com/security-ir/latest/userguide/create-an-aws-supported-case.html) | | **Investigation** | You have a perceived security incident and need support with log analysis and secondary confirmation of incident response investigation | 15 minutes (first response) | [Investigations and Inquiries](https://docs.aws.amazon.com/security-ir/latest/userguide/create-an-aws-supported-case.html) | | **Inquiries and Guidance** | You have questions about Amazon GuardDuty findings, suppression rules, alert triaging configurations, proactive response workflows, or general security posture related to AWS Security Incident Response capabilities | 15 minutes (first response) | [Investigations and Inquiries](https://docs.aws.amazon.com/security-ir/latest/userguide/create-an-aws-supported-case.html) | | **Onboarding Issues** | You are experiencing technical issues during the onboarding process for AWS Security Incident Response | Varies by support plan | [AWS Support case](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case) | For all AWS-supported cases (Active Security Incident and Investigations and Inquiries), AWS Security Incident Response engineers will respond within 15 minutes for the first response. This response time applies only to the initial contact and does not apply to subsequent responses. The following example covers use of the console. 1. Sign into AWS Security Incident Response via the AWS Management Console. 1. Choose **Create Case** 1. Choose **Resolve case with AWS** 1. Select the type of request 1. **Active Security Incident**: This type is for urgent incident response support and services. 1. **Investigations and Inquiries**: Use this type for perceived security incidents where AWS Security Incident Response engineers can support in log analysis and secondary confirmation of incident response investigation. You can also use this type for inquiries about GuardDuty findings, suppression rules, alert triaging configurations, proactive response workflows, and general security posture questions related to AWS Security Incident Response capabilities. 1. Set the start date estimate to the date of your earliest indicator of the incident. For example, when you experienced abnormal behavior for the first time or when you received the first related security alert. 1. Define a title for the case 1. Provide a detailed description of the case.  Consider the following aspects which can help incident responders with the case resolution: 1. What happened? 1. Who discovered and reported the incident? 1. Who is affected by the case? 1. What is the known impact? 1. What is the urgency for this case? 1. Add one or multiple AWS account IDs that are in scope of the case. 1. Add optional case details: 1. Select the main services that are impacted from the drop-down list. 1. Select the main regions that are impacted from the drop-down list. 1. Add one or many threat actor IP addresses that you identified as part of this case.  1. Add optional additional incident responders to the case that will receive notifications. To add an individual, do the following: 1. Add an email address. 1. Add an optional first and last name. 1. Choose **Add new** to add another individual. 1. To remove an individual, choose the **Remove** option for an individual. 1. Choose **Add** to add all listed individuals to the case. 1. You can select multiple individuals and choose **Remove** to delete them from the list. 1. Add optional tags to the case. 1. To add a tag, do the following: 1. Choose **Add new tag**. 1. For **Key**, enter the name of the tag. 1. For **Value**, enter the value of the tag. 1. To remove a tag, choose the **Remove** option for that tag. After a AWS supported case has been created, the AWS Security Incident Response engineers and your incident response team are immediately notified. **To create an AWS-supported case with AI investigation** 1. Open the AWS Security Incident Response console at [console.aws.amazon.com/](https://console.aws.amazon.com/). 1. Choose **Cases** from the navigation pane. 1. Choose **Create case**. 1. For **Case type**, select **AWS-supported case**. 1. Provide case details including title, incident start date, and affected AWS account ID. 1. In the **Describe the security event** section, provide a thorough description of the incident. 1. Provide additional information about affected AWS services, regions, and other relevant details. 1. Choose **Create case**. After case creation, both the Security Incident Response engineers and AI agent begin working simultaneously. **To respond to AI clarifying questions (optional)** 1. Navigate to the **Investigation** tab in your case. 1. Review any clarifying questions presented by the AI agent. 1. Respond to the questions or choose **Skip** if you prefer not to answer. 1. Choose **Submit** to continue. All fields are optional. **Responsible AI disclosure** Investigation summaries are generated using AWS Generative AI capabilities. You are responsible for evaluating AI-generated recommendations in your specific context, implementing appropriate oversight mechanisms, verifying findings independently, and maintaining human oversight of all security decisions. # Create a self-managed case You can create a self-managed for AWS Security Incident Response through the Console, API, or AWS Command Line Interface. This type of case *DOES NOT* engage the AWS Security Incident Response engineers. The following example covers use of the console. 1. Sign into AWS Security Incident Response via the AWS Management Console at [https://console.aws.amazon.com/security-ir/](https://console.aws.amazon.com). 1. Choose **Create Case.** 1. Choose **Resolve case with my own incident response team.** 1. Set the start date estimate to the date of your earliest indicator of the incident. For example, when you experienced abnormal behavior for the first time or when you received the first related security alert. 1. Define a title for the case. It is recommended to include the data into the case title as suggested when selecting the **Generate Title** option. 1. Enter AWS account IDs that are part of the case. To add an account ID, do the following: 1. Enter the 12-digit account ID and choose **Add account**. 1. To remove an account, choose **Remove** next to the account you want to remove from the case. 1. Provide a detailed description of the case.  1. Consider the following aspects which can help incident responders with the case resolution: 1. What happened? 1. Who discovered and reported the incident? 1. Who is affected by the case? 1. What is the known impact? 1. What is the urgency for this case? 1. Add optional case details: 1. Select the main services that are impacted from the drop-down list. 1. Select the main regions that are impacted from the drop-down list. 1. Add one or many threat actor IP addresses that you identified as part of this case. 1. Add optional additional incident responders to the case that will receive notifications. To add an individual, do the following: 1. Add an email address. 1. Add an optional first and last name. 1. Choose **Add new** to add another individual. 1. To remove an individual, choose the **Remove** option for an individual. 1. Choose **Add** to add all listed individuals to the case. You can select multiple individuals and choose **Remove** to delete them from the list. 1. Add optional tags to the case. To add a tag, do the following: 1. Choose **Add new tag**. 1. For **Key**, enter the name of the tag. 1. For **Value**, enter the value of the tag. 1. To remove a tag, choose the **Remove** option for that tag. The incident response team will be notified by e-mail after the case is created. # Working with AWS Security Incident Response engineers After you open a security incident case, the AWS Security Incident Response engineers begin working on your incident. This section explains what to expect during the investigation and how to collaborate effectively with our team. # What to expect from AWS Security Incident Response engineers When you open an AWS supported case, a Security Incident Response engineer is assigned to your incident. Your assigned responder will: + Review the initial information you provided in the case + Analyze relevant AWS service logs and security findings + Identify the scope and impact of the security incident + Develop an investigation and response plan tailored to your situation **Response timeline**: The service level objective (SLO) for acknowledgment of new cases by AWS Security Incident Response engineers is within 15 minutes. The initial assessment timeline might vary based on case severity and complexity. If AWS Security Incident Response engineers don't receive a response or critical information from you within 5 business days, the case is closed. # Investigation workflow AWS Security Incident Response engineers follow a structured incident response process aligned with the NIST 800-61r2 framework. During your investigation, you can expect the following phases: 1. **Initial triage** - Security Incident Response engineers review your case details and confirm the incident scope 1. **Investigation** - Security Incident Response engineers analyze logs, identify indicators of compromise, and determine root cause 1. **Containment** - Security Incident Response engineers recommend actions to limit the incident's impact 1. **Eradication and recovery** - Security Incident Response engineers help you remove threats and restore normal operations 1. **Post-incident review** - Security Incident Response engineers provide findings and recommendations to prevent future incidents Throughout these phases, your Security Incident Response engineer keeps you informed through case updates and may request additional information or actions from you. # Information Security Incident Response engineers may request To investigate your incident effectively, AWS Security Incident Response engineers may ask you to provide: + **Timeline details** - When you first detected the incident and any relevant events leading up to it + **Affected resources** - Specific AWS account IDs, services, regions, and resource ARNs involved + **Access information** - Details about who has access to affected resources and any recent access changes + **Business context** - How the affected resources are used and the potential business impact + **Logs and evidence** - Additional logs, screenshots, or artifacts that may help the investigation + **Authorization** - Approval to perform specific containment or remediation actions on your behalf Your Security Incident Response engineer will explain why each piece of information is needed and how it helps the investigation. # Communication best practices Effective communication accelerates incident resolution. Follow these practices when working with AWS Security Incident Response engineers: + **Respond promptly** to information requests from your Security Incident Response engineer + **Provide complete information** even if you're uncertain about its relevance + **Ask questions** if you don't understand a recommendation or need clarification + **Update the case** with any new developments or changes to the incident + **Designate a primary contact** from your team to coordinate with Security Incident Response engineers **Important** If AWS Security Incident Response engineers don't receive a response to critical information requests within 5 business days, we work toward case closure. You can reopen a case if new information becomes available. # Your role during the investigation While AWS Security Incident Response engineers lead the investigation, your participation is essential. You're responsible for the following actions: + Providing timely responses to information requests + Implementing recommended containment and remediation actions in your AWS environment + Authorizing Security Incident Response engineers to take actions on your behalf (if you enabled proactive response) + Coordinating with your internal teams (security, legal, compliance) as needed + Making business decisions about incident response priorities and trade-offs AWS Security Incident Response engineers provide expertise and recommendations, but you maintain control over your AWS resources and make final decisions about response actions. # Case closure AWS Security Incident Response engineers close your case when: + The incident has been contained and remediated + All investigation findings have been shared with you + No further Security Incident Response engineer assistance is required + You request case closure Before closing a case, your Security Incident Response engineer provides a summary of findings, actions taken, and recommendations for improving your security posture. If you need additional assistance after case closure, you can open a new case or contact AWS Support. # Responding to an AWS generated case AWS Security Incident Response might create an outbound notification or case when you need to act on or be aware of something that potentially impacts your account or resources. This only occurs if you enabled the proactive response and alert triaging workflows as part of your subscription. These notifications appear as Security Incident Response cases with the prefix "[Proactive case]" in the AWS Security Incident Response console. To view and manage these cases, complete the following steps: + Open the Security Incident Response console at https://console.aws.amazon.com/security-ir/ + Choose **Cases**. + You see all cases, including those with the "[Proactive case]" prefix. You can update, resolve, and reopen these cases as needed. You can communicate directly with the AWS Security Incident Response team through these cases, ensuring efficient handling of potential security issues. # Managing Cases **Topics** + [Changing the case status](changing-the-case-status.md) + [Changing the resolver](changing-the-resolver.md) + [Action Items](action-items.md) + [Edit a case](edit-a-case.md) + [Communications](communications.md) + [Permissions](sir-permissions.md) + [Attachments](attachments.md) + [Tags](tags.md) + [Case activities](case-activities.md) + [Closing a case](closing-a-case.md) # Changing the case status A case is in one of the following states: + Submitted: This is the initial status of a case. Cases in this status have been submitted by a requested, but are not yet being worked on. + Detection and Analysis: This status indicates an incident responder has started work on the case. This phase includes data gathering, triaging the event, and performing analysis to create data driven conclusions. + Containment, Eradication and Recovery: In this status the incident responder has identified suspicious activity that requires additional effort to remove. The incident responder will provide recommendations to you for business risk analysis and additional actions. If you have enabled the opt-in features for the service, then an AWS incident responder will seek your consent to perform containment actions with SSM documents in the impacted account(s). + Post-incident activities: In this status the primary security event has been contained. The focus now is to recover and return business operations to normal. A summary and root cause analysis is provided if the resolver for the case is AWS-supported. + Closed: This is the final status of the workflow. Cases in a closed status indicate work has been completed. Closed cases cannot be reopened, so ensure all actions are complete before transitioning to this status. Choose **Action/Update Status** to change the status of the case for self-managed cases. For AWS supported cases, the status is set by the AWS Security Incident Response engineers.  # Changing the resolver For self-managed cases, your incident response team can request help from AWS. Choose **Get help from AWS** to change the resolver for this case to AWS. Once the case is updated to AWS supported, the status is changed to **Submitted**. The existing case history will be available to AWS Security Incident Response engineers. Once you have requested help from AWS you will not be able to change it back to self-managed.  # Action Items An AWS Security Incident Response engineer working on the case may request actions from your internal team. Action items that appear after a case has been created include: + Request to provide permissions for an incident responder to access a case  + Request to provide more information about the case Action items when a case is ready to close: + Request to review the case report + Request to close the case # Edit a case Choose **Edit** to change the details of a case. **For AWS supported and self-managed cases:** You can change the following case details after a case has been created: + Title + Description **For AWS supported cases only:** You can change the additional fields:  + **Request type:** + **Active Security Incident**: This type is for urgent incident response support and services.   + **Investigations**: Investigations allow you to get support for perceived security incidents where the AWS Security Incident Response engineers can support in log dive and secondary confirmation of the security event. + **Start date estimate**: Change this field if you received indicators for this case that pre-date the initial provided start date. Consider providing additional details in regards to the newly detected indicator in the description field or add a comment in the communications tab. # Communications AWS Security Incident Response engineers can add comments to document their activities when working on a case. Different AWS Security Incident Response engineers can work on a case at the same time. They are represented as **AWS Responder** within the communication log.  # Permissions The permissions tab lists all individuals that will be notified for any change to the case. You can add and remove individuals from the list until the case is closed. **Note** Individual cases allow you to include up to 30 total stakeholders. Additional permission configuration is required to grant case-level access to these stakeholders. **Provide access to a case in the console** To provide access to the case in the AWS Management Console, you can copy the IAM permission policy template and add this permission to a user or role.  Adding the IAM policy to a user or a role: 1. Copy the IAM permission policy. 1. Open IAM in the via [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **User** or **Roles.** 1. Select a user or role to open the details page. 1. In the permissions tab, choose **Add permissions.** 1. Choose **Attach policy**. 1. Select the appropriate [AWS Security Incident Response managed policy](https://docs.aws.amazon.com/security-ir/latest/userguide/aws-managed-policies.html). 1. Choose **Add policy**. # Attachments Your incident responders can add attachments to a case that help other incident responders with their investigation for self-managed cases. **Note** If you choose an AWS supported case, AWS cannot view attachments. All details for AWS supported cases must be shared via case comments or through you providing a screenshare using your preferred communications technology. Choose **Upload** to select a file from your computer to be added to the case. **Note** Any uploaded attachments are deleted seven days after a case has been `Closed`. # Tags A tag is an optional label that you can assign to your cases to hold metadata about that resource. Each tag is a label consisting of a key and an optional value. You can use tags to search, allocate costs, and authenticate permissions for the resource. To add a tag, do the following: 1. Choose **Add new tag**. 1. For **Key**, enter the name of the tag. 1. For **Value**, enter the value of the tag. To remove a tag, choose the **Remove** option for that tag. # Case activities Audit trails provide detailed chronological records of all case activities. They provide important information in post-event activities and help to identify potential improvements. The time, user, action, and details of any case change are logged in the case audit trail.  # Closing a case For AWS supported cases, choose **Close Case** on the case details page to permanently close the case at any status. A case typically reaches the status **Ready to Close** before it is permanently closed. If you close a case prematurely at any other status than **Ready to Close**, you are requesting that AWS Security Incident Response engineers will stop working on this AWS supported case.  If your incident response team is the responder, select **Action/Close Case** on the case details page. **Note** The "Ready to Close" status signifies that a case can be permanently closed and that there is no additional work to be done on a case. A case cannot be re-opened again after it has been permanently closed. All information will be available read-only. To prevent accidental closure, you will be asked to confirm that you want to close the case. # Working with CloudFormation StackSets **Important** AWS Security Incident Response doesn't enable containment capabilities by default. To run these containment actions, you must grant the necessary permissions to the service using AWS Identity and Access Management roles. You can create these roles individually for each account or across your entire organization by deploying CloudFormation StackSets, The StackSets create the required roles. For specific instructions on how to create a StackSet with service-managed permissions, see [ Create CloudFormation StackSets with service-managed permissions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-associate-stackset-with-org.html) in the *AWS CloudFormation User Guide*. The following are templates to create the *AWSSecurityIncidentResponseContainment* and *AWSSecurityIncidentResponseContainmentExecution* roles. ``` AWSTemplateFormatVersion: '2010-09-09' Description: 'Template for production SIR containment roles' Resources: AWSSecurityIncidentResponseContainment: Type: 'AWS::IAM::Role' Properties: RoleName: AWSSecurityIncidentResponseContainment AssumeRolePolicyDocument: { 'Version': '2012-10-17', 'Statement': [ { 'Effect': 'Allow', 'Principal': { 'Service': 'containment.security-ir.amazonaws.com' }, 'Action': 'sts:AssumeRole', 'Condition': { 'StringEquals': { 'sts:ExternalId': !Sub '${AWS::AccountId}' } }, }, { 'Effect': 'Allow', 'Principal': { 'Service': 'containment.security-ir.amazonaws.com' }, 'Action': 'sts:TagSession', }, ], } Policies: - PolicyName: AWSSecurityIncidentResponseContainmentPolicy PolicyDocument: { 'Version': '2012-10-17', 'Statement': [ { 'Effect': 'Allow', 'Action': ['ssm:StartAutomationExecution'], 'Resource': [ !Sub 'arn:${AWS::Partition}:ssm:*:*:automation-definition/AWSSupport-ContainEC2Instance:$DEFAULT', !Sub 'arn:${AWS::Partition}:ssm:*:*:automation-definition/AWSSupport-ContainS3Resource:$DEFAULT', !Sub 'arn:${AWS::Partition}:ssm:*:*:automation-definition/AWSSupport-ContainIAMPrincipal:$DEFAULT', ], }, { 'Effect': 'Allow', 'Action': ['ssm:DescribeInstanceInformation', 'ssm:GetAutomationExecution', 'ssm:ListCommandInvocations'], 'Resource': '*', }, { 'Effect': 'Allow', 'Action': ['iam:PassRole'], 'Resource': !GetAtt AWSSecurityIncidentResponseContainmentExecution.Arn, 'Condition': { 'StringEquals': { 'iam:PassedToService': 'ssm.amazonaws.com' } }, }, ], } AWSSecurityIncidentResponseContainmentExecution: Type: 'AWS::IAM::Role' Properties: RoleName: AWSSecurityIncidentResponseContainmentExecution AssumeRolePolicyDocument: { 'Version': '2012-10-17', 'Statement': [{ 'Effect': 'Allow', 'Principal': { 'Service': 'ssm.amazonaws.com' }, 'Action': 'sts:AssumeRole' }], } ManagedPolicyArns: - !Sub arn:${AWS::Partition}:iam::aws:policy/SecurityAudit Policies: - PolicyName: AWSSecurityIncidentResponseContainmentExecutionPolicy PolicyDocument: { 'Version': '2012-10-17', 'Statement': [ { 'Sid': 'AllowIAMContainment', 'Effect': 'Allow', 'Action': [ 'iam:AttachRolePolicy', 'iam:AttachUserPolicy', 'iam:DeactivateMFADevice', 'iam:DeleteLoginProfile', 'iam:DeleteRolePolicy', 'iam:DeleteUserPolicy', 'iam:GetLoginProfile', 'iam:GetPolicy', 'iam:GetRole', 'iam:GetRolePolicy', 'iam:GetUser', 'iam:GetUserPolicy', 'iam:ListAccessKeys', 'iam:ListAttachedRolePolicies', 'iam:ListAttachedUserPolicies', 'iam:ListMfaDevices', 'iam:ListPolicies', 'iam:ListRolePolicies', 'iam:ListUserPolicies', 'iam:ListVirtualMFADevices', 'iam:PutRolePolicy', 'iam:PutUserPolicy', 'iam:TagMFADevice', 'iam:TagPolicy', 'iam:TagRole', 'iam:TagUser', 'iam:UntagMFADevice', 'iam:UntagPolicy', 'iam:UntagRole', 'iam:UntagUser', 'iam:UpdateAccessKey', 'identitystore:CreateGroupMembership', 'identitystore:DeleteGroupMembership', 'identitystore:IsMemberInGroups', 'identitystore:ListUsers', 'identitystore:ListGroups', 'identitystore:ListGroupMemberships', ], 'Resource': '*', }, { 'Sid': 'AllowOrgListAccounts', 'Effect': 'Allow', 'Action': 'organizations:ListAccounts', 'Resource': '*', }, { 'Sid': 'AllowSSOContainment', 'Effect': 'Allow', 'Action': [ 'sso:CreateAccountAssignment', 'sso:DeleteAccountAssignment', 'sso:DeleteInlinePolicyFromPermissionSet', 'sso:GetInlinePolicyForPermissionSet', 'sso:ListAccountAssignments', 'sso:ListInstances', 'sso:ListPermissionSets', 'sso:ListPermissionSetsProvisionedToAccount', 'sso:PutInlinePolicyToPermissionSet', 'sso:TagResource', 'sso:UntagResource', ], 'Resource': '*', }, { 'Sid': 'AllowSSORead', 'Effect': 'Allow', 'Action': ['sso-directory:SearchUsers', 'sso-directory:DescribeUser'], 'Resource': '*', }, { 'Sid': 'AllowS3Read', 'Effect': 'Allow', 'Action': [ 's3:GetAccountPublicAccessBlock', 's3:GetBucketAcl', 's3:GetBucketLocation', 's3:GetBucketOwnershipControls', 's3:GetBucketPolicy', 's3:GetBucketPolicyStatus', 's3:GetBucketPublicAccessBlock', 's3:GetBucketTagging', 's3:GetEncryptionConfiguration', 's3:GetObject', 's3:GetObjectAcl', 's3:GetObjectTagging', 's3:GetReplicationConfiguration', 's3:ListBucket', 's3express:GetBucketPolicy', ], 'Resource': '*', }, { 'Sid': 'AllowS3Write', 'Effect': 'Allow', 'Action': [ 's3:CreateBucket', 's3:DeleteBucketPolicy', 's3:DeleteObjectTagging', 's3:PutAccountPublicAccessBlock', 's3:PutBucketACL', 's3:PutBucketOwnershipControls', 's3:PutBucketPolicy', 's3:PutBucketPublicAccessBlock', 's3:PutBucketTagging', 's3:PutBucketVersioning', 's3:PutObject', 's3:PutObjectAcl', 's3express:CreateSession', 's3express:DeleteBucketPolicy', 's3express:PutBucketPolicy', ], 'Resource': '*', }, { 'Sid': 'AllowAutoScalingWrite', 'Effect': 'Allow', 'Action': [ 'autoscaling:CreateOrUpdateTags', 'autoscaling:DeleteTags', 'autoscaling:DescribeAutoScalingGroups', 'autoscaling:DescribeAutoScalingInstances', 'autoscaling:DescribeTags', 'autoscaling:EnterStandby', 'autoscaling:ExitStandby', 'autoscaling:UpdateAutoScalingGroup', ], 'Resource': '*', }, { 'Sid': 'AllowEC2Containment', 'Effect': 'Allow', 'Action': [ 'ec2:AuthorizeSecurityGroupEgress', 'ec2:AuthorizeSecurityGroupIngress', 'ec2:CopyImage', 'ec2:CreateImage', 'ec2:CreateSecurityGroup', 'ec2:CreateSnapshot', 'ec2:CreateTags', 'ec2:DeleteSecurityGroup', 'ec2:DeleteTags', 'ec2:DescribeImages', 'ec2:DescribeInstances', 'ec2:DescribeSecurityGroups', 'ec2:DescribeSnapshots', 'ec2:DescribeTags', 'ec2:ModifyNetworkInterfaceAttribute', 'ec2:RevokeSecurityGroupEgress', ], 'Resource': '*', }, { 'Sid': 'AllowKMSActions', 'Effect': 'Allow', 'Action': [ 'kms:CreateGrant', 'kms:DescribeKey', 'kms:GenerateDataKeyWithoutPlaintext', 'kms:ReEncryptFrom', 'kms:ReEncryptTo', ], 'Resource': '*', }, { 'Sid': 'AllowSSMActions', 'Effect': 'Allow', 'Action': ['ssm:DescribeAutomationExecutions'], 'Resource': '*', }, ], } ``` # Cancel Membership A role having the CancelMembership permission for AWS Security Incident Response can cancel the membership from the console, the API, or AWS Command Line Interface. **Important** Once a membership has been canceled, you will be unable to view historic case data. When you cancel a membership, your membership will be deleted immediately and you will not have further access to the cases on the membership. Any resources or investigations that are `Active` or `ready to close` will also be terminated upon membership cancellation. When you cancel a membership: Your membership will be deleted and you will not have further access to the cases on the membership. **Important** If you resubscribe to the service, a new membership will be created and the case resources that lived under the prior membership are only accessible if you downloaded them prior to cancellation. After the membership has been canceled, everyone in the membership incident response team are notified by email. **Important** If you created a membership using a delegated administrator account and you use the AWS Organizations API to remove the delegated administrator designation from the account, the membership will be terminated immediately.