Find Your Security Blind Spots with GuardDuty Gap Analysis | Amazon Web Services

Key Takeaways

[music] >> Hey everyone, I'm Sejal Kothari and I'm accompanied with Vivek Shrivastav. We both are technical account managers at AWS. Are you drowning in security alerts, spending hours investigating GuardDuty findings only to discover many can be false positives? Today, I'm showing you how AWS Security Incident Response transforms GuardDuty from a detection tool into a complete incident response solution. First, let's understand why GuardDuty is critical. AWS operates on a shared responsibility model where AWS secures the cloud infrastructure, but you're responsible for security in the cloud. That means monitoring your accounts for threats like compromised credentials, unauthorized access, crypto mining, data exfiltration, and ransomware attacks. GuardDuty is your intelligent threat detection service continuously analyzing CloudTrail logs, VPC flow logs, and DNS queries across your entire AWS environment to identify anomalous and malicious activity. But, here's the problem. GuardDuty generates hundreds, sometimes thousands of findings. Your security team manually reviews each one, potentially suppressing all the low and medium severity findings. They investigate IP addresses, check if domains are legitimate, validate IAM principal activity, and determine if that EC2 instance behavior is normal or malicious. This manual triage process is exhausting, time-consuming, and expensive. Worse, while your team investigates false positives, real threats can slip through unnoticed. Enter AWS Security Incident Response, or SIR. Think of it as GuardDuty's intelligent triage and human-in-the-loop response layer. Here's how it works. First, SIR automatically ingests every GuardDuty finding and any third-party findings you send to Security Hub CSPM the moment it's generated. But, instead of sending everything to your team, it uses sophisticated auto triage technology to analyze each finding against your unique environment profile. It learns your normal behavior, your trusted domains, known CIDR ranges, ASNs, and other important metadata. When a finding comes in, SIR asks, "Does this match the customer security perimeter?" If yes, it automatically triages the finding. If no, for example, if something doesn't match your known good profile, SIR escalates it to the AWS SIRT team, which stands for Security Incident Response Team. They are our elite security experts who have handled thousands of real-world incidents. Now, here's where it gets powerful. SIRT team doesn't just send you an alert. They proactively investigate with you. The SIRT team analyzes the threat, determines scope, identifies impacted resources, and creates a proactive case in your SIR console with their findings. But, it's not just proactive monitoring. You can also open reactive cases 24/7 for active security incidents or investigations. You get a 15-minute service level objective. That means within 15 minutes of a potential threat, you have expert eyes acknowledging the case. SIR becomes an extension of your security operations center. Let's talk results. SIR is able to auto triage 99% of alerts and respond to the 1% of true potential threats for an organization. Security teams can stop wasting hours on noise and focus on strategic security work. And when real threats emerge, like ransomware, crypto mining, credential exfiltration, privilege escalation, you have AWS's best security minds investigating alongside you with access to logs and insights you may not have even enabled. SIR handles threats aligned with the MITRE attack framework, covering the full attack life cycle from detection and analysis through recovery. SIR doesn't replace your existing security stack, it enhances it. It integrates with third-party tools through Security Hub CSPM, including Wiz, Orca Security, CrowdStrike, Trend Micro, and SentinelOne. You can connect it to your ticketing systems like Jira or ServiceNow and route notifications through Slack, Teams, or PagerDuty using EventBridge. Ready to transform your security operations? Onboarding takes less than 10 minutes. Enable AWS Organizations, designate a delegated administrator, and you're done. GuardDuty detects, SIR triages, SIRT team investigates, you focus on what matters. Would you like to have a comprehensive security coverage across all your AWS accounts? Here's why GuardDuty via Organizations is the only recommended way to deploy, and let's understand how it creates the foundation for comprehensive security coverage. Your AWS security is only as strong as your least protected account, and right now you probably don't know which one that is. Let me show you exactly where the gaps are and why they keep coming back. Now, let's understand the invitation-based problem. Many organizations enable GuardDuty account by account using invitations, or have gaps where GuardDuty is enabled or appropriately configured. The result, inconsistent coverage with critical security gaps. New accounts, VPCs, and regions get missed. Security teams manually track which accounts have protection enabled. You're constantly chasing coverage across hundreds of accounts, updating configuration region by region. Every account and region present attack surface for your organization. One forgotten account becomes your weakest link, and the attackers will find it. This fragmented approach creates blind spot in your security posture that the threat actors actually attack. Here is the recommended solution. GuardDuty via AWS Organizations solves this completely. Enable it once from your management account using delegated administrator architecture, and every account in your organization, current and future, gets automatic GuardDuty protection instantly across all commercial AWS regions. New accounts automatically covered the moment they are created. New organizational units fully protected. Configuration changes applied uniformly across your entire organization. No manual invitation, no coverage gaps, no administrative overhead, no exceptions. This is organization-enabled delegated administrator the foundation for uniform security coverage across entire AWS environment. It's not just convenient, it's the security best practice which AWS recommends because it guarantees comprehensive threat detection coverage. With Organizations, you get guaranteed uniform coverage. Every account, every region, every resource gets protected. GuardDuty monitors CloudTrail logs, VPC flow logs, and DNS queries across your entire organization from a single pane of glass. You maintain complete visibility into security findings organization-wide. And here's a critical part, even regions where you don't actively deploy resources get monitored, catching unauthorized activity before it spreads. But, base coverage is just the start. GuardDuty protection plan let you extend threat-specific detection to your most critical workloads. For example, S3 malware protection for your data lakes, EKS runtime monitoring for container environments, RDS login protection for your databases, Lambda network activity monitoring for serverless. These protection plan can also be auto-enabled across your entire organization through delegated administrator, so every account gets the right level of coverage for the right resources automatically with zero gaps. This organization-wide GuardDuty deployment becomes the foundation for AWS Security Incident Response. Security Incident Response automatically ingests findings from all your GuardDuty-enabled accounts and regions, providing comprehensive auto triage and expert investigation across your entire AWS footprint. In order to understand how to enable GuardDuty via Organizations to achieve comprehensive protection, zero gaps, and complete visibility, I'm sharing the link in the description. In the last section, let's understand how to confirm your GuardDuty coverage. Let me show you how to identify your security gaps using AWS Cost Explorer. Now, let's understand the visibility problem. Here's the challenge. GuardDuty is enabled across your organization, but do you actually know which accounts and regions are protected? Most security teams assume they have full coverage, but the reality is different. Accounts get created, regions get overlooked, and suddenly you have blind spots in your security monitoring. The problem here is that there is no simple dashboard showing you exactly where GuardDuty is and isn't running. Now, let's discuss how to identify the coverage map. Use AWS Cost Explorer to visualize your GuardDuty coverage. Open Cost Explorer in your management account and set your time range to last 30 days. Filter by service and select GuardDuty. Then, group by linked accounts to see which accounts have GuardDuty cost. You can export this as CSV and create an analysis by region, or create a second Cost Explorer view grouped by regions to see regional distribution. What you will see is a powerful, complete map of where GuardDuty is generating cost, which means where it's actually running. Every account and region combination with GuardDuty charges show active protections. In order to identify and close the gaps, you can cross-reference this Cost Explorer data with your complete account and region inventory. Accounts missing from Cost Explorer results indicate no GuardDuty protection. But, remember, Cost Explorer data can take 24 to 48 hours to appear, and accounts with zero usage during the selected time frame won't show cost. For most accurate coverage verification, also check the GuardDuty console directly in your delegated administrator account to see which accounts and regions have GuardDuty enabled. We have built up the knowledge, and now I will walk you through step-by-step in this demo. Let's begin the setup in your AWS management account. Let's start by searching Cost Explorer in your console search bar and launch Cost Explorer. Set the date range to last 3 months and click apply. Granularity will be monthly. Under filter, select the service drop-down. Search and select GuardDuty. Click apply. Under group by, select linked account. Cost Explorer now displays GuardDuty spend broken down per member account. Any account which is not incurring cost for GuardDuty means GuardDuty is not configured or not enabled in that account. There is a coverage gap. Those accounts have no threat detection active and should be investigated and remediated. Now, let's understand how to view cost per region. Change group by dimension to region. Cost Explorer now shows GuardDuty spend per AWS region. Similar to accounts, you can locate the regions where you have not incurred cost, which indicates GuardDuty is not enabled in that region. If you have workloads running there, those resources are unprotected. Use this view to identify blind spots across your AWS footprint. Now that we have identified where GuardDuty is and isn't running using Cost Explorer, let's talk about how to turn that data into shareable executive-ready report. This is especially valuable when your organization has hundreds of AWS accounts, and you need to communicate coverage status to leadership, security auditors, or stakeholders who don't have console access. We will use the AWS Cost Management dashboard to do this, and it takes just three steps. You will select dashboard from the left navigation menu under AWS billing and cost management console. Select create dashboard. Name the dashboard as per company standards. Under add widget drop-down, select predefined widget. Drag monthly cost by service widget to dashboard. Set the service filter to GuardDuty. Set group by dimension to linked account or region, depending on whether you want account level or regional visibility. For this example, I'm using region. Set the date range to the last 3 months. Set granularity to monthly. Once your dashboard is configured, you can export the entire view as PDF or CSV, which is perfect for board meetings, quarterly business reviews, or strategic planning sessions. In today's session, we covered GuardDuty and security incident response, the value they bring to your TDR landscape, how properly configuring GuardDuty across your AWS enterprise, and understand where your gaps in coverage exist by simply using Cost Explorer. I hope you enjoyed today's video, and always remember, security is a journey and not a destination. >> [music]