Welcome to the Azure Security Podcast,
where we discuss topics relating to security, privacy,
reliability, and compliance on the Microsoft Cloud Platform.
Hey everybody, welcome to Episode 43.
This week we have everybody here.
We have Sarah Gladys, Mark, and myself, Michael.
We have a guest here this week,
Liz Kim, who's here to talk to us about Azure Policy.
But before we get to Liz,
let's take a quick lap around the news.
I'll kick things off.
A couple of things caught my eye over the last couple of weeks.
First one, it's interesting,
it's in App Service and Azure Functions.
They now have the ability to configure
basically an arbitrary OpenID connector.
Historically, you could only authenticate to say,
Azure AD, Facebook, Google, or Twitter.
Actually, I see now they've got Apple in there as well.
It's interesting.
But now you can essentially set up
any OpenID connector you wish,
which is really cool to see.
It gives a lot of flexibility there.
I've been doing a lot of work over the last few weeks,
actually, in Azure Functions and OpenID Connect,
and OAuth 2.0,
getting right into the bowels of
sort of spelunking OAuth 2.0 tokens.
Definitely wouldn't recommend it.
But anyway, it's great to see that we can now
essentially configure any kind of OpenID connector.
The other thing that I noticed is,
I think I actually touched on this a few weeks ago,
but we now have some new virtual machines
that support confidential compute.
These are called the Azure, you know, wait for it.
They have the DCAS version 5 and the ECAS version 5.
These support things like always encrypted memory.
They support things like virtual TPMs,
trusted platform module.
They also support things like secure encrypted virtualization,
secure nested paging.
Try saying that one quickly a few times.
But this is great to see.
They're both AMD and Intel CPUs.
So this is really great to see.
Again, this is all about encryption of data in use,
not just encryption of data at rest
or encryption of data on the wire.
So I'm a huge fan of the whole confidential compute initiative,
and it's good to see that we have these new VMs.
The last item I wanted to bring up in public preview,
there is now an Azure Bastion native client.
This is actually really cool.
I've been sort of experimenting with it just recently,
but you can basically connect to your target
Azure virtual machines via Bastion from the Azure CLI,
like from the command line.
Like on a native client.
So I'll just open up Windows Terminal,
because I know everyone's using Windows Terminal.
You've ditched command prompts and using Windows Terminal now.
I can open up Terminal, connect to Azure
with a safe connection,
and I can go straight through Azure Bastion.
This is really nice.
You can also log into Azure Active Directory,
join virtual machines using your AAD credentials.
Okay, so let's see.
What has caught my eye this time?
Defender for Cloud,
what the product previously formerly known as
Azure Defender and Azure Security Center,
there's a ton of GA updates, the name change.
It's always nice to remind people of that.
But really cool is the native CSPM,
which is Cloud Security Posture Management,
if you're not familiar with that acronym,
for AWS and Threat Protection for Amazon EKS,
which is their Kubernetes service,
and EC2, which is their virtual machines.
So now if you're using some AWS,
but you've also got Defender for Cloud,
then you can actually look at their posture management
for those products, which is very cool.
So you can do it across Azure and other clouds.
We've also expanded the security control assessments
with the Azure Security Benchmark version three.
So if you're using Hygiene in Defender for Cloud,
there's an update to the security benchmark.
Also the Sentinel connector bi-directional alert synchronization.
So basically if there's an alert raised in Defender for Cloud,
it will also raise it in Sentinel for you
and sync between the two.
That's now GA.
So for those of you who are waiting for it to go GA,
it is there.
We've also got new recommendations around AKS,
the Azure Kubernetes service.
Our recommendations have now been,
the security recommendations are mapped to Mitre Attack Framework,
that's gone GA.
So a lot of GA things here as well.
I'll link in the show notes because I'll just go on forever.
There's a lot of things that have gone GA.
So if you're one of those businesses that doesn't use things
until they've gone GA,
there's a lot of new things in Defender for Cloud.
Next, I definitely mentioned this when it went public preview,
but now it's GA again.
So for those of you who are waiting for things to go GA,
AKS, you can now create AKS clusters without local user accounts.
So of course, local user accounts are generally not a good thing
on anything.
We want them to be synced up to a centralized identity provider.
So now that is available in AKS.
Going on to our public preview though,
ExpressRoute Private Peering,
which I am definitely going to struggle to say for the rest of this,
is now supporting the use of BGP communities with virtual networks.
So if you're using BGP communities,
you can now actually get the ExpressRoute Private Peering
to use that as well, which is very nice,
particularly if you have a large environment.
There's also GA for the centralized management of keys
for encrypting Azure disks.
So you can now manage Azure Key Vault centrally
in a single subscription and the key stored in Key Vault
to encrypt managed disks and snapshots
and use those keys to encrypt managed disks and snapshots
and other subscriptions in your organization,
which is really nice because it means that, of course,
you can centrally manage your security policy.
Azure App Service,
they've got now a diagnostic settings feature that's gone GA.
So what that means is if you're using Azure App Service,
the Azure diagnostic settings is now generally available.
Diagnostic settings can be sent to log analytics,
they can be sent to a storage account,
and of course, it can be sent to Sentinel as well.
So the kind of logs that are coming out of the Azure App Service
are the App Service Console logs, App Service HTTP logs,
App Service Environment Platform logs,
Audit logs, File Audit logs, Service App logs,
Service App IPsec audit logs, and Service Platform logs.
So definitely get logging those somewhere
because you should probably be logging them
for operational and or security operations
if you're using Azure App Service.
And then Logic Apps, love a bit of Logic Apps.
Of course, we've got the Fall or Autumn,
I'm going to say Autumn 2021 release of Azure Logic Apps.
So we're always building on the cool things
you can do with Logic Apps.
Of course, you can use it throughout,
there's various different products that use Logic Apps,
including my baby Sentinel.
Some of the cool things we're doing is that you can now use
SQL as a storage provider rather than just a storage account.
We're also having more things within Logic Apps
support managed identity rather than having to use
a specific user account.
And we're also making the Logic Apps designer better.
It's getting a major refresh.
And we're also having some more plans.
So there is a consumption plan and a standard plan,
and you're going to be able to export between the two,
which is something you couldn't previously do.
So definitely go and check out the new things in Logic Apps
if it's something you use.
And then finally, of course, we will move on to my baby,
which is Sentinel.
A couple of things that's worth highlighting,
of course, lots of things were announced at Ignite last month.
But a couple of things I wanted to highlight is you can now
ingest GitHub logs into your Sentinel workspace.
So if you're using GitHub and you want to do threat monitoring
on it, as you should, if you are using it,
we've now got a native solution to be able to do that.
And the other thing that's gone public preview is that is
definitely worth mentioning because it's very, very popular,
is the Amazon Web Services S3 connector.
So if you've got logs going into S3, into your AWS S3 bucket,
we now have a connector that can pick them up off there.
So we can bring in VPC flow logs, guard duty, and cloud trail.
Now, we do have, and we have had for some time,
a different AWS cloud trail connector that just uses the
API coming from AWS.
But I know I've worked with customers who that connector
doesn't work for them.
Sometimes there are limits on the AWS cloud trail API
that is a limitation on the AWS side.
And sometimes we've had customers that can't get all the logs
out properly because they just generate too many cloud trail
logs.
So it's really great now because we completely bypass that API
with this new connector.
I know a lot of customers have been waiting for it.
So go and have a look.
And then the last thing, which is there's actually
some more sensual things, but this is what I know that a lot
of people were asking for.
We now have our Windows forwarded events connector.
Now, it did have a different iteration a while back,
but now our Windows event collection and Windows event
forwarding is all supported through this new data connector.
You also have to use the Azure Monitor agent, the AMA,
in order to do this.
But I know a lot of customers who are not familiar with
Windows, a lot of customers wanted us to be able to support
Windows event forwarding because they'd already got that
solution set up and then it was better than having to
install an agent everywhere.
So it is now here.
So go check that out.
It is still public preview, but I know a lot of folks are
waiting for it because a lot of you already have Windows
web stuff and web infrastructure.
So now you can go and do that.
And that was a very big news chunk from me.
That's the best that look.
That's the longest news you've ever had.
I think it's the longest news anyone's ever had.
I know.
I just wanted so much news before Christmas.
Yeah, so I'll go quick.
So yeah, the one thing I just want to highlight sort of as a
meta point within a lot of Sarah's news, like I love that
we're GA-ing features that are, you know, have both, you know,
Azure and AWS support like the Defender for Kubernetes stuff
right out the gate.
I think that's awesome.
And it really reflects, you know, how Microsoft is really
supporting what customers are running, which is multi-cloud.
The big thing on my side is something that I'm working on.
It's, it may be released by the time you hear this podcast,
really trying to get it out in the next few days within
recording this, the new cyber reference architecture with
the updated product names and a few fun little surprises on
some sequences that we added there.
We'll be coming out very shortly.
And so definitely check that out, the AKMS slash MCRA.
Let's try saying that 12 times fast.
And so that is coming very soon and possibly out by the time
you hear me.
I'm so glad that Sarah and Michael and even Mark provided
so much information because I just came back from vacation
and I forgot everything that I knew before.
But this week I've been working heavily with Defender for
Identity.
I found out that soon we will have automation for incident
response going in public preview.
Although the changes will not take effect immediately,
there's research going on for changes that this automation
will provide to speed up.
For example, if the automation wants to disable a user or
reset a password or perform some other type of task.
An option if the analysts do not want to wait for the changes
to take effect is to use Azure AD Identity Protection,
which opens seeing certain risks such as anonymous IP
address that use a typical travel on familiar signing
like credentials or credentials being found to be
sold on the dark web.
Password spray or others, then certain actions will take
place such as prompting for Azure AD MFA or resetting the
password itself.
The one thing for this is that you need Azure AD Identity
Protection, which is part of Azure ADP2 license.
In addition, you could consider using a conditional access
continuum access evaluation.
So, open seeing certain risks, you could trigger
re-verification of the session and this will happen whether
the user just signed in like 10 minutes ago or it ended
during those 10 minutes, the health of that session has
changed.
So, please take a look about those automation that
Defender for Identity will be providing soon.
I think I heard that they're turning them on by the end
of the year.
In talking about signing risks, we're adding new
proactive detections to stay ahead of both common and
emerging attacks vectors.
As mentioned earlier, we checked on anonymous IP,
others are typical travel and so on, but now we are adding
detection for anomalous talking, talking issues
anomaly on familiar signing properties for session
cookies and others.
Basically, we are trying to address talking related
attacks like the ones observed with solar winds.
And finally, I wanted to briefly talk about OT and IoT.
Microsoft recently announced a partnership with CoreLight,
which is one of the industry open network detections and
response platform for IoT to integrate with Defender for
IoT.
The reason that I wanted to focus on that is that
one of the problems with IoT industry or many vendors is
that they have close network solution.
So, in order to have and to incorporate for OT and IoT
devices, sometimes you must buy just the full platform of
those vendors.
Well, Microsoft with the partnerships that are
is doing with CoreLight, now not only can provide
detection of IoT devices through the network
sensor, but also now it can get information from
partners like CoreLight.
In addition, for those of you that are not aware,
Defender for Endpoint also monitors and reports on any
OT IoT devices.
So, we're trying to provide a full coverage that not only
enables OT IoT, but also then there could be correlation
between IT and reduced blind spot that attacker may
take advantage when trying to jump from one
environment to another.
Yeah, this is the longest news section I think we've
ever had.
We're running at almost 20 minutes as long as we've
ever had.
So, now they got that out of the way.
Let's introduce our guest.
This week we have Liz Kim, who is here to talk to us
about Azure Policy.
So, Liz, thank you so much for joining us on the
podcast.
We'd like to spend a moment to introduce yourself to
our listeners.
Thank you for including me here.
I'm so excited to be here.
I'm Liz.
I'm a program manager on the Azure Control Plane
team.
The Control Plane team essentially has ARM and
all the governance services like Azure Policy,
Azure Resource Graph, Management, GRIPS, Change
History, Tags, those number of things.
I'm responsible for the Azure Policy product.
I've been driving it since the very beginning of the
launch.
We launched it as a public preview about four years of
I think we're right on the four year mark since our
launch.
And I've been with Microsoft for eight and a half
years.
So, before Azure Policy, I worked on Azure Log Analytics
and before then I was on a system center.
Very nice.
So, I'm going to be brutally honest before we get
stuck into this.
I'm a huge Azure Policy nerd.
And this podcast may actually devolve into just a
Liz and Michael discussion.
So, unless someone else pipes up with questions,
I'm just going to keep on going.
I'm a huge Azure Policy fan.
I just adore the...
I just think it's fantastic.
I mean, from a governance perspective, the fact that
I can put really strict rules in place.
I mean, one of my favorite rules by far is
preventing, say for example, people spinning up
resources in regions that they don't want to
spin resources up.
So, if you're in East US 2 and West US and you
don't want someone accidentally spinning up a
resource in say Germany, then you can put policy
in place to restrict that.
But while...
So, anyway, the point is, I'm just a huge nerd
when it comes to policy.
I'm just a huge, huge fan.
So, let's just start things off with the most
simple thing because I think people need to
understand exactly what policy is.
And it's actually interesting when I speak to a
lot of customers.
It's interesting how many customers don't even
know policy exists.
That being said, I've also come across some
customers who actually have had...
I'll be honest with you.
Let's just say an interesting experience with
policy.
And 99 times out of 100 is because they're
doing it wrong.
So, I'd like to sort of address some of those
issues if we can as we move through the podcast.
So, let's just start off with the absolute most
basic of questions.
And what on earth is Azure policy?
And when would you use it?
So, Azure policy is essentially about
controlling your resource configurations
and assessing the compliance results at scale.
You would be able to block resources that are
non-compliant or auto-remediate these resources
and then also get a compliance assessment
of all your existing resources on whether
they're compliant or non-compliant against
each of the policy that you have applied
on your Azure environment.
I said resource configurations earlier,
but we are also expanding on controlling the
resource operations as well.
And so, in the future, we would be able to
control the operations that you do such as
delete or move operations at scale as well.
Liz, can you explain some of the common use cases?
Yeah, absolutely.
So, for any customers who are exploring with
Azure policy, generally I recommend on them
exploring the built-in initiatives that we
have today.
And by built-in initiative, what we mean is that
on day zero, when you go to Azure policy experience,
we actually have a lot of policies already in there
for you to easily get started with.
And so, examples of the things that we have in
there, for example, would be we have one for you to
enable all of the monitoring agent across your
VM and VMSS.
Or we also have one for NIST 800 regulatory
compliance requirements to evaluate not all,
but a subset of the controls that are required
for NIST, as well as for things like,
you might want to control your VM skews for your
non-production environment.
That's our deal.
So, a best way for you to really explore the
explore policy would be through the built-in
initiatives.
And lastly, I think tags is also a common
use as well to make sure that you have the right
tags applied.
You can also use it to automatically inherit
your tags from the resource group or from the
subscription.
And so, you could also use policy to make sure that
those tags are in place.
Can you just give us a quick overview of perhaps
one of the initiatives, one of the example
initiatives that you have?
I'm going to be honest with you, when I've sort of
worked with customers, most of the time we've just
gone straight in and just start deploying policy.
I mean, I planned it out a little bit, but I know
some customers who have used the initiatives,
but I actually haven't.
So, can you give us an example of what one of
these things might look like?
Yeah, so initiative, actually, let me define an
initiative first.
Initiative is just a grouping of policies.
A policy controls a specific configuration zone
given a resource, and then you can group it for
enabling it for a bigger effort going on.
And so, an example of an initiative might be
there's one before making sure that you have all of
the monitoring related agents enabled.
And so, that essentially consists of a number of
policies to make sure that you have the MA agent
on your VM and your VMSS dependency agent,
making sure that you cover both Windows and
Linux VMs, that's what I'll be able to do.
So, that could be an example of an initiative.
Another initiative that we have is, for example,
the Azure Security Benchmark Initiative as well,
that covers all the security related policies
in that initiative as well.
That's nice, didn't know about that.
Hey, Mike, did you know about that?
Do you know that there's an initiative for the
Azure Security Benchmark?
Is that the one that's associated with almost an
Azure Security Center with Defender for Cloud?
Yeah, exactly.
So, if customers are on Azure Defender,
it's actually already assigned on the
customer's environment.
We went through a migration from the Security
Center Initiative to the Security Benchmark
Initiative.
So, it's already assigned to most of the
customer environments.
Yeah, it's good to know.
I did not know that, but it's actually really good
All right, let's get into some real nitty-gritty
So, I mentioned before that there are a bunch
of customers on policy and look, I'm going to be,
I'm going to be upfront.
I mean, it's been a bit of a mixed bag.
And the reason is 99 times over 100, if it's a mixed
bag is because some things are not being planned
very well or people don't necessarily understand
the implications of what they're doing and then
things start to break.
And a lot of it boils down to two, from my
perspective anyway, if there's more to this,
please let me know.
There's two aspects to this.
One is at what level in the hierarchy is an
appropriate place to deploy policy?
That's number one.
The way I look at it, there's two aspects, right?
You can deploy it really, really high up, say,
you know, a subscription or management group
or something.
And that gives you like a single point of management
or fewer points of management.
The downside is you're going to push policy down
to things where policy might not be applicable.
I've always said to customers, there's really,
in my opinion, there's like two sets of lower
case P policies, some that are good ideas
and some that you're willing to die on the
hill for.
In other words, some things that you're really
willing to do, for example, restricting
to specific regions, right?
We're going to deploy this thing in,
I don't know, let's just say, you know,
ECUS 2 and US West 2.
And that's it.
We don't want to push it anywhere else in
case of sovereignty issues.
That is one I'm willing to die on the hill
for.
But some may not be so overly
energetic about and they may affect
some particular applications.
So again, you can have it really, really high,
you have to do absolutely everything underneath it
and run the risk of potentially breaking things.
Let's be honest, depending on what you're doing.
The other option is to push it far down,
like to resource groups or even individual
resources.
But now you've got a management's explosion, right?
Because now you've got all these things to manage
and who can manage them and what sort of roles
do those people have?
So it's this trade-off you've got to make.
And a lot of it also boils down to the other sort
of axis, which is the action, right?
So there's different actions that you can perform
and probably the two that most people think about
are the audit action, which is basically
don't block it, but just say, hey,
this event happened and it would, you know,
it violates policy. And then the other one is deny.
And at that point, you're blocking
something and that's what can cause,
you know, from my perspective anyway,
the combination of pushing a policy really high
and then pushing deny all the way
down through all the subscriptions.
So for example, you decide to deny
a public IP address to a
storage account. Well, what happens
if you actually do have a valid reason
to have a public IP address
on a storage account, which can happen.
So I realize kind of a,
I'm not sure if there's a question in there,
but it's like, so what's
your experience there? I mean, am I,
you know, doing it wrong?
Are customers doing it wrong?
Is there some more nuance to this
that I'm not familiar with?
So you touched on a lot of different topics.
Let me try to respond on
one topic at a time. So I think
first of all, you touched on the kind of the scope
at which the policy gets applied.
Our general recommendation
is that you apply it at as a high
of a scope as is applicable
and then use
exemptions to, exemptions
or exclusion to
exclude the sub one,
sub resources or sub scope that are
not applicable.
And so if you're trying to
block all outbound
port, for example, on your non-production
environment, then apply that policy on your
non-production management group.
And then if some resources or
subscriptions need
exemption, you can create an exemption at that
scope. That essentially
essentially allows you to be able
to have the control over those
environments and, you know,
still have the flexibility
for those special snowflakes.
And Michael, another thing
that I, you touched on that I would also
love to dive into is kind of the
different effects or different
enforcement types that we have, right?
So you touched on kind of the audit
thing, audit policy effect, which allows
you to create the resources
but we'll just flag it as non-compliant
and give back the compliance
result that is non-compliant
or we will deny it.
So you won't even be able to create
that resource. First of all,
before you apply any deny policies,
our recommendation is
first to always use this on audit first
and then switch over to a deny
so that you at least have an idea of
kind of what are the things that you're going to be
blocking. We also,
you know, recommend customers to use
our non-compliance reasons message
so that, you know, when someone gets
blocked, they have a friendly message to
read as to, you know, like
where they can get more info or where they
can get exemptions, what the policy
is for, that sort of deal.
We also have
auto remediation effects
as well for customers
who really want to make sure that,
for example, I'm just going to use
the earlier example on the update
that Sarah gave on the AKS
disabled local auth, right?
Let's say that you always
want to make sure that
the local auth is disabled by default
but you don't necessarily want
the engineers to be bothered
by it or to be, you know,
you want these things to just happen by default
without engineers having to be blocked
and manually change it.
We also have an auto remediation capability
as well. And the cool
thing that we do with modify effects
specifically is that
we actually intercept the request
appended so that
it has the right property value
and then we let the request
go through so that it's
actually created. So by the time
it's created, it has the right
property value already in place.
So, you know, there's no security
vulnerability that you expose
by using a auto remediation capability.
All right. So that gave me
a bunch of questions.
So first of all, if I switch everything to
audit, so action equals audit,
where is that order report?
Is it in Defender for Cloud?
Was it formerly Azure Security Sensor or is it somewhere else?
It needs to be in like a central place, right?
So I can easily get to it.
So there's two types of data that we produce for audit.
There's events
information. So, you know, like when some
resource gets created and if it's
audited, we'll drop an event
and that goes into Azure
Activity Log.
And then there's also the compliance
state that we produce as well, right?
So we'll say, oh, this resource is
non-compliant and
that non-compliance data is available
through the, first of all,
we have our API,
Policy Insights API that you can get the
data from. We also route
all that data over to Azure Resource
Graph as well. And so
you can query Azure Resource Graph for all
of this data. Oh, that's cool.
Yeah, the resource graph angle, that's really
cool. Okay, the other question I have that's
following from that, I've got, by the way, I'll have one more after
this, is what happens if I
let's say I have some storage accounts that have
a public IP address
and I decide at
say the subscription level to deny
public IP addresses for storage accounts.
What happens to the existing storage
accounts? A great question.
So we don't actually
it's not like we delete the existing
resources by default, right?
So what we'll do is we will go
and first scan all your existing
resources.
And for every resource that you have, we'll
give a compliance data, compliant or non-compliant
and we produce that as a report.
On the existing resources
they will,
we will not take any enforcement until
that resource goes through an
update. So you know the next time that resource
goes through a put or patch request
we will do the enforcement of deny
but otherwise we will let that resource
be. If you rolled out
a remediation policy like a modify
or deploy if not exist effects
then you will also have an option
of rolling out remediation
on existing resources
and that, again
I recommend that you do a gradual rollout
on these
remediations and so
we have multiple knobs available in
there so that you can just start
remediating for resources in a particular
region first, sub scope
first, we just released
maybe two weeks ago or so
on being able to do a per millilay rollout
as well so you can do a percentage based
rollout as well. And so you can
also do a remediation on existing resources
but that again is
a user action based.
We don't touch the existing resources
when you roll out deny policies
unless it goes through an update.
When you say an update
so if I have a storage account
that has a public IP address and there's a policy
that says no public IP address is on storage
accounts, when you say it goes through
an update, do you mean like if I modify
like a setting on that storage account?
Yeah, exactly. Perfect.
That's actually really cool so that leads to my
last question. Well my last question
is all the other questions. So
you said that you can have like an
exemption or an exception like below
like say for example the subscription. So for example
let's say I have a resource group.
What are the machinations of that?
How do I set that up?
So let's say I've got
company A
and they've got a subscription
and then there's a resource group
that handles something really funky and really specific
and the development team says we want to be able
to set our own policies.
Obviously we'll use some of the policies
from the subscription where it makes sense
but there's like a couple of policies in there that do not make
sense and will actually stop us from doing our business
requirements. So we want to be able to
override those. So what are the
two parts. One is what does that process
look like and second, who can do that?
So let me answer the letter per first
and then we'll get to the first part.
So let's say in your example that the policies
on the management group level.
Someone who has an access
to the resource group like a you know as
an owner on the resource group or owner on the
subscription will not be
able to create exemptions on that resource group.
We
do a link access check to make sure that
whoever is creating exemption
also has permission
on the assignment as well which in this
example would be management group scope.
So the application team
will essentially need to go request
the exemptions to the
Cloud Center of Excellence team or
Cloud Architect team, Security Architect team
whoever has access at that management group
scope. In terms of
how you go about doing that
we generally
from what we've observed customers
generally have a
some kind of a ticketing processes
or tools
they have in place that
they integrate the exemption
creations into.
And so that's actually the reason why
we introduce exemption as a separate
resource type. Aside from
the not
scopes or the exclusions we already had
which was a property on the assignment.
So we introduce exemption as a separate resource type
precisely so that it's easy
to plug into the existing tools
that customers have
and all that tool will do is essentially
once that exemption cost has been approved
create the exemption
resource at that scope
at that resource group scope.
And so the process
side of the story is generally
customers already have a tool that they
leverage today and then
they create the exemptions once approved.
Can you talk to us a little bit
Liz about
some of the new things coming up
or stuff we've recently released
because well you know with every single
Microsoft product we have
we've always got tons of new things
happening so
what's exciting and new in the policy world?
Yeah so we have a lot
going on on the
Azure Policy space I think
first of all I touched on
the ARG integration
a little bit earlier but
we are putting more and more of the
Azure Policy resource types into
Azure Resource Graph so
we just finished on putting
in the policy assignment definitions
and
definition sets into
Resource Graph so you can join that data
with compliance data and produce you know full
report. That work is going on
and then up next on our ARG integration
is putting in exemptions resource.
Customers have an interest in
putting together a view to figure out
whether the exemptions that are
approaching expiration for example
and so you would be able
to produce that report through
Azure Resource Graph.
We also have some
investments going in on being
able to do more with
the policy expression
on the policy language
I mentioned earlier
but we are about to release a denied
delete policy.
That essentially is kind of our
first step in introducing
a policy that's able to manage
the operations on the resource
with denied delete you can
essentially protect your critical resources
to avoid accidental deletion on those.
So the denied delete
sounds a lot like
resource locks. Is it similar
to that? Is it new functionality? Does it provide
extra functionality that resource locks don't normally
provide? Yeah so
it's essentially just like resource
lock but at scale
so you would be
able to apply it across all of your
management group to protect
your resources
and also another benefit that it provides
is that the resource owner
or subscription owner would not be able
to override it.
Resource lock is something that
the owner could just delete that lock and do
the operation that they wanted
but policy would essentially make it so that
they have to go request the exemption
for them to override it.
Yeah I've always seen resource locks
as a bit of a...
they've served their purpose but they're hardly as
robust as something that's
more complete like this which is good to see.
You know, denied delete is
the first thing that we're starting off with
and then you'll also see us
expanding to other operations like blocking
move operation
or controlling things that can be done
through post API.
So that's sort of a deal as well.
The other sets of
the investments that are coming on board
is
I'm going to touch on two things that I'm most
excited about.
One is we've had
customer asks on wanting to
extend policy valuations
to also reference their own
data sets. Right, so for example
you know a lot of customers have policy that
controls the
tax to make sure that you have call center ID
but that cost center ID may not
be a valid ID that you put
in. Right, and so
essentially what we are supporting through
custom data policy is that you can
upload that data over to Azure
and reference that data
so that we can look
that up at runtime
and do an enforcement accordingly.
That is another investment
that is going on
and then we also have additional
investments for
being able to declare policy
enforcements to be done on the
dependent resource types as well.
So you know we have some behaviors in Azure
where
storage accounts, sorry functions make dependency
on storage accounts and so
storage account gets created
by default or you know
Databricks creates a bunch of resources
in the resource group. So we are also
we're also looking into
a mechanism for you to
control those resource
types and what the behavior needs to be
for those dependent resource types
in Azure.
Probably the last pillar of investments we
do is around the life cycle of
policy. The area
of investments that we are going to release
next semester
which is our upcoming six month is
first of all we have version management going out.
I think a lot of
customers have been waiting on the version management.
It's going to support
both the custom definitions and assignments
but it will
also support and build things as well.
So now you will have an option
to
choose when you
migrate between the versions
on the built-ins as well. So version management
is something that we are super excited about.
We also have some
additional investments to make it easier
for customers to do a gradual
rollout of the policies
for you know doing
resource location by location basis
or
specific tags.
So we have what we call a selector
on the assignments and exemptions
that will be released in the upcoming
semester as well.
I worked with a customer a few years ago
they would have killed for versioning
of policies.
It's not really versioning
it's actually a version number. This is
policy version number two.
You may want to say something like
for this particular environment we are not going to roll out version one
of the policy but for this other environment
we will roll out version two because of potential
compatibility issues or something like that.
So man that's great
to hear. I didn't even know about that.
As soon as you said I kept thinking about this customer
so that's really great
to hear. So one thing we always ask
our guest is if there was one
single thought you'd like to leave our listeners with what would it be?
I think the main thing
is to explore with the different
enforcement effects that we have
in policy. I think the power
behind what policy can do
at the end of the day is all
about what policy
language can express.
I would just start
exploring on what are the
enforcement effects that we support
to get an idea of what are possible
things that you would leverage as your policy for.
Nice.
One thing I mentioned at the very beginning
I'm just a huge fan of it as your policy.
When you look at controls
like preventive controls and detective
controls and responsive controls
I mean as your policy can kind of fit all three
of those areas. But from a
preventive control it really is
a such a magnificent defense
when it's designed correctly and used
correctly. I like the idea
that you had of having it at the
highest possible level and then using
exceptions below that. For those
areas where you do need
to sort of deviate from the policy
and then with the
policy version coming out
that's really going to solve
so many customer headaches.
So yes, thank you so much for joining us
this week Liz. I really appreciate you taking
the time. I know everyone else on the podcast
did as well. I learned a lot.
Again, I've used policy for a long
time but I learned a lot
on this podcast. That's always
a good thing to see.
To all our listeners out there
this is our last podcast for
2021. Hopefully
2022 is going to be a little
bit better than 2021. I know everyone's had
a bit of a rough time.
I know everyone on the podcast that we've had
has been exceedingly busy.
I'm off diving in a couple of days
with my wife.
I've only taken actually one week vacation
this year so I'm going to make up for
a little bit over this break.
So anyway, to all of you out there, thank
you so much for listening in this year.
We've had a great year. The podcast has
really grown over the last
over the last 12 months.
It's way above anything that
we ever expected. The feedback
we've had has been nothing but positive.
We've had fantastic guests.
A lot of people have learned a lot
through this podcast. So for that
I'm very, very thankful.
So again, for all of you out there,
thank you so much for listening. Take care of yourself.
Take some time with your family
and we'll see you next year. Thanks again.
Thanks for listening to the Azure Security
Podcast. You can find
show notes and other resources at our
website azsecuritypodcast.net.
If you have any questions, please
find us on Twitter at azuresecpod.
Background music is from ccmixter.com
and licensed under the
Creative Commons license.