AWS CISO details automated cybersecurity tools for customers

Chris Betz wants to take as much of the enterprise security burden off the plate of AWS customers as possible, and three of the cloud giant's internal tools are helping him achieve that.

Betz, CISO at AWS, spoke with TechTarget Editorial recently about the cloud provider's automated cybersecurity defenses, which are designed to identify and mitigate threats with minimal action required from customers. The defense tools include Sonaris, which Betz first spoke about publicly during the AWS re:Inforce 2024 conference in June. The internal tool scans vast amounts of network traffic to identify and mitigate malicious scanning and attempted connections to AWS infrastructure.

In a blog post last month, Betz explained how two other internal tools, MadPot and Mithra, work in conjunction with Sonaris to provide what he called active defense for AWS customers. Mithra is a neural network graph model that analyzes and scores domains, detecting on average 182,000 new malicious domains each day.

MadPot is the cloud provider's extensive honeypot system that collects threat intelligence across AWS services and features automated response capabilities. AWS announced last month that MadPot and other threat intelligence tools helped the company identify the infrastructure used by Anonymous Sudan, which aided the U.S. Department of Justice's investigation into the notorious cybercriminal group.

Betz discussed the three internal tools and the ways that they mitigate threats for customers, how they work in concert with other AWS security offerings, and why automated defenses are so important to the cloud giant's overall security strategy.

Editor's note: This interview was edited for clarity and length.

Tell me about the synergy between MadPot, Mithra and Sonaris, and what they provide AWS customers behind the scenes.

Chris Betz: Think of Sonaris as two parts. What we're working to do is take advantage of the fact that AWS is a massive infrastructure in and of itself. In addition to being a massive system provider to customers, we have a large internet presence as well. Sonaris takes advantage of our infrastructure to understand what attackers are trying to do. It builds on top of the sensors we have on our own infrastructure to understand what's going on, and that helps identify attacks that are targeted to interact with our APIs or other things. It also identifies attacks that are not targeted at us, but just happen to hit the same IP space. Similarly, we run Linux servers, and people try to attack Linux servers all the time.

MadPot builds on top of that with a set of infrastructure that mimics our customer environments to understand what attackers are trying to do at a deeper level in the infrastructure. If you put down a piece of malware or something else like that, MadPot provides a very high-fidelity signal that goes deeper into the attacks. Together, you get this massive breadth of coverage. What are attackers trying to do to different infrastructures? You also get information about what people are trying to do by leveraging our infrastructure, attacking unintentionally public S3 buckets, for example.

And then Mithra is this massive neural network graph model that uses DNS information, based in part on tips from both MadPot and Sonaris, to more deeply understand what are probably malicious domain names and what they look like. You take all three of these signals: MadPot, with a really deep understanding of specific malware on platforms that look like our customers; Sonaris, which understands the breadth of our infrastructure; and Mithra, which looks at domain names. Sonaris also provides an action tool that helps defend customers. Let's say we identify a specific IP address as probably malicious. There's no reason why that IP address should be talking to any resource, whether its AWS' or our customers', so we stop that bad actor from being able to access any resource on AWS.

Simply telling people, 'Hey, there's a potential problem' is not where we want to be. Our goal is wherever possible to transparently -- and without the customer even having to worry about it -- protect them against threats.

When we bring these all together, you get this very powerful set of capabilities that operates completely transparently to our customers. Customers don't have to change anything. They don't have to react. They just get the protection. And we do this across hundreds of different types of malicious interactions classified by MadPot and Sonaris.

These actions help protect our customers without requiring alerts or anything else. This fits into our overall philosophy about how we take action on threat intelligence to defend customers, because ultimately our goal is to make sure that our customers are able to operate most securely when they're operating on AWS. Simply telling people, 'Hey, there's a potential problem' is not where we want to be. Our goal is wherever possible to transparently -- and without the customer even having to worry about it -- protect them against threats. Identify the threats at line speed, implement the protections in fractions of a second and just defend those customers. In addition to that, we then take the same sets of threat intelligence and move them into the customers' environment through tools like GuardDuty.

GuardDuty benefits from all of the same threat intelligence and is able to better understand what's happening within the customer's environment because it executes in the context of the customer and within their accounts. There are things that I would not want access to [as an AWS employee] -- information about how a customer's running their infrastructure. GuardDuty, running on their behalf within their accounts, has access to that information, and it's then able to inform customers about things related to this threat intelligence. The customer can use that information to trigger actions or whatever else they want to do.

And then the third piece of things that we're able to do with our threat intelligence is pick up the phone and contact customers when we see something where neither GuardDuty nor the automated protections are the appropriate response, and we need to get them involved and informed. We do all three of those.

You mentioned three scenarios. Do you have a sense of how often that third scenario happens, where you have to pick up the phone?

