How to Pass Your Compliance Audit With AWS

Clarke Rodgers (00:08):
Customers today are trying to figure out the best way to integrate security into their core business practices. 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 Jessie Skibbe, Senior Practice Manager for AWS Security Services. Jessie runs a unique business inside of AWS and is an expert in audit and compliance.

These are questions and answers you may have as you continue your own transformation journey to the cloud. We hope you enjoy.

Clarke Rodgers (00:46):
Jessie, thanks so much for joining me today.

Jessie Skibbe (00:48):
Yeah, thanks for having me. Excited to get into this conversation.

Clarke Rodgers (00:50):
Can you tell me a little bit about your background and what brought you to AWS?

Jessie Skibbe (00:54):
So, I began really early in my career as an individual contributor — like literally the person running the CAT five cable, managing the on-prem servers and applications. Worked my way up into Director of IT for three facilities in the company I was at. Then I transferred into another role where I worked in financial services.

So in the, I guess early 2000's, a lot of IT leaders duly diving into security. So I took the route into security at that point. So I was responsible. I became responsible for security for our organization. That led me into also a compliance role because again, in financial services, but also serving public sector customers. So it was a really wide variety of different regulations that my company that I worked for had to comply with. So I just dove straight into compliance, security. At that time, of course, we learned that it was appropriate to separate the two. So not having technology and security leadership responsibility.

And during that process, I was just subject to audits, just a lot of audits from our customers. And so I took a different seat on the other side of the audit table. So I actually went to work for a third-party audit firm. It was a PCI, a Payment Card Industry qualified security assessor, and also a CPA firm. And now here I am at AWS. So I've been at AWS for a little over four years now. And when I first started, I was the first employee of a new subsidiary that was being created. And my first job was to create a PCIQSA company for AWS.

Clarke Rodgers (02:30):
So, let's talk about that. So AWS SAS, tell me about the organization and how it came to be.

Jessie Skibbe (02:38):
Yeah, that's a great story. Part of the Amazon culture is to be misunderstood for a period of time while you're inventing something new. So essentially, if you want to think about it, we are an audit entity within AWS. And so, the reason why we created this, what I told this story a lot in the beginning, “Why is AWS creating a QSA company?” And the reason was that our customers were asking for prescriptive guidance from a qualified security assessor.

So there's lots of great individuals with former certifications and lots of audit experience, but an actual certified individual that was both an expert on the AWS platform and the framework was really that kind of unique skillset that we were able to combine and be able to provide our customers with the expert audit guidance they were looking for.

Clarke Rodgers (03:27):
So, if I heard you correctly, you focus right now on PCI and High Trust?

Jessie Skibbe (03:33):
Right.

Clarke Rodgers (03:34):
Is it a fairly even blend between those requests from customers? Or are you getting more PCI, more High Trust? What's common?

Jessie Skibbe (03:42):
Yeah. Well definitely the majority of our work is PCI. That's where we started and that's where the most demand is. But we also do a lot of SOC2 guidance, NIST guidance. I won't go through the alphabet soup here, but you understand, if it's security assurance and it's compliance related, we can help customers.

And a lot of times it's even the customer bringing their internal control set to us saying, “this is our on-prem environment, these are our controls that we have to be compliant with.” Because rarely does a customer have one, rarely. So it's always a mix of multiple requirements, including some requirements they may be getting from their customer on down the line. So, if it's a security assurance control, we're going to help a customer through navigating it — how to architect, how to build it on AWS, and also how to tell that story to their auditor when they're ready for the actual assessment.

Clarke Rodgers (04:33):
I find that's probably the trickiest thing, is to translate to an auditor who's been doing this for years in an on-prem environment, to, "cloudify" it.

Jessie Skibbe (04:44):
That's actually a really good point because we do act as translators the majority of the time. And what I want to go back to, too is when we first created this subsidiary, it’s a great example of understanding what we wanted to do. And we got really clear immediately about what it was. We wanted to help customers overcome compliance obstacles. We wanted to have that voice for external auditors, for our customers, for internal teams, to be able to share that story of how customers can leverage the cloud to be compliant.

So we had that very high level understanding of the “what.” And this was what I really worked hard on communicating with the team. “If we do nothing else, we help customers pass audits.” Straightforward, simple, I meet you in an elevator, you ask me what I do, I tell you that. But what the team actually learned over the last four years is just all of the “how.” And one of that is a lot of times in our customers what we see is that the audit, the compliance, the risk professionals are sometimes the last to get the deep education in cloud.

