Security is in our DNA: A Conversation with AWS CEO Matt Garman | Amazon Web Services

Yeah, absolutely. Thanks for having me.

My first job actually, I interned out of business school for AWS before we ever launched in 2005. And from the very first day I started, Andy Jassy drilled it into our head that security was priority zero. It was the first thing that we got to think about, no matter what. And so when we were thinking about the early days of AWS, we were constantly thinking about, 'What does it mean? How do we think about security? How do we think about isolation?' At the time, there was a lot of concerns about trusting your data to someone else. And I think it was the right bias for us to be very focused on security, the right bias to be extra diligent on isolation, on isolation of customer workloads, but also our own security and how we think about accessing customer data and how we think about protecting customer data. And so that was a huge focus for us very early on. It was a big area of investment for us and it remains that way today, of course. And we've only continued to scale as the security threats get bigger. We think more and more about how we both protect the security of the cloud, like our own security, and protecting customer workloads in that way, but also giving tools to customers so they can protect their own workloads in that shared responsibility model. So everything that we do, it's the first thing that we ask our developers to think about, it's the first thing that we ask our data center folks to think about, from a physical security, from a logical security, from software security, from maintenance of our software and services, from operations of our services. It's front and center in everything we do.

Number one is... The biggest lever that I think we have is that focus on culture. And it is a focus on making sure that the leaders know that security is their responsibility and that they should be thinking about it. And so we have a couple of mechanisms that we use to enforce that and make sure that they're learning. Because I think when people come from other environments, in particular, they don't actually have that same bias. And other places don't necessarily start with security first. They kind of do it afterwards or it's someone else's problem. Or maybe the security team will take care of security. Right? And you're on the security team. We don't rely on you for security, right? Everyone is responsible for security. You're an excellent partner in that journey to help us build best practices and enhance security. But we really have to build that as part of the culture. And so it's definitely part of the learning when engineering leaders come in, when product leaders come in, they have to think about that responsibility as something that they take seriously for their products. And we have several mechanisms where we review, we try to encourage leaders to think about how they're improving security, where they think about... Their products are secure, but that's why there's belts and suspenders and extra belts, right? And where else can we find ways to keep getting better? Because our job and the promise that we make customers is: 'We keep getting better,' right? The security landscape out there keeps getting more challenging. The bad guys keep getting more skilled and we've got to keep having more layers of protection. Finding those mechanisms where you can reinforce that with your leaders where you don't punish people, right? It's not a punishment, but it's understanding that we won't ship a product if it doesn't have the right bar in security. We won't even embark on something if we don't think that it has the right constructs around a security isolation. And the first time people get something that doesn't get launched because we don't think it has the right bar to deliver, or that we read a new product offering suggestion and we go, 'Ugh, I don't like how that thinks about this particular architecture in a way that doesn't work.' That message gets reinforced and then I think it drives a lot of the right behavior.

Sure, yeah. There's a couple. One is that's a great opportunity for us to help reinforce with our leaders and frankly a great opportunity for me to learn and I think for all of us to learn. And so we have that weekly meeting where we review, oftentimes there are, actually almost all the times, there are kind of these security issues where we're looking around corners where this could have been an issue if we hadn't caught it or again, if we didn't have other mitigating controls in place. But it's a very good opportunity for us to dive in and understand where are the choke points that we might've missed, why something slipped through, where is it where we've identified a new type of concern that we want to roll out to a bunch of different teams. And so we do this every week where we go and look for opportunities around all the teams across AWS, where we want to dive a little bit deeper to learn where we can actually build that. And I think that mechanism is powerful, because, number one, it's a great opportunity to teach those leaders how to really think and dive deep. And we have a whole host of leaders that are on that call or in the room that'll dive into those problems and understand what's going on. And we'll often we'll debate back and forth on the trade offs of doing A or B. Because a lot of times these are subtle type of issues where we're trying to decide, there isn't a clear like, 'Oh, you forgot to close a port or...' So it's not that, right? It's not those type of issues. It's more subtle things like, 'Ooh, this could happen or this could happen,' or it's a edge case that we're looking at. And then there's that mechanism of just, 'Okay, great, now that we've done this, how do we go talk to the other 50, 100 teams that may have a similar type of thing and make sure that we spread that learning?' And it also helps us as leaders where we hear the next week and the next week, and the next week, where we can actually build on our learning and understanding and think about where there might be other areas that we're looking around corners. And so it's a super powerful reminder for all of us about how we think about it, and frankly, a good opportunity for us to learn from each other on how we keep getting better.

That's right. And I think the other important part of that is, I think this is a mistake where some people think about a mechanism like that as, 'We're going to yell at somebody for making a mistake.' And I think that's a really important part is you don't want to make it a punishment to have an issue that's brought up in that meeting. It's, in some ways, it's a good thing that you flagged it and found it and we're all learning from it. And so I think that's important too, because you don't want a culture where teams want to hide that issue, where they're like, 'Uh-oh, I don't want anyone to find out about this because I don't want anyone to like yell at me.' And so you really want to encourage a culture where people bubble these things to the surface so that the broader organization can learn from them.

That's right. That's right.

It could be. I think that's probably true.

Well, like I said, I think it is, there is no signal anywhere in the market that security is becoming less important nor that the bad guys are becoming less sophisticated, right? And so, it has to be something that we continue to invest in and will invest in because I do think it's one of the things that frankly differentiates what AWS does versus everyone else, especially what you can do on-prem, but frankly even from the other cloud providers, it really is a differentiating capability for AWS and we want to keep it that way. As I think over the next couple years, there's additional surface area that we have to think about how do we secure. I think as you think about AI, there's a whole host of other attack vectors that you want to think about and escape vectors and ways in which security, AI is, I'm optimistic that it is an incredibly powerful tool and capability and technology for companies to drive a lot of value. And it's probably powerful for the bad guys too, and for fighting, and helping find security issues. So, I think it can be both. It's something that we're leveraging to figure out how we can continue to improve our offerings and our underlying security. But I also think it's one of those things that could, it's going to increase the volume of surface area that we've got to protect against. And so I do think that that's going to be an area where we're going to have to double and triple down on our efforts. And we are already. And I think that over the next kind of three to five years, that'll definitely be a space that we want to think about. And I think as the... And the other thing I think that's important, that as that space is moving fast, people will sometimes have the temptation of saying, 'Yeah, we can probably squeeze by and we'll go do security later.' And for me that's just, that is not an acceptable trade off for us. As you think about where is the right isolation boundary and you think about what is the right time for when you might launch a product or service or whatever. It's just not one of the... It is not an area that I'm willing to give any sort of compromise on, but I do think there's probably some temptation to do that. And so we'll just have to keep educating our teams. And I'm sure that others out there in the market will be tempted to give on that level to move fast. And my bet is long term, that'll be the wrong choice.