AWS re:Invent 2025 - AWS detection and response innovations that drive security outcomes (SEC323)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - AWS detection and response innovations that drive security outcomes (SEC323)

In this video, Marshall Jones and Ryan Holland present AWS detection and response innovations, focusing on three core services: Amazon GuardDuty for threat detection with Extended Threat Detection capabilities and malware protection for AWS Backup, Amazon Inspector for continuous vulnerability scanning across EC2, ECR, Lambda, and code repositories with AI-generated remediation patches, and AWS Security Hub with newly GA-launched exposure-based findings that correlate threats, vulnerabilities, and misconfigurations into unified risk assessments. They demonstrate Attack Path visualization, Asset Inventory features, simplified per-resource pricing bundled as Security Hub essentials, and integration with AWS Security Incident Response service featuring Agentic AI-powered investigation. All findings use OCSF format for standardized security data across hybrid environments.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: AWS Detection and Response Innovations Overview

All right, welcome everybody to AWS detection and response innovations that drive security outcomes. My name is Marshall Jones. I'm a Security Solutions Architect at AWS. Day to day, I focus on our detection and response services that we'll be discussing, doing go-to-market work, helping customers operationalize and scale these services, as well as gathering great feedback from our customers to drive service innovation going forward. So let Ryan introduce himself.

Sure, yeah, I'm Ryan Holland, and I lead the GuardDuty service team. All right, so this is a talk that has happened at re:Inforce and re:Invent in the past where we go over all the new launches and innovations in our detection and response services. So if you're returning to this talk, welcome. If you are new, also welcome.

What we're going to cover in this conversation is an overview of our detection and response portfolio. What are these native services? How do customers normally use them? We're going to go through a number of different demos. We're going to talk about our new features and capabilities. We will also try and save some time at the end if folks have questions or want to connect afterwards. We can do that as well.

So we're going to get started with the problems that we see quite often. Like I said, day to day, I talk to a lot of different customers about the different security challenges that they're trying to overcome at their organizations, and these ultimately get lumped into a few different things. Mainly, a lot of fragmented visibility. Good security response and security operations are usually built on somewhat of a data problem, unfortunately, for some of us security practitioners out there. This is having visibility and having access to the data that you need to have visibility into what's going on in your environment, what might be a risk, what might be just a benign vulnerability or something like that, and really understanding what you actually have out there so you know what to make decisions on, what to go respond to, and what to go remediate.

Some of this different information that we get over time has limited context across the whole environment. So, kind of leading into our third challenge as well is disconnected security signals. Either the signal doesn't have much context, and we really need more information to truly understand what a different security signal is telling us, and then also not having specific signals together. So there's a lot of jumping between different tooling and a lot of putting different pieces of the puzzle that don't really fit together to try and understand what the overall picture is. And then ultimately what that causes is a delayed response. Security is obviously one of those things that folks just want to work so they can focus on their business, and when there's delayed response and delayed remediation, that is obviously something that is a challenge for security teams as well as business owners and something nobody really wants, right?

So ultimately, what are the things that we want to accomplish based on these challenges and based on the business outcomes that we want to drive with these native detection and response services? So first, protecting your workloads against security risk, right? Pretty simple. You have different workloads, different applications on AWS, different infrastructure. Protection for those is of the utmost importance. Centralizing monitoring and enhancing visibility into potential risk. So what we mean by that is, how do we do this in one place and not in a bunch of different places to make this easier for folks to come to the conclusions that they need or the insights that they need to derive from their data and their security tooling in a central spot?

Ultimately, we want to investigate and respond to these security issues quickly. So going back to the challenge with delayed responses, how can we do this as quickly as possible across the incident response or security operations lifecycle, right, all the way from a detection to an investigation to a response and a remediation? And then we are quite aware that customers are in multiple different environments. So how do we do this across hybrid environments and hybrid different applications and do this using AWS native services in a single place?

Detection and Response Portfolio: Three Core Pillars

So if you're familiar with our detection and response services, they really fit into a few different categories. So the first category being threat detection and workload protection. This is where a number of different things happen, really behind the GuardDuty service.

This service brings a wealth of knowledge across AWS, drawing from our different threat intelligence sources and signals from our large customer base to understand where threats might be happening in a customer's environment utilizing this tool. We also identify what the new and ever-evolving threats are that customers need to be looking out for, ultimately making this easy for them to do at scale. Ryan's going to jump into what this looks like and how people utilize this in more detail.

The second piece is vulnerability management. We really see this in a couple of different tools. If you're familiar with Amazon Inspector or Security Hub CSPM, we can see automatic discovery of misconfigurations of AWS resources. For example, you might have some EC2 instance that doesn't have EBS volume encryption, or you've got public SQS queues. This may be specific vulnerabilities that we'll see in packages and operating systems. They might be code vulnerabilities in Lambda functions, or it might be vulnerability discovery through CI/CD pipelines. This is some of the detail that we'll jump into.

