How the C-Suite Sets the Bar for Security Culture

Clarke Rodgers:
We often say security is our top priority at AWS, but how do we ensure that’s actually the case? It starts with getting buy-in at the top and building security culture throughout the entire organization.

Hi, 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.

Today, we’re talking with Sara Duffer. Sara has an uncommonly deep understanding of Amazon Security thanks to her previous role serving as technical advisor to the Amazon CEO. Join us as Sara shares learnings from her experience as both a security leader and a technical advisor. Please enjoy.

Clarke Rodgers:
Sara, thank you so much for joining me today.

Sara Duffer:
Thank you. It's so nice to be here.

Clarke Rodgers:
Would love if you'd spend a little time telling me about your career and your current role at AWS.

Sara Duffer:
So, I've been here at AWS now for 13 years. Started originally in the AWS infrastructure team, where I spent a lot of time within our data centers. Pretty quickly after that, I moved over into, at the time, our very small compliance team, which became our security assurance team.

Clarke Rodgers:
And have you always been in security or did you first get into security just when you came to AWS?

Sara Duffer:
Always got into security. I started my career leaving college, went straight in to do attack and penetration work, physical security — started legally breaking into organizations. And then I moved into more of implementation of security solutions. So actually, solving the problems I was finding, which was a fun space to move into and ultimately, moving then over into AWS.

Clarke Rodgers:
So, your security background is impressive enough as it is, but you had another role at AWS and Amazon, which is fairly unique and it's the role of technical advisor. Could you share a little bit about what a technical advisor is and what they do?

Sara Duffer:
So, I started in the technical advisor role, it was November of 2020. And that was technical advisor to Andy Jassy, who was CEO of AWS at the time. He obviously, later moved over to be CEO of Amazon and I moved over to be TA to Andy in that role too. And a TA is really, at its core, a teaching role. So, it's all about being able to teach a leader about scale and execution at a pace that you just have not seen before. And it was an absolutely fantastic experience.

Clarke Rodgers:
So, are there any key sort of lessons learned that you got from your experience in the TA role?

Sara Duffer:
Every day it was such a lesson. One of the things I did really early on when I was moved into the TA role, is I kept a running list — what I call my one-liner lessons learned — which I told myself I'd add to on a weekly basis. I very quickly find myself adding to on a near daily basis of just observations of great leaders and how they execute and how they engage. So, there were a lot of lessons. I think there's three that really stick out for me — and these are very much learned from just watching and engaging with Andy. The first one is time is such a valuable resource; you have to be very thoughtful as to where you put your time in.

And that couples very closely with the next one, which is, when you say “Yes,” it has to be a full body, “Yes.” You really need to mean it and you need to be thinking about future self, not just your current self. He's like, "Sure, I can do that sometime in the future." And that sounds so simple and it's actually much harder to execute. Those are two core ones.

Then the next one, which I just got to see repeated by so many incredible leaders, but obviously, Andy is exceptional at it, is voracious curiosity. And it is the type of question-asking which is firstly, constructive, but very quickly, can probe to understand the core foundations of whatever the meeting that you're in is or what those core learning blocks are, how the team thinks, checking and pushing on a team to make sure how they're thinking is in alignment with how we think from an Amazon perspective and what things to learn from the team. And that voracious curiosity just showed itself time and time again, consistently across all of the senior leaders across Amazon.

Clarke Rodgers:
That's fantastic. So, let's switch gears to your current role. One of the topics that keeps coming up in our AWS CISO circles is post-quantum cryptography. What are your thoughts?

Sara Duffer:
Well, in today's public key cryptography schemes, it leverages mathematical problems for factoring discrete logarithms and elliptic curve cryptography. And so, we are very much in the early days of quantum computing and there's going to be a lot of benefits realized to society out of this. One of those, is the ability to be much faster in solving hard computational problems with the unintended consequences of potentially in the future, there may be a quantum computer which is able to potentially break our public key cryptography schemes that we have today. So, there is a lot of conversations today about post-quantum cryptography, or PQC, and schemes that we can start thinking about putting in place today that can continue to protect our data for the potential future where we will see quantum computing coming in.

AWS is doing a lot of work in this space today. We have our cryptographers who have actually contributed PQ key agreements and PQ signature schemes. And it's not just theory. There is a lot of theory that's out there and there's a lot of work that NIST, for example, is doing in this space, which we are also contributing to. But there's also reality and we have, for our TLS-1.3 end points, we've implemented PQ today, within our AWS Secrets Manager, our KMS service and our certificate management service. So, it actually is something that people could even try today, which is kind of cool.

Clarke Rodgers:
In the last year or so, generative AI has sort of taken the world by storm in all sorts of different forms and fashions. How do you think about it in the crypto space? Is it going to be helpful? Is it going to be a hindrance? Is it too early?

Sara Duffer:
I think from a Gen AI perspective, we hear a lot of discussion around this worry about IP disclosure. And because of that, you're hearing more and more of a discussion around privacy preserving techniques by which you are able to continue to be able to, for example, train large bodies of data and be able to preserve IP associated with it. So that's a space that, very much, the team is focused on and thinking about as we even look internally at what solutions we have.

Clarke Rodgers:
Security trends and predictions are of major interest to our customers. What are you seeing happening in the security space in the next, I don't know, three or five years or so?

