Getting started with AWS Security Incident Response | Amazon Web Services

Key Takeaways

Hello and welcome everyone. I'm Sejal Kotian and I'm accompanied with Vivek Shirvikar. We both are technical account managers at AWS. In this video, we will walk you through setting up the AWS security incident response service. In just a few minutes, you'll have a robust security monitoring system protecting your AWS environment. So, what is AWS security incident response? It's a fully managed security service launched at re:Invent 2024 that automatically triages security findings and provides you with direct access to the AWS security incident response team, known as SIRT. Think of it as an extension of your existing security operation center. The service helps you prepare for, respond to, and receive guidance to recover from security incidents like account takeovers, data breaches, and ransomware attacks. Key point for AWS customers. AWS security incident response is currently available at no additional cost for enterprise support and unified operations customers. Before we begin, let's cover what you need. It is required to have AWS organizations with full features enabled. That's the only hard requirement. It is highly recommended to have Amazon GuardDuty enabled across all AWS accounts and active regions. GuardDuty provides the threat findings that power the auto triage and proactive case creation. To evaluate your GuardDuty coverage, refer the YouTube video find your security blind spots with GuardDuty gap analysis linked in the description below. It is recommended to leverage AWS [clears throat] Security Hub CSPM for aggregating third-party security findings. You can check the available third-party tools that integrate with SIR through the Security Hub CSPM integration tab. For tools not natively supported through Security Hub CSPM, you can use Amazon EventBridge to route those findings into your incident response workflow. Let's begin the setup. Log in to your AWS management account. Search for security incident response in the console search bar. This takes you to the AWS security incident response landing page. Click sign up. You'll now see the central member account selection screen. Here is an important best practice. Delegate a security tooling account rather than using your management account. This aligns with the AWS security reference architecture for dedicated security accounts. Enter your security tooling account number. Select delegate. Click next. You'll see a prompt to continue sign up in the delegated administrator account. Next, sign in to the delegated administrator account to complete the process. Once logged in to your delegated administrator account, navigate to the security incident response landing page and click sign up. Select your home region. Choose the region where most of your AWS activity occurs. Since this is an organization-level service, you only need to enable it once per organization. Next, associate accounts. You can select coverage at the full organization level or at the organizational unit level. Note that you cannot select individual accounts, but you can target specific OUs. All accounts under selected OUs, including sub OUs, are automatically covered. Enter a membership name. Use what aligns with your naming standards. Next, add team contacts. Add the first two members of your incident response team. You can include up to 10 team members total after setup. These can be your security engineers, leadership, legal counsel, or even MDR partners. Add tags according to your organization's tagging strategy. Click next. Now, let's review the default permissions. When you sign up, the SIR service creates service linked roles across all AWS accounts, including the management account, to access your organizational units and establish the membership. It grants log access permissions, allowing internal AWS teams to review VPC flow logs, CloudTrail management events, and S3 CloudTrail events during incident investigations. And it enables proactive response permissions to ingest alerts from GuardDuty and Security Hub, apply suppression rules, and escalate critical findings. Confirm the option allowing the above discussed actions, then click next, review, and sign up. We have completed the onboarding steps now. I'm handing over to Vivek, who will talk about post-deployment configurations. >> Congratulations. Now that you have completed onboarding SIR, here are the next steps to maximize value. First, update your incident response team. Navigate to incident response team in the left navigation pane. Add up to 10 team members with names, title, and email addresses. These are separate from IM users and SSO roles. I highly recommend adding your MDR or MSSP partners as team members. Alternatively, you can add them as watchers on individual cases or apply the pre-populated IM case permission policy to their roles for least privileged access. Next, configure Amazon EventBridge and your ITSM integrations. EventBridge enables EventBridge architecture for security incident response, letting you trigger downstream services like SNS, Lambda, SQS, or Step Functions and route notifications to tools like Slack, PagerDuty, or Microsoft Teams. For Jira and ServiceNow, AWS provides fully developed solutions for bidirectional integration where case updates in SIR are automatically reflected in your tickets and vice versa. I have linked the step-by-step instruction for both EventBridge and ITSM setup in the description below. Once enabled, AWS Security Incident Response starts working immediately. The auto triage system ingests GuardDuty and third-party security of CSPM findings, analyzing each against your environment security perimeter of known good attributes like domain, CIDR ranges, IM principal, and expected behaviors. Over time, it creates suppression rules for bending reducing noise in your scene. When a finding can't be mapped to a known good activity, CERT investigates. If they confirm a threat or need more information, they create a proactive case in your SIR console and notify your incident response team via email. For AWS supported cases, an AI investigative agent activates automatically alongside cert engineers. It pulls evidence from CloudTrail, IAM, and cost explorer, correlates everything, and delivers a clear actionable timeline within minutes, not hours. Regardless of how case is created, cert team has a service level objective to acknowledge the case within 15 minutes. Behind the scenes, the service keeps getting smarter. Benign findings trigger updated suppression rules in GuardDuty and Security Hub, meaning fewer false positive over time. And you will receive monthly reports covering accounts monitored, findings processed, investigations conducted, and a detection summary for the period. And that's it. In just few minutes, you have enabled a fully managed security incident response capability with direct access to AWS security incident response team. To recap what you have now, automated triage of security findings from GuardDuty and third-party tools, proactive case creation when real threats are identified, direct access to cert within 15 minutes of SLO, a centralized case management portal, and integration capabilities with your existing ITSM and communication tools. Remember, security is a journey and not a destination. Start with these basics, get comfortable with the monitoring and case workflows, and then explore advanced features like containment actions and event bridge automation. For more information, check out the AWS security incident response documentation and the maximizing value with AWS security incident response blog post linked in the description below. Thank you for following along. Stay safe out there.