Finally, risk management. We have some great new information to share with you all here. Risk management is obviously something that folks want to evaluate across their environment. One of the things that we talk to customers quite often about is how do I determine what I should go prioritize first? What is my biggest risk in my environment? What we want to do as far as the risk management pillar in Security Hub, which we'll talk about that was launched at general availability at the keynote yesterday, is to understand what is our risk posture across our environment. What should we go respond to first? What is the context across this environment to understand why we should prioritize that first? And ultimately, correlate this risk posture across our environment.

Amazon GuardDuty: Fully Managed Threat Detection Service

So with that said, we'll jump into the first service and I'll let Ryan take over. Awesome, thanks Marshall. Yeah, so as Marshall mentioned, our first service to talk about is Amazon GuardDuty, which if you're not familiar is our native threat detection service. It's fully managed. It uses a variety of different machine learning techniques in order to identify threats that could impact your workloads, your identities, including things on containers, as well as RDS databases and Lambda functions as well.

One of the most important things about the way that this works is it is fully managed. You don't have to feed any of the data to us for us to be able to process it. We manage all of this on your behalf behind the scenes and it helps customers detect suspicious activity or malicious activity. We have added a bunch of neat features that really help analysts get to the bottom of what is going on that's caused an alert to be created with our Extended Threat Detection, which we'll talk about in detail. That gives you a really deep insight into the activity that we're observing within your environment.

We have some features that we'll talk about that can assist with preventing or detecting the presence of ransomware. We centralize this across your entire AWS estate. Typically most customers don't have just one or two accounts. You have a large number of AWS accounts in most enterprises. Using the AWS Organizations integration, we have a function called delegated administrator which allows the organization admin to delegate control of the GuardDuty service to a security-owned account. That security operator then can control and configure which features they want to enable on which accounts they want those enabled on.

There's even the ability to just configure it for auto-enable. So if a new account is created in the organization or if a new account gets added to the organization later, you don't have to go and keep track and bootstrap that account any longer. With the Organizations integration and the auto-enablement feature, we will just automatically see there's a new account, it's added, and that you've told us that all new accounts should have this particular security configuration. We'll automatically apply that for you. We also see that the threat detection here helps customers satisfy several different types of compliance requirements including PCI DSS.

So I just want to take a minute to talk about how do we do this. The first part is getting access to the data that we need in order to identify potential threats. From a data perspective, we break these into two categories. The foundational data sources are always on for all customers that enable GuardDuty, and these are VPC Flow Logs, DNS query logs, and CloudTrail. Very important to point out, you don't have to turn these on. We get access to all of these log sources behind the scenes directly through integrations from the core service teams that produce them.

This has a couple key benefits.

One is cost. If you don't otherwise have a reason that you would need to store and actually get your flow logs, you don't have to turn those on. We still get to see them. It also has some security benefits as well because if a malicious actor got access to an account, they can't go and disable a log source and prevent us from getting access to that data.

So in addition to those foundational data sources, we also have a host of what we call protection plans. These are add-ons that you can enable either across the entire organization, or you can also pick and choose individual accounts where you want them on. One of the important things I always like to point out is each of these protection plans, as well as the foundational data sources, comes with a 30-day free trial, so you can turn them on. And if you have an account that, for example, isn't using EKS and you turn on the EKS protection, there's no charge for that being enabled until an EKS cluster shows up. So sometimes we see customers turn them on even for services they're not actively using.

And once we have all that data, we look at it in several different ways. So there are multiple different ways we can detect threats. Some of these threats we can detect what we call stateless. We can look at a single event and say this is not good. A good example of this would be threat intelligence-based detections. If you're querying a domain that we know is bad, that's bad, and we don't need to see really anything else in order to give you a finding for that.

And we get our threat intelligence from several different places. We partner with third parties, so we partner with CrowdStrike as well as Proofpoint. We collect that data, and you don't need to have a license for that. We apply that to the flows and the DNS query requests within your accounts. We also generate a large amount of threat intelligence internally that we expose to customers through GuardDuty. So the Amazon Threat Operations and Defense team that runs our honeypots across the globe, we get a lot of great threat intelligence from them that is not only really good quality threat intelligence, but it's also very relevant because this is threat intelligence that is actually targeting our customers because they're hitting our honeypots.

We also get threat intelligence from our internal security team, which is looking at and trying to protect Amazon as a whole. And again, we externalize all that by applying that as threat intelligence to the workloads for GuardDuty customers. We also use several different machine learning mechanisms to detect behavioral anomalies. You'll see this when we look at things like S3 access or EKS audit logs, as well as RDS logins, where you can't just look at a single event and decide whether or not it's good or bad. We have to understand what is normal for a particular user or a particular bucket, and then build the baselines and understand whether or not the activity that we're seeing is generally consistent with what we'd typically have observed in the past.

And then in other cases, we use some learning algorithms that look for other types of baselines that aren't really machine learning based but still look at previous behavioral activity in order to look for deviations. And then when we determine that there's something that warrants sending you a finding, we first take that information and we try to put as much context into these findings as we can. So in addition to all of the data that was in the source log event that generated a finding, we also expose additional context that we can gather from our backend.

