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 52. 52 means we've been going for two years, officially two years. So it's our second birthday today. Really excited. I didn't think we ever would get to where we're at, but really, really proud of this podcast.
So some fantastic guests over the years, like last two years, and hopefully we have many, many more years going forward. This week, we have myself, Michael, we have Mark and Sarah. Gladys is out right now, and we also have a guest, Shai Amar, who's here to talk to us about Microsoft Defender for Containers. But before we get to Shai, let's have a lap around the news. Mark, why don't you kick things off? So we're actually getting ready for build and RSA. So not a whole lot of specific news.
So I thought I'd take the opportunity to reinforce some just ongoing critical best practices around. When we look at the most damaging attacks that are out there, it's still unfortunately ransomware, which are really extortion attacks. So just want to make sure that folks had a current perspective on that, which is you have consistently focus on backups first, make sure that can back up the systems that matter, and that you can restore them quickly, being the much more important part.
What we've learned there is, it's really a team sport between security and IT and business folks. Because the only people that can answer the question of, if everything is down today, would you need running tomorrow morning first? That's the business folks. Then what does that translate to in terms of specific systems and technical assets, etc.? Well, that's your IT team. Then how do you best protect those against the attacks we're seeing? Well, that's the security team.
So really going through that process, working with your business and IT partners and security in there is super, super critical to make sure that you are able to recover quickly. Then the next step for it, which also applies in any other attack as well, to reduce the damage is of course privilege access. You can do a lot more damage as an attacker with admin account, than you can with a standard user account.
The securing privilege access, we do have that full end-to-end strategy, plan, technology and specific steps outlined on how to protect your most important, most impactful technical IT accounts, like global admins, enterprise admins, domain admins and the like, as well as your other privileged and sensitive roles, like developers, like a Swift terminals, where effectively people make financial transactions, maybe trading terminals, et cetera, depending on your business.
So those super high impact things are also covered by that privileged access guidance. And that's just the AKMS slash SPA or SPA, as we like to call it, for securing privileged accesses out there. Okay, so I guess it's my turn. Kind of the same as Mark. It's a little bit quiet on the news front, because we're leading up to RSA. So there's going to be lots of news in the next few weeks. I'll also apologize if I sound stuffy, because I got COVID. We don't all record in the same room, by the way.
So I'm not giving anyone COVID. Definitely a couple of things. Obviously it would be wrong if I didn't talk about my baby Sentinel. We've got a couple of public previews, which have come out. We've got similar incidents. So when you raise an incident in Sentinel, it will now also suggest similar incidents, whether they've been closed, or just anything that we've seen. So that might be, it will help you see if you've got other incidents that might be part of a larger attack story.
And the other thing, I don't know, Michael or Mark, if you have done this yet, but this week just gone, I did my SC100 exam in beta, Microsoft Security Architect. Because it's in beta, I haven't got my result yet. My fingers crossed I passed it first time. Go and check that out if you're interested, if you're keen on your Microsoft certs, because that's a pretty new one that's definitely, I think a lot of people will be wanting to take.
But if you've never taken a beta exam in Microsoft land, you don't get your results straight away. You get them a little bit later. So that's always worth bearing in mind. Hey, it's funny you should bring that up about SC100, because you and I also did our AZ500 refresh, right? Roughly the same time. We did. Yeah. For those of you who don't know, we actually did our AZ500, which is the security services or something as your security services.
We did it the same week without even knowing that each other had taken the exam the same week. I barely passed, I'm not to be honest with you. Knowing Sarah, she probably aced it, but anyway. Yeah, but now that it's been a couple of years or something, I don't know how long it is, you have to have it refreshed. So I'm going to tell you right now, if you have AZ500, do not let it lapse. The refresh is actually dead, dead simple. Compared to the exam, it's probably two orders of magnitude easier.
All you need to do is just go to the Microsoft learning page. I'll put a link in the share notes and click all the way through, see if you're eligible for the refresh. And if you are, you'll be given like a little sort of learning path, go through the learning path, and at the end will be a, what I thought was actually that, like a test test, just a sort of a sample test. Turns out, no, that's actually the real thing.
And later that evening, I wrote an email saying, congratulations, you've refreshed your AZ500. Oh man, that was way easy. So yeah, do not let it lapse. I am literally not kidding. It is two orders of magnitude easier than the exam. The exam's horrible. Is that similar to your thoughts as well, Sarah, on the, I don't know, what's called refresh? I don't even know what it's called. Yeah, I can't remember exactly how it's phrased, but I totally agree.
And actually it's also the same for some of the other Microsoft certs out there. I know for my Azure architect, and I think it's AZ, I think it's something like 303 and 304 nowadays. Definitely do your refresh, because the refresh is very, very easy compared to the real thing. It will take you not very long at all. And just as Michael said, when I did my first refresh, I thought I was going to have to sit and do, at least, actually a whole exam again. But no, it's much, much easier.
So yeah, I'll just back up what he said. Don't let it lapse, do the refresh. You get lots of reminders. So you get like 90 days, 60 days, 30 days. So make sure you do it so much easier than doing the exam again. All right. Now we've got that out of the way. Let's talk about my news. I only have a couple of items. Actually, it's funny, yeah. Like you two, I was looking at the news, I'm like, man, the security news is light.
And then I realized when Mark said it this morning, yeah, that's why it's, RSA is coming up and the build conference is coming up next week as well, which, you know, quite normally we keep big, big announcements for those kinds of events. So that kind of makes sense. So I literally only have two items. Item number one is Azure Virtual Machines in the DCS version three series now have extended coverage. So they're now available in Australia East, Japan East, South Central US and Southeast Asia.
These are the virtual machine types that support confidential computing. So they have Intel SGX or Software Guard extensions, CPUs in the VM. So they can be used for confidential computers. So for example, products like Azure SQL Database can use it for always encrypted with secure enclaves. So the part of the query engine runs inside of the secure enclave. So that's really cool to see. Huge, huge, huge fan of confidential computing VMs. So that's good to see.
The second one, so we now have, oh, by the way, that was in public preview for those new regions. The generally available now we have Azure Arc enabled servers support for private endpoints. So this allows you to manage your windows and Linux servers from Azure without sending network traffic over the public internet. So if you've got these Azure Arc enabled servers, which on-prem, for example, the traffic does not go over the public internet. This is really great to see.
I know a lot of customers are huge fans, especially when it comes to sensitive data, even if it's encrypted, just not sending it over the internet at all. So this is great to see as well. And that's kind of basically all I have. So with that, let's turn our attention to our guest. This week we have Shai Amar, who's here to talk to us about Microsoft Defender for Containers. Hey, Shai, thank you so much for joining us this week.
Would you like to spend a moment, and just give our listeners a better background? Yeah, thank you for having me. Thank you all. As you mentioned, my name is Shai Amar, and I'm working as a Program Manager at Microsoft these days. Actually, I'm coming from the Microsoft Customer Experience Engineering team for Microsoft Defender for Cloud. So what we talk about today is actually one of the plans that we have in the Defender for Cloud product, which is the Defender for Container.
I'm working at Microsoft over seven years for now. So I will start the journey as a customer engineer, and then move to a role of the CSA, Cloud Solution Architect. I will start with the platform, and in these days, focus in the security area.
So actually, the team that I'm coming and working, we are helping a lot of our customers with deployment of specific Defender for Cloud plans, improving sub-secure scores, and even being their voice inside the engineering team, like capturing feedbacks and sharing that feedback within our product management. And I'm very happy to be here and excited to actually talk about this topic.
I'll add a couple of questions around, because basically, a container is a very stripped-down VM that you sort of attach to an application, so you can kind of move it between infrastructure and slide it. Would that be kind of a good, accurate description?
Yeah, actually, that's a good one to start with, because sometimes when we are referring to the container plans or either talking about the container security, or unlike the traditional compute, the containerized application, our elastic spawn, and repeatedly, so images that are actually involving in that phase are immutable, and containers are short-lived. So most of the time, customers that are asking about this topic, they're really concerned about the security pipeline.
Where should they start the journey with? With that said, actually, every time we're talking about this topic, we must understand what is the security landscape, right? What are the traits that we have in the Kubernetes, or either if it's native or a native one? Like you asked, Mark, I want to highlight two things here.
So first of all, as part of this journey, when customers actually start and onboarding some of the Kubernetes, either it could be AKS or even on-prem one or multi-cloud, most of the time, they are asking them, where should they start with? It's like, okay, I have now cluster which security trends landscape I should tackle. This is something that I need to do scan or even research, or just ask myself if it's something that I need to cover against any kind of metrics or kind of thing.
So what we have done recently, we actually announced a new plan, and this is actually the topic for today. We announced a new plan, which is called the Microsoft Defender for Container. What we tried to do is actually merge two areas. One of them is the Kubernetes and the other is the container registry, which we can discuss later. So the major one of this is actually to collaborate.
What Microsoft has done is she took a part in the center project, and that project was contributed knowledge that the company gained in the field with container security. And Microsoft unparalleled visibility actually gave that metrics, if everyone familiar with the MITRE, so we collaborate and expand that metrics to be part of the container plans that we have today. So now offering a lot of capabilities around threat detection.
But this is actually to highlight your question about where we could start, or maybe just ask ourselves what or where we should start with. So we must aware, first of all, in which stage we are choosing, like if it's native or native, it's one thing, but really understand about the MITRE and actually the threat landscape that's involving. And so what we are having today is more giving a sense of that coverage inside the product. Having said that, I just want to highlight two things here.
One is actually, if you're not familiar with Defender for Cloud, is more about a solution that we have today to give us also capability around the Cloud Secure Post-Dream Management and the Cloud Workload Protection solution. But let's focus, like you mentioned, Mark earlier, about the area of containers. It's sort of an interesting distinction, because when you use something like Azure Kubernetes Services, like AKS, a lot of that sort of shared responsibility is on the Cloud provider.
But if you're hosting container services on AVM in Azure or on prem or AWS or wherever, you essentially have more to monitor and worry about that isn't being secured by the Cloud provider. Correct? Yeah, absolutely. And that's a great topic as well. So yeah, most of the time when customer actually on board and AKS, the native management cluster, like you mentioned, by the way, it could be AKS or EKS for AWS or GKE.
And we are covered, by the way, all of them today in the new plan, which is great, because we announced recently also supportability for that. This is relevant to multi-Cloud. But yes, this is like the model of shared responsibility. Most of the time when you're on board, you are having two areas which you should focus on. One is the control plane. And this is actually the area when you're on board the native Kubernetes cluster. You have the coverage from that infra from your Cloud provider.
So most of the time you're thinking, okay, I have the control plane, it's covered by the vendor, I don't need to take care a lot of. And there is the other which we called the data plane. So the data plane is actually where you are most of the time thinking about, okay, now I published an application, it's now it's alive. Okay, how should I tackle this?
Because this is the place where the shared responsibility model is actually coming to a decision when you need to understand more about the landscape. What I mentioned earlier, the threat landscape of the managed Kubernetes, right? So we should focus in some area to understand more about this threat landscape. One of the areas when we always try to highlight on the control plane is the API. API is actually the in the Kubernetes cluster, even it's the manage.
This is where the place when we have the control plane API. And it could be valuable for misconfigured images. For example, we can deploy something that is coming from untrusted repository. And then you can ask yourself, okay, that's fine. I can confirm that everything is coming from a secured repo and it's like trusted and everything seems so far so good. So what could be like happen from attack techniques variation?
So it could be a variety of things like, for example, if someone want to communicate with the cluster, even myself, it could be exposed to some compromised account, right? Or even like traffic that could be unauthorized. And that's come the place when we collaborate with the understood of control plane in the cluster on the data plane. So even that, we can do things that can make unfoll or exposed to some malicious stuff. Let's say, for example, I need to manage this cluster.
So I need to do kind of an AF capability like management installing Kubeflow, etc. And then I forgot to close the management port. So it's like exposed to the internet and kind of stuff. So this kind of variation of things could happen daily, right? Even for the ops and the other teams, others take all this in the team. So we need to take care from that point and really understand good about the landscape, the threat landscape, even for managed Kubernetes.
And we can go separately to understand about AKS, EKS on the other, because everyone on them we can cover separately. But most of the threat landscape would be the same in the manager on shared responsibility model. Is to understand about the common attack techniques. Most of them will be coming from the volable images that could be exploited. The other could be even like a backdoor containers or even access to exposed application.
So this could be a variety of stuff that could be fall to two areas, what we call the control plane and the data plane as well. Gotcha. So it sounds like there's quite a variety of attacks that are possible. I'm curious which ones are sort of the top ones that we see the most that organizations would need to worry about, particularly in that sort of SaaS oriented thing where the cloud provider takes care of the control plane. Yeah, that's a good one.
So yeah, we see a lot of them, but actually we can even give an example of a real world wide attack range illustration that you know happened recently. So one of them was the crypto mining crypto mining attack actually in the in the containers, the environment. They aren't you at all. But what we saw in the in the Microsoft defender for cloud solution, we regularly detect the right range of mining activities that run inside the containers.
And unusually, those activities are running inside the volable containers such as web application. We already know this could be kind of known for abilities. And recently, just for an example, there was a new crypto mining campaign that targets specifically Kubernetes environment. And actually you can ask yourself, okay, what is the different and what differs this attack from other crypto mining attack.
And what we saw here is its scale, meaning with only two hours of malicious containers, only two hours. There was a huge deployment, 10th of Kubernetes cluster was deployed. And actually the containers, when we look deeply was when running an images from a public repository, it was the Monero miner one. And this image actually run an XM rig. But it's not to understand really the type of the miner. It's more about to understand the capability of the attack and the scale that it could be affected.
Because rapidly we saw growth from the scaling, which could be a very popular, you know, some open source library that can use the Kubernetes cluster of that example. By the way, we saw from that elementary that the Kubernetes was deployed from a public repository and we able to figure that. Same actor that deployed the crypto mining container also enumerated the cluster resource. So what is done in case, okay, cluster is one thing. What about the things that I'm really take care of.
So we saw that it was include the Kubernetes secrets. This could might lead to exposure of connection string passwords and other secrets. So when you're talking about cluster or Kubernetes specific for this kind of attack, it's more about not just using the compute is also getting some sensitivity data from it. Can you talk a little bit about the features of Defender for containers? We're talking a lot about the attacks and I love hearing about attacks because they're always interesting.
But what sort of controls and features do we have within the product that would help mitigate these types of attack? Yeah, that's a great one. So actually today with the Microsoft Defender for container, we are protecting multi-cloud and hybrid container deployments. Meaning by that that we are focusing in multi-pile stages. One, we call this an hardening and you can ask, okay, what should I think about hardening?
So hardening is more about the place where you continually assess and improve your security posture of the containers environments and workload. So it's like asking yourself a questions, okay, did I do everything that is related to my API? Did I make sure that I have deployed containers only for trusted depository data trust? That's kind of developer right can do some of deployment around and then I want to force things.
I want to make sure that no one will do kind of the deployment in the early stage in the CI CD pipeline, for example. So this is the one of the major aspects that we are handling. And the other one is the vulnerability management. So you probably know that in containers there's a lot of usage with public repo sometimes and open source repos. And sometimes you can deploy things which coming with the vulnerable stuff.
So you need a great, I would say visibility and capability and that's what we do as well. So we can reduce the attack surface by continuous scanning. What we do today, we actually scan those images. So if you publish or either pulling or pushing some container images to your repo, so we actually scan them. And we can identify and manage the vulnerabilities and give you the awareness of that vulnerabilities in that area.
The other stuff which we should focus also and we mentioned earlier even on the question when Mark was raised is more about the advanced threat detection, right? So we also want to have capabilities about the runtime threats. So when I actually have a cluster that is running pods and container benets, I need to have capabilities such as alert and insight. So what we have done today, we are collecting this alert and giving like correlation with the MITRE tactics.
So we have over 60 alerts that are described well in the documentation. And then come into place, okay, I have AKS. This is something from Azure. What about else? So we are covering today the multi-cloud support, which means that we have coverage today also for AWS, the EKS cluster, and also for GCP, which is the GKE.
And what we have done actually to achieve that, we give customer the capabilities to onboard CSPM and the CDWP plan, which stands for Cloud Workload Protection, based on our connector. So you can actually connect your Azure Defender for Cloud solution also to give capability to scan those Kubernetes cluster within AWS and GCP. And this is like the tools that we have today. And of course, capabilities like deployment at scale.
So if you have a variety of cluster across your subscription environment, we give you capabilities to do this via policy, Azure policy, that you can assign based on some initiative and just give you a sense of how you can achieve that at scale, meaning that you don't need to mess with each one of the cluster to have our solution.
The other thing I wanted to ask you, Shai, was you touched on earlier talking about container registries, because, well, as you quite rightly pointed out, having a clean container registry with good images in is really important. And of course, if you just download things from random repos, you don't know what could be in there. But do we have any other specific container registry controls or things that we can do to help secure those, because it's such a weak point for containers?
Yeah, absolutely, Sarah. Thank you for pointing that. Because it's really to understand about what I need to configure to have this capability. So today, I can say I like to use the acronym of zero configuration, because if you enable today the Microsoft if an effort container planning the solution, we will automatically discovery and onboarding your ACR ACR stand for Azure container registry that you have today.
So what will happen every time that you will push, pull or either input, like you mentioned, we will do the scanning for you. So if something will come vulnerable inside, so you will be able to give and just notify inside the recommendation blade about the availability that we have found. And it's like having a bird eye right view for registry vulnerabilities. So you can, for example, make some steps to block those deployment in early stages. What I mean like stop this at early stages.
Let's think about organization. They have a pipeline. They have a landscape, right? So we assume that if you are starting like in a dev stage or dev landscape, you want to figure out what you have deployed or misconfigure deploy. For example, for untrusted and if it's valuable, you want to stop it, right? You don't want to be in a situation when you deploy some stuff like to the production and then you will fall like in a state what we called in in active mode, right?
You don't have capabilities to do some active stuff because we know we can never be like and go first than the attacker. So that capability, Sarah, with scanning, pulling and even importing things to the container registry, give us a more like a bird eye view and just thinking from the landscape where we should focus like in the stage of the deployment like cycle.
Because when I talking about Kubernetes most of the time, this is something that we are starting from the dev stage and want to be in production like most more understand about those risks. With the runtime itself, we are continue scanning the running images. So we also give that visibility and of running images and vulnerabilities.
So let's summarize this. So in one end, we won't like to have a scanning, right? A scanning mechanism tool that will scan us the registry, make sure that we are highlighting everything that is vulnerable. And of course, then we can reach out and say, look, you have deployed something is vulnerable. Please make sure that is not. We will not allow this to be part of our next landscape like say integration, preprode, etc.
Pre production, for example. So when we want to make sure this is something that we clear out on the other one, we can be like more falsely, meaning by falsely, we can actually deny things. We can tell, okay, we are not allow you to deploy anything that is coming from untrusted location. That's the only repose that we allow you to deploy from.
And that's we are in stage of more like strict and even like sometimes block stuff, don't allow to develop or to do this kind of a pushing or even importing some stuff to the to the repo. We depend on the strategy we want to have because if we want to develop first, sometimes we can block it like on the first stage. But sometimes we need to merge right into the line to the lifecycle because this always will be the complex when you ask yourself, which things I should do first
like do I need to go with deny or should I do scanning and then like stop it at early stages. So this is like in overall what we have today in the vulnerability management scanning area. So I've got one last question about container registries. Does Defender for Containers cover other? Does it cover generic container registries? Is it just Microsoft? Just because of course there are lots of different types of container registries out there.
I know it does multi cloud, but I just wanted to double check with registries. Yeah, that's a great question. It's also raised up a lot from our customers. So today we are supporting the ACR that is native in Azure, but we have a full description and fully documentation around what is like on on supported today.
So what I can tell you that if you want like to exclude it or either trust by other like repositories. So what we can give today is like using some policy on Azure policy definition that you can streak to specific registries that you can allow.
So let's say for example that they want to allow specific registry that I want to allow so I can use kind of of Azure policy to restrict that as well. But native. Yeah, this is currently what we have and this is fully described in the in the official DAC that we have in the different container. We can share that link later as well.
So I was working with a customer just recently an insurance customer on secure scores, which is part of Microsoft Defender for cloud. They wanted to get their secure score up and sort of manage the secure score moving forward. One item that was flagged, frankly sort of terrified some of us was as your policy for gatekeeper. Can you comment a little bit about what that is and why it's important. One thing that we found is once we'd enabled it that we we had issues inside of Kubernetes.
There were configuration settings, but they can only be discovered because we had the as your policy for gatekeeper. So would you like to just sort of comments on that a little bit. Yeah, absolutely. Thank you for pointing this out. This is a good one because what we have changed recently and actually we want to be more native right in the end when customer deploy any kind of a KS cluster either way to be a KS or GKE.
Most of the time when we're talking about gatekeeper or even the demon said, for example, those are capability that are building into the cluster. So meaning that today we have when we are talking about native deployment that we have done. So like the defender for container if you enable it today, we actually using a native deployment way and what's the meaning behind of that, meaning that we are actually deployed to fix the defender profile, which is the Kubernetes
demon said what it provides us is provide us the runtime protection and collect security signal. So then you ask yourself, OK, why I need it at all. So if you remember when I explained earlier when you want to detect things that happen inside the cluster, meaning
that in the nodes themselves, we need to collect signal right and events. Then we choose to use the demon said because demon said is more native to our cluster is built. So in that area, I think it was good and was understand by the way we're using that having also using capability, which is called
EBPF without going any deeply on that. If if you're not familiar, so EBPF is more like a technology that origins within Linux kernel. So it's not something that is related to Microsoft if enough for container. It's more about capabilities like in the Linux to run sandboxes
program in operating system kernel. It's you safely and efficient to extend capabilities of the kernel without requiring any kind of kernel chain source code or even load the model, which is great. On the other end, you mentioned the gatekeeper, which is the Azure policy Aidon and then what could happen. So what we are doing with the gatekeeper, we enable you to apply it scale capabilities
on the data plane policies and enforce them. For example, frictionless, we can use what we call the fixed remediation to enable that policy add on. It could give you a lot of benefits when you're hardening even the cluster like having things like do not allow deploy something that is coming from untrusted location.
So I must understand for the case that you have described when you're expanding this policy is also things that you need to aware from the recommendation that we provide you inside the solution. So what I will provide like suggesting to do first is just go through the
recommendation and make sure that everything aware is aligned to the deployment stage because when we're talking about misconfiguration sometimes we marked everything that is not configured correctly as an unhealthy run. So you can be sure that is something is not configured correctly
or everything not in an unhealthy state besides unhealthy. So my recommendation to do if you enable this kind of enable make sure you have enabled the defender for container plan on your subscription level and then look at the cluster and make sure you have the two capabilities that we mentioned like enabled.
The one is the defender profile and the other is the Azure policy add on which is the one that extend the gatekeeper and beneath you have the full recommendation inside the cluster just to make sure you are fit and aligned.
Hey, can you just explain really briefly just for those who are not aware of what gatekeeper actually is and what you know and it's important in a Kubernetes environment. Yeah, absolutely. When we actually talk about gatekeeper is not something that we are calling in in Azure is more about to
extend again the the structure of Kubernetes. So when we talk about Kubernetes and gatekeeper is more about understanding out what is can really provide us. So when we're talking about gatekeeper it giving us capabilities to allow and deny policies inside the cluster.
So thinking about like something we call this admission controller. For example, you want to do things like the nighting so even do some management inside the cluster. So one thing that you can use is actually the capabilities of admission control, which is part of the gatekeeper.
So this is is just a brief right so this is not something that we say in general. So if you think about what is gatekeeper at all. So it's actually allow the Kubernetes cluster administrator actually to implement policies. So it's all about policies in the end. So you want to ensure compliance. You want to ensure something like is related to best practices. I use some policy agent to validate it. The mission control and then you're okay. What could I achieve with admission control.
Like I mentioned, you can deny things to be happen at first. For example, former entrusted location and things like that. So most of the thing when we're using that capability is give us a lot of benefit because it's already there. And we can use a lot of compliance and
each to ensure that our cluster is really aligned to what we called to our baseline of security threat. And let's skip that we mentioned earlier according to the baseline want to achieve. So actually for those of you who are not aware. So I just mentioned eBPF.
I put a link in the show notes. eBPF is an isolation technology. It was born in Linux, but it's available in other operating systems including Windows. So I put a link in there. It's actually really interesting technology. By the way, for those of you looking to work out what eBPF stands for, it stands for absolutely nothing whatsoever. So don't go trying to find out what the acronym is.
On the topic of as your policy for gatekeepers, I mentioned working with this customer. And one thing they noticed straight away is that their ingestion rates into log analytics were pretty elevated after they turned this on. And so one thing that we were talking to the customer, we looked at their log analytics workspaces. We found that they were using the pay as you go consumption model, which is by far the most expensive and you should never be using it except for small experiments.
That's about it. So is any area, is any sort of improvements that you guys are making in this area to make log analytics ingestion a little bit more palatable? Yeah, actually we have done with the new plan. We announced actually we removed the dependency on MMA. So this is a lot of customers shared the feedback with us that MMA caused them some complication when they're on board the cluster.
So today with the new plan, we are not rely we don't have this dependency to have the MMA as part of the provisioning. And MMA is Microsoft. So yeah, yeah, the log analytics one. Yeah, you're right. So I use this like a short acronym. Yeah, but you refer to the log analytics. But on the ingestion way, you're right. So sometimes customer connect right, the the different for cloud solution or either other seems like solution right like Sentinel, for example, or third party.
So the ingestion is really depends on on actually the tier that you declare. But what what I've mentioned earlier regarding this kind of integration that we have today. So today, the dependency of MMA is not there. But when we're talking about ingestion and other stuff, yeah, it should be like measured, right? So we need to fully understand what is the use case because today we have a connector that we can connect to any kind of seems solution.
And it's rely on the workspace right on the log analytics workspace. So yeah, it should be measured. These things could happen if you're not aware from the aspect that you want to trigger or monitor, right? So we just need to make sure that everything is done from the perspective of understand with ingestion. We are talking about is more related to alert or something similar.
Because in the end, you can always make things like, you know, make sure about the capacity or measurements about the log analytics. Two things need to remind is also in gentian and retention, right? So there's two aspects you need to consider. But that's that's a good thing because the dependency was really, you know, well, the removal of the dependency at the lot to our customers as well to to, you know, to continue the journey with the
containers. But yes, you need to keep in mind also on the gentian and the retention from that stage, which is another topic. Yeah, so just make sure I get it right. So the Microsoft monitoring agent removing that reliance. Does that reduce the the quantity of data going into the log analytics workspaces?
Yeah, I will say, but it's need to be confirmed against the environment because we use it as a dependency to onboard the plan. So I'm not sure if the issue was referring to ingestion data that is raw data, you know, like security, alert and etc.
Or it's more rely about this dependency if it was a rely to this dependency, for example. So yeah, it could remove that cast. But if it's more about the amount of the injunction that they're receiving, this is another topic that you'd consider, you know, measured and be sure there are a line there log analytics workspaces with the retention and of course the injunction right against the tears that you mentioned and not use pay as you go and
I really want to stress that. So one thing that we learned from this customer was, first of all, you know, do review your log analytics workspaces and again, this has got nothing to do with Microsoft Defender for containers. This is just
general good practice. Yeah, so look at what you're using make sure it's the cost of the more cost efficient one. And again, to your point, you know, you don't need to necessarily retain stuff in a log analytics workspace, you know, forever, you can certainly offload it.
So things like Azure Data Explorer. And there's also new models coming out for, you know, sort of more cost effective workspaces that have a slower sort of access time they're not really designed for ingestion they're designed for querying and querying only.
So yeah, so keep an eye on that and also make sure that someone within the organization is just keeping an eye on making sure that all the appropriate log analytics workspaces, you know, but being sort of maintained and there needs to be a plan right there needs to be someone focusing on the cost of those things.
Yeah, absolutely. One thing we are using in the product and you can probably we can suggest the same. We providing some workbooks that give us visualization on that area so every kind of plan that you enable. And if you want to estimate how it going to cast if I use this and this so today we leverage and
have a disk capabilities inside the product. So this is something that you can use as well. This is not something like build everywhere what but for variety of stuff that we have inside it could help a lot based on my experience with customers having kind of visualization view that is relied on workbook can be really advantage. Yeah, 100%. Hey, so you have any any sort of like, you know, sort of top couple of tips that you'd like to give people.
Yeah, so actually, first of all, if you have communities and any kind of them and you are don't know what is actually based on your security landscape, you need you can enable this plan and make sure that you are aware from the recommendation be sure that you are aware from the
threat landscape that I mentioned earlier, because most of the time you will not be able to track any application right any kind of application that you have everywhere. So this could give you a sense about the threat landscape and everything there.
The other stuff that I will always like to mention is be sure that your cluster either if it's a native or could be a multi cloud, no matter what be sure that they are in healthy state from the secure posture way. It could be one thing to end them proactive right and be in active. That's my tips for that. All right, so if you had one final fall I just one thought that you would leave people with what would it be.
My thought will be always know your environment, especially for containers don't think about like the same as as virtual machine just think about the more you need to understand is about your trend landscape as cover at all to understand more you can use the Defender for container to do that. And the other one is also know better about the threat landscape that is related to your specific Kubernetes environment.
So I will say thank you so much for joining us this week. I know that you're incredibly busy and I appreciate you taking the time. Spend time with us to go over this. This really cool product. As for those of you not aware that actually there was actually two products right at one point was Defender for Kubernetes and Defender for containers right we sort of consolidated into into one exactly yeah yeah yeah.
So again, yes, thanks again for joining and to all our listeners out there. Thank you for listening. Stay safe and we'll see you next time. Thanks for joining 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 CC mixer.com and licensed under the Creative Commons license.