Scaling Compliance and Security Assurance at AWS

Clarke: (00:05)
Chad, thank you so much for joining me today.

Chad: (00:07)
It's great to be here.

Clarke: (00:09)
So could you please share a little bit about your background and what brought you to AWS?

Chad: (00:14)
Yeah. So I've been with AWS about 11 years, been doing security and compliance ever since I've started back in 2010. And I came from EY where we did a lot of security consulting, a lot of business continuity consulting. And that background was really good to help me doing what I am today, and that is security compliance for AWS.

Clarke: (00:43)
So as the Head of Security Assurance at AWS, what are some of your primary responsibilities? 

Chad: (00:49)
Well, our primary goal and mission is to help our customers move regulated and really sensitive data to the cloud and a lot of things come along with that. You need to be able to prove internally that you've got your environment secure. You also have to audit AWS, make sure your supplier, AWS is secure. And so that's where we come in, where we prove through audits and certifications and other direct audit engagements that the things we're doing in the background, the things that the customers can't see, is secure and compliant with all the different kinds of regulations and certification standards that we adhere to.

Clarke: (01:35)
So you have internal teams, internal compliance teams making sure that AWS services meet a certain bar. I imagine you also work with external third party auditors and regulators?

Chad: (01:46)
Yeah. Yeah. So most of our work is related to the external engagement with external auditors, regulators, regulator examiners, and customers that are also performing audits on AWS, doing their own due diligence on us.

Clarke: (02:03)
Got it. So AWS is famous for being the largest startup that's out there. And we move very, very quickly, and we release products and features to customers as they ask for them or as soon as possible after that. I imagine in your world, you're looking at this control and that control, and everything has to be perfect. How do we, and specifically your team, meet that need of still being able to move fast, but then meet the compliance and security assurance goals?

Chad: (02:35)
That's a great question and one that we get constantly challenged on. I mean, we definitely want to keep and maintain that culture of moving quickly, iterating quickly, releasing great products to customers.

Chad: (02:53)
That sometimes goes at odds with what we're trying to do, and that is make sure the processes are documented, the controls are documented, and that we have all the controls needed for big comprehensive compliance frameworks, like FedRamp, or ISO, or others, where they require a comprehensive control framework and processes that match what the industry expectations are on those best practices. So that is a challenge sometimes when what we're doing does not actually conform with what maybe traditionally other companies might be doing.

Chad: (03:31)
But the great thing about working here and being part of this team is that security is job zero. And the reality is if you can get security right and you can invest in security and everybody's on this same page, the rest of the compliance stuff is pretty straightforward. I was going to say easy, but I meant it's pretty straightforward, meaning we can go document, we can kind of trail behind what everyone's doing and formalize the documentation, document the processes in ways that resonate with the auditors and with the regulators.

Chad: (04:10) 
Sometimes there are some things that we need to do and improve. And over time, as the auditors get deeper in what we're doing, we are helping improve things as well. But primarily, because we have security nailed so well internally, both from the tactical point and the leadership sponsorship point perspective, then it really does make it so our job is pretty straightforward.

Chad: (04:37)
But yes, our team also does a lot of things to help enable, relieve the burden of the compliance processes and the audits from our service teams. We do that as much as we can. And as we do that and as we get better at doing that, the more we can scale, the more we can do more of these kinds of audits for more customers and more GOs.

Clarke: (05:00)
I'm glad you brought that process up. Many customers struggle. You know, they have applications that they make available to their customers and they have to audit it them sometimes that's a write the application, put it into production, and then the audit team takes a look at it and makes sure it meets whatever standard there is. I would imagine at the speed and scale that we operate, that there may be some automated artifacts that come from the development process itself within AWS that helps everyone.

Chad: (05:33)
Yeah. I mean, that's another issue of things we have we're challenged with as we scale, is how much of the evidence can we gather versus where we need to require some kind of engagement with the development teams to say, we can't get this evidence ourselves. We need you to provide the evidence for us or talk to the auditors for us.

Chad: (05:58)
So our ability to provide services, the services to our customers that are in the internal developers, services such as doing the documentation, gathering the evidence, kind of making sense or framing up what they're doing in, in how the auditors want to see it, the better we are at that, the more we can scale, the more we can expand our compliance frameworks to other different types of certifications, other different types of customers and other GEOs.

Clarke: (06:33)
So do you have talent within your teams that actually writes code to help gather evidence? And do you develop your own programs to do that?

Chad: (06:40)
Yeah, that's a good question. And that's a question that I often get from customers in that, like how do we structure the team in that regard for as far as how technical are we? 

Chad: (06:50)
You know, we do have a team. I do have an engineering team that does this. That's kind of a control automation team and like a workflow team that does things like enablement for evidence collection and things like that. It's really important that we have this team. It is really essential because we're dealing in our organization with a bunch of developers and we need to be able to speak their language. We need to not only be able to speak their language, but also we need to know what tools they use. We need to understand how they develop code, how they deploy code, how they secure that code, what they have to do to launch, what they have to do to operationalize their services, updates, things like that, providing new services. We have to understand it in such depth that we can then build tools that plug in to how they work.

Chad: (07:45)
And I think it's a big key because a lot of times you'll see a compliance team or program with none of that understanding and then they just kind of end up throwing over the wall, a bunch of requirements with the compliance hammer of, hey, if we don't do this, we're going to be in trouble. And that really isn't like a good way to really enable scale. It doesn't scale. It can be done that way, but that actually doesn't scale. The only way to scale is to be really embedded to the way that they work and take that and enable them to do their work just as they normally do without any interference, like compliance specific interference. If we're really successful at that, then that makes a very, very scalable compliance program.