So for example, on the machine learning findings, we don't just tell you that this user did something that's unusual. We also include all the information that we have about what we expected to see, so what was the usual activity that we observed and then what were the specific things that we saw that were unusual in this particular case, which can really help the kind of first-line responders look at and determine whether or not it's unusual but benign or unusual and worth additional investigation. We also add tags for resources that have tags. We'll collect all the tag data and again just trying to give as much context and as much information as we can gather about the resources that are impacted and include those in the findings to make them more actionable because they have additional context.

And all of these findings now also go through our Extended Threat Detection analysis, and I'll dive more into how that works here in a minute. And then all of our findings are obviously available in our console, but we also send them out through EventBridge. So through the EventBridge integration, you can send them to a downstream SIEM or your SOC or other automated actions that you might want to take. We also send them to Security Hub, which Marshall will show you here in a little bit, so they can be correlated with other signals that we see from within your accounts. And you can also investigate them with Detective or send them through to other partner tools as well, again through the EventBridge integration.

GuardDuty Malware Protection: Agentless Scanning for EBS and S3

The last capability that we have is our malware detection. From a malware perspective, we allow customers to scan their EBS volumes. This is all done without any agents, so there's no agents that need to be installed and no third-party software to license, and we do this in two different ways.

You can simply ask us to scan an instance and we'll scan all the volumes, but more generally what we see is customers enabled to scan on detection. We have gone through the list of finding types that we have in GuardDuty. We've identified those that are more relevant for the presence of malware. So if we generate one of those findings behind the scenes, we'll snapshot the volumes for that instance, copy them to a secure location, and perform a malware scan, and then report back in the presence of a finding. We'll also update the source finding that created the need for that scan as well.

We also offer malware scanning for S3, so this was a feature that a lot of our customers were asking us for, and it's really, especially right now, targeting the use case of untrusted uploads. We have a lot of customers who maybe have a web app and their customers are sending them files or uploading documents, or maybe they're accepting content from a third party. Before you ingest that into your application, you want to make sure that there's no malicious content in there. So you can tell us which buckets need to have this protection on, and anytime an object gets placed in that bucket, we'll immediately go and scan it.

We will tag it with the result, so you can configure this in your pipeline such that none of your applications can access objects that have been identified as having malicious content to prevent that from getting into your data pipelines. If the file is clean, we'll mark it as no threats found, and then you can go ahead and use that as a signal to move it along through your application. So I want to talk just a moment about those different protection plans. Again, these are all the different expansions that you can add, and they add more context and data into the GuardDuty system as well, which will become very important in a minute when we start to talk about the Extended Threat Detection feature.

GuardDuty Protection Plans: Enhanced Visibility Across Workloads

S3 Protection enables us to take visibility into S3 data events. From a CloudTrail perspective, that's part of the foundational data sources. We see the management events, and that would include some S3 events like list buckets, for example, but it doesn't include the data events like get object, put object, or delete object. So what is the actual activity that a user is performing within a bucket? With the S3 Protection turned on, we get access to all of those logs, and again, you don't have to turn the data events on yourself. We get them directly from S3 on the back end.

We use this to build profiles of normal activity for a bucket. Is a particular bucket normally used as an input bucket where it's mostly writes? Are we suddenly seeing large data being exfiltrated from it? We also look at the principals and which buckets they tend to interface with and how they do those actions in order to identify potentially anomalous behavior. We also have our EKS Protection, so this gives us access to the EKS audit logs, and this is kind of similar to your CloudTrail for EKS. It's the control plane activity.

What types of pods are being created? What types of activity is taking place on that EKS controller itself? Again, this is in order to identify misconfigurations like making it publicly accessible or also unusual activity like suddenly we're seeing privileged containers that we haven't seen in your account previously. That could be an indication of an identity compromise. We have our RDS Protection, so this looks at anomalous behavior for logins to the databases themselves. This is really on the data plane of the database and allows us to profile what are the users, what databases do they normally log into, where do they log in from, and other activity of that nature to identify logins that seem suspicious or unusual.

We have our Lambda Protection, which gives us visibility into the network connections for your Lambda functions. Whether or not maybe you've downloaded a third-party library that has been compromised and maybe your Lambda functions are reaching out to command and control or to crypto mine, this will give us visibility into the flow log data in order to identify those malicious network flows. This works both for VPC-enabled as well as non-VPC-enabled Lambda functions, so we'll get that visibility regardless of the networking configuration that you've used.

The last one is our Runtime Monitoring. Runtime Monitoring adds an eBPF-based agent to your compute workload in order for us to get even more context and visibility into the activity that's taking place.

This is especially important for containerized workloads. If we're just looking at the instance level and you've got 100 pods on an instance, knowing the flow log data isn't super helpful. This will give us visibility down to the process ID as well as all the lineage of the process that was creating any flow data or looking up any domains as well as executing processes.

