Clarke Rodgers (00:05):
Security leadership has to start at the top. When the C-suite sits down to discuss business strategy, security has to not only have a seat at the table, but be the first priority on everyone’s mind.

I’m Clarke Rodgers, Director of Enterprise Strategy at AWS and your guide for a series of conversations with AWS security leaders here on Executive Insights.

My guest today needs no introduction: Adam Selipsky, CEO of AWS. Listen in as we discuss how security culture was first established at AWS, what communication looks like between the CEO and CISO, and how Adam supports security initiatives from the top. Thanks for joining us.

Clarke Rodgers (00:46):
Adam Selipsky, CEO of Amazon Web Services. Thank you so much for joining me today.

Adam Selipsky (00:50):
It's a pleasure to be here.

Clarke Rodgers (00:51):
So, let's take a step back in history a little bit. So, it's 2005. You had the blessing from Jeff Bezos to go ahead and move forward with this little experiment called “AWS.” How did you approach those very early security conversations with those customers? And I can appreciate there are a lot of customers at that point that said, "What's cloud?" "What's distributed computing?" They may not even have that, but what if any, security conversations were happening at that time?

Adam Selipsky (01:22)
It was a very new concept and, admittedly, to a lot of people it was not intuitive that you would give your workloads over and have them run “somewhere out there.” Of course, that's why it's called the cloud, it's somewhere out there. So, it's understandable that it took a bunch of education, but it really started to make sense to people once we explained a few of the fundamentals, the biggest of which was that Amazon had had to get really good at all this because there was no AWS.

Clarke Rodgers (01:49):
For sure.

Adam Selipsky (01:50)
And so, Amazon had to be really good at running infrastructure that was highly scaled, highly available, highly cost-effective, and of course very operationally available and secure. And we really built off of all of that expertise inside of Amazon, which was operating at a scale that, frankly, even then not a ton of companies were operating at and built AWS. And one of the big premises was that there was a bunch of undifferentiated heavy lifting. Sometimes we called it the “muck” of infrastructure. And most companies really shouldn't have to be good at that infrastructure.

If you're selling automobiles, if you are streaming movies, if you are discovering drugs, why should you be good at running massive infrastructure and keeping it available and keeping it secure and having it be low cost and moving forward and be innovative? And that of course was the business of AWS.

Clarke Rodgers (02:50):
Right.

Adam Selipsky (02:51)
And so, it made sense for us to be really good at all those things. So as one of the major elements of that, we really would explain our approach to security, which was that flat-out it was job zero at AWS.

"Fast-forward 17 and a half years later, it's still job zero at AWS. It is still the most important thing that we do. We will still drop any other priority if we see either a security need or a security opportunity."

I make sure to be very vocal about that because it's just more important than anything else we do. In fact, we were very clear from the beginning. We used to say that there were very few potential extinction events for AWS, but the wrong security problem was one of those few things that could be an extinction event for the company, particularly in the early days. And we took it that seriously.

Clarke Rodgers (03:44):
And so, did that drive certain behaviors in the product teams as they were developing these new services like SQS and S3 and EC2?

Adam Selipsky (03:54):
The way we’ve really ensured that we have the absolute best and most security that we could possibly have is to have a very well-defined ownership model. It’s really…I guess you could call it a matrix. So, we have a large scaled, highly expert, absolutely tops, world-class security team. We have thousands of people worried about nothing besides security. Not many companies can say…it wouldn’t make economic sense for most companies to do that.

So our security team, our centralized AWS Security team, builds a lot of technical capabilities, has a lot of experts to help audit and counsel and drive strategy. At the same time, our service teams, EC2, S3, DynamoDB, Connect, Amazon Bedrock, whatever it may be, all are 100% owners of their security. It is not outsourced to the security team.

So, if there's an issue with one of our services, that service GM is fully on it, feels full ownership, is fully driving, and of course has the full partnership of our security team. And I think building that security into our service team culture ensures that we actually then build it into the service. This is critical. We build it into the service from day one — we don't come after the fact. We're always improving security of course, but we fundamentally bake enterprise-grade, rock-solid security into everything we do in any service from the moment we start developing it.

Clarke Rodgers (05:43):
And it makes a lot of sense because that service owner is closest to the thing that they're building. So they know what risks and et cetera that are facing that particular-

Adam Selipsky (05:52)
Well any security problems are not going to be introduced by a central security team. They would be introduced unintentionally by your own team. So your own team better be the ones to first and foremost to spot it and fix it. And we've really got the belt and suspenders approach with a very robust set of capabilities from our security team.

