Think Like an Auditor: How to Measure Security Compliance

Clarke Rodgers (00:07):
Compliance and regulatory frameworks are a critical element of a robust security organization. Understanding the requirements landscape is a very real challenge for many AWS customers. 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 Samara Moore, Senior Manager for Security Assurance at AWS. Samara and her team work diligently to help customers overcome their compliance and regulatory challenges. We hope this conversation provides useful insights for you and your team as you continue your own cloud transformation journey. Thanks for joining us.

Clarke Rodgers (00:59):
Samara, thank you so much for joining me today.

Samara Moore (1:01):
Yeah, thanks for having me. Excited to get into this conversation.

Clarke Rodgers (1:05):
If you'd be so kind, I'd love to hear more about your background, and what brought you to AWS and then your current role?

Samara Moore (01:11):
Sure. So my background, I'll say I've always been interested in security. At the time I started there wasn't really a “cyber security.” It's gone through number of name changes since the late nineties. But I started out working in consulting, doing risk assessments and security assessments. And over time got hired by one of my customers, a government customer. And that's where I got into government service and got to do a bit more hands-on security, which I really craved. And during that time, I got to work not just on government systems, but really help shape the policy that the US was forming around protecting critical infrastructure.

During my time there, I did a detail at the White House where I got to work, not just on the energy sector where I had been focused for several years, but also other critical infrastructure sectors. And leaving there, went to go work for a private entity and it was while I was there, I really got a good understanding of how using IT services helps enable our mission.

I came here to really help tackle a tough challenge, and that was working with critical infrastructure companies or really those companies that are more regulated. Working with them so they would feel comfortable and have that assurance that they could run their most critical workloads using AWS services. I knew it was a tough challenge, but that's what attracted me to AWS. And that's why I'm here, to really build upon the work I've done with regulators in the past and really help with the digital transformation while still driving for secure and resilient infrastructure in critical services.

Clarke Rodgers (02:59):
Do you primarily work with regulators that are regulating AWS or regulators that are regulating our customers who may run some of their workloads on AWS, or of all of the above?

Samara Moore (03:13):
It's a mix of both. Regulators are focusing on ensuring those critical functions, which many of our customers operate, are secure and meeting their requirements. As a result, their underlying infrastructure, they want to have assurance that that meets the security, and reliability, and resilience requirements. So that's where we get brought in more indirectly. There's direct oversight by regulators with AWS, so we get involved there as well.

Clarke Rodgers (03:44):
I've had conversations with compliance and audit professionals, so I'm going to guess that this is similar in the regulatory world, that there's a need to do basically some translation between, this is how things were done in an on-premise environment and this is how things are done in the cloud. But then the ultimate outcome is the same. Do you spend a lot of time basically being a translator with regulators and teaching them cloud as well? Or how does it all work?

Samara Moore (04:16):
Yes. That's a good bit of what we do. And I pulled from some of my prior experience when working with regulators now and really step back and say, "Okay, what security objective are you really focused on? Now let's talk about how that objective is accomplished using cloud services." And really advocate for flexibility to focus on accomplishing objectives versus prescriptive security requirements, many of which are asset based, which kind of breaks down when you get to using cloud services and could keep our customers from taking advantage of the full capabilities available to them in the cloud.

Clarke Rodgers (04:57):
So what is your team made up of? Is it sort of audit, compliance, regulatory professionals, or is there engineering professionals? Are there tech professionals? What does that look like?

Samara Moore (05:09):
It's a mixture. It's always all of the above. In fact, we target and we recruit individuals that have a strong background within a given sector or industry and understands the regulatory landscape, and really what the regulators care about.

So we have people with a compliance background, some with an audit background as well, but we also have engineers. So, we have team members who started out focusing more as solution architects or doing more technical work and have supported customers in the compliance space, and actually are really good at doing that translation, that are interested in doing the regulatory engagement space.

