Amazon CSO Steve Schmidt talks prescriptive security for AWS

While AWS offers a variety of cloud security tools, understanding and implementation varies by user, which can lead to dangerous outcomes.

As cloud security has become a more complex endeavor, the world's biggest cloud provider has taken a more active role in advising and assisting customers to help them avoid common pitfalls. Amazon CSO Steve Schmidt addressed those problems, such as blocking public access to cloud resources, during the second part of a Q&A with SearchSecurity (part one can be read here). As more companies move to the cloud and require different levels of guidance, AWS has expanded its approach to offer both default and prescriptive implementation needs.

Despite the shared responsibility model for cloud, Schmidt said prioritizing customer service is a must for the cloud provider. He discussed changes AWS has made in recent years to reduce misconfigurations, as well as its role in incident response and how AWS addresses cloud vulnerabilities.

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

You talked about limiting public access to AWS resources in your re:Inforce 2022 keynote. It seems like you've made progress on a common misconfiguration that was affecting a fair amount of customers, because we're seeing fewer examples of accidental data exposures or breaches because resources were mistakenly made public. How did you accomplish that?

Schmidt: We enabled "block public access" for S3 by default three years ago at this point. And we have always had the security group firewall rules for instances that are closed by default. That has been the case since the beginning of the service. It's something that we have taken very seriously for a long time. And I think a lot of customers have just learned more about all of our security tooling; if you're using GuardDuty, for example, it tells you if you have resources that are exposed, and it warns you about it. Now, what the customer decides to do with that is up to the customer. We can't tell what their business is. They may be running a public website, in which case it may be perfectly reasonable for it to be open. We don't know because we don't see their data. But at the same time, we have to give them that information and say, "Please check. Is it OK?"

Do you have a rough idea of how often AWS has to contact customers about public access today?

Schmidt: The security team doesn't usually reach out to people unless it's an exceptional circumstance. For example, when the Log4J vulnerabilities happened, yes, we did look for customers who might be vulnerable and warn them about it in that circumstance. However, in most cases, it is the tooling that customers subscribe to that tells them. GuardDuty is the engine that warns them.

The irony with GuardDuty is that my team built it long ago, and it was a really awesome discussion on user interface. What people don't realize is behind the scenes in GuardDuty, there's an enormous amount of configuration that occurs in order to launch. And one of the reasons it took us a while to launch it is that we built the user interface so there's literally one checkbox to turn it on. We asked "What is the least friction possible for a customer to do this?" And wow, it succeeded. The uptake that we've seen from that as a result has been amazing. Don't make it hard. Just make it simple. Make it an easy decision for customers.

Did you get a lot of feedback from customers on how to make configurations and properly setting resources so they're not public? It seems like even though cloud services were designed to be easier than managing your own infrastructure, cloud customers have still struggled with all the security controls and settings and configurations.

What we do hear from customers is requests to give them more prescriptive guidance. They want us to tell them the right way to do things.

Schmidt: That's not something we hear very often. What we do hear from customers is requests to give them more prescriptive guidance. They want us to tell them the right way to do things. And so what we've chosen to do is to start embodying that in some of the services that we introduced like GuardDuty; it has a very prescriptive set of rules that come as standard. You as a customer can choose to turn them off if you want to, but they're there by default because customers have told us, "You know this better than I do, so you tell me what I should do."

On prescriptive guidance, was that approach taken sort of by necessity, because the customers were asking for it? Or is that something that you saw yourself eventually having to do years ago, as cloud security got more complex?

Schmidt: It's both. What we did first was to look at the options that customers want to be able to use, and we built those. And then we said, "OK, we now have a lot of options, and people are saying, make it simpler for me." The customers tend to come into chunks. There are the customers who want the default settings and want guidance and want prescriptive implementations. And then there are the really big customers on the other end who want every custom switch, bell and whistle there is. Those are the folks who really want to control exactly what they're doing themselves. And we have to build for both. And now what you see is the stuff that will ship with the checkbox like GuardDuty, with everything enabled. But behind the scenes, a customer on the other side can go in and tune each one of those rules for their specific circumstances. But we start off from a default that is what we consider to be appropriate.

