# Onboarding guide
<a name="onboarding-guide"></a>

 AWS Security Incident Response helps you prepare for, respond to, and recover from security events such as account takeovers, data breaches, and ransomware attacks. The service triages findings from Amazon GuardDuty and AWS Security Hub CSPM, escalates security events, and manages cases that require your attention. You also have access to the AWS Security Incident Response team (SIRT), who investigates impacted resources and provides guidance throughout the incident lifecycle. 

For a full overview of the service, see [What is AWS Security Incident Response?](what-is.md) 

# Prepare for onboarding
<a name="onboarding-preparation"></a>

 We recommend using a proof-of-concept (POC) approach when implementing AWS Security Incident Response. Before deployment, complete the following preparation steps with your internal teams and AWS account team. 
+ **Identify key stakeholders**: Map out the incident response decision-makers in your organization. Their involvement in policy updates and process changes is essential for a successful rollout.
+ **Validate finding sources**: Confirm that all security finding sources are properly configured and deployed. GuardDuty and Security Hub CSPM are critical inputs for the service's auto-triage technology.
+ **Determine account scope**: Decide whether AWS Security Incident Response will cover your entire AWS organization or specific organizational units (OUs). Defining this scope early makes implementation and scaling more straightforward.
+ **Establish escalation protocols**: Update your existing escalation procedures to include AWS Security Incident Response. Communicate the updated protocols to all stakeholders and response personnel.
+ **Collect points of contact and critical information**: Collecting customer metadata early ensures a smooth onboarding experience and enables timely outreach from AWS SIRT when needed. See [Appendix A: Points of contact and critical information](appendix.md) for the required information.

# Onboarding prerequisites
<a name="onboarding-prerequisites"></a>

 The only required prerequisite is enabling [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) with **All Features** enabled. Consolidated billing alone is not sufficient. 

 While not required, we strongly recommend enabling [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) and [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) across all accounts and active AWS Regions to get the most value from AWS Security Incident Response. 