And then understanding our customer needs is really, really important and allows us to get ahead of things. And so we have some individuals who have come from our sales team and who are used to working with customers, and that is really helpful to round us out and help us stay customer aligned and look at things from a different perspective.

Clarke Rodgers (06:09):
So as part of our shared responsibility model, AWS has certain responsibilities for the security of a customer's workload, and then the customer has certain responsibilities for the security of their workload.

In a regulatory context, if a customer needs to meet some sort of regulatory obligation that a particular service may not have at the time, I assume your team will do that sort of translation like we already talked about, but maybe in the other direction this time to the service teams to say, "Hey, here's a regulatory obligation that we need to meet and this is the outcome that we need to have." And then perhaps your engineers actually work with them to achieve that outcome? Or could you help me understand how that process works?

Samara Moore (06:56):
So, there can be a situation where there could be either a new requirement, or unique requirement, for a specific industry that customers have raised that they need the capability or the ability to meet. And so what we would do again is seek to understand that requirement. Part of it, honestly, is first making sure we really understand what the regulator, again, is trying to achieve.

Clarke Rodgers (07:18):
Sure.

Samara Moore (07:19):
And see how we can best do that with our existing services. Where there is a need to offer something different or in addition to what's already there, what we'll do is work with the service teams again to see how do we best meet this new requirement, or help our customer meet this new obligation? And then the service teams will work to build that in to their roadmap.

I think a good example of this is, and this isn't necessarily with service teams, but working with solution architects to create capabilities to make it simpler for customers to comply. Where we've helped customers map to their requirements to capabilities that we have within different services and develop quick start guides and templates to where that can help automate a good portion of the work that they have to do, and then they can tailor it from there.

But it really gets back to understanding the shared responsibility model and how it's applied to their specific solution and how they're using cloud services. So, to help that, what our service teams have been building out over the last few years has been additional security documentation that has been really helpful. And it's just publicly available to where our customers can go and see where it may map to frameworks already or security domains. If there's a framework where they would like mapping, our team works with service teams and solution architects to provide that mapping, just, again, to help simplify security and their efforts to meet their compliance obligations.

Clarke Rodgers (09:03):
And I imagine part of that process is also to help define what the right evidence looks like, because the regulators and the auditors that support all this want to see proof, right?

Samara Moore (09:15):
On the evidence side, again, so much of it is going to be specific to that customer's environment. So when we are dealing with evidence, oftentimes it's on our side of the responsibility model, so security of the cloud, but we can walk through with customers and help. If they're sharing what they'd like to provide, we can give them some guidance on how they can do that using our services.

Clarke Rodgers (09:38):
Got it. So if I'm a regulated customer and I'm coming to AWS, what are some of the first things that I'm going to want to do to make sure that AWS is the right place for my regulated workloads?

Samara Moore (09:58):
One of the first things you're going to want to do is understand how we meet the core security requirements and understand what they are inheriting from AWS and how that aligns to what they have to demonstrate. So, depending on the regulatory framework that they have to follow, they may be able to simply say, "Hey, AWS is meeting these industry standards. There's independent third-party validation of it here. We can provide proof of it." And they're good to go.

Other instances, their regulator may ask for a bit more detail. And so the customers should appreciate that where that's the case, those are discussions that they should have with us and we'll work with them to try to provide that. The other thing is to understand the regulatory framework that they have to follow and whether or not that language and guidance will allow them to use cloud services.

So, an example of this I'll pull from the US electric grid. They have requirements that are very device specific. And while they may not explicitly say you can't use cloud, the way the requirements are written, it's not clear how an auditor or regulator might interpret it. And if the customer is very risk averse, and this industry appropriately so is risk averse, they will be hesitant to use it. So they will want to understand where there's flexibility to leverage cloud. And then if it's not clear, where is the regulator going? So, are they open to this? Are they looking to change? Have they given some additional guidance in this space?