We support all of our major compute types. So we support Fargate, we support ECS on EC2, EKS, as well as EC2 instances by themselves. And we built this in a way to make it fully managed and really lightweight. It's eBPF-based, so the agent itself doesn't have any kernel driver requirements. But in order to make it even more lightweight, we designed this in such a fashion that the runtime sensor itself doesn't have really any rules or logic built into it.

It's really collecting all this data and it streams it to our backend through a VPC endpoint, and this allows us to have a lot more computationally expensive rules and detection content on the backend because it's on our compute. It also means that you never have to worry about whether or not you have an updated rule set because all of those rules are on our backend. We can push an update for an emergent threat and every single one of the millions of agents out there automatically have that protection, so we're able to detect that very quickly.

We can do this deployment for you in a lot of cases. So for EKS, we have a direct integration on the backend with the EKS service that allows us to identify all EKS workloads within your account. Whenever there's a new cluster that's created, we'll create a managed add-on that will add a daemon set to all of your hosts and make sure that those sensors are running.

For Fargate, your developers don't need to make any changes to their deployments. If the GuardDuty Fargate runtime is enabled, when they submit a deployment just as they would normally, Fargate will see that the security admin has chosen to enable runtime and it will inject a sidecar container into that deployment automatically, making it very easy and seamless for them to get that protection. For EC2 instances, we leverage Systems Manager to affect those deployments as well.

Extended Threat Detection: AI-Powered Multi-Stage Attack Identification

All of these also create additional signal for which is one of our more recent launches, which is Extended Threat Detection. We originally launched the Extended Threat Detection at this last re:Invent looking at two key data sources, so the CloudTrail data source and the S3 data source, and we had two findings. One was compromised credential, one was compromised data, depending on which data source was contributing more to the logic.

What we're doing here is we're taking these input signals and findings, and we're applying some machine learning and AI to those in order to identify whether or not it looks like a multi-stage attack that is coming from multiple different data sources and also spanning lots of different events. We're also looking at and adding additional signals that maybe aren't findings, so we have this concept of weak signals where there's something we know about an IP address or a domain and it's not necessarily enough by itself to generate a finding. But when we look at that in hindsight with other information that's now come in, we can actually apply that to that and then again raise the severity on that.

When we generate these findings, they come with all of the context around which MITRE tactics and techniques that we saw, as well as all the resources that were involved, all the identities that were used, and a timeline that shows you when the attack started, when it ended, what were all of the actions that we saw in between, as well as a human-readable explanation that should allow your incident responder to very quickly understand what resources were impacted and why we felt that this needed to generate this finding.

So a couple of things about the Extended Threat Detection. First of all, there's no additional cost for this above and beyond the GuardDuty service and those protection plans that you have turned on. Again, it's completely integrated. We also add those additional weak signals to these models in order for us to really enrich the output, and we use a lot of the data that we have visibility to about what we're seeing threat actors in AWS customer accounts doing in order to train a lot of these models, and this allows us to quickly update these to identify new and emergent threats.

When we send out these findings, they just come as a new finding type, so the finding types start with the word attack sequence, and this allows you to consume this just as you would your other finding types too. So if you have existing workflows or existing integrations, these findings will simply go to them as well.

Earlier this year at re:Inforce, we launched the compromised clusters for Amazon EKS, which combined CloudTrail, S3 data events, as well as EKS audit logs and EKS runtime data. Then yesterday during Matt's keynote, we launched the final two of these attack sequences, which are our compromised compute workloads that look for compromised EC2 instances, as well as compromised container workloads for Amazon ECS. For ECS, it supports both ECS on Fargate and ECS on EC2.

One of the other announcements that we made actually in the road to re:Invent just a little over a week ago was the launch of GuardDuty Malware Protection for AWS Backup. As I mentioned before, we already had malware protection for EBS and for S3, and what this adds is the ability for you to seamlessly add native malware detection for your AWS backups, both for EBS as well as S3. This can be enabled by checking a box with no additional software to buy or license and no additional compute required to do this. It also allows us to automatically scan new backups as they're created, and from a cost perspective, we do incremental scanning once an additional scan has been made. Very importantly, you can also do on-demand scans at any time if you want to rescan something with the latest virus definitions. You can also have it so the scans run on restore to make sure that before you restore any of your content, it's been scanned with the latest malware definitions as well.

GuardDuty Feature Demonstrations: Attack Sequences and Backup Protection

This can be integrated into a workflow also to prevent an infected backup from reaching your air-gapped vault, for example. In this case, we have a backup that's being backed up from the resources, and as we're performing that scan or if we're performing incremental scans on the data that changed, we will mark it as infected if there's malware. That can trigger a result where you can say you don't want this to get into your air-gapped vault to make sure that it doesn't get committed and that you don't accidentally back up infected content.

With that, I will show you what a couple of these look like. Again, as I mentioned, this is the EC2 compromised instance group, the new Extended Threat Detection. The first thing you'll notice is we give you a start and stop time. This finding can be continuously updated if we see additional activity. This same exact attack sequence will get updated with a new end time as well as all the new data, so it can be a living finding if that activity is still continuing. We'll tell you what were the different types of resources, namely in this one we had some EC2 instances that all shared the same instance profile. We'll tell you what instances we saw the activity on and then the MITRE techniques and tactics that we saw along the way, as well as some of the data around the networks that were involved and whether or not there was malicious processes or malware that was identified in this process as well.

