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 73. This week is just myself, Michael and Gladys. And we have two guests this week. We have Boyan and Sean, who are here to talk to us about Microsoft Defender for Cloud as code. Hopefully that will become evidence as we go through this. I only have one news item this week.
We've just announced in public preview more capabilities for migrating on-prem databases to Azure SQL database, most notably authentication and authorization steps, as well as TDE or transparent data encryption. Anything that reduces the friction of any kind of migration like this is always welcome. So this is great to see. And of course, it's also in my own backyard, which makes it even more exciting for me. So let's now turn our attention to our guests.
So this week, as I mentioned, we have Boyan and Sean, who are here to talk to us about Defender for Cloud as code. Gentlemen, welcome to the podcast. Would you like to take a moment and introduce yourself to our listeners? Thanks so much, Michael. Boyan here, product manager with Microsoft on the customer experience engineering team for Defender for Cloud.
I act as a subject matter expert on Defender for Cloud for a select set of Microsoft's largest customers and helping them not just deploy Defender for Cloud, but also capture quality feedback as to what we can do to further drive the evolution of the product. And I couldn't think of a better person to join me today than one of my close good colleagues, Sean. Great introduction, Boyan. Hello, everyone.
My name is Sean Wasonga, and I am also a product manager with the customer experience engineering team. On top of covering solutions such as Defender for Cloud, I do have an array of experience with Microsoft security solutions such as Sentinel, Defender for IoT, and I'm now focused on Defender for threat intelligence. I work with customers and partners, and it's always interesting to see how we can have discussions that give them visibility of some of the things that we're seeing in the field.
Fantastic. Actually, it's a really good job. Sarah's not here this week because he mentioned Sentinel, and she'll be getting all excited about it. So anyway, we'll stay focused on Defender for Cloud. All right, so let's just kick things off. Look, so a very good friend of our podcast is Yuri Diogenes, who is well known in the Defender, sort of Microsoft Defender arena. But it's been a while since we've had him on the podcast.
So would you mind just spending a little bit of time kind of explaining what Defender for Cloud is? Because I know things have changed over the last few months. They certainly have, Mike. So the innovation is not stopping in the Defender for Cloud space. We're not just looking to add more capabilities, but we're looking to even address more use cases that we're seeing with the clients that we're engaged with, as well as the partners that Sean touched upon.
So just to remind folks on this show, so Defender for Cloud is one of Microsoft security solutions. It's something that the market is referring to as a cloud native application protection platform or CNAP.
And that's also important to recognize because it has a lot of other functionalities, most of which, however, can be divided into three buckets of functionalities, one being around providing continuous assessment for infrastructure service, as well as platform as a service, workloads that can be inside of Azure, that can be outside of Azure, and detecting any misconfigurations in them.
And when the Defender for Cloud detects misconfiguration, it's able to then provide with security best practice guidance on how to harden those workloads and remediate them. The second kind of pillar or bucket of capabilities is all around threat detection. How it's important to remediate misconfigurations.
It's equally important once best practice guidance has been applied and resources hardened, to also monitor the environments for potential signs of compromise, which is why we have also the second pillar of capabilities. And I'm also very, very excited about the third pillar of capabilities which we have, which is really around the DevSecOps space and how to centrally better manage DevOps security.
So this comes in the form of something referred to as Defender for DevOps, which is a plan we announced in November of last year. And I know that sounds like super far away, but it was effectively only a couple of months ago. So a lot of excitement and a lot of capabilities and use cases that we also cover in that space. So all of those capabilities kind of put together make up what's nowadays Defender for Cloud and what Gartner refers to as a CNAP solution.
And it's also very, very important to recognize we not just do this for Azure, but we obviously do it outside of Azure with native support, for example, for AWS and GCP. And we can even integrate with another Azure service called Azure Arc and also extend Defender for Cloud capabilities to hybrid. So just a quick whistle tour of what Defender for Cloud is and its latest positioning. Thanks for that question, Gladys.
I think just to sort of state in terms of what area we're trying to resolve and basically address, it's more in line with our roles, right? Customer experience engineering. We're constantly hearing from the field, our engagement with customers and partners, how they can leverage all those functionalities that Boyan mentioned across the different workloads, right? And the different environments, whether it's on multi-cloud environments, on-prem leveraging Azure Arc.
And in line with how they do their operations from a technology perspective, how can we help them programmatically deploy and manage our solution? Now, if you think about Defender for Cloud, we're supporting an array of different workloads, whether it's your storage, whether it's your networking, whether it's your compute, et cetera. And what's of interest from us, from our customers and partners is to understand leveraging the internal tools that they use and the internal processes.
How can they leverage infrastructure as code to deploy and manage that defined solution? So why are we here? It's just basically to take our customers through that process in terms of using infrastructure as code in deploying and managing MDC. Let me make sure I get this correct. I want to make sure I get this fully understood.
So essentially what you've got is the intersection of Microsoft Defender for Cloud with infrastructure as code so that you can deploy and monitor Microsoft Defender for Cloud, but using code as opposed to, say, for example, the portal. Is that a fair summary? Absolutely. So there are a couple of different advantages of using infrastructure as code. So at a very, very high level, it really allows organizations to describe to desired states of their public cloud infrastructure.
So they can really programmatically describe as to how does good or how does best look like for them with regards to public cloud infrastructure that they're using. They can then use things such as templates and put those under version control touching upon the likes of, for example, Git to then make track changes made to those templates.
And this is important because every time when they make a change to those templates, which describe their public cloud infrastructure, they can then programmatically deploy those changes to their public cloud environment. This can obviously be Azure. It can be also other public cloud environments as well.
And here is where we then see that intersection happening between Defender for Cloud as well as infrastructure as code, where on one side they have infrastructure as code with templates that really programmatically describe of how do they want their public cloud infrastructure to look like, and they can then use tools like, for example, GitHub actions to ensure that those are programmatically deployed to their public cloud environment.
And here is where it also applies then to Defender for Cloud. They're able to use it to configure different aspects of Defender for Cloud or to ensure that the desired state of their public cloud infrastructure is what they want it to be. So I just want to make one last comment and then I'll hand it over to Gladys.
There's a comment that I made a long time ago, which is, if you're designing and developing and deploying solutions on Azure in Europe, so let's say a software developer, you've got to learn basic networking or that kind of stuff, or basic infrastructure controls. If you're an IT person who's used to doing management of solutions, you're going to have to learn basic programming or basic programming tooling. And here we see another example. Something that sort of says infrastructure is code.
For example, this stuff we're talking about right now, you've got to know things like tooling and you've got to understand the basics of version control. And I mean, don't get me wrong, that maybe it will be configured for you. But all of a sudden you see yourself sitting inside of a code editor, and using, as you mentioned just now, using Git and GitHub actions and those sorts of things.
So yeah, this is another great example of where, again, if you're an infrastructure person and you really want to progress your career, you really have to start skilling up on these kinds of tools because you're going to get left behind if you don't. And I'll hand it back, that's just a quick comment, but I'll hand it back to Gladys. Actually, before I ask the next question, I'm going to comment myself.
I definitely agree on this because we always talk about embedding security with any infrastructure that is being built, right? So this is what this capability is enabling, right? From the get-go, get the different capabilities enabled with the infrastructure that is being built. So talking about that, then who is the intended audience for this? Who do you think would take the most advantage of this type of capability? Good question, Gladys. For us, we really think everyone, right?
If you think about whether you are end customer, you are partner supporting end customers, you are managed security service provider, this whole element can actually support you to deliver your overall security operations and helping you scale and deploy Defender for Cloud with ease. It's something that it's really intended to help all these different personas in different ways.
Whether it's a managed service provider that has multiple tenants and they need to, for example, deploy one specific detection threat analysis solution across different tenants, it can be done with ease. Whether it's a customer who has multiple tenants as well, or a customer needs to onboard new subscriptions, it basically works for everyone. And that was our intention in terms of coming up with this defined guide as well. I want to focus a little bit when you say multiple tenants, right?
This is really important. It's not just multiple tenants, subscriptions, and resources overall, right? And now that organizations are keeping up and having multiple subscriptions to deliver a service or an application, I think this capability can be used tremendously to ensure that all the configuration is seamless across all those subscriptions. Am I misunderstanding this?
No, you're capturing it quite well, Gladys, and if you think about it, even on the customer end, we live in a global village, right? Like an organization that's probably situated in the United States of America will probably have other areas in the UK, organizations that are still tied to them in the UK, in Africa, in South America, et cetera.
And the solutions such as this can actually help you have a singular way in terms of how you deploy and manage your overall security solutions, specifically around Defender for cloud, but in a specific standard. So leveraging infrastructure as code is something that can help you do that. So how do I get started? That is a question that Sean and myself also asked ourselves when we started working with our clients and with our Microsoft partners as well.
And what we realized is we had to Michael's point. So we invested time in being able to then write this code. And we already knew how do we want our public cloud infrastructure, especially Defender for cloud, to then be configured and to look like in those even global environments. The thing we just needed to then come to terms with is what vehicle do we then use to programmatically deploy these changes?
So we opted for using GitHub actions and predominantly just because the code that we've written, so our infrastructure as code templates, they were already in GitHub to begin with. So it was a logical for us then to use the native GitHub tooling, which is GitHub actions for us to be able then to programmatically deploy our infrastructure as code templates to the Azure environment as well as then configure Defender for cloud.
Now this is not to say that you all out there listening can't use something other than GitHub actions as well. So that's a little bit where the beauty in this also resides. So you can use things even like Azure DevOps, for example, you can even use non-Microsoft tooling because a lot of the guidance that Sean and I put together, you can even apply it to non-Microsoft tooling that you probably might be using as of today.
So just to add on that, yes, we did advise that you can move towards GitHub actions. We have quite a number of tools that you can actually use. But in terms of the work that myself and Boyan did is we realized that sometimes you need a guided path in terms of how you can get this going. And we came up with three ways in terms of how we can actually deliver this in form of content.
One, we did publish an article that can actually help you get started with the whole process of deploying and managing Defender for cloud as code. That article is publicly accessible and it provides a step-by-step guidance that's really extensive and not only does it focus on infrastructure as code, but it also provides guiding principles around Azure policy, REST APIs, and Azure CLI and PowerShell all in relation to what's deploying and managing Defender for cloud as code.
Two, we did create a GitHub repository that actually contains example workflows that you can use as a starting point to kickstart your automation deployment for your Azure environment with GitHub actions. We do believe in community and we're really interested to see how many people can actually contribute towards that repository, adding more workflows and bettering our overall process. Last but not least, we did create a YouTube video.
Now the video provides a live scenario in terms of how you can actually leverage what we created with GitHub actions and helps you to deploy Defender for cloud programmatically. Now if you combine the blog, what we have in the GitHub repository and video, you should be at a good spot in terms of leveraging infrastructure as code to deploy and manage MDC.
All right, so you sort of covered off really briefly how to get started, but when the rubber hits the road, what sort of assets are you guys providing to help people really make some traction here? That's a really good point. So imagine if you're now a security engineer listening to this podcast, how do you actually get started?
So we even see it as end-to-end journey between now using infrastructure as code, committing it to your repository, then using things like GitHub actions or Azure DevOps to then programmatically deploy it in your Azure environment for which you can then configure the different aspects of Defender for cloud. So what Sean and I put together is we wanted to really capture each step on this journey.
So we provided even with the DevOps automation that can be used and step-by-step guidance on how to create an application identity in Azure, how to connect it to GitHub and even templates in GitHub for different GitHub actions that resemble specific aspects of either Defender for cloud that you can configure or different use cases that you can achieve.
What we also did is because we realized working with organizations that there are a lot of different ways you can apply Defender for cloud because it has a lot of capabilities. We also wanted for simplicity sake to provide the guided inventory of what are the configurable components that you can then use this templates to configure Defender for cloud for.
So that was also a big thing for us is really trying to simplify it as much as possible and providing folks with kind of bit-sized modules that they can apply to their Azure environment but also to their AWS and GCP environments, which is why as part of the guidance we also in addition to those modules added best practice guidance on how they can automate the whole deployment of Defender for cloud at scale.
So even it covers things like enablement of Defender for cloud not just in Azure but also at scale outside of Azure. For example, onboarding once AWS and GCP environment to Defender for cloud and having that multi-cloud security insights all in a single dashboard. We also then want to make sure that we cover this process end to end, which is why we all put that all together in form of those three deliverables that Sean mentioned. So when should we use this?
What are some of the use cases that can be covered? Great question Gladys. So I do have a couple of thoughts where we think this can actually be applied. I did mention a few. Top of mind, we talked about partners that manage security providers that are deploying Defender for cloud as a security solution across multiple customers and multiple tenants. This is something that's ideal.
Having specific templates based off of specific standards and easily allowing you to start monitoring the environments, enabling these threat plans, starting getting alerts and actually responding to them comprehensively. That will be one of the key use cases that I would think of from the onset. Secondly, now this is on the customer base. Your new customer, multiple workloads, you're working on new subscriptions.
You want to ensure your environment that's a multitude of different workloads, whether it's your compute, your storage, your DNS, your DevOps environments. And you want to ensure that it's actually covered towards a complete extent. You can actually leverage this across in terms of how you can ensure that every new subscription that's onboarded is protected and covered by Defender for cloud. Boyan, I don't know if you have another use case that you can think this would be practical for.
I believe even Gladys touched upon it and it's all about how to then seamlessly configure and embed security into infrastructure. And I'd like to add that nowadays infrastructure doesn't need to reside just in one public cloud provider. We are seeing examples where organizations are using multiple, which obviously brings with itself a sort of complexity because there are things that differ between individual public cloud providers when you compare them.
So it's also all about how to use this guidance to put something in place where you seamlessly then embed security, not just in Azure, but also in AWS as well as in GCP by using the vendor for cloud. And I believe that multi-cloud aspect is something also worthwhile just highlighting because we see it's also in the organizations that we work with, regardless if they are just Microsoft partners providing service to their customers or customers themselves looking to adopt Defender for cloud.
I'm getting excited about this. As we have talked to our listeners before, one of my roles is helping engineering or developers teams within Microsoft to embed security with our services. And one of the things that I keep recommended is Defender for cloud, right? So if we had a Defender for cloud as code type of capability that now you are talking about it, I could basically give that to my engineering teams. But at one time you talk about version control.
So can you talk a little bit about how that would work? Because there's different components of Defender for cloud. What about if I just want to deploy right now the free version and then eventually I want to add all the other components, how that version control will work? Happy to. So when we work with customers, when they start on this journey to onboard to Defender for cloud, some are even surprised by the amount of misconfigurations that Defender for cloud attacks.
And on one hand, that's also a good thing because it allows them to evolve their thinking about how to better secure their resources and how to deploy those resources more securely going forward in Azure, but also across AWS as well as GCP. And version control allows us then if they need to make any changes to the infrastructure as code templates, that they use them to programmatically deploy those resources in their, for example, Azure environment. And they need to then further harden it.
They're able to change the template and they're able then to even use version control to track any changes made to it. And also to your point Gladys, is the innovation in this space is not slowing down. So we're continuing to invest in Defender for cloud. We're continuing to bring out new capabilities in form of new plans, which is why we can then look to add those to the deployment guidance that Sean and I put together.
We're able not just to configure different aspects of it that are currently available in the product, but they're obviously reflective of the new plans and capabilities that we're going to be looking to add. All right. This has been great. I'm always a big fan of infrastructure as code just because of my development roots, but it's nice to see this work being done to help people manage and monitor Microsoft Defender for cloud. All right.
So one thing we ask our guests on every podcast episode is if you had one final thought to leave our listeners with, what would it be? From my side, I would encourage folks to give this a try. And a lot of organizations still believe that they need to have, let's say, a DevSecOps team of engineers to set these things up and we can't commit to it to do it today. We're going to do it next quarter or we're going to do it like next fiscal when we get the budget for it.
So my kind of call to action to folks listening to this is just give it a try. It's surprising the value that you can get just by connecting, for example, your AWS GCP environment to Defender for cloud and having all of those insights in a single dashboard where you're able then to take those insights away with you, work with the internal teams, even the workload owners on remediating those misconfigurations because those in turn will make your environment and your organization more secure.
On my side, it's more in regards to two things. It's not leaving you with a thought, but it's more of a statement and a call to action. So from a statement perspective, one thing that I can always depend on is the creativity and great insights that we usually get from our customers and partners. So my call to action would be we will be sharing the GitHub repository and the guide and the YouTube videos.
So we're interested to see what sort of ideas our customers and partners can actually provide in forms of contribution towards those GitHub repositories. We shared a couple of workflows. We had a couple of ideas in terms of what you can enable automatically. And it's just basically focused on GitHub actions. If we can see contributions on Terraform, Bicep, Azure DevOps, I think it would be amazing.
So my call to action is to the customers and partners go forward and contribute as much as you can. And I'll be looking forward to see what it can actually do. Yeah. And we'll have links to absolutely everything, including the GitHub repo in our show notes. So again, hey, thank you so much for joining us this week. Really appreciate you taking the time. And to all our listeners out there, thank you so much. We hope you found this episode of use. Stay safe 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. All music is from ccmixtor.com and licensed under the Creative Commons license.