Clarke Rodgers (11:46):
And then I imagine you and your team are there to answer those questions and to help the regulator and the customer understand that, again, back to that outcome driven perspective that well, your outcome is this, here's how you can achieve it in cloud and then leave it. It's a much more educated discussion between the regulator, and the customer, and AWS at that point. Is that fair to say?

Samara Moore (12:09):
Absolutely. I go a little bit further and I use that example intentionally because that's a situation where, yes, it's a long-term gain. And I want to say that up front, right? These things don't change on a dime. But when you understand what those barriers might be, then we can start a dialogue with regulators. And that's where having a good relationship with regulators is so important.

And so, in the case of US Electric Grid, we have been working in partnership and responding to requests from the regulators to learn more about how security and resilience can be accomplished using cloud services. And over time with our engagement, and our customers' engagement, and others in industry, after I'd say probably about two or three years, they actually release guidance on how it can be done.

Now, that's huge because now customers have some specific direction from the regulator that says, "Yes, we know our standards are written this way, but for this type of data you can leverage cloud services and these are the things you consider." So we consider that a huge win for us. But, again, it's a long-term gain and it's that regular engagement with customers to understand where they're coming from, as well as with regulators.

Clarke Rodgers (13:29):
I imagine either you, or members of your team, or both are frequently in front of regulators giving education sessions, for lack of a better word?

Samara Moore (13:38):
Yeah, we are. In that particular case, AWS participated in multiple regulator technical sessions that were on the record, which was huge. They did a response to an open notice for feedback, and then actually joined the standards body so we could be directly engaged. And we do this, again, working with customers and on behalf of our customers.

Our team, I'll mention, is a global team and so the challenges and what we're talking about, it exists in all the regions that we operate. What we seek to do is have information sessions with regulators and it can take a number of different forms. It can be maybe a direct engagement on a particular topic that they've asked about. And what our team will do is pull together leaders from across AWS, from the service team, from our security and infrastructure team that have deep knowledge and understanding, and then we form that translation role.

We understand where the regulators are coming from, because we've been engaging with them, we understand our internal position, and then we try to bring them together so we can get to a good place in understanding how to meet that objective. So that's sort of a one-on-one. Sometimes we'll do a deep dive just on that, and that's awesome. It's closed door, open space to ask tons of questions and get answers.

The other type of session we'll have is where we'll do something like a round table. We've done a number of those around the globe just this year where we will invite several regulators in a region to come together. We'll learn from them, and it really starts out with understanding what do they care about. It's a great opportunity for us to listen and hear the voice of the regulator. But then we also, again, will pull together experts from within AWS to come and talk about the topic and really break down and understand what they care about, why they care about it. We may not always be able to solve it in the moment in that session, but we've got some great actions to take away and then come back to them and continue to partner with them in this manner.

Clarke Rodgers (15:42):
So, having a team and the talent on a team to actually do this is not what I would call standard, entry level IT work, right? So what kind of people are you looking for to join your team? What do you look for as a new hire on that team?

Samara Moore (15:57):
I look for a number of factors. One, someone who's willing to learn, who recognizes, they have a lot to bring but also a lot to learn. A security background. Not just a certification, but the ability to apply security concepts, someone who can think of the art of the possible and can really help with that translation between what we have today, and where we can go or understanding what the regulator wants to accomplish and then how we can connect the dots with our capabilities to accomplish that. Those are really important. And then, of course, getting back to some of our key leadership principles, the ability to earn trust as well as-.

Clarke Rodgers (16:44):
Especially important in your line of work.

Samara Moore (16:45):
Especially important, right. And then the ability to establish partnerships, to listen, to be told, "Hey, you don't quite have it right" and be okay with that. So that flexibility is really important.

Clarke Rodgers (16:57):
And then as the team grows, as an AWS security leader, you have a responsibility to bring up that next generation of leaders within AWS. Can you talk a little bit about the mentorship and leadership mechanisms that you follow to grow your team and give them more responsibility?

