(update music)
- Welcome everyone.
I'm Cheryl Cage.
I'm a senior security partner strategist with AWS
and I am on the security and compliance partner team.
Our team is led by security partner strategists
and solutions architects
that come from the compliance and security background
and they're well versed
in moving regulated workloads on AWS.
And then we have,
the big part of our program is our partners here.
We have DuploCloud and A-LIGN with us.
And we are our partner-led, partner-driven program.
So we have vetted all of these
security and compliance partners
that can accelerate and automate that compliance on AWS.
And today, we are going to be talking about
streamlining and accelerating compliance for SOC 2.
So I wanted to turn it over to our two partners here
that we have.
And we'll start off with A-LIGN,
with Scott and Connor.
Can you tell us a little bit about A-LIGN?
- Yeah, absolutely.
So, in A-LIGN, we focus in and around readiness services.
So, predominantly professional services
in and around SOC 2 compliance.
We also support other compliance frameworks.
So as you mentioned, PCI DSS, HITRUST,
so on and so forth.
Our team has basically been,
built out these service lines in and around the space.
And, predominantly for our conversation today,
we'll be talking a bit about SOC 2, which is where we're one
of the largest issuers of SOC 2 reports in the world.
- I'm gonna turn it over to Venkat here from DuploCloud.
- We are a DevSecOps as a software company.
The general idea is that you would
use the DuploCloud software,
install it in your cloud account,
and give rather high-level specifications,
and the software automatically
takes care of implementing the lower-level details.
So while it does a lot of automation,
I would say automation is one part,
out-of-the-box security and compliance
is the core reason why people buy it,
about like 70, 80% of our customers bias for compliance.
So, and then we have done about two dozen
compliance certifications for our customers
and yeah.
Very excited to be here.
- We're happy to have you here.
And we're happy to have you show everyone
the great things that you're doing
around security automation and acceleration.
Some of the things that we're going to cover today,
we're gonna cover SOC 2, what is it?
What is the process?
We're going to talk about that SOC 2 journey,
how automation plays a part in that.
We also wanna go into like continuous monitoring,
continuous compliance, how does that help with the process?
And then we wanna go over some risks and pitfalls
for customers to avoid as they're going through.
What I wanna start off with is for A-LIGN here,
if you can explain what is SOC 2, why do I need it?
And then, what is that process?
- Yeah, absolutely.
So, as far as SOC 2 goes, we can start with the basics.
So as far as the definition goes,
SOC stands for systems and organization controls.
It's basically a security audit
that is issued or performed by a CPA firm, like A-LIGN.
And basically, what we do is we look at the people,
the process, and the technology
around the organization that we're auditing.
So when we talk about the people,
who are the key players,
who's in in charge of governance
and what are their roles and responsibilities
within the organization.
Then when we talk about processes,
what are the policies, what are the procedures?
What are the mechanisms in place
to make sure that things are functioning appropriately?
And then lastly, technology.
So technology, of course,
what tools, what systems is the organization using
to make sure that the security posture
is appropriate for the organization?
As far as the process itself goes,
there's a couple of different things.
There's a readiness assessment,
I think Scott mentioned earlier,
which is essentially what the starting point
for for most clients.
Then we sort of move to a Type 1
which is the design phase of the audit,
which essentially says, Hey,
now that we've done the readiness assessment,
we've identified all these key gaps.
What's the design of the overall control environment.
Then once we have that established, we move to the Type 2,
which is kind of the final piece, if you will,
in the audit cycle,
which basically is now we've had the readiness assessment,
we've identified what these gaps and pitfalls are,
we've moved to the Type 1,
we've determined that there's an appropriate design
of the control environment.
Now we move to the Type 2 and say, Okay,
how are these controls operating
effectively over a period of time.
As far as the scope of the SOC 2,
there's five basic trust services criteria
is what they're called.
So the most common one is security.
Then we have availability, confidentiality,
processing integrity, and privacy.
And depending on the scope
or depending on the services that the client is providing,
some of those may be applicable, some of those may not,
just depending on the nature
of the services and of the business.
So that's kind of the what of what SOC 2 is.
If we talk about why it's important,
I mean, I think it's really arguably
the most common security and compliance standard
out there right now.
And it definitely gives organizations that we work with
a competitive advantage in the marketplace.
And I also think it builds trust
with your customer base as well.
And you say, Hey, here's our security posture.
We've been audited by a third-party firm.
And here are our controls.
So it certainly provides that benefit for our clients
in terms of a competitive advantage and just making sure
that their security control environment is sound.
- So, one follow up question there.
You talked about Type 1 and then Type 2,
Can I just go to do a Type 2 assessment?
- Yeah, I wish it was that easy.
We typically dissuade our clients from going that route,
especially if they're coming to us for the first time.
And the reason being is that there's just
a lot of moving pieces with the SOC 2 security,
even if you're just doing the basic security principle
and not adding on any of the other four that I mentioned.
There's still quite a long list of controls
and things that you need to work through.
And so that's what I really try to coach
and guide clients that come to us and say, Hey,
we need to start with the readiness assessment.
We need to figure out what the gaps
and the deficiencies are.
And then from there, we can start talking
about the Type 1 and the Type 2.
So there's a lot of overlap between SOC 2
and some of those other standards.
So, if a client was already compliant
with some of those other standards
and they came to me it might change
the calculus a little bit.
But for the most part, we always like to start
with the readiness assessment, or certainly at Type 1
before moving to the Type 2.
- What's are the main trust service criteria
you see customers going through that are built on AWS?
- The most common one by far is security.
So security is required for every SOC 2 audit.
And I would say most of our clients
are at least the ones that we work with
tend to kind of fall, obviously security,
availability and confidentiality are usually
the other two most common ones that we see.
Again, availability kind of being an assessment
of the overall availability of the services or the systems
that we're looking at.
Things like uptime and that sort of thing.
And then when we talk about confidentiality, really,
how does the confidential information
within the organization,
how is that secured and how does that data flow
in and out of the organization?
- And Venkat, what's the main reason or main driver
when customers come to you for SOC 2
that they're saying why they need it.
- Yeah, I think you could basically say
when you have to do SOC 2, like Connor sort of mentioned,
trust is one of the main principles
and to have all those security and also audited,
but how do you sort of get there?
Like, I think I would basically say
that there's sort of three pillars.
Like he said, like there's people processing technology.
Technology, you could say that I would basically say
nowadays 70-80% is about cloud and cloud infrastructure
and the rest of it is about endpoint security.
So the role that we play is that we would make sure
that the cloud infrastructure is actually secure.
So we are the implementation piece.
So now what the customers generally would do is
that either they can do it themselves
by putting a lot of sort of point tools in place
or they sort of come to us and say that,
Okay, we want an out-of-the-box compliance infrastructure.
And second, this is something
that we don't need to worry about.
We wanna focus on our application
and we wanna make sure that behind the scenes,
everything is compliant.
If something is not compliant,
we need to be alerted and so on.
So what we do is that we not only make sure
that the compliance controls are implemented
which is what we call as provisioning time controls
like encryption address, VPC, security groups, whatever,
encryption and whatnot.
And then once that is done in an ongoing basis
on an operations, we tend to monitor.
So that's generally why they would sort of come to us.
And like, there could be a vast, different
types of audiences.
There are people who are like really small customers.
They don't have any DevSecOps engineers in-house
or they may actually be a larger organization
who have much larger infrastructure
and they need to be compliant much, much faster.
So that's some of the common drivers
why they would talk to us
and the general approach towards it.
- Can either one of you discuss,
the AWS shared responsibility model and how you handle that
for how that factors into SOC 2 assessments.
- I think in general, AWS is a shared security model.
What it basically means is
that they are responsible for some part of it
and that the customer is responsible for other parts of it.
So what are their responsible?
They're responsible for data centers.
They're responsible for a lot of physical controls
and things like, security groups, for example.
So as long as you provision the security group,
they're responsible for the implementation of it.
Like the VLANs, the routers, and whatnot,
as long as you provision the VPCs
and those things correctly.
But then fundamentally, you are responsible to make sure
that those controls are applied correctly.
You have the right set of security groups,
encryption address is being applied
because you could do things in both ways, right?
And sometimes people ask,
like why do people go and open security groups, for example.
Or why would somebody actually not go and do encryption?
Because there are a lot of technical reasons.
Like, for example,
if you want to run an inexpensive database, for example,
really a small database encryption may not even be supported
because I mean, it's not a production use case.
So you have to really go through the nuances of it.
And there is some literature about like,
what are the specific controls that you need to implement?
I mean, there's a lot of documentation in AWS,
even in our website and so forth.
But that's the general principle of how you have to do it,
but you have to go control by control.
And the stuff which is not in your scope,
I think it's called inheritance if I'm not wrong,
like you can inherit those controls from AWS.
- Yeah, I think, you know,
just jumping into the shared responsibility model
a little bit more.
You really look at it from kind of the stack
and who owns what,
starting at the infrastructure as a service.
AWS actually carries their own SOC 2
and they do that for each one of their services.
So they've implemented those controls.
They've been able to assert that these are in place
and then it kind of starts moving up the stack,
up to the customer.
So each one of those layers,
you have different ownership
and who's responsible for the controls that are in place.
Many times once it gets to the customer,
it may just be customer data.
So they may be responsible for the encryption at rest,
encryption in transit of the customer data
that's moving through that environment.
So it's really understanding what you own
in the shared responsibility model,
making sure that you have the controls
that are necessary to be in place
from a security best practices perspective.
And then just making sure that you are able to report back
and assert as a management team on what you've got in place.
- Right.
And in fact, like I would say that if you were to put
like names, you have AWS, you have the DevOps people
which is customers in house,
and then you have the developers.
The developers are responsible for the application,
penetration testing, and stuff like that.
DevOps is responsible to configure AWS correctly,
security group, IAM role, and a whole bunch of things,
and then AWS, which has its own set of things
around IaaS and so forth.
- Yeah, and a couple tools for AWS
that can help with that too.
Our SOC reports are,
they're on the AWS Artifact service
that customers can download and see what our controls are
and how they were tested.
And then there's also our services and scope page
that outlines all of the AWS services
that have been compliant,
they have gone through the testing.
The other thing is,
we did discuss scoping a little bit,
so, how do you help your customers scope those controls?
So how do you automate the controls for them?
And when they say they come to you and say, Oh,
I'm gonna go through the security trust service criteria.
What controls do I need to have?
Since SOC 2 is not prescriptive,
or they don't define what the controls are,
so the customer needs to define those.
- Yeah, I'll start off.
But I think at a high level,
there are some standard best practices
that you sort of put in that are applicable
to the AWS level of configurations.
Some of the things are very standard, like encryption,
security groups and monitoring and stuff like that.
They're part of that.
But then I think it's really that when they talk to A-LIGN
and companies like A-LIGN when they actually go
and help them put in place a lot of the scoping.
- Yeah, I think essentially when you think through it,
if you think about it from a security-by-design perspective,
which is to know your requirements,
build to your requirements,
and then monitor them over time.
If you know going in that you have to adhere to SOC 2,
you're still gonna look
towards industry standards and guidelines.
Like, let's say a CIS benchmark
for how you configure and harden your AWS environment.
And then from there, you build up, right?
So it's really looking towards the industry
in and around what security best practices are available.
Knowing your requirements and then building to those
within the environment.
- Right, and I'll add to that, is that in general,
where we have been engaged,
we try to take high standard of security posture,
wherein we try to push as many controls
as possible out of the box.
And then of course there are some cost concerns
because like, for example,
let's say you want to enable guard duty.
You might not want to enable guard duty in a dev environment
and so forth.
So we tend to like put as many controls as possible
and then provide simple nOps
to push the rest of them once the scoping has been done
by talking to the auditors and so forth.
So the general idea is that it's automated
in such a way that you can start with a good standard
and then you can go up if you like
and sometimes you can also go down.
- And we talked about the readiness assessment.
Is that normally when you go through that scoping process
with the customer?
- We like to always start
with the readiness assessment, of course, like we said,
but really that scoping conversation
kind of starts even before we get to that point.
So really, once a client reaches out to us and says
Hey, I'm interested in SOC 2.
We wanna move forward with that.
That's usually the point when we have kind of what we call
a timing call or a scoping call.
We need to make sure that the SOC 2 framework,
works for every one of those clients.
And certainly there are controls that we can map
for each one of those that would be applicable,
and we do that.
But it really just kind of starts,
when the client engages us, Hey, what's your business?
What are you guys doing?
And how can we help from there?
And then usually those that kind of becomes clear
during from that conversation.
And then from there, of course we go, Hey,
readiness assessment Type 1, Type 2, so on and so forth.