Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability and compliance on the Microsoft Cloud Platform. Hey everyone, welcome to episode 77. This week it's myself, Michael, with Gladys and Mark, and we have a guest, Anthony Shaw, who's here to talk to us about security implications of infrastructure as code. But before we get to our guest, why don't we take a little lap around the news. Mark, why don't you kick things off?
One of the things that I've been thinking about a lot lately, and it's actually in our, we captured it in the security architecture design session, module three that released a month or two ago, the link between zero trust and security operations, or SOC as some people like to call it. So one of the things that we found that's really interesting is, you know, a lot of folks are familiar with, hey, why would we think about zero trust?
Because hey, the firewall ain't going to protect your cloud apps, it's not going to protect the data and the systems that are outside of your traditional network perimeter, right? And so that dynamic and sort of the urge to work on access control, which is extremely rational and correct, is absolutely correct.
The thing that is interesting is that a lot of folks aren't necessarily seeing that the same exact dynamic of, hey, we need to protect stuff wherever it happens to be, you know, working from home out in the cloud, et cetera, also is happening to the detect and respond part of the NIST cybersecurity framework lifecycle, you know, identify, protect, detect, respond, recover.
Ultimately, you do need to also do threat detection and response and recovery of assets, even if it is a person working from home, even if it is in the cloud. And so the exact same underlying drivers for that are also affecting and forcing a change in the way people think about security operations, adding new tools, getting some asset specific stuff, XDR tools is the easiest way to deal with that, extended detection and response.
Because if you got Defender for Endpoint agent on it or CrowdStrike or pick your favorite flavor, Defender for Cloud, obviously my favorite is Defender for Endpoint, just in case anyone's wondering. But you got Defender for Cloud that's getting asset specific around the various different things, Azure storage, SQL, multi-cloud, VMs, et cetera, lots and lots of stuff. But ultimately, that same thing is driven by that, hey, we need to protect at something other than the firewall edge.
And taking an IDS and then blocking an IP, that's just not how it works anymore. And so it's just a lot of folks kind of miss that connection. So that's one of the key drivers, along with modern tooling and alignment with the business that we talk about in that architecture design session workshop. So it's been top of mind for me lately. So that's one of the things I've been focusing on. Defender for Endpoint is one of my favorites.
And actually, because of that, the first new that I'm going to be talking about is related to Defender for Endpoint. Last year we announced the addition of device inventory view as part of Defender for Endpoint. And we've been integrating more and more, including Defender for IoT. To build on top of all this work, we are expanding our device discovery capability through the use of risk IQ. So now with this integration, we could discover internet facing devices. And this is in public preview.
What I love about this is that besides the internal threat intelligence that we are using with our products, adding this capability enables us to see the services from a different perspective, from an external perspective. We have the capability of having better analysis of threats in the environment and mitigating those issues. The next news that I wanted to talk about is DDoS attack IP protection. Actually this is an enterprise grade DDoS protection at a more affordable price point.
I am happy about this because I've seen DDoS increasing actually. There's several articles talking about how it's been becoming more frequent for organizations to have to deal with it, even personally. Actually I've been troubleshooting all the time my family internet and I see all those DDoS attacks. So I am really happy that they have created this more affordable type of solution. So if you have time, just review the links that we are providing to you as part of the podcast website.
And that's all for me. Yeah, I've got a few items. The first one is we now in public preview, Microsoft Defender for APIs with Azure API Management. This is really cool, it interacts, obviously as the name suggests, it interacts with API Management and provides a whole other layer of defense on top of your APIs. I was actually talking to the program manager for it the other day and we're trying to get her on podcast to do an episode because I actually think it's a really cool technology.
Next one is, this is kind of an interesting one. We now have in general availability the ability to ping your Azure load balancer. Now you may think, well, okay, that's not very exciting. Well, it actually kind of is because historically you had to do a TCP ping. You couldn't do an ICMP ping. Well, now you can. Obviously you need to, well, not obviously, but perhaps it sounds obvious, but you need to make sure that you have a network security group configured allowing ICMP traffic inbound.
But other than that, yeah, it's great to see because ICMP is just so much more lightweight than doing a full TCP connection. Another one is Azure Cosmos DB for Postgres SQL now supports customer managed keys for data encryption. I've said this so many times, but I'll say it again, that there's three massive areas that we're seeing across the whole company. And that is managed identities for clients, using AAD credentials, customer managed keys, and using private endpoints.
So this is great to see yet another product, in this case something in my backyard, Azure Cosmos DB, now supporting customer managed keys for data encryption at rest for the Postgres SQL interface. And last but by no means least, many because I just discovered this over the last few days. So if you're writing C sharp code, for example, or any kind of managed code, you may be familiar with the system.data.sqlclient assembly.
Well that has been deprecated in favor of the Microsoft.data.sqlclient assembly. And there's a really good reason why you should start to migrate to Microsoft.data.sqlclient. And that is because in SQL Server 2022, we added a new option in encrypt. So encrypt used to be either false or true. It's a terrible name. It should really be like, you know, protect or something, because it's actually enforcing TLS. So encrypt equals false means obviously no TLS. Encrypt equals true means use TLS.
Well now we have encrypt equals strict. And that disables the trust server certificate directive as well. It does a strict certificate check. The thing is the system.data.sqlclient assembly is essentially on life support. It won't see any major changes being made to it whatsoever. It doesn't know about encrypt equals strict. And so if you actually have some code and you want to use like this strict check, it's not going to work.
So start to think about migrating your code over to using Microsoft.data.sqlclient because we support encrypt equals strict. There's other reasons in there as well. So for example, there's a new, we're trying to move everyone over to using MSAL, which is the OAuth 2 library versus ADAL, which is the Azure Active Directory library or the Active Directory library. So that's not supported in, ADAL is not supported in Microsoft.data.security. We've moved over to the more modern MSAL.
So there's lots of good reasons to move to Microsoft.data.sqlclient. All right, that's the news out of the way. I hope that last one made sense. If you weren't listening, just use Microsoft.data.sqlclient rather than system.data.sqlclient. All right, now we've got the news out of the way. Let's move our attention to our guest. As I mentioned before, this week we have Anthony Shaw, who's here to talk to us about infrastructure as code, but through a security lens.
So Anthony, thank you so much for joining us this week. We'd like to take a moment and just introduce yourself to our listeners. Hey, Michael. I normally listen to the podcast whilst walking my dog. So this is novel to be in my office instead, but I'm the Python Developer Advocate while I run the Python Developer Advocacy team at Microsoft. I've been here for a couple of years and worked in cloud for my whole career. My focus over the last eight years has been on Python.
I've published a book called CPython Internals, which is about the Python compiler, also a fellow of the Python Software Foundation. So I've kind of gone quite deep on Python as a language over the last eight years, but essentially worked in cloud since I was in school. So security pops up a lot when you stick things on the internet.
So early on when I was in technical support, basically going and mopping up all the spills of people publishing applications on the internet with poor or no security and then getting hacked. So that was leakage or just defacement or things like that, kind of working with those customers early on. So yeah, that's been an interest of mine, been application security specifically.
Yeah, here to talk about infrastructure as code and kind of how developers now need to think not just about the application security, but actually start thinking about infrastructure security as well, because often the infrastructure as code template is actually an artifact of the code. So they're kind of spilling into each other. Yeah, I like the fact that you brought up this notion of infrastructure and kind of development.
There's a class that I used to give inside of Microsoft just for personal reasons more than anything else, which was basically teaching infrastructure people how to use developer tools. Because even if you're not a developer and you're an infrastructure person, you've got to know how to use basic developer tools. And in many cases that might mean sitting in front of Visual Studio code.
That definitely involves repositories and version control, knowing Git, potentially GitHub, depending on where you're storing your repos. So yeah, the time has come now where people, even if you're not a developer, you have to understand basic developer tooling. Because that's, and CI, CD pipelines as well, because that's basically the way the world is going. And you also pointed out Python. I mean, people often use Python for infrastructure as well.
So congratulations, you've got to learn development all over again. Is that a fair comment or am I just like, just toot my own horn here? Yeah, no, absolutely. It's kind of whose responsibility is it? And I think when we talk about security, security is everybody's responsibility. That kind of overlooks that you need to have domain expertise and security, and not everybody can have that. When developers now are saying, okay, here's my application that I've been working on.
Here's how you would deploy it to the cloud. And I can describe that in code now, in templates. When do they work with a security team? Do they do their own security reviews? Do they need to understand the security implications of what they've put in that template? And both the development team needs to understand those things. But also, I think, no matter what you're doing, whether it's, I mean, IT admins need to understand code nowadays.
You're using PowerShell or another scripting language to do pretty much everything in AD tenants or in Azure tenants or in Office 365 tenants. So that is your interface to the cloud now. So you need to understand those programming tools. And you can't just have a shared drive where you put all the scripts and then everybody writes to it. You need to have some sort of version control.
And then once you introduce version control like Git, then you should start to think about how do we automatically check the scripts that we have, the templates that we have, the code that we have. Because developers are used to doing this. They've been doing at least the CI part, not necessarily the CD part, for a long time. So when we check in code, push code up, all the tests should run automatically and say, oh, you changed this, but it broke this other thing.
So we want to verify that as early as possible. And that's not just the test from a code perspective now. There's a lot of other things that we verify typically in a CI process, which would include style, like have we used names for variables that people don't like? But also, have we made spelling mistakes? We've added more and more automated tools in that process. And that's kind of where I see it bleeding into infrastructure security in particular.
Yeah. And if I can add sort of my two cents on it, in a way, infrastructure people, which I am one, and so my questions will definitely be coming from that origin story. I'm definitely a security person now, but started my IT career in the infrastructure side. It's easy to forget sometimes, if you're not Michael Howard, that helped build Windows, that all those things that we're used to hitting setup exe and installing or clicking out and making a VM, that's all code that was all developed.
And it's just that that line is getting a little bit fuzzier, where it used to be, hey, we got this CD out of the box from Microsoft and then we do the thing and occasionally run an update. I mean, it's code at the end of the day. And so it's just that as you need to do custom things and there isn't a pre-packaged SaaS app or box software in the old days, it's code. And so you need to be able to have a custom app that does that custom business requirement.
And so I sort of see it as a little bit of a back to the future or a redefining the line between what is packaged for you and supported and maintained by a vendor versus what is really custom. You're going to have to potentially put in some code or copy paste somebody else's code and then make sure that that stuff is secure in the code rules kind of way versus the infrastructure rules kind of way. So you've been talking about infrastructure as code and security.
What kind of issues are you seeing that are being addressed? Yeah, so there's five major things that we've been seeing when looking at the security of the infrastructure that's being defined in the code. The number one is the network security. So now that in the cloud, everything is essentially a software defined network.
When you create networks between applications and databases or different data layers or when you're defining what is public, what is not, whether you have VPNs, things like that, all of that is a kind of a network definition. An application template can include its own network and its own network infrastructure. So what is the security of that network? And network security is its entire, it's a whole domain in itself and people do that for a profession and it's extremely complicated.
So it's kind of unreasonable for a developer to suddenly go, oh, I'm going to define the network and the security spec. So network security is number one. And then there's the secret management. So you can, if you wanted to, hard code the secret for the database, the admin username and password. You can hard code that in the template if you wanted to, you shouldn't, but you can. And then you've also got secrets to pretty much everything else.
So your monitoring infrastructure, your database backend, your caching. Every time you bolt on a service that is used by the application, you're able to authenticate that service. So that links into the third one, which is when and where do you use managed identity? And which service is compatible with that and can you connect that in? So managed identity kind of links into that as well. And then the next one is the actual code itself and who or what can change that code.
Because once you've got the application up and running, you can change the code on a frequent basis. So you don't want just anybody to go and change the code in the production server or even the test environment. So how do you verify the code that gets published, who it is? Or often if it's an automation tool, like where that's coming from? And then make sure that somebody hasn't injected some strange code or even just by mistake sometimes managed to deploy to that environment.
So that's the four major things that we're seeing, but there's a few other bits and pieces that are popping up as well. The fifth is what application security requirements do you put in around there? So what types of firewalls do you have? What kind of auditing do you have? So within the Azure Security Suite, then what do you include? I've got to pull the newbie card here, because I understand the concept of IEC and the automation power of it as a general point.
Can you give us, me included, our audience an overview of what is IEC? What does it do and how does it work? Just a couple minutes, just quick explanation, just to make sure that we understand this. Because all that stuff sounded familiar, but I wasn't sure what framework to hang that in. Yeah, sure. So you traditionally used to have to deploy things, not infrastructure, by going through a GUI, like the portal or the installer. You talked about the old style installers on the desktop.
And then you would have a set of instructions saying, okay, this is how you would install this product, or this is how you would configure it. So go in the portal, pick this option, change this dropdown. So when you're building an application, normally you would have a sandbox, so you would put all the products in place, configure all the services, get it working.
And then when you want to repeat that process, you don't want to have to describe by hand what you need to click on and which options you need to pick. So what you can do with infrastructure as code is you can basically take a snapshot of that and then describe it in code. It's more like a template. So ARM templates is one method of doing it. Bicep is another. There are also non-Microsoft specific ones, like Terraform is an infrastructure as code tool.
And basically what the infrastructure as code tool will do is it will look at the template, it will see that you've defined, let's say, a VNet and an app service. And maybe within that you've got some service principles. So you would define those in code and say what all of the parameters should be. And then the tool will look at your target environment. Let's say that's in Azure and you've got a tenant. And you say, okay, deploy this template to Azure.
It will look at Azure and say, does that component already exist? No, okay, let's deploy that. And then it will check that all the settings makes a change in the portal and doesn't actually capture that in the template. The next time you run the template, it will override that. So basically it makes sure that what is in the template actually matches what is running in the environment. Gotcha. And does it enforce that over time or is it just sort of that initial setup for the app?
It's just the initial one. If you run it again, it will override the settings. So it's something called idempotent. This is a very strange word, which is kind of common in DevOps tools where you basically describe something as code. The goal should be that the outcome will be the same no matter how many times you run it and no matter what the target looks like. So if the target doesn't exist, the outcome should be the same.
If the target does exist but it's configured weirdly, that's kind of one of the principles of the infrastructure as code tools. Gotcha. So I think I've actually been exposed to this as sort of the portal jockey where it's a little button that I never really use that generates the technical configuration of things in the Azure portal. Yep. Awesome. Thank you. That helps a lot. Like Mark, I'm also learning about infrastructure as code. Actually I've been playing with Bicep lately.
Can you give a brief explanation why would you choose to use Bicep or Terraform versus ARM templates in order to do infrastructure as code? Yeah. ARM is very, very verbose. So if you create an environment, kind of in principle when you're deploying applications it will be housed within a resource group. So you kind of use the resource group as the soft container or the boundary of the application.
What you can do in Azure is you can pick on a resource group and say, okay, create a template for that entire resource group. So it'll say, okay, if you wanted to deploy everything in that resource group again, here's what it would look like as a template. And it will give you that in ARM. And in most applications it's going to be thousands if not tens of thousands of lines because there's a lot of settings in there. There's a lot of properties. It includes even things which you didn't override.
So things which are the defaults but you didn't override them, it will include all of that stuff in the template. Now that's fine if you want to just save that and take a snapshot and then going forward. But to actually work with it as either a developer or an infrastructure expert, it's quite hard to read through and understand what's going on. I find ARM is actually more a language that Azure speaks. So Bicep is an abstraction on top of ARM. So basically it's a different syntax.
It's designed for people to actually write templates for Bicep. And then Bicep templates actually compile into ARM. So you can actually use the abstraction layer on top of ARM so that you don't have to define all of the defaults. You don't have to define so many of the dependencies. And also you can set variables because let's say you've got a resource group and you've named everything. I don't know, I've got a notebook on my desk with a unicorn on it. You've named it the unicorn application.
You want to call it something else. So you would say, okay, that is a variable. That's a thing which can change each time I deploy the template. So in Bicep you can say, okay, that is an input. So when you deploy that template, it will ask you what's the name you want to use and then it will go and populate all those fields. What I have learned is very little, but I was trying to basically assign some roles for each of the subscriptions that I'm working on.
Do a policy assignment, Azure policy assignment. And what I like the most is how short it was to input all this. So it allowed me to implement a lot of security type of settings really fast. And I like re- type of command because it basically puts the beginning of the template and you have to fill up things. So if the listeners want, I recommend Bicep. I haven't played with TeraFone, but it's really easy to use.
All right, so one thing you sort of touched on before was the sort of things that you look for when you're reviewing these templates. I mean, how do you do that? I mean, do you do it by hand? Do you have a tool to do it? Like you said before, you can end up with an ARM template or ARM templates that are thousands of lines long. So what's a quick way of doing that? Because you need to do it at scale eventually. So what are the best practices around that?
So how we were doing it before was we would deploy the template and then go into Defender and do a review of that resource group. And that would then come back with, oh, this setting is not really ideal. We haven't used managed identity where you could have done or kind of highlights any kind of security risks and then prioritizes those.
And what we would do is then go back and look at the template, make adjustments, deploy it again, run the audit again, and then see kind of what the differences were. So that's kind of the old way of doing it. There's a couple of challenges with that approach. I mean, the obvious one is you've deployed the infrastructure. The security issue that it's picked up is significant. I mean, we were doing that with test environments, so there's no exfiltration risk.
I mean, there's no secure data on there, but still, you shouldn't really be deploying infrastructure to a public network and then seeing if it's insecure because that ship's kind of sailed already. So what we've been doing instead recently is using Defender for DevOps, which is in preview. So there's a tool called Template Analyzer. We've basically integrated that into our CI-CD process.
So what we have in the repositories, the code repository for each of these applications that we're building is we've got the code, so the actual app itself, and then we've got a folder which has got all of the bicep templates. And then in GitHub Actions, but it works for Azure DevOps as well, we've got basically a workflow that would then go and verify that the application works, like runs all the tests and stuff like that.
And then the next thing it does is runs Template Analyzer, and then it checks whether there are any security issues in the template before it has actually been deployed. So what that's picked up is a lot of the stuff which I've mentioned already, which is around how you're managing secrets, how code can be deployed, and then where managed identity is being used as well. So it actually highlights a lot of that stuff up front.
The good thing about that is you've always got, in application testing, you've got this time to fix versus the cost of the fix. And the principle is the sooner you spot the bug after writing it, the cheaper and quicker it is to fix it. Make a bug in the code and you run the tests locally on your machine and it tells you that's broken, you can fix it and that takes five minutes.
If you only discover the bug because you've shipped it to a million people and you have to patch it and ship a hot fix, that costs you a lot more money. So it's the same with this. Shift left, always cheaper, always better. Yeah, cheaper and faster. So if you have a security issue based on either the initial check-in of the template or a change, then people can make that adjustment.
So if we've got a repository that's got the infrastructure defined and someone on the team comes in and makes a change to the infrastructure template, then the tool would run automatically and in their change request, in the pull request, they can apply, here's a link to the documentation.
And then when you're reviewing that code change before even approving it and merging it in or even getting it anywhere near deploying it, you've already had a discussion about whether that is creating a security risk or if it's a false positive, then the reasons why and let's document that and it all gets captured in GitHub or alternatively within Azure DevOps. You know, there's actually a really good analogy here. I just thought about it.
If you're deploying some resources and then running Microsoft Defender for cloud to see if you've got vulnerabilities, that's a lot like a dynamic analysis scan. But if you're actually looking at the code for potential issues, that's very similar to a static analysis scan. On my lifecycle, we actually require both. You've got to do a static analysis scan and a dynamic analysis scan because often they find different things.
So would you recommend that people, even if they're, I don't know what the answer is, but here we go anyway, even if you are using Defender for DevOps, even if you are doing analysis of your infrastructure as code files, obviously Microsoft Defender for cloud is still important because there may be some things that the cloud can possibly pick those up. Both need to be done. And we actually kind of touched on the reason why a bit earlier.
So I was saying the way the infrastructure as code works is the outcome should always be the same no matter how many times you run it. What it doesn't do, it doesn't monitor the infrastructure to see if there are changes. It only does that when you do the deployment. So if somebody went into the portal or the APIs or the Azure CLI and made a change which created a security risk, then Defender is going to pick that up.
Alternatively, there are some more complex scenarios that Defender is also going to pick up. So there's only so many things that the template analyzer can do because it's still just looking at the template. It doesn't have as much context as Defender does. So you kind of need to use both. Very similar to using static code analysis to do application code reviews.
You'd want to look at something statically and highlight that really early on, but you still need to have a security testing process to actually verify the application whilst it's running. Because there's only so many things that you can verify statically in code. And it's the same with templates. So it sounds like there might actually be multiple teams involved in this.
Not just the security team, the IAC team, it would have to be the ones that fixed it because nobody likes someone else messing with their stuff. Are there other sort of specialties like would the developers get involved or infrastructure folks? I'm just kind of curious from a role-based perspective like what you typically see. What we're seeing is that the developers are very heavily involved in defining the infrastructure requirements.
Because within the cloud, where everything is kind of platform as a service, the infrastructure components are actually closer to what the developer is used to doing rather than what a IT admin is used to doing, if that makes sense. So when you're defining what an application needs, you would say, okay, I've got a caching component. I've got the application itself. Which language is it running? What version? And then within the database, I'm just looking at the development of the infrastructure.
So how am I configuring it? What performance requirements do I have? So a lot of that, the developer would have specific expertise in that. Then you've got more of a solution design and solution architecture role, which is looking at, okay, what are the requirements of the infrastructure in terms of performance and scalability, and then you've got the security aspect as well. So actually looking at the infrastructure and saying, okay, for that design, what security risks could we have?
How are we mitigating them? And where are we doing that? The thing I really like about Bicep, if you're working with Bicep, is that a Bicep template in VS Code, so if you're using Visual Studio Code with the Bicep extension, when you're running a template, it's a lot easier. One is it's got a visualization tool, so it'll actually draw a infrastructure diagram of everything that's in the template automatically.
So that's a really easy way of sharing with people, okay, this is what the infrastructure would look like, and then annotating that. Something else that you can do is, if you've got a piece of infrastructure that you want to turn into a template, instead of doing the entire resource group, you can say, can I just give you a specific resource in Azure, and can you create the template for just that?
So for example, you've got Redis in Azure, which is a caching service, then you'd say, okay, I've actually got one of those running, I know that it's configured properly, so you can go from VS Code and say, okay, import that into my template. So yeah, that's kind of how the teams can start to work together is actually to review the templates and then to do the process, but the visualization tool was a nice way of kind of starting that conversation. Yeah, that sounds pretty slick.
So before you gave us four or five examples of the kinds of things you look for, from my perspective, number one is always secrets. I'm always looking for secrets in anything, whether it's code or configuration files or whatever. But what about networking? The most common one that we come across is how the application code talks to a backend service like the database.
So if you have a software-defined database like Azure SQL, Azure Database with Postgres or MySQL, or even Cosmos and Cosmos for Postgres, they're all kind of similar, you need a way over the network to connect to that database. And Azure's got its own networking infrastructure, so it can connect automatically to any database, but you don't necessarily want the database server to allow connections from absolutely everybody on the internet. It does have a layer 7 firewall.
It's also got Azure SQL and Azure Database with Postgres and MySQL. Both have throttling capabilities, so if it does try and attack it to work out credentials, for example, it will throttle that over time. However, if somebody created a credential with some really weak username and password, then you've still got that on the internet and potentially you've got a big exfiltration risk.
So what you should do in practice is make sure that only the application can connect to the database and try to authenticate. And the way that that should be done, it will be using a virtual network or a VNet. So in the template, you should define for your database that it is exposed on a VNet, and the only other thing which is on that VNet is the application which needs to connect to the database.
The complication there is that developers sometimes want to connect to the database via a video or one of the Postgres management tools directly from their home computer or the office computer. So you've got to work out whether you want to put a gateway in there like a VPN or add a specific firewall role to NAT them in. But what I often see is that people just put Azure SQL or Postgres on the public internet and the portal that says allow all Azure IPs.
Now that doesn't just mean for their tenant or even for their subscription, it means everybody who is on Azure. So basically that's opening yourself up to additional risk. So that's kind of one of the big network security issues I kind of see in the templates. So, Antoni, as a summary, can you provide some capabilities that can be implemented in infrastructure as code in order to better the security of the infrastructure? Yeah, absolutely.
So I think if an application is self-contained, then the infrastructure template should include the service principles, the identities, and also the role permissions that are required for each of the components to be able to authenticate and connect with each other. So the code is it's all isolated and when you're looking at that and auditing that in the future, it's clear all of these role assignments belong to this application and this is the boundary of that application.
So you're not having people manually doing role assignments and then you've got to all of a sudden worry about the configuration and auditing that.
So if you want to have policies within your organization that say, okay, we definitely need these auditing features enabled, we're going to have only these kind of minimal role assignments, then you can put that stuff in the template and then whenever that template is deployed, you've already got all of your best practices, not just the ones that we at Microsoft define, but also the ones that you've got within your org. You've automatically got that stuff deployed and running.
So you've basically rolled out your best practices from the beginning and it makes review a lot easier down the track. Anthony, one thing that we always ask our guests at the end of the episode is if you had just one little final thought you would leave our listeners with, what would it be? I'd recommend you check out the template analyzer tool in Defender for DevOps, which is in preview. It's a free tool, it's open source.
Have a go with it, run it over some of your templates and then have a look at the results. That's my recommendation. Thank you so much for joining us this week. Always learn a lot on every single episode and this was absolutely, learned a great deal. I know all of us did. It's actually kind of interesting also from my perspective being a developer, Mark and Gladys, mainly being infrastructure folks, don't mean to offend anybody, but it's interesting that you're sort of stuck in the middle.
But that's good to see, right? I mean, we're seeing the world move to using these development tools for managing their infrastructure. Thank you so much for joining us and to all our listeners out there. Thank you so much for joining us. Take care and we'll see you next time. 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 Azure Setpod.
Background music is from ccmixtor.com and we'll see you next time on Azure Security Podcasts.