Betz: It varies based on the threats that we see. When we start getting to that level, that is the threat intelligence that we produce by facing and deeply observing a specific threat actor. There are times when threat actors are more active, there are times when they're not, and there are times when we're able to see more of what they're doing. It does tend to be very periodic. There are not weeks that go by when we haven't reached out to a customer, because we're doing this very actively. But our goal is, wherever possible, to try to load this stuff into the systems because if we can protect a customer without them having to take action, then that's a win for both of us. That lets us pay attention to these really high-level, sophisticated threats.

Walk me through a typical scenario where you do have to contact a customer and where you feel like the best and maybe the only option is to contact the customer directly and inform them of what's going on. Do you have specific people at customer organizations that you call and specific people at AWS who are in charge of this process, or does it depend on the scenario?

Betz: It does depend on the scenario. But let me give you an example. We had a piece of malware that was running on MadPot, and from that, we identified what the command and control of the malware looked like. And we know that that IP address is malicious. It's being used for command and control of malware. So, what did we do? We used Sonaris and shut off communications to that command and control. That's great, but then those same indicators, those same domain names, IP addresses and ports, show up in GuardDuty, and a customer who has a system infected by that malware is now getting an alert. We've taken care of the immediate action. We stopped the malicious communication because that bad guy doesn't get to talk to anything on AWS. We provided an alert in an automated way with GuardDuty. But in this case, we knew that this malicious actor was a sophisticated possible nation-state actor.

We've got customer administrators, security contacts and others that we can notify, and we can notify automatically, but this is a case where we did that and also the customer's [AWS] account team reached out to the customer. We brought the right experts and got the right connection to the threat intelligence team, and we're able to say, 'Hey, we're seeing this, and we might be able to help you defend yourself.' In this case, the customer in question had not previously identified that they were being targeted by this activity. We were able to have a conversation with them, and they were able to address the security issue that they had.

How much work goes into sitting down with customers in these scenarios to communicate the importance of that threat intelligence and what needs to be done? I imagine that in some situations, the threat intelligence is pretty complex and it takes a little bit more effort.

Betz: It does, and it does on both sides. And that's why this is something that we do; wherever we can provide defense, we'll do it. We have tons of customers where GuardDuty is tightly correlated with their SIEM. In some cases, they've got automation running off of GuardDuty, and that is enough. We don't even have to pick up the phone and call. We're already operating at line speed. That's where we want to be. There are cases when we can't, where things are not working the way we want it to, and that's where we reach out.

In the case I mentioned, the customer was a relatively mature company and took the tip and was able to run with it. We were able to help them out. There are frustrating cases where that doesn't happen, but I do think that there's more success. Security response teams are also very busy at many of these companies, and wherever we can enable this line speed defense, whenever we can just block the activity before it even happens to hurt customers, that's just a solid win.

Is that type of activity mostly the non-nation-state, unsophisticated threats that are more of your garden-variety cybercrime? Or is there activity that's automatically blocked that does fall into that more sophisticated, APT-level category?

Betz: It's certainly inclusive of both nation-state-style actors as well as ransomware and other untargeted activity. Generally speaking, it really depends. There's one class of activity that we see and protect against in this case that is of the less targeted variety. And I say less targeted, not untargeted. 'Hey, I'm going to go look to see if I can find something around your IP space' or something else like that. With MadPot and Sonaris there, we're going to see that and we're going to stop it right there.

There are some things that we can identify, like public S3 buckets; if someone's looking to see if there's a public S3 bucket, that could be a sophisticated actor looking for those kinds of accesses. And then there are certain types of activities where an adversary is deep into a particular customer's infrastructure, and we may not see that with these kind of sensors. That's where the customer's defenses become most important. My goal with these kinds of programs is to catch what we can in an automated way, to try to lower the noise floor, and to make it as easy as possible for customers to be secure when operating on AWS. That lets them build the tailored security experience that they need without spending so much time on the stuff that I can take care of for them.

You mentioned malicious URLs and domains. Looking at the volume of data that you are and seeing how many malicious URLs pop up every day, is there anything that can be done to slow that down?

Betz: There's a class of malicious domains that are created for a specific, targeted purpose and have nothing to do with each other, and that happens sometimes. But one of the most interesting things is domains that are created automatically. For example, there are some types of malware that every day and every hour may use a different domain name to try to hide themselves in the noise. The domain name generation tends to be algorithmic. One of the cool things is part of Mithra is predictive analysis, where we can in days, weeks -- sometimes even months in advance -- predict the series of malicious domain names. In fact, the patterns themselves stick out, and then you can predict what those are going to look like in the future and get ahead of the attackers. That's incredibly valuable and powerful. Domain names are just a translation for IP space; attackers use those domain names as the way to get communication together, but it's also an Achilles' heel for them. Those domain names, in and of themselves, become something that's signature-able and trackable for us, able to defend against, and that's powerful.

Rob Wright is a longtime reporter and senior news director for TechTarget Editorial's security team. He drives breaking infosec news and trends coverage. Have a tip? Email him.