► Listen to the podcast: The Role of Security in Product Development

Clarke Rodgers (06:09):
Absolutely. So, we're 17 and a half years later from initial launch, how have the security, and when I say security, I mean risk and compliance conversations as well. How have those evolved in your interactions with customers?

Adam Selipsky (06:26)
I think that the security conversation started with "Really could this possibly be secure?" And of course we've covered that. We’ve quickly moved past there, and I think there were some seminal moments when Netflix announced that they were — and they're very capable by the way, they can build any of these capabilities, but they chose not to. When they announced that they were going to essentially get out of the data center business and put all of their infrastructure on AWS — which implicitly meant all the security, all of the availability — I think a lot of people really took note of that. And that changed the tenor of the conversations.

We had a number of government agencies, including prominent members of the intelligence community of the US government saying publicly that AWS provided better security than they had in their own data centers. And again, a lot of folks including big enterprises, banks, pharmaceutical companies, et cetera, took notice of that. So, as you had big customers like that saying, “This is a great security model, we are going to trust AWS with these functions.” I think a lot of other companies took notice.

Clarke Rodgers (07:35):
So last year, in season two of the series, I had the privilege of interviewing the AWS CISO and we were talking about security mechanisms, what works in large organizations, what doesn't work so well. And one of the most effective mechanisms that he referred to was the weekly CEO/CISO meeting at AWS. And of course he said, this sets the tone for the rest of the organization. It keeps the CEO informed of what's going on in the security realm. It keeps the CISO informed of what's important to the CEO.

So, my question to you is, I would love to hear your perspective of that meeting. So not a security professional, but your perspective as a business leader. How does that meeting work for you?

Adam Selipsky (08:20):
In this particular case, one of our many security mechanisms is this weekly meeting that I and my Chief Information Security Officer, Chris Betz, jointly run. And as you mentioned, it does send a cultural signal. So it is a weekly meeting, no kidding. And we prioritize it. And the content is incredibly simple. We go through the top couple three security issues that have surfaced over the past week.

We always have the meeting, there's always two or three of them. Some times may be more “interesting” than others, but we never don't do it. We always look at the top ones and we inspect very deeply. So, it's not a presentation. Very much in Amazon style, there is a written document, a written summary of the security issue. It has been carefully vetted before the meeting and it's complete and contains exactly where we are and exact next steps on that security issue. And the folks on the appropriate service team and of course security team, anybody who's directly involved, are all in that meeting.

And it is definitely educational. It's sometimes comfortable and sometimes, frankly, less comfortable because we take this incredibly seriously and if we see any issue that needs to be remediated, any behaviors which need to change, anything that we need to do different technically to ensure the outcomes we want, then we're very open about them in that meeting. And so, I think that also sends a cultural signal that we are absolutely deadly serious about this. And so, it helps technically to make us better. And I think it's also important culturally at reinforcing that, indeed, security really is still job zero at Amazon.

Clarke Rodgers (10:13):
So a slight pivot from there, your line of business leaders. How do you hold them accountable for the security of their particular service or other business that they're running inside of AWS?

Adam Selipsky (10:24)
Well, in general, they hold themselves accountable. And that's the culture we've built around this, which is by far a better answer than somebody else trying to hold them accountable. So, I think with the culture we've built around security, with the clear ownership model we've established where it's really part of their day job, not an extra added thing. And with mechanisms like the weekly security meeting, which of course they attend, if it's their team who’s got an issue that week, I think that really creates a lot of different forces for momentum of their holding themselves accountable. And it's really much easier, much better that way.

It is important to have the centralized security team. They are the ones that are true experts on anything and everything security. They get to look at best practices across all of our teams. They're the ones who can ensure that if there's any team where we suspect we need to do anything differently on security, they can talk to the leaders on that team, be it technical or business leaders. So, I really think it's having these multiple mechanisms that all come together that really puts the ownership on that team.

► Listen to the podcast: Vulnerability Management in a Zero Day Security Scenario

On the rare occasions where there is an issue with the team, it becomes very evident immediately that we're expecting that team to understand the issue, that team to remediate the issue. Of course, they're going to get help from whoever they need help from, but that they own it.

Clarke Rodgers (11:53):
I think that's a really important point to call out, having that business leader ownership around security as well as the functionality of the product they're building and the P&L, right? A lot of our customers, they have those responsibilities separate, and then sometimes there's an issue because of that, but having that single path of ownership is fantastic.

Adam, thank you so much for taking time out of your busy day to meet with me today.

Adam Selipsky (12:16):
It's a pleasure. Thank you.