>> Hey everybody, stay tuned,
where Jeff and I will be having a conversation
about security in terms of governance.
[MUSIC]
>> Welcome to the Azure Enablement Show
where we're having technical conversations with
Microsoft experts about some of the questions
or obstacles you may face on your Cloud adoption journey.
Now today, we're talking about one of the disciplines
within governance and that discipline is security.
To help guide me through that conversation is Jeff.
Jeff, welcome back to the show.
>> Thank you, Sarah, wonderful to be here.
>> It's awesome to see you.
Security is such a massive topic and it's something
that I think we can all agree is
really important for every organization,
but where should we even begin talking about security, Jeff?
>> I think it's important when any organization approaches
security to think of it like a baseline.
When we talk in a context of this discipline,
we say establish a security baseline.
What that means is that security in
the Cloud starts with understanding
the responsibility that you have within the Cloud,
just like with traditional on-premise data center.
It's important that we have an understanding of
what our responsibility to security will be in the Cloud.
As we transition from traditional IT to Cloud responsibilities,
we understand that there is now
a shared model of what Azure, in this case,
is going to provide for us and what we, from a configuration,
from a platform perspective as a customer, what we institute.
That shared responsibility model really gives
us a lot of flexibility
and how we can establish that security baseline,
whether very tight or whether
very loose and we can reduce friction and adopt the Cloud quickly.
Azure has many tools for security to help us
with that default baseline as a platform.
The key thing here in the relationship is to understand
that the relationship between governance and security.
Security is not governance.
Once you've made security decisions,
you use governance tools to ensure that those decisions are
effectively and efficiently applied across the entire environment.
>> That makes sense.
Now there must be
some common mistakes or issues
that you have with some of your customer conversations, Jeff.
Is there any stories you can maybe share with
us to help our audience avoid making those similar mistakes?
>> Yeah, absolutely. I think,
in our engagement with customers,
I find there's two categories.
The first category is documenting risks,
understanding the business tolerance for
risk and mitigation strategies are in place.
Think about the concept of data and access.
Developing a clear, simple,
well communicated guidelines to
identify and protect data and monitor those systems.
That's the first one,
just making sure that you documented your risks,
that you understand the business tolerance and you have
mitigation strategies or agreements in place.
The second one is around implementing
best practices for corporate policy and security.
This is where you have network requirements,
things like on-premise networks must be
secured against potential unauthorized access,
where you have a hybrid identity strategies around
key factors of IAM control for Cloud-based identity services,
making sure that you're implementing the corporate policies in
the Cloud in a similar fashion
that meets the requirements for compliance there.
So really two categories. I see,
documenting risks and then implementing those strategies.
I think one of the areas that
this could get challenging is actually making it real and
putting it in perspective overall.
How about we just take some time,
I'll show you a little bit in the Azure portal what it looks
like impracticality of some things
we've already talked about earlier in the show.
We've talked about governance
and we've talked about landing zones,
bringing some of these concepts
together in one picture. Is that good?
>> Yeah. That will be great, Jeff.
>> Excellent. What I have here is I've started in
my Azure portal with the management group structure.
The reason why I started here is because we
have to approach it with landing zones,
which is how we get ready in the Cloud and make it real.
First, we have the "Start Small and Expand" process.
For this landing zone, what I've done is I've implemented
the blueprint for Azure Cloud Adoption Framework.
Then I have the Enterprise-Scale, a Contoso example,
which deploys a number of management groups
for me and I have different policies on
these management groups at different levels.
What I've done is I've taken the policies
of my organization and I've
implemented Azure policy against each one of
these management groups to help me with
some of those default configuration.
I'm going to look now at the "landingzone" in "Management group"
and Enterprise-Scale Contoso management group.
I look here under my online and I can
see my policies that I have implemented here,
so I can see what resources are in compliance.
Very quickly, under the Enterprise-Scale Contoso,
we have around 80 plus policies
that are implemented when you use
the reference implementation of enterprise scale.
I can see I've gone ahead and thrown a bunch of
VMs and storage accounts in here so we can see some real data.
You can see that there are some non-compliant,
there's some compliance resources that have
been deployed and this helps me with having
that process of governing
those security configurations because
one of the things about Enterprise-Scale is it
starts with a management baseline
as part of the reference implementation.
To show that, what I'm going to do is I'm going to jump to
the "Resource group" that
is called Enterprise-Scale Contoso management.
In here, in an Azure landing zone,
it's deployed out solutions from the login analytics dashboard.
Here, right underneath the resource group,
I can see a number of solutions that have been
deployed to do things like activity tracking and change tracking.
We've got Azure Security Center standard that'll be
implemented on my virtual machines
under the landing zone subscription as a policy.
Those configurations in Azure Security Center
will be sent to my VM.
If I go here now and look at my workspace summary,
I can see I have a number of solutions that help me
with the inventory tracking and understanding my environment,
even my security audits,
things like patches and updates I can see as
part of this template and it helps me
establish that baseline for security.
Here's my system update status that was deployed there.
Another example that we have is with "Start Small and Expand."
In "Start Small and Expand" using the CAF model.
The first thing is at the top level management group,
so we go to our "Management group" here,
I can apply policies to the subscription
that's in my "Start Small and Expand" subscription.
Then as I go into that "Start Small and Expand"
subscription that I' applied the blueprints to,
I'll see in my "Resource groups" list here that part of
the Cloud Adoption Framework blueprint for migration
includes a shared services resource group
that has my log analytics workspace here.
This helps me to establish that baseline piece by piece.
Where Enterprise-Scale has some
of the security baseline built into it,
the "Start Small and Expand" allows me to
adopt a solution at a time and
build that security framework around
the workloads that were migrating one component at a time.
If I go to my workspace summary,
I'll see I have a blank slate that now I
can go and add solutions to.
This helps make it real around two different approaches
that we provide right in Azure as far as
establishing your landing zone and then creating
a security baseline and understanding the workloads
that are going to migrate in to your landing zones.
>> Awesome, Jeff. That really brings it
into a clear picture of how it works.
Now, is there anything our customers can do for early success
or if they already have existing resources in Azure,
how can they set themselves up to go down the right path as well?
>> Yes. Let me share my screen real quick on this browser
because there's a few things
that you want to start when you start with security.
The first thing is in
the Cloud Adoption Framework in the strategy section,
we have a define your security strategies.
You want to make sure that you have a security strategy and
you're planning for that strategy going into the Cloud.
The second thing is understanding
that security benchmark has
integrations into helping you with that risk.
When we look at the security baseline overview here,
we have a template that will help you
define that baseline for your business when it comes to risk,
when it comes to mitigating that risk
and understanding what your tolerance is.
Typically, we talk about tolerance in two ways,
data breach and then actual business
continuity when a workload is down.
Those are the two core ways.
The third solution or the third thing that will help you
get started quickly is our Azure Security Benchmark.
This is Azure Security
aligned to different frameworks for security,
things like the Center for Internet Security controls,
CIS or NIST, the National Institute of Standards and Technology.
We've aligned security configurations to
the benchmark and Azure Security Center has
a baseline built into it that
will help you with establishing your security baseline as well.
>> Awesome. That's probably how to do
your production environment and we all are probably
on agreement that we should be securing
our production environments.
More about our Dev and our Test environments,Jeff.
Should they matter,
will our production environment looks like in terms of security,
should they be different, should they have no security?
What does that model look like?
>> Yes. Great question.
I think the place that we start is with data sensitivity.
If your data production environment is going to
have a lot of sensitive data,
you start with the security requirements of
the data and then that'll tell you
whether or not you're going
to need to meet those security
requirements at your Dev environment.
There's process typically in IT of
scrubbing data when you're working in non-production environments,
you can't use actual production data.
I think we start there with data sensitivity and the cataloging or
identification of the sensitivity of
that data and then we work our way from there.
Most DevOps practices strategies
are going to call for your security
in a test environment
versus development environment to
match the production configurations.
If you think about it from a DevSecOps perspective,
you want to match that development security configuration
as closely as possible to what's going to be at
production to make sure that you have
a smooth promotion and compliant quick promotion process.
>> Cool. Thank you so much for your time today, Jeff.
I definitely have a much clearer picture
of what I should be thinking about in terms
of security when I'm having those governance conversations.
Now if you want to find out any more about
the resources that Jeff mentioned during this episode,
please do hang up our description box where
we will be dropping links to that as well.
Also remember to tune in for
future episodes of the Azure Enablement Show.
[MUSIC]