Samara Moore (17:18):
So, I think it's growing our team, but also helping contribute to the profession. I think one of the unique things we have here at AWS is that we see challenges other folks haven't seen. We work at a scale others haven't. I think we have a lot to contribute to the information security community. And so that coaching and mentorship is very important within our team. We also seek to do that externally with other industry forums that we participate in.

Within our team, we really push our leaders to always grow. One of the things I like to advise is we should always, and I do this for myself, seek a professional training and a technical training every year in some way, shape or form. We should always be looking to sharpen our skills. It doesn't matter what level you're at, you should have a coach and a mentor. So we encourage our team to be mentors and to be coaches to other people.

When it comes, though, to helping people grow, AWS has so many different opportunities. And just from a security perspective, so many different ways you can apply security expertise. So we do encourage folks that want to explore a different aspect of the challenge to transfer to other jobs. And it might seem counterintuitive if you've got this amazing person, but we do encourage job transfers, and I have been the recipient of several amazing job transfers. So that's another way that I think that we help coach, develop, and encourage growth within the team.

Clarke Rodgers (18:46):
So as your team grows and you meet more and more customer needs in the regulatory space, what KPIs or other measurements are you using to demonstrate the effectiveness of your team, both internally to AWS and then to customers as well?

Samara Moore (19:04):
Our approach to KPIs is a little bit different because we're not operational and this is a long-term game. But one area is our ability to shape and influence regulations or requirements before they come out, or even existing ones. And to drive change or different implementation guidance to help our customers. So that certainly is an indicator for us.

Another one is, quite frankly, when regulators are reaching out to us and they're knocking on our door and asking for guidance, that is a huge indicator that we have a successful engagement program. Over the last year, I've heard an interesting theme from several regulators where they say, "Hey, we want to partner with you. We don't necessarily want to just be transactional." We recognize there's some boundaries we have, but they are seeking to grow and understand in this space too, because they want to achieve their objectives in the right way. To me, that's a measure of success.

Another one that's, I think, more directly customer focused is when we can see, full circle, the output from feedback or requests that we've gotten from customers. So an example of this is in the telecommunication space where one of our leads got feedback from policy and customers around the need to meet this GSMA certification — so this mobile security certification.

Once we saw that that was a customer need that would be coming soon, we sought to understand what that certification required. This is what we need, this is what we're already doing. And we worked with the audit team to be able to demonstrate that through achieving a certification. We achieved that certification just in time for our customer to be able to leverage it in alignment with their roadmap, and have proceeded to do that and achieve it in two regions. And since then, we've had several customers now make the decision to leverage us because they felt comfortable and had assurance that they could run that critical workload on AWS services. So for us, that's a win because, again, it doesn't happen overnight, but we're able to see how we hear the voice of the customer, the voice of the regulator can take action internally and then deliver value for our customers.

Clarke Rodgers (21:37):
So a lot of our regulated customers who are using AWS may not be fully in the cloud yet, right? They still have some on-prem workloads and they have their own relationships with their specific regulators. I imagine they either have a desire to build a team like yours, or maybe they're in the process of it? Can you give some advice on what that team could look like and what their relationship with their regulator could be?

Samara Moore (22:05):
There's two aspects I'll call out. One, in engaging with the regulator, looking to be proactive and letting them know that you want to set up that proactive relationship. Likely the regulator wants the same. They want to have input and hear from others about the best way to achieve their different oversight objectives.

The other part is having those strong relationships internally so that they can translate the ability to understand their business and translate how these systems are enabling their business. And the role that they play goes a long way in being able to justify different decisions and work with the regulator. So having that translation ability and those different skill sets in the team is useful. Everyone doesn't need to be a security expert, but having people who have the ability to listen and talk to a regulator is really important. Someone who can take what the regulator's looking for, not just necessarily what they ask for.

Clarke Rodgers (23:21):
And understand the difference. Samara, thank you so much for joining me today.

Samara Moore (23:24):
Thank you. It's always a pleasure.