And so along the way, we've created programs such as Cloud Audit Academy, which was a partnership between AWS Security Learning and our team to be able to create an educational series so that we could help internal and external auditors understand how to think differently about the cloud environment. So we've never sought out to teach audit, but we do teach auditors how to think about the cloud environment.

Clarke Rodgers (06:17):
Again, it's back to that sort of translation function.

Jessie Skibbe (06:20):
Exactly. Yeah. So we're translating, for example, here's how you get an asset list, thinking about your asset control, and on prem, and now what does that look like when you're in a cloud environment? So we give tips and education on that, and we tie it really closely to industry frameworks that they would recognize. So all through the training they get, “here's the NIST reference,” “here's the ISO reference,” so that they can create that bridge between, here's what they understand about their on-prem environment related to a specific control. And here's how that control is now looked at in the cloud environment.

Clarke Rodgers (06:54):
Ok, so if I'm a customer then, and I use AWS SAS to help and it's to help me for my PCI, AWS SAS doesn't actually certify me. Is that correct?

Jessie Skibbe (07:06):
Yeah, that's a really great question and one I get quite a bit, and although we never say never, it's not our intention to write reports on compliant. And the reason why is we have a great wealth of partners out there that are serving our customers really well today. And we're not looking to compete with that.

In fact, we look to empower our partners and by working together, we essentially set the ball on the tee for the auditor, and we're working shoulder to shoulder with our customer. So engineering teams all the way through to internal audit teams, we're there to help guide them, but we're not there to write the audit report, even though we technically have the ability to. It's not something that we believe we need to do given the strength in our partner community.

Clarke Rodgers (07:51):
Got it. So could you walk me through what a typical engagement would look like for, let's just say a PCI customer that comes to you?

Jessie Skibbe (07:59):
Yeah, well, what's interesting about the start of the engagement is that the stakeholder that finds us is not what I would think. It's not what I thought coming in. We're not working with the CISO organization, we're not working with compliance leadership, we're working with engineering or technology leadership.

Clarke Rodgers (08:14):
Interesting.

Jessie Skibbe (08:15):
Right, I know?

Clarke Rodgers (08:16):
Why do you think that is?

Jessie Skibbe (08:18):
Well, I know why it is because they've been given a task. They're saying this workload that you're migrating to AWS or that you're building, we have to be PCI compliant, just full stop. And it's a major business outcome because if they're not, they're not going to be able to continue doing business with certain customers and fines and fees. So it's a business outcome that's relayed to technology leadership. So the technology leader or the engineering leader knows they have a business outcome they have to achieve. They're just not sure exactly how.

So I'll actually give you an example, Clarke, because there was a story that we helped a customer in the early part of the pandemic that was really meaningful in a lot of ways. So we had a customer come to us and in this case actually they found us through a partner. They went directly to their partner, that it was a High Trust, this is a High Trust example.

So the customer came to us through their partner, who was their High Trust assessment company. And the partner knew we were working on a partner-aligned offering to provide to customers because we can work on preparing them for audit, they actually take them through the whole audit process. So they found us through there. And the opportunity from a business standpoint for our customer was that it would normally take a customer 24 months to achieve High Trust certification. It's a very complex, very dynamic framework. And in this case, for them to get to this additional piece of market segment, High Trust certification was a business requirement they had to meet for their customer. So we start working together with our partner very closely. We were able to get them to achieve High Trust certification within 12 months.

So we decreased that by 50%. And they were able to enter that new market and provide services to a wider variety of customers in the pandemic timeline. So that just felt good. It felt like we were doing the right thing and really allowed us to test out this concept of being able to provide that compliance advice. So in this particular engagement, what we did was provide user stories and epics and compliance-specific guidance into the hands-on builders who were actually building the application and building the environment.

So that's how we were able to get them to High Trust readiness by the time the application was ready to go live. So it was an extremely accelerated timeline, and that's what our true value is to customers, is to be able to accelerate that timeline because of our unique marriage, I guess, of expertise, of the compliance expertise along with the AWS expertise.

Clarke Rodgers (10:47):
So I imagine there was a lot of automation that went into that and code development to actually extract the evidence and show that this is in fact meeting the compliance outcome that they're looking for?

Jessie Skibbe (10:58):
Yeah, that's actually a really great point. I didn't touch on evidence, but yeah, it's not only the builder guidance that we give from an engineering perspective, but it's also that “here's a script” or “here's exactly how you can pull the evidence on the back end.” And then the other piece that we provide that's really important is that true bridge of information between the technology and the audit control. Because we tell the story, our primary deliverable we call an audit playbook. And that essentially makes that connection between the technology, here's how it's functioning, and here's how you gather evidence. So like I said earlier, we put the ball on the tee for the auditor, and this case was our partner could go in and write that audit report very quickly knowing that they have all the information in front of them ready to go. So that's how, in a sense, we accelerate the audit process.

