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.
Jessie, thanks so much for joining me today.
You're welcome, Clarke. I'm glad to be here.
Can you tell me a little bit about your background
and what brought you to AWS?
So I began really early in my career
as individual contributor,
like literally the person running the Cat5 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 2000s,
a lot of IT leaders were really diving into security.
So. Oh wow.
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 you know, during that process,
I was just subject to audits, you know,
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.
Now here I am in AWS.
So I've been in 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 PCI QSA company for AWS.
So let's talk about that. So AWS SaaS.
Tell me about- Yeah.
the organization and how it came to be.
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.
Okay.
And so the reason why we created this
when 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- Sure.
and lots of audit experience,
but an actual certified individual
that was both an expert on the AWS platform
and the framework- Okay.
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.
So if I heard you correctly,
you're focused right now on PCI and HITRUST?
Right.
Is it a fairly even blend
between those requests from customers?
Are you getting more PCI, more HITRUST?
What's it kind of look like? Yeah,
well, definitely the majority of our work is PCI.
That's where we started and that's where the most demand is.
We also do a lot of SOC 2 guidance, NIST guidance.
I don't go through the alphabet soup here,
but you understand, like, you know,
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. (chuckles) Right.
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.
I find that that's probably the trickiest thing, right,
is to translate to an auditor who has been doing
this for years in an on-prem environment to,
quote, unquote, "cloudify" it. Yes.
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 is a great example
of kind 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,
where we wanted to have that voice
for external auditors, for our customers,
for internal teams to be able to share that story
of how they can let customers
can leverage the cloud to be compliant.
But so we had that very high level understanding of 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. Right.
I meet you in an elevator.
You ask me what I do, I tell you that.
Right.
But what the team actually learned
over the last four years is just all of the how.
And one of that is, you know,
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- Right.
how to think about the cloud environment.
Again, it's back to that sort of translation function.
Exactly. Yeah.
So we're translating, you know, for example,
here's how you get an asset, you know, list.
You know, 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- Okay.
that bridge between here's what they understand
about their on-prem environment
related to a specific control.
And here's how that control- Sure.
is now looked at in the cloud environment.
Okay, so if I'm a customer then and I use AWS SaaS
to help and it's to help me for my PCI,
AWS SaaS doesn't actually certify me.
Is that correct? Yeah,
that's a really great question and one I get quite a bit
and you know, although we never say never,
it's not our intention to write reports on compliant.
Okay.
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, right?
And we're working shoulder to shoulder with our customer.
And you know, 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- Sure.
have the ability to.
It's not something that we believe we need to do
given the strength in our partner community.
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?
Yeah, well, what's interesting
about the start of the engagement is
that the stakeholder that finds us
is not what I would think, you know?
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,
right? Interesting.
I know because- Why do you think that is?
(laughs) Well, I know why it is
because they've been given a task.
They're saying, "This work load 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.
Okay.
They went directly to their partner
that it was a HITRUST, this is a HITRUST example.
So the customer came to us through their partner
who was their HITRUST 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 HITRUST certification.
It's very complex, very dynamic framework.
And in this case,
for them to get to this additional piece of market segment,
HITRUST certification was a business requirement
they had to meet for their customer.
So we start working together with our partner very closely.
We were to able to get them
to achieve HITRUST certification within 12 months.
So we decreased that by 50%. Wow.
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, you know,
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 the hands-on builders who were actually building
the application and building the environment.
So that's how we were able to,
you know, get them to, you know, HITRUST readiness
by the time the application was ready to go live.
So it was an extremely accelerated timeline.
and that's where we found
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.
So I imagine there was a lot of automation
that went into that and code development to actually
extract the evidence- Right.
and show that this is in fact
meeting the compliance outcome that they're looking for.
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 the, "Here's a script,"
or "Here's exactly how you can
pull the evidence on the backend."
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- Right.
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.
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.
Yeah.
What are you and your team doing
to help those auditors understand this whole process?
because, you know,
user stories and EPICs are not part
of a normal auditor's vocabulary.
So how do you help educate them?
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 audit,
those compliance leaders that ask us to stay
a little bit longer or, you know, start to see the value.
So earlier you mentioned Cloud Audit Academy
and I imagine the target audience for that are,
you know, are sort of 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?
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 kind of step through, I guess quickly too,
there is a 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.
Oh wow.
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. Oh, great.
You know, because these are the regulators that are going
to 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 that, you know,
our initial mission of really being an industry voice
as it relates to audit and helping people think differently
about audit in AWS specifically.
And then everybody's speaking
the same language effectively.
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.
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?
I don't think there's a one size,
you know, fits all or most,
but I definitely see they're understanding the value
of having compliance engineers.
Okay.
You know, 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.
Right.
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, you know,
in depth on how technical we can go
because they see the need to have that understanding
within their audit team.
So I think it depends 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- Sure.
and ease some of that compliance burden
that customers are facing today.
What do you see the future of AWS SaaS
like 5 or 10 years from now?
What kind of services are you going to be offering
to customers, do you think?
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 that's, you know,
we have to think about customers
that are migrating to the cloud.
They're building, they're innovating very fast.
Sure.
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, right?
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, you know, on every second,
or every few seconds, right? Right.
So we're thinking big and trying to incorporate ways
of that, building that automation going forward.
Jessie, thank you so much for joining me today.
You're welcome, Clarke. I really enjoyed the conversation.