All of this will show you the MITRE tactics in a nice chart so you can see what were the different types of attacks that we saw. Over on the right, you can see the full timeline starting from the first event that we saw that we correlated to this attack and then all the way down to the end, including which processes were involved, if there was a process ID, if there was runtime data, just to give you as much context as to why we felt that this was likely a compromised instance.

I also wanted to show you real quick what the S3 backup looks like. If you were to try to back up a piece of malware, not only do we show it in the AWS Backup console so the backup user can be aware that there was some malware identified, but it will also generate a finding on the GuardDuty side so the security team can also get visibility into this. It will show you information about what the backup vault was and also what was the malware that was found. In this case, we used a test EICAR file.

Lastly, one other launch that I did want to talk about that wasn't in our keynote but I think is also very cool and our customers really like is that we had a feature in GuardDuty for a long time called suppression rules. The concept of a suppression rule was if there was activity in your environment that was normal for you and you would like us to stop telling you that we're looking at it, even though it might trigger one of our rules, you can create a suppression rule. The suppression rules previously required exact matches though, so we've added some additional flexibility to this feature where you can now use wildcards. That's really useful in a lot of cases where you can use either a question mark or a star or not matches. You can say this matches a string with a wildcard or not matches.

These rules provide additional flexibility in creating configurations that help tune the output we're sending you in our findings. Now I want to move on to talk a little about Inspector.

Amazon Inspector: Continuous Vulnerability Assessment for Cloud-Native Applications

Inspector is a vulnerability assessment tool built specifically for cloud-native applications. Unlike a traditional enterprise vulnerability scanner where you schedule scans, we do continuous scanning and support scans across many different cloud constructs. With EC2, we also support Amazon Elastic Container Registry. If you're pushing your containers to ECR, they can be scanned on push, and your developers will even get notified of this as well. When there's a vulnerability identified in ECR, we also notify the developer that this has happened so they can take action. We can also support scanning of code, including Lambda function code as well as code repositories that we'll talk about more in a minute.

This helps you identify the software vulnerabilities that exist across your cloud platform as well as unintended network exposure. One of the other things that Inspector does is it will look at network reachability, and we use some automated reasoning. For example, if something's behind a load balancer, it might not have a public IP, but we can deduce that it is actually publicly accessible if it's behind a load balancer that's publicly accessible. This helps you understand which of your resources are on the public internet. We use network reachability as well as other context that we have around things like whether it's actively being exploited in the wild. If we know there's an exploit available and we're actually seeing it being exploited, we will use that context to help prioritize remediation.

One of the other things that we'll use for prioritization is whether it's in use. This is especially important from a container workload standpoint. If you have a lot of containers in a container registry, odds are you're going to have vulnerabilities in some of them. All of those are things you probably want to fix eventually, but the ones you probably want to fix now are the ones that are actually being run on your ECS or EKS workload. If you're using ECS or EKS, we will not only show you the containers in the registry that have vulnerabilities, we'll show you which ones are being used and use that to help prioritize which vulnerabilities you should address first.

We also have a lot of features that really help our customers shift left into the development cycle. First of all, there's an API that you can use to call in your CI/CD pipelines that will allow you to detect the vulnerabilities in the build process and then block the build. We also have integrations with Amazon Q Developer that will allow you to notify your developers as they're writing code if they're about to import a vulnerable package, for example. You can bring that all the way to the developer before the code's even committed or if it's in the pipeline as it's getting built in the CI/CD pipeline. The idea being we want to prioritize identifying the most impactful vulnerabilities you have in your running workloads, but ideally if we can stop a vulnerability from ever reaching production, that's obviously the best case.

We use Systems Manager to do the continuous scanning for EC2 instances. However, if you're not using Systems Manager, we can still scan your EC2 volumes agentlessly as well. For our code scanning with Lambda functions as well as code repositories, we don't just tell you there's a problem. We'll use generative AI to generate a remediation action, including a patch that you can download and just commit that will fix the vulnerability. I'll give you an example of how some of these work here.

This is an example of a Lambda function that has a vulnerability, and in this case, this is a vulnerability for log injection. You can see in this case, we don't just tell you which function it is and why we think this is a problem. We'll point you to the line of code specifically that is causing this vulnerability. We'll give you an explanation of why we think what you've done here is not a good idea, as well as a recommended fix. Here's the change you can make. You can download this patch and just commit that, and it'll fix that vulnerability for you.

Similarly, we support integrating with third-party code repositories as well. With the same idea, we will scan your code in your GitHub environments and scan not just the code, but also infrastructure as code. If you have CloudFormation or Terraform templates, then we can look at those and identify potential vulnerabilities in those.

