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.