Clarke Rodgers (11:42):
So you mentioned earlier that the engineering teams are the ones who typically find you because they need the help from an engineering perspective to either understand the compliance requirement or develop the evidence for their either internal auditors or external auditors.

What are you and your team doing to help those auditors understand this whole process? Because user stories and epics are not part of a normal auditor's vocabulary, so how do you help educate them?

Jessie Skibbe (12:10):
Yeah, that's a really great question because although I said they don't find us initially, we find them. So we take the initiative, the bias for action to connect ourselves with the internal audit, with the compliance teams to have the right stakeholders at the table. And we find that there's sometimes a little bit of hesitancy to work with us. But once they understand that we are actually industry certified auditors, we're not engineers ourselves, we are there because audit is our focus. And once we can earn their trust with the actual road mapping that we do for them, we become their best friend over time. I mean, it's the engineers and the technology leaders that hire us, but it's definitely those internal auditors, those compliance leaders that ask us to stay a little bit longer or start to see the value.  

Clarke Rodgers (12:57):
So earlier you mentioned Cloud Audit Academy, and I imagine the target audience for that are the big four audit firms, customers with their internal audit and compliance teams. Is there anybody else that takes advantage of that material that you know of?

Jessie Skibbe (13:12):
Yeah, that's a really great question because we really did build it for the audit community, and that really means anyone who wants to learn more about cloud audit. And just to step through, I guess quickly too, there is an agnostic version. So it's not AWS specific, that's the 101 course. There's also the 201, which dives a lot deeper into AWS specifically. And then just recently at re:Inforce, we released Cloud Audit Academy 301, which is PCI DSS specifically. So we're really just getting started with that.

And actually, we're starting more with internal audit teams wanting to learn more about PCI, but from a cloud audit Academy 201 perspective. So this is AWS specific and it really does, it covers the wide variety. If you think about all of the basic controls, access control, physical security, that's a great course. And interestingly enough, it's caught the attention of some regulators. So we've actually done several international and US-based regulatory agencies that have expressed interest and have wanted to train their staff, which makes a lot of sense. Because these are the regulators that are going into our customers and evaluating their AWS environment.

So, to me, that's a big win when we can actually reach all of the members of the audit community, customers’ internal audit, third party audit companies, as well as regulators. That goes into our initial mission of really being an industry voice as it relates to audit and helping people think differently about audit in AWS specifically.

Clarke Rodgers (14:45):
And then everybody's speaking the same language effectively.

Jessie Skibbe (14:48):
Right. We actually had one regulator that was attending a course alongside of several of their customers, so talk about powerful conversation. We're quite flexible with who can receive the training and like I said, our overall mission is to enable auditors in all different types of roles.

Clarke Rodgers (15:06):
So, in that same vein, how are they building out their organizations today? Is it, yes, there's the audit talent or the compliance talent, but they're also hiring engineers for their team?

Jessie Skibbe (15:17):
I don't think there's a one size fits all or most, but I definitely see they’re understanding the value of having compliance engineers because the idea of having continuous compliance integration in the pipeline is obviously where the majority of our most mature customers either are or are going. And also having that understanding even with internal audit teams, which our Cloud Audit Academy has grown.

The program that we started several years ago has really grown because customers are seeing the need to have that more technical... It's grown as far as in depth and how technical we can go because they see the need to have that understanding within their audit team. So I think it depends on where they're starting, where they want to invest. But I definitely see that compliance engineering, that whole concept of how can we actually innovate, bringing the right people to the table to actually innovate and ease some of that compliance burden that customers are facing today.

Clarke Rodgers (16:13):
What do you see the future of AWS SAS like five or 10 years from now? What kind of services are you going to be offering to customers, do you think?

Jessie Skibbe (16:21):
So, we're constantly thinking about ways we can scale and provide greater levels of automation to our customers. So we've got some ideas, some things on the roadmap that we're building to be able to serve more customers with fewer resources. So more to come on that. But we have to think about customers that are migrating to the cloud, they're building, they're innovating very fast. That's the thing that cloud gives them the ability to do. So how can we incorporate compliance at the speed of innovation that they want to go?

So we have to think differently about how we provide, how we inject that compliance information, how they can incorporate builder guidance and testing guidance into that. We're publishing code every second or every few seconds. So we're thinking big and trying to incorporate ways of building that automation going forward.

Clarke Rodgers (17:11):
Jessie, thank you so much for joining me today.

Jessie Skibbe (17:12):
You're welcome, Clarke. I really enjoyed the conversation.