For example, in this case, this Terraform will create an EKS cluster that will be accessible to the internet. It's not usually a great idea. So we'll show you exactly where in your Terraform we think you've made this mistake and give you the recommended fix, again with a patch that you can just simply commit and apply and then make the vulnerability go away. With that, I'm going to hand it back over to Marshall.

AWS Security Hub: Unified Security and Risk Management Solution

All right, so we've talked about vulnerabilities, we've talked about threat detection. Now we're going to go into risk management. In this space, we'll discuss Security Hub. So this is something that we launched GA in Matt's keynote yesterday. Security Hub is our unified security solution. Really what we are working backwards from here is some of these different inputs that you see on the left side like our threats and our vulnerabilities. We also have things that we didn't cover such as Security Hub CSPM. This is the configuration of AWS resources, what might be misconfigured, not leading to the best practices of how you would configure different resources in the most secure way.

There's also other things like the network exposures from Inspector, sensitive data from Amazon Macie that you can discover in Amazon S3, as well as Access Analyzer that can do things like tell you that you've created a trust policy that lets somebody outside of your organization assume a role or helps with understanding when policies are not configured to be least privileged. So bringing a number of these different signals into one place so that folks can understand what is my risk posture across a number of different things. So not just, hey, I have a threat here or I have a vulnerability here, but let's bring these things together and understand what resources are creating the most risk in our environment that we should go address first.

So if you think back to some of those challenges we went over in the beginning about, you know, where do I prioritize my time, how do I take signals from various tools and bring them together, it's ultimately what we want to accomplish so folks can respond more quickly, respond across their organization with the correct prioritization. So as we introduce Security Hub, there is a number of different components that we're helping customers with here. So once again, unifying the security operations across your organization with Security Hub, as you'll see in a minute, we'll go through in the console.

This is also helping with some of those deployment capabilities. So before, GuardDuty and Inspector and Security Hub CSPM are things that you would go configure individually across different regions, across your organization. Now it was easy to do from an account standpoint, but they were still individual in the nature of deployment. With Security Hub, we're introducing the ability to be able to configure everything from one central location, and then that way we can have that risk context brought in together and prioritize as well as being able to streamline the response.

So now that we have all of this information, we have different integrations with different ticketing services such as Jira and ServiceNow, as well as integrations with Amazon EventBridge with all these findings where you can create your own response actions if necessary. Maybe that's tagging some sort of instance, maybe that's actually making some sort of mutating action to remediate what's going on. So you'll see some of the key capabilities that we are introducing in Security Hub. The first one being these exposure-based findings.

So we had previously had Security Hub CSPM findings, we have GuardDuty findings, Inspector findings, Access Analyzer findings. When we bring these all together to create a risk-based finding, that is what we're talking about when we're talking about exposure findings. Another capability that we're introducing in Security Hub is Attack Path. So we actually see in a visualization of the interconnected resources and for example, like the openings between them. So say for example, you have an internet gateway that has certain ports open, maybe it's just all ports open to the world.

We can trace that back to our EC2 instance that's got vulnerabilities, it's got overly permissive instance profiles associated with it. It has access to sensitive data in S3, and you can see visually all of this different information and how it's all interconnected. Another key functionality in Security Hub is Asset Inventory.

One of the things I've always heard as a security professional is that you can't protect what you don't know exists. Coming back to that data problem I talked about earlier, we're introducing an asset inventory that allows you to understand what exists in your environment and across your organization, whether that's five accounts or five thousand accounts. You can see all the different assets, how many different EC2 instances and IAM roles you have, and what findings are associated with each one.

Now you're not working backwards from a finding and saying, "Okay, there's this one finding associated with my EC2 instance. I wonder what else is associated with it, like what other problems does it have?" Instead, you can work backwards from an actual resource. You can filter by which resources have the most different findings, whether it has the most vulnerabilities, GuardDuty findings associated with it, Security Hub CSPM findings, and so on. This is very powerful from an asset inventory perspective, allowing you to work backwards from the resource instead of working backwards from a finding, depending on the different use case and investigation scenarios.

Ultimately, with this correlation and these different signals helping with the triage, we're getting you closer to the answer you need. You can say, "Here's what I need to go remediate, here's who I need to contact, who has access to these resources." Instead of you putting all these pieces of the puzzle together and then going to a response, we're putting those pieces of the puzzle before you. That way you can get to your decisions faster, get to your learning faster, and we're also helping that through those integrations with things like ServiceNow and Jira. With that said, I'm going to show you what this looks like.

Security Hub Deep Dive: Cost Estimation, Simplified Pricing, and Console Walkthrough

Another thing that we didn't touch on in the slides yet is the cost estimation. Obviously, anything that you do in the AWS console, from enabling a service, a lot of times has a cost associated with it. One thing we've heard from customers is, "Hey, I need to know how much this is going to cost before I turn it on. I might need to get approvals from my finance department." Now, with all of these different services, everything we've talked about to this point, they all have different free trials. Those free trials might be fifteen days for things like Security Lake and Inspector. They might be thirty days for things like GuardDuty and Security Hub CSPM.