Clarke: (08:39)
That sounds a lot more collaborative than some of the stories that I hear where people avoid the compliance people altogether. I imagine with this people don't avoid you in the coffee room or anything like that.

Chad: (08:49)
And that's that good point. There are many times when the tech leaders will come seek me out to better understand what's required and kind of how they can help support me and my team because of that, because they understand that this part of the business, the compliance angle for us, AWS, it's absolutely essential in order for our customers to use us for those regulated workloads. Otherwise they just simply can't and there's a big bit of our customer base we couldn't serve if we weren't doing that. So they understand that and they seek me out many times to help better coordinate a line and get resources and things to help support their business.

Clarke: (09:34)
So Chad, you meet with a lot of customers and regulators and auditors. What trends are you seeing from those groups as far as how they look at cloud service providers and how they go about auditing them?

Chad: (09:45)
Five years ago, I thought for sure by 2020, we are going to have a situation where auditors share evidence and we don't have to ask for evidence over and over. Well that hasn't materialized at all. If anything, they're backing away and saying, you know what, our evidence is our own, we need to subjectively and objectively take a look at your environment. We need to be able to draw our own conclusions. And if you've gathered evidence for somebody else, we're not going to accept that. We need to do our own testing and our own sampling. And so unfortunately that's the case. So we have to get very, very good at generating evidence and our evidence generation capability has grown to match that, but we're still... I mean, we can always do better because it is a difficult part of it.

Chad: (10:35)
But I would just say overall, I would say people are getting smarter. They're asking the right questions. They're asking deeper questions. And we are getting better at answering those just with all the experience we have with these customer auditors and regular and external auditors.

Clarke: (10:53) I would imagine exactly as you said, that as people are... Cloud is no longer a novelty, right? It's being used everywhere and by everyone, therefore people are getting a lot more experience with it so they know which questions to ask. So I know we have some customer facing tools like AWS Artifact that allow customers to take a look at our third party attestations. Is there anything else that you make available to regulators? You know, they may or may not be customers as well, to help satisfy them?

Chad: (11:23)
Yeah.

Clarke: (11:24)
As far as our controls go?

Chad: (11:26)
Well, I would say that first off, customers that are using AWS and they're validating their supply chain, those kind of audits are very different because we have to put in context how they're using AWS with what we do behind the scenes that they can't observe. And so we help them with that. And it's a more straightforward conversation than a regulator that's not a user of AWS. They'll come in and they'll just start asking questions based on how they think we should be managing risk and things like that. It's a bit more challenging than because we don't have any context of their use to put it in, right?

Chad: (12:10)
So when customers ask us, it's really great partnership. They tell us how they're using AWS. They basically explain to us how they need to articulate their use and the supply chain of their use to the regulators. And so we can help them and we can point them in the right directions. And it's a very good and positive partnership there.

Chad: (12:35)
Regulators, it's just a little bit more broad and asking questions that don't have that context. So it's just a different challenge. But we still... Like, I think one of the takeaways that we've taken away in the past couple years, and that is to treat our auditors and our regulators and our customer auditors like real partners. And that's something that, like you said earlier in this interview, a lot of customers, or a lot of people in general, just don't want to deal with compliance. Regulators are here. Oh, no, Let's shut the doors. Everyone shhh don't say anything, you know? And that really creates kind of barriers between the two organizations. And I think that those barriers exist everywhere, especially with big banks and their regulators or healthcare companies and their regulators.

Chad: (13:26)
There's sometimes... the level of partnership varies, but we see with us and with our customers, those that have a true partnership with those examiners and auditors, it makes it so really they can help each other out because auditors and examiners are their customers too, really, even if they're not using AWS, they're customers, they need to understand, they need to accomplish some things. And the more we're proactive about helping them accomplish what they need, the faster it goes and the better experience it is. So we really have learned that lesson where being a true partner and really engaging with them in a positive way is really the best way to go and probably the only way to scale any of this in the future.

Clarke: (14:12) 
So in that same vein, what kind of mechanisms, training materials, education materials do you make available to regulators and third party auditors so they understand the cloud better and maybe how to audit it better?

Chad: (14:28)
I think gone are the days where they come in and they don't know anything about the cloud. I think back in 2012, the GM of S3 was in an audit meeting and the auditors ask what's S3? And then later he pulled me aside and said, why are they asking me these very basic questions? And so those days are gone.

Chad: (14:54)
I mean, there's just so much material out there. Not only do we have like the cloud academy, so materials that we've developed, that's cloud agnostic training, as well as AWS specific training. There's tons of better training and knowledge and understanding of the cloud out there. So we're not at square one anymore. We're square two, or maybe even three by the time anybody comes in.

Chad: (15:21) 
So we though, we need to help keep get those examiners and auditors ramped up and we have internal materials that we have. We have something called the Digital Audit Symposium where it has a lot of the narratives and the control narratives and things, and presentations by the control owners and the GMs talking about how they operate their service, and in relation to the controls. So we have a lot of that stuff available, but it only goes so far because like I said, the whoever's coming in to do the audit will ask their own questions and dive deeper and we have to answer those on the fly, in an interview kind of format. And that's just the kind of the standard in the industry. But we are getting better and better as we write more narratives because whenever we get asked a question about something very specific and deep, we will say, we'll write a narrative on it. And so then the next person who asks us, we have a narrative ready and so they can more easily read it and understand it.

Clarke: (16:25)
Chad, thank you so much for joining me today.

Chad: (16:27) 
It's great being here. Thanks, Clarke.