How does incident response factor into this prescriptive approach? For example, let's take Zoom; Amazon has already worked with the company to help scale up its incident response team and provided training and guidance. But let's say there's a major cyber attack. What is Amazon's role there in terms of incident response, even if the attack is completely independent of anything that has to do with Amazon technology? Do you mobilize your security team and get somebody on the phone with them?

Schmidt: We do. It starts off with their account team and their technical account manager. Typically, we'll see what they're doing and what help they need. And then we'll get the right parties involved on the Amazon side. So yes, absolutely. We'll help them out. And that can often be doing things like showing them the logs that they need to go look at in order to determine what's going on, and building queries for those logs, which will help them. It's also teaching people how to spin up EMR [Elastic MapReduce] clusters if they haven't done so previously to parse logs. We can also help customers do things like ensure that they snapshot disks appropriately so they can do forensics on the snapshots.

It depends on the customer. And it's often what can we do that we can help them with that will free their staff up to do things that only they can do. For example, I can help snapshot discs pretty easily because that's making API calls from the outside. But I can't go and look at their logs and tell what makes sense, because that's their application, so it's dividing labor in a lot of ways and making sure that they've got the right expertise to ask the right questions.

It seems like this approach is a shift from the shared responsibility model for cloud. It felt like under that model, if there was an incident in the customer's environment, well, that's the customer's environment. It's not the cloud provider's job to do IR.

Schmidt: Even though we have had that shared responsibility model -- and by the way, you can blame me for that name because I came up with it -- we have always helped customers when they run into a problem. And that's sort of a corporate ethos for Amazon. That is just the way that the customer service processes set up within the company. All executives in the company have to go through something called C2CS, which is "customer connection customer service." You sit and answer customer service calls, and you answer customer service tickets, and it is intentionally there to help you, No. 1, understand what the customers are really feeling and how they're working. But it's also a chance to go in and make people happy and to be able to say, "No problem, we can fix that." We don't say, "Well, sorry. That's your problem" because No. 1, it's not the way we do business as a company. And No. 2, it's just not good business, period, to tell a customer "Sorry you had a bad day, but you're on your own." That's not going to work well.

But it looks like shared responsibility may be shifting somewhat as cloud providers in general are taking a much more active role in security and are granularly involved in responding to incidents. Are you concerned at all that AWS will be pulled further into the incident response equation?

Schmidt: I think it depends on the individual customer. We've got all of the normal service offerings that customers can subscribe to. And I think that's one of the important things -- we'll do what we can to help people. But that tends to be "best efforts," unless the person has a contractual relationship, in which case we have to respond within specific SLAs [service-level agreements]. For customers who want to have us on the hook and to have us help them with things, they have a support contract. For other circumstances, we will do what we can when it's appropriate and reasonable. And reasonability is a relatively important term there. If someone comes in and says, "Hey, can you know, you helped me parse 2 exabytes of logs?" then we're going to tell them that's going to be kind of difficult.

The topic of cloud vulnerabilities has been a source of concern in the infosec community lately because there's no CVE system that documents them like traditional software vulnerabilities. Some experts tried to jumpstart that effort by launching their own open database for cloud vulnerabilities. Do you think there's a need for a better CVE system that includes cloud vulnerabilities, even if those bugs don't require interaction on that part of the customer? Would that benefit customers?

Schmidt: I personally don't think so. The reason is the data is already there for the customer. If you search for "AWS security bulletin" in the search engine of your choice, you will go right to the page where we describe all that stuff in detail. And having yet another place that you have to go look at -- which will not be authoritative because that is authoritative where we put it -- I don't think helps customers. It may help somebody who's vending tools that do that. I don't know. But the data is there, and that's the important thing. In the specific data that we really care about is whether the customer has to do something. And that's why we always include that in our security bulletins. It very specifically states if customers do not need to take action, or customers should update to version X or whatever.

We try really hard to figure out the right level of information so that it's helpful and not noisy. And the noise part is the problem because if every hiccup and burp on the internet gets reported on somewhere, people are going to get lost and miss the really important stuff. The part we need you to read is the part that requires action – you need to go update [your software]. And we don't just post bulletins; we actually have a process with our personal health dashboard where we push alerts to customers. If we can tell that you are running, you're running [Amazon] RDS MySQL 3.8.4, we will actually push a message to you saying there is a vulnerability in 3.8.4 that needs to be updated. You need to either choose to accept our update during the maintenance window or go update it yourself now.