All of those different services have usage pages, so you can see exactly what that service would cost you during that free trial and you can have an exact estimate. With the cost estimator that we're introducing in Security Hub, this is an ability to create an estimate based on what we can see from Cost Explorer in your environment. Based on historical patterns, which obviously is not exactly a projection out to the future, but based on historical patterns, this is what it would cost for you to turn on this service.

One of the other things that we've introduced here is simplified pricing. Before, if you turned on GuardDuty, it had a line item associated with it, different protection plans associated with it. If you had Security Hub CSPM turned on, it has line items, and it became kind of complex pretty quickly. There are a number of different line items that you need to decipher to understand how much this is costing you in total.

With this simplified pricing, we're essentially bundling what we see customers normally use together. We have this showing in a couple of different packages. Security Hub essential capabilities includes Security Hub CSPM, Inspector scanning for things like CIS and ECR and Lambda and EC2, also GuardDuty foundational data sources, and Malware Protection for EC2. One of the different components here is to be able to create these rich exposure-based findings, getting that data into Security Hub to be able to create those findings. This is kind of the baseline amount of services that is needed to do that.

With that, we've also gone to an easier way to estimate this. It's now per-resource-based pricing instead of usage-based pricing. For example, with usage-based pricing in the past, folks would need to understand what are the usual trends in my environment. Obviously with the cloud, you can scale up, you can scale down. It looks like Ryan's got somewhere to go after this.

But yeah, you can scale up, you can scale down, and you don't really know what exactly that might be over a month's time. With the usage-based pricing, we can take it and understand an average of EC2 instances across the time and come up with a better estimate. One thing to note that you'll see on here is when you do this different bundled pricing, we also give a more competitive pricing rate associated with using all of these things together. You're opting into a number of different features, and if you do that, there are different cost advantages to doing that.

One thing to note is you can use these still individually, but if you want to take advantage of the easier simplified pricing, we definitely encourage you to take advantage of this, but you can do this either way. Another thing here is if there are the different essentials, you can turn on just the essentials, you can turn on the essentials plus threat analytics, as well as additional capabilities, which today exists with Inspector Lambda code scanning. You can add these things on piecemeal based on what you want out of your environment.

Let's go to what this looks like in the console. Security Hub, this is the new Security Hub page, so if you haven't had a chance to see this, definitely come give this a look. One of the things that we've introduced, and one thing I failed to mention earlier, sorry, is we actually had this in public preview at re:Inforce this year, and then obviously yesterday we did the GA announcement. There are some new things in here if you looked at this in public preview before. You're going to see some new things such as the trends in this. For example, you can see day over day or week over week, and then you can see across these different finding types. For example, the threats from GuardDuty, the exposures from Security Hub, you can see your amount of resources, total amount of findings, and if you scroll down, we have some different charts and things that you can filter by. For example, you only want to see your critical level threats, and you can see what this looks like over time.

Another key widget that's on this summary page is security coverage. Talking to security professionals a lot, one of their questions is, hey, I want to make sure that I have this coverage everywhere. It's part of our standard operating procedures. I need to tell an auditor that folks have an easy way to see that you have coverage everywhere versus going out and looking at the different consoles and understanding what exists there. Like I said earlier, we are actually making this a little bit easier for folks to understand what exists. With the account coverage, we can see that, hey, all of these different accounts in our demo environment, we have 100% on everything, but you could see what accounts have vulnerability management, what accounts have the threat analytics, which ones have sensitive data discovery configured or posture management. Then you can configure these based on these different data types. So Security Hub, the essentials based on what we were seeing from the pricing page, the threat analytics for GuardDuty. This is once again policies that you can set at an OU level, you can set across a whole organization. From here, Security Hub will make sure that you have all of these capabilities turned on, whether you have 5 accounts, whether you have 5,000 accounts, based on that policy, and then obviously switching it up if you need, maybe different coverage per OU or something.

Moving on here to what these exposure findings look like. Let's talk a little bit about this. Let's scroll down here and look at just the first one. We can see that the potential finding title is potential resource hijacking. EC2 instance with an open security group has software vulnerabilities. This groups by the different EC2 instances that have this risk. If I go ahead and click on one of these, I'm actually going to expand the view, so hopefully you all can see it better. If we look at this, we get a basic summary at the top. This instance is accessible within the VPC and has low priority vulnerabilities exposing this instance to resource hijacking.

One of the things that folks usually ask about is, hey, I've got vulnerabilities that are critical, they're a remote code execution vulnerability, but this instance doesn't actually have access to the internet, so somebody couldn't exploit that. So those are the types of things that we're helping customers bring to the surface here. Maybe you do have some critical levels of vulnerability, but it's a remote code injection and it's not exposed to the internet, so that's maybe not as severe as, hey, you've got this medium level severity, but this instance has every port, every IP open to the world, so it's kind of just a matter of time. That's something we should go prioritize and focus our time on.