Sara Duffer:
For me, I have two spaces that I'm really interested in right now. One of them, which is very nascent, but I think is going to become more and more top of mind for CISOs out there, and that's the concept of cryptographic computing. So cryptographic computing is a way of using cryptographic means in order to enable multiple parties to share information in a way that's able to keep that information private. And an example of that today is actually, if you look at AWS Clean Rooms, which is a service that enables our customers to collaborate and share information and get learnings. There's actually a piece of that which is called the cryptographic compute for Clean Rooms. And that enables customers to be able to share information in cryptographic means. It's still early days and it's still something you don't hear as much about, but where you're going to hear more and more on the topic of cryptographic computing is around this concept of privacy preserving.

So, you think about the world today is going towards more and more data analysis and how we can share and learn more and train data, etc. And more and more you're going to have that concept of, “How do you have privacy preserving techniques?” And one of those ways is using cryptographic computing.

The other one is very near and dear to my heart, which is a new service that actually, our team launched this year, which is the AWS Payment Crypto service. And what I find fascinating about what this team is doing is that, payments today, in order to be able to enable that sort of end-to-end encryption that's required, large major processors have to continue to maintain a sort of HSM on site. And what AWS Payment Crypto enables organizations to do, is to leverage AWS Cloud to be able to perform those key management and cryptographic functions that you would traditionally have done with that sort of on-prem HSM.

It is still very early days for this service. It's also very new. And also, the most important point about this service is that it's also has met the PCI PIN compliance requirements, which is absolutely critical. And I think there's a lot to sort of watch in this space as you're able to continue to help and enable customers to sort of move out of their on-prem into the cloud. And that's sort of an exciting place that I'm certainly keeping an eye on.

Clarke Rodgers:
So, shifting gears slightly to more of a development perspective. For years, we've been talking about, “Let's make sure that we're building in security by design into applications,” and then that progressed to compliance by design and privacy by design. How do you incentivize, what are the expectations that you sort of set for development teams to actually think that way? And ideally, it's at that sort of iteration stage, “Here's the thing I want to build, let me take all these things into consideration,” but how, mechanistically, do you set that up?

Sara Duffer:
It's all about the culture, which starts at the top. I mean, it's been said time and time again, but it truly starts at the top. Security, privacy, compliance, it really is your job number one. And you get that sense as a part of the culture with each of our builders within AWS. And I think that's probably the core starting point. But what's really important as well is, for each of our builders, and for any team and our customers as well, that are building even internal services from a security or privacy perspective for team members is meeting the developers where they are.

I think what you see sometimes, a lot of cases is missing is, just even in those tactical items, measuring the amount of work every engineer needs to do and then actually, collectively measuring how many of those tactical things are going out to all of those builders. Because the overall impact of being able to tactically react to all of those one-off asks, you suddenly realize that's a significant burden that engineers as a part of their day job are taking on.

And there's multiple ways of solving that problem, but maybe that will make you move faster to be able to identify, “Are there proactive ways we can solve this particular problem?” like in pipelines or whatever, to prevent this issue actually having to engage an engineer at all? Which will be even better. And so, I think that's one of the core things in addition to, it starts at the top and making sure you have the policies in place to define what it is that you need to get done. Then you have your day-to-day execution and your identification of issues.

But at that issue management piece combined with the change management piece and truly being able to identify what it means to meet the developer where they're at and being able to walk that line around like a severity two or very high severity issue that we need to drop everything and fix. And at the same time, let's look at all the other items that we're asking people to fix. Are there other ways we can do this and remediate it in a different, timely manner? So, I think that's probably one of the most interesting areas that I know that we've looked at as an organization consistently over time, is how do we consistently reduce the burden on engineers and reduce the friction associated with having to remediate any issues?

Clarke Rodgers:
And a big part of that, as you said, is the culture and the ownership — that security, even though it doesn't say it on my name tag, is part of my job.

Sara Duffer:
Exactly. Very much so.

Clarke Rodgers:
So, I know throughout your career, mentoring has been very important to you. What kind of mechanisms did you set up to make sure that you were helping those that really wanted to reach out to you and get some of your advice?

Sara Duffer:
I have been very fortunate in my journey through getting to AWS and also throughout AWS, as I've always had incredible mentors and coaches who have always been willing to step up and engage at any point to have conversations with me, to sort of rally me, to advocate for me when I wasn't in the room. I think one of the interesting things for me is, when I moved into the technical advisor role, it was amazing. Yes, my emails did increase, but what actually happened was the reduction of people just reaching out to connect and to learn more and to identify opportunities. And I think it was a case of people were slightly intimidated.

I think one of the most valuable mechanisms I use today is, I've always had a rule that anyone that reaches out, regardless of where they are in the organization, I'll always give them 30 minutes. And so, when I was in the TA role, one of the great things that offered was the ability to have very junior members of people who worked in the organization, from our builder community or from our fulfillment centers, reach out to very senior individuals in the organization who'd reach out for a thirty-minute connect to learn more.

I also ensure that I have a set amount of time every month that I set aside specifically for mentoring. So, I usually have four slots and you get four slots, four weeks or four meetings to be able to engage. And at the end of that, we make a decision — do we continue, do we not continue? And that sort of enables people to have also an exit plan or an exit ramp on some of the mentoring as well.

Clarke Rodgers:
That's fantastic. I'm sure they appreciate the opportunity. Sara, thank you so much for joining me today.

Sara Duffer:
Thank you so much. This was great.