Video Transcript:
-Can you prevent data breaches in the cloud before they happen? I’m going to show you how with Microsoft Defender for Cloud. And the protection you’re about to see goes beyond the list of general security recommendations that you may be familiar with. You can now prioritize the hardening of your security defenses based on the connected dots of risks found with Cloud Security Posture Management, meaning you now have a level of predictive and future-facing defense, and it’s even agentless. While threat protection tools can help you to visualize attacks that have already happened, Cloud Security Posture Management in Defender for Cloud lets you get ahead of what could happen with visualizations of potential attack paths based on your environment’s existing configuration and resources.
-It calls out specific vulnerabilities and misconfigurations that attackers might exploit to gain a foothold in your environment step-by-step. Then it ranks recommendations based on the severity of risks and the potential impact to key resources. And this helps you focus on what matters the most. In fact, these recommended actions are based on the best practices of Microsoft’s global security teams. And beyond security, it can also determine compliance actions to take, so your organization can meet industry-specific compliance goals.
-All of these are made possible by connecting signals across identity, sensitive data, compliance, and configurations in your multi-cloud environment. Then mapping these signals into the Cloud Security Graph that is unique to your organization. It’s dynamically updated according to the services you have in place. Next, beyond the insights that we proactively surface for you, we also make it easier to find resources at risk with a simple query-based interface called the Cloud Security Explorer, which you can use without knowing Kusto Query Language. And these protections can even extend to your code repos to drive security in the DevOps stages, preventing security issues in the code, which can get carried into the cloud pipeline. In fact, I’ll make this real by first walking you through a multi-cloud example, starting with how to set everything up.
-You’ll get started by connecting your resources to Defender for Cloud. Azure subscriptions will show up by default, and you can add AWS accounts, GCP projects, and even connections to GitHub and Azure DevOps. And again, this is all agentless. All of these services are using Microsoft Entra ID as the identity provider. Once everything is set up, as I showed earlier, the signals from your connected resources will form a graph of how resources, identities, and activities are connected, and then generate tailored recommendations based on what it finds. After that, it’s time to start improving your cloud security posture. Let me show you that experience. First, on the overview dashboard, you’ll see a high level view of your security information, including the secure score of each of your multicloud environments.
-If you’re new to the secure score concept, it’s basically a calculation based on the number of weighted risk factors. And on the top, you’ll also see that everything is consolidated with the number of assessed resources, active recommendations, attack paths and security alerts. Defender for Cloud is continuously assessing connected services for new security issues. To see them and remediate them, I will click into Recommendations, and here is a list of actions to take. As I work through these actions, my current secure score of 34% will increase. Now with so many recommendations, you might be wondering, where should I even start? Well, Defender for Cloud also helps to prioritize the remediation of discovered issues using the cloud security graph. The key to better prioritization is more context, and that’s exactly what we give you.
-Imagine if you have two virtual machines each with the same vulnerabilities but you also know only one of those VMs is internet facing. It makes more sense to prioritize that VM over the VM not facing the internet. To prepare that additional context, we analyze all the signals and give you a visualization of the potential attack path that could be used to exploit your resources. Here you are seeing a list of potential exploits that can happen in my cloud environment, each highlighting details of risk categories and affected resources. This internet-exposed VM is what we commonly see. There are several high severity vulnerabilities, including sensitive data exposure and compute abuse. Together, these two risk factors put the VM at risk for being hijacked. When I click in, you’ll see it shows information about the internet exposure, its IP address and network interface. This VM uses a managed identity with permissions to a cloud storage account. When I click into the VM, I can see more information, and under insights, I can see that it’s vulnerable to remote code execution.
-Then if I dig into the storage account and into its insights, I can see the types of sensitive data this VM has access to. In this case, social security numbers, credit cards, and ASP.NET machine keys. Now that I have a better picture of how the entire attack path can form, let’s fix it. In the recommendations attached to the attack path, it breaks down all of the things needed to eliminate the potential attack path. I’ll start with the last one about restricting ports on network security groups associated with this VM. In fact, the attack path exposes the ripple effect that vulnerabilities can have across your resources. And the nice thing is we have a tool for proactive risk investigation as well. I can write customized queries in the Cloud Security Explorer to continue my investigation.
-To help you get started, we prepared a few query templates to find all internet-exposed VMs ones with high severity vulnerabilities or a specific vulnerability. I’ll use the template in the middle to get started. Now you can see all the conditions for this query visually. I can search it as is to find vulnerable VMs. But let me show you how to refine the query by adding a few more conditions. I’ll add one at the top level and you’ll see that I can choose from several categories. I’ll pick Metadata to find the VM name that we saw before. I’ll leave equals and paste in attackpath-vm. Now I will add one more top level condition. This time using the identity and access category with can authenticate as. Then I will select the resource type, in this case, application identity to see which types of resources it can access.
-Then, I will add a final condition at the application identities level using has permission to, and I will choose all the popular ones, including VMs, Kubernetes clusters, managed databases, and storage. And with everything configured, I’ll hit search. And almost immediately, I can see my results because I filtered on the single VM and what it has access to, it reports back access to three storage accounts and another VM. I’ll pause here for a second because, as we saw before, our vulnerable VM had access to sensitive data, including social security numbers, credit cards, and crucially, ASP.NET machine keys. And that last one was a clue that there might be higher value target in the storage account.
-So let’s dig into the first result. Then go into the storage account called Terraform-state. These Terraform-state files contain infrastructure as code records and are reused when new infrastructure is deployed. In other words, they contain information that attackers would want to see and exploit. So by using Azure DevOps and tracing back to the roots of the Terraform file instead of just blocking access to one VM itself, I’m going to also protect VMs that will be deployed in the future. Here you can see the inbound RDP access over port 3389 is by default set to allow, and that’s bad. Now I can work with my developers to default deny access to RDP and block incoming traffic. And once I commit this change, these settings will be deployed. These changes are going to solve the problem from the root, in our case, closing inbound RDP connections for Windows VMs connected to this file.
-Now, let’s fast forward a little to track our impact in the recommendations. And you’ll see that our secure score, which was 34%, has now inched up to 36%, and every point here counts for your cloud security posture. Now that said, even if you work through this entire list, you’ll want to return to these recommendations because we’ll keep updating them along with potential attack paths as threats continue to evolve.
-So that was an overview of how you can get ahead of future attacks using Defender for Cloud. And everything I demonstrated is available today. To learn more, check out aka.ms/MDCdocs. Subscribe to Mechanics if you haven’t already, and thanks for watching.