If we look at this one though, we can see the attack path here, a little small, but we can see everything that's involved. So like the EC2 instance, what's the VPC, the different IAM role, the IAM policies associated with it, so we can see not only does this thing have vulnerabilities, but it's got an IAM policy that's named administrator access, so most likely an administrator. We can see the contributing traits. So if we think of contributing traits, this is where the underlying detection sources are. So the things like threats, in this case, misconfiguration with the security group, vulnerabilities associated with that EC2 instance, we can see all the different traits there.

Let me go up. Once again we can see the traits, or we can see the different resources involved with this. So there's an EC2 instance, a security group, the subnet, and an IAM role. This is specifically the things that need to go be remediated, all in one spot from multiple different sources. All right, cool.

So with that, let's go back here. So why build Security Hub in this way? Why would customers want to use Security Hub, right? We're trying to unify these different data sources, these different detection mechanisms. They're rich data from things like GuardDuty, from things like Inspector, putting these things together so folks can get closer to the end state of, I know the data's sitting in front of me, I have a decision to make, or it's already built into my playbook, hopefully, and I can now more easily make those decisions. This ultimately will save you time, right? You're not needing to do that triage yourself, not needing to do this risk analysis yourself, getting closer to that. And then the other things like simplified pricing and simplified deployment, making it even easier to enable these services, to operationalize these services, get them approved at your organizations, making it overall easier to get these detection and response outcomes out of AWS native services.

So I'm going to take a moment to talk about Security Hub plus OCSF. If you're not too familiar with OCSF, this is the Open Cybersecurity Schema Framework. So it's a data standardization for different log and finding data. This is an open source solution that got open sourced in, I believe it was 2022, and it actually joined the Linux Foundation in 2024. There's over 1,000 participating organizations, AWS being a major contributor to this, but a number of different vendors that I'm sure you all are very familiar with. But all of these security findings, these exposure-based findings, the findings that we're ingesting from the underlying detection services, these are all in OCSF format. So when you're potentially integrating with a response solution or some analytics solution, you have standardized findings to get you into analytics a little bit easier. So like whether it's a vulnerability, whether it's a threat, the different fields are going to be the same, the different data sources are already understood, and ultimately working with a bunch of the different vendors that you might be using, using the same standard format can help streamline that.

So like I touched on, one simplified bill. We wanted to make the billing process much easier. Predictable pricing, cost estimations, a single invoice, you're not doing this across services, and just simplifying, you know, oftentimes for security professionals, we don't want to handle the billing stuff. We want to focus on the security stuff, and so we want to get you to focus on the security stuff faster, and less focused on the billing. Go through this real quick.

AWS Security Incident Response: Agentic AI-Powered Investigation and Enterprise Support Integration

The number of services that we've talked about, we've mainly focused on GuardDuty, Inspector, and Security Hub. There are other pieces of this puzzle, right? Macie for sensitive data discovery, you can feed your data into Amazon Security Lake or the newly launched at Matt's keynote yesterday, the CloudWatch Unified store. This also integrates with investigation functionality in Amazon Detective, as well as AWS Security Incident Response, which we'll touch on real quickly in a second.

So AWS Security Incident Response, if you're not aware, this is a service that is in the console. It combines a couple of different things. It helps customers prepare, respond to, and more effectively respond to these different security events faster. It combines different triaging technology behind the scenes to bring in a bunch of findings together, as well as human expertise from our Customer Incident Response Team that Ryan touched on earlier. Ultimately, it gives customers direct access to a security professional 24/7 that will look at the output of that triaging and help customers respond to and recover from any sort of security issue that they might be having in their environment.

One thing that we launched earlier this week too is the ability to, this is actually part of Enterprise Support. So if you're an Enterprise Support customer, you can turn this on with no additional cost to get these added benefits. So something you should look into, takes pretty minimal configuration to get up and going. If you're not an Enterprise Support customer, there is metered pricing and a free tier that you can take advantage of for this as well.

Another big launch in the Security Incident Response service was an Agentic AI-powered investigation. So this is bringing an agent experience into this console. Right now there's a triaging system that whittles down different findings to say, here's the one that you should prioritize based on some different factors associated with an individual customer's environment. But then there's investigation steps. What other IPs did this EC2 instance interact with? What other CloudTrail data was associated with this IAM role during this time, maybe the seven days before? There are other questions that you'd want to answer based on this finding information.

That agent does a lot of that work based on some pre-training and the expertise that the Customer Incident Response Team has built up over the years. So that when the human, on the AWS side, the security professional and your team get together, there's already a number of the steps that used to be a human manually doing, they're already completed. So now we can have the discussion faster, we can get to the end stage faster. What are the decisions we need to make for response? What do we need to go remediate?

A couple of other things, HITRUST certification, some ticketing with ServiceNow and Jira direct integrations, and then we also made it to where customers could not only deploy this across their organization, maybe they only needed it associated with one organizational unit or a specific account, or they needed a combination of both. So we made it easier for customers to do that from a picking and choosing where they want to deploy perspective. So with that said, I want to say thank you everybody for coming to this.

---

; This article is entirely auto-generated using Amazon Bedrock.