+ [GuardDuty and AWS Security Incident Response](https://docs.aws.amazon.com/security-ir/latest/userguide/guardduty.html)
+ [GuardDuty best practices](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_best_practices.html)

## Third-party EDR integration
<a name="third-party-edr-integration"></a>

 Security Hub CSPM can ingest findings from third-party endpoint detection and response (EDR) vendors. When ingested, these findings are auto-triaged by AWS Security Incident Response for proactive case creation. To set up a third-party EDR integration, follow the steps in the [Security Hub CSPM integrations documentation](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html). 

![\[AWS Security Hub CSPM console\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/thirdpartyintegration.png)


**Note**  
 You don't need to enable Security Hub CSPM standards or controls. Only the vendor integrations are required for AWS Security Incident Response to ingest third-party findings. 

 **Pricing**: The first 10,000 Security Hub CSPM findings are free. After that, the cost is \$10.00003 per finding. For more information, see [Security Hub CSPM pricing](https://aws.amazon.com/security-hub/pricing/). 

# Step 1: Enable AWS Security Incident Response
<a name="deploy-configure"></a>

 The onboarding process takes approximately 10 to 15 minutes per AWS organization. For a walkthrough, see the [Getting Started video](https://docs.aws.amazon.com/security-ir/latest/userguide/getting-started.html) in the service documentation. 

**To enable AWS Security Incident Response**

1. Sign in to the AWS Management Console using your management account.

1. Open the AWS Security Incident Response console and choose **Sign up**.  
![\[AWS Security Incident Response sign-up page with the Sign up button.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/AWS_Security_incident_Response.png)

1. Designate a security tooling account as the delegated administrator.
   + For guidance, see [Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) in *AWS Prescriptive Guidance* and [Delegated administrator](https://docs.aws.amazon.com/security-ir/latest/userguide/delegated-admin.html).  
![\[Set up central membership account page for selecting a delegated administrator account.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Set_Up_Central_Membership_Account.png)

1. Sign in to the delegated administrator account.

1. Enter your membership details and associate the relevant accounts.

1. For **Account scope**, choose to enable AWS Security Incident Response for your entire AWS organization or for specific OUs. You can select coverage at the OU level, but not at the individual account level.

1. For **Proactive Response**, confirm that the setting is enabled. Proactive response is on by default and creates a service-linked role that allows AWS SIRT to ingest GuardDuty findings and open proactive investigation cases when threats are detected. For more information, see [Proactive response](https://docs.aws.amazon.com/security-ir/latest/userguide/proactive-response.html).
**Important**  
 The service-linked role is not automatically deployed to the management account. You must configure it manually for complete coverage. For instructions, see [Setup proactive response and alert triaging workflows](setup-monitoring-and-investigation-workflows.md). 

1. (Optional) Choose to pre-authorize AWS SIRT to perform containment actions on your behalf during active incidents. Supported containment actions include runbooks for compromised S3 buckets, EC2 instances, and IAM principals. If you skip this step, SIRT will provide manual guidance during investigations. For more information, see [Containment actions](https://docs.aws.amazon.com/security-ir/latest/userguide/containment.html).

1. Review the service permissions and onboarding configuration, then choose **Sign up**.  
![\[Review service permissions screen showing the permissions that AWS Security Incident Response requires to monitor findings.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Review_Service_Permissions.png)  
![\[Sign up confirmation screen for enabling proactive response monitoring.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Review_and_Sign_Up.png)

# Step 2: Configure your incident response team
<a name="configure-incident-response-team"></a>

 After you complete deployment, configure your incident response team to ensure proper notification and escalation during security events. 

**To configure your incident response team**

1. Open the AWS Security Incident Response console.

1. In the left navigation pane, choose **Incident Response Team**.

1. Add up to 10 team members. For each member, provide their name, title, and email address.  
![\[Incident response team configuration page showing team member details.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Teamates.png)

 Your team can include organization leadership, legal counsel, managed detection and response (MDR) partners, cloud engineers, and other stakeholders who need to be notified during security events. 

# Step 3: Understand case types and management
<a name="understand-case-types"></a>

 AWS Security Incident Response provides two types of cases to manage security events: proactive cases that are automatically created when threats are detected, and reactive cases that you create when you need assistance from AWS SIRT. You can also grant case visibility to external parties such as partners, legal teams, or subject matter experts. 

**Topics**
+ [

## Proactive cases
](#proactive-cases)
+ [

## Reactive cases
](#reactive-cases)
+ [

## Watchers
](#watchers)

## Proactive cases
<a name="proactive-cases"></a>

 The auto-triage feature continuously reviews high-volume alerts to filter out noise and focus on critical, high-impact threats. When a potential threat is detected, the system escalates the finding to an AWS SIRT responder for investigation. If the finding is confirmed as a genuine threat, a proactive case is created in the case management portal and all configured stakeholders are notified automatically. 

 No manual configuration is required for proactive cases beyond enabling GuardDuty and integrating third-party security solutions with Security Hub CSPM. The service also integrates with an AI investigative agent that correlates data from multiple sources to accelerate investigations. This capability is currently available for reactive, AWS-supported cases. 

## Reactive cases
<a name="reactive-cases"></a>

 AWS Security Incident Response provides a subscription-based case management portal where your organization works directly with AWS SIRT. AWS SIRT assists with security investigations and active incidents with a **15-minute service level objective (SLO)**. There is no limit on the number of reactive cases you can open. 

**To create a case**

1. Open the AWS Security Incident Response console.

1. Choose **Cases**, then choose **Create case**.

1. Choose a case type:
   + **AWS-supported**: Escalated directly to AWS SIRT for investigation and guidance (15-minute SLO).
   + **Self-managed**: Kept internal to your organization for tracking and documentation.

1. Complete all relevant fields. Include as much detail as possible to support an efficient investigation.

 Both case types use the same data fields. You can escalate a self-managed case to AWS SIRT at any time by choosing **Get help from AWS** in the upper-right corner of the case. 

![\[Create case screen showing options for reactive cases.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/reactive-cases.png)


 For detailed instructions, see [Create a case](https://docs.aws.amazon.com/security-ir/latest/userguide/create-case.html). 

## Watchers
<a name="watchers"></a>

 You can grant case visibility to external parties using Watchers or IAM policies. These options let you include partners, risk and compliance teams, legal counsel, or subject matter experts in your investigations. Watchers receive notifications for all updates to a specific case. IAM policies provide direct console access with least-privilege permissions. 

**To add a watcher to a case**

1. Open the AWS Security Incident Response console and choose **Cases**.

1. Open the case you want to share.

1. Choose the **Permissions** tab, then choose **Add**.  
![\[Case overview page with Permissions tab.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Overview.png)

1. Copy the pre-populated IAM policy and apply it to the appropriate IAM roles or users.  
![\[Watchers configuration page showing IAM policy.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Watchers.png)

**Note**  
 Each case includes a pre-populated IAM policy scoped to that specific case. This maintains least-privilege access for third-party MDR partners and investigation teams. 

# Step 4: Integrate with your existing tools
<a name="integrate-existing-tools"></a>

 AWS Security Incident Response integrates with your existing security tools and workflows to streamline incident response operations. You can configure automatic finding ingestion from GuardDuty, set up event-driven workflows with EventBridge, connect to ITSM platforms like Jira and ServiceNow, and collaborate with your SIEM and MDR providers. 

**Topics**
+ [

## GuardDuty findings and suppression rules
](#guard-duty-findings)
+ [

## Amazon EventBridge
](#amazon-eventbridge-integration)
+ [

## Jira, Slack, and ServiceNow integrations
](#jira-slack-servicenow)
+ [

## SIEM and external tooling
](#siem-external-tooling)

## GuardDuty findings and suppression rules
<a name="guard-duty-findings"></a>

 AWS Security Incident Response automatically ingests, triages, and responds to GuardDuty findings and Security Hub CSPM findings from third-party integrations. The auto-triage technology handles analysis as an added layer of detection and analysis. The service can create auto-archive rules in GuardDuty after escalating on a false-positive finding. Responders will always discuss this with you before implementing the rule. 

**To review GuardDuty suppression rules**

1. Open the GuardDuty console.  
![\[The GuardDuty console.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/guardduty-console.png)

1. Choose **Findings**.

1. In the navigation pane, choose **Suppression rules**. The **Suppression rules** page displays a list of all the suppression rules for your account.

1. To review or change the settings for a rule, choose the rule, and then choose **Update suppression rule** from the **Actions** menu.

**Note**  
 Organizations using SIEM technology will see reduced GuardDuty finding volumes over time, which improves both AWS Security Incident Response efficiency and SIEM performance. 

## Amazon EventBridge
<a name="amazon-eventbridge-integration"></a>

 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) enables event-driven workflows for AWS Security Incident Response. You can configure case activity to trigger downstream AWS services (Amazon Simple Notification Service, AWS Lambda, Amazon Simple Queue Service, AWS Step Functions) or external tools such as Jira, ServiceNow, Slack, and PagerDuty. 

**To configure an EventBridge rule for AWS Security Incident Response**

1. Sign in to the delegated administrator account for AWS Security Incident Response.

1. Open the EventBridge console.

1. In the navigation pane, under **Buses**, choose **Rules**.

1. Choose **Create rule**, complete the rule details, then choose **Next**.

1. Under **AWS service**, select **AWS Security Incident Response** from the dropdown.

1. For **Event type**, select the event or API call you want to match. You can edit the pattern manually to include multiple events.

1. Choose **Next**.  
![\[Event pattern configuration showing AWS Security Incident Response as the selected service.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/event-pattern.png)

1. Select one or more targets for your events, such as Amazon SNS, AWS Lambda, an SSM document, or Step Functions. Configure cross-account targets if needed.  
![\[Event pattern configuration showing targets.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/event-pattern-target.png)

1. Review and create the rule.

 To use pre-built partner integrations, check **Partner Event Sources** in the EventBridge console. Available partners include Atlassian (Jira), Datadog, New Relic, PagerDuty, Symantec, and Zendesk. 

![\[EventBridge partner integrations page showing available third-party partners.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Amazon_EventBridge_Partners.png)


## Jira, Slack, and ServiceNow integrations
<a name="jira-slack-servicenow"></a>

 AWS provides fully developed solutions for bi-directional integration with Jira, Slack, and ServiceNow. These integrations keep AWS Security Incident Response cases and your ITSM or ChatOps platforms in sync — updates in one system are automatically reflected in the other. 

 **Benefits of integration** 

 Integrating AWS Security Incident Response with your existing ITSM platform streamlines your security operations by centralizing incident tracking and response workflows. These pre-built solutions eliminate the need for custom development, allowing your security teams to maintain visibility across both AWS native and enterprise-wide incident management systems. By leveraging EventBridge for event-driven automation, updates flow seamlessly between platforms in real-time, helping make sure that security incidents are tracked consistently regardless of where they originate. This unified approach reduces context switching for security analysts, improves response times, and provides comprehensive audit trails across your entire incident response lifecycle. 

 For deployment instructions, see [AWS sample solutions for Jira, Slack, and ServiceNow](https://github.com/aws-samples/). 

## SIEM and external tooling
<a name="siem-external-tooling"></a>

 AWS Security Incident Response doesn't directly ingest findings from your SIEM. However, when you open an AWS-supported case, AWS SIRT responders analyze and investigate SIEM findings in parallel with your team. SIRT helps identify correlations across hybrid and multi-cloud environments and assists with scoping threat actor activity across providers. 

 AWS SIRT also collaborates directly with your MDR providers and third-party investigation teams. Tabletop exercises are available to help establish effective coordination processes before an incident occurs. 

# Appendix A: Points of contact and critical information
<a name="appendix"></a>

 Complete the following table and provide it to your AWS account team before deployment. This information enables AWS SIRT to reach the right people quickly during a security event. 


**IR and SOC Personnel Contact Information**  

| Entry | IR \$1 SOC Personnel: Role, Name, Email | Primary, Secondary Escalation Contacts | Internal, Known CIDR Ranges | External, Known CIDR Ranges | Additional Cloud Service Providers | Working AWS Regions | DNS Server IPs (if other than Amazon Route 53 Resolver) | VPN \$1 Remote Access Solutions and IPs | Critical Application Names \$1 Account Numbers | Uncommon Ports Commonly Used | EDR \$1 AV \$1 Vulnerability Management Tools Used | IDP \$1 Locations | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| 1 | SOC Commander, John Smith, jsmith@example.com | Primary | 10.0.0.0/16 | 5.5.60.0/20 (Azure) | Azure | us-east-1, us-east-2 | N/A | Direct Connect, Public VIF 116.32.8.7 | Nginx Webserver (Example Critical) \$1 1234567890 | 8080 | CrowdStrike Falcon | Entra, Azure | 

**To submit this inforamtion, complete the following steps:**

1. Complete the preceding metadata table with your environment information.

1. Create an [AWS Support case](https://repost.aws/knowledge-center/get-aws-technical-support) with the following details:
   + **Case type:** Technical
   + **Service:** Security Incident Response
   + **Category:** Other

1. Attach the completed metadata table to the case.