Microsoft Defender for Cloud - Simply Explained

Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365, FM, I'm Mirko Peters. So Microsoft Defender for Cloud sounds like antivirus, right? That's a fair guess because the Defender name shows up on a lot of Microsoft security tools. But here's the thing, Defender for Cloud isn't there to scan your laptop for a bad file that watches your whole cloud setup. Think of it this way, Defender for Endpoint keeps security inside a single room. It watches one laptop or server for malware, strange programs, or signs someone is trying to take control. Defender for Cloud watches the entire office building around that room. It checks who can enter, it checks whether a side door faces the street, it looks at the locks, the alarms, the storage rooms, and the rules that decide who can reach sensitive areas. In plain English it helps you see three things. How safely your cloud resources are set up, whether something suspicious is happening, and what you should fix first. A warning might tell you a door is unlocked, an active threat alert tells you somebody may already be trying that door. That difference matters. Let's start with why cloud security becomes messy so quickly. Why cloud security breaks down so easily? Years ago, a company might have had a small server room, a few physical servers, and one team looking after most of it. The setup moved slowly. Today, a company can create a new virtual machine in minutes. A developer can add storage for a project, another team can create a database, someone else can run containers for an app. Each part may have its own team and its own security tool. You might have one tool for servers, another for databases, another for storage, and another for containers. Each tool shows part of the picture, but nobody sees the full building. That creates gaps. A storage account might allow public access by mistake. A virtual machine might leave remote desktop protocol RDP open to the internet. On Linux, it could be secure shell or SSH, an old admin account might still have access months after a contractor leaves. A server might miss security updates because it only ran as a short test. None of these mistakes need a clever attacker. They only need one unlock side door. The cloud environments change all the time. A resource that looked safe on Monday can become exposed on Tuesday because somebody changes one setting, creates a new network rule, or copies an old template with weak permissions, still inside. You've probably seen this in real life. A team needs a quick test server. They create a virtual machine, give it a public address so they can connect from home and open RDP or SSH because it's faster. The test works. Then the project ends, people move on, and that server stays online. It's public door remains open. Nobody means for that to happen, but it happens because cloud resources are easy to create and easy to forget. Now add the way many companies really work. You may have workloads in Azure. You may still run servers in your own office or data center. A supplier may use Amazon Web Services or AWS. Another team might use Google Cloud Platform. Security doesn't stay in one portal anymore. A long list of alerts doesn't solve that problem either. If you see hundreds of warnings without knowing which one exposes customer data, which one affects a test system, and which one creates a route towards something sensitive, you still don't know where to begin. You need context. You need to know what exists, what faces the internet, who can access it and which fix removes the most risk. That's where Defender for Cloud starts. It looks for the weak doors before somebody gets inside. Cloud security posture management. The first building block is Cloud security posture management. That name sounds heavy, so let me put it in plain English. It's a regular safety inspection for your cloud resources. Instead of walking around a real building with a clipboard, Defender for Cloud checks the settings around your cloud services. It looks for things that could leave a resource exposed, a weak network rule, missing encryption, too much access, or a setting that no longer matches your company's rules. And these checks keep running as your environment changes. That matters because Cloud security isn't something you set once and forget. A resource can be created, changed, copied, or moved at any time. Defender for Cloud keeps checking the current setup rather than relying on a review someone completed months ago. You'll often see something called Secure Score. Think of it like an inspection score for a large office site. It gives you a view of how many recommended safety controls are in place and where work remains. It isn't a pass or fail test. A score of 100 doesn't mean no risk exists. It means the checks included in that score look healthy. And a lower score doesn't mean your cloud has already been breached. It means Defender for Cloud found settings that deserve attention. The score gives you direction. But more useful than the number itself are the recommendations behind it. A recommendation tells you what needs attention, which resources face the risk and what change can reduce it. You might see that a particular storage account allows access wider than your policy permits. Or a virtual machine might not have a control your security baseline expects. You don't need to guess where to look. The recommendation points to the resource and explains the issue in a way the right team can act on. That turns a vague warning into a piece of work with a clear owner. But not every finding deserves the same response. Imagine you find two issues. One affects a small test resource. No one can reach from outside. The other affects a public facing resource that can reach customer data or a sensitive system. You fix the second one first. That's the thinking behind risk-based priority. Defender for Cloud tries to help you spend time where a weak setting could lead. To something more serious rather than treating every warning as equal. This leads to a term you may see called an attack path. An attack path is a possible route an attacker could use. Starting from a weak point and moving towards something important. Maybe a resource has public access. Maybe that resource connects to an identity with broad permissions. Maybe that identity can reach a database holding sensitive information. Defender for Cloud can show that chain. It doesn't mean an attacker has used the route. It means the route exists and you should decide whether to close it before somebody does. That's a big difference. Parts help you see why a small setting can matter far beyond the resource where it first appeared. A public endpoint on its own might look like one minor issue. Connected to a powerful identity and sensitive data it becomes a much higher priority. Sometimes several attack paths share the same weak point. Microsoft calls these choke points. A choke point is one place where fix can close several possible routes at once. For example, tightening access on one identity or removing one unnecessary public connection can reduce risk across multiple resources. That saves time. Instead of fixing 10 related symptoms one by one, your security and cloud teams can focus on the shared cause. Defender for Cloud also uses policies and compliance checks. The policy is a rule you apply across your Azure subscriptions and resources. You might set a rule that storage needs encryption that certain network ports can't remain open, or that resources need a specific security setting before people use them. Policies create consistency. Without them, each team can build resources in its own way and security becomes a manual check after the fact. As policies you can check whether resources follow the same rules as they are created and changed. But there's a common mistake here. Many teams leave policies in audit only mode and assume those policies will stop risky setups. Audit mode only reports the issue. It tells you someone created something outside the rule but it doesn't block the change. That can be a sensible starting point while you learn what existing resources might break. Once you understand the impact and fix the older issues, some high risk rules may need stronger enforcement. So the goal isn't to chase a perfect score or read every alert in every portal. To build a clear work list, you see which resources need attention, which risks connect to sensitive targets and which single fix removes several parts at once. That gives security teams and cloud teams a shared place to start. A safer setup reduces the easy opportunities but it can't stop every threat already in motion. Workload protection, post your management, checks the setup around your cloud services. Workload protection looks at the things actually running there. Think about everything your company puts to work in the cloud. A virtual machine runs an old business app. A database holds customer records, a storage account keeps uploaded files, containers run parts of a modern app, a web app handles customer requests. Those are workloads, Defender for cloud ads protection based on the workload you need to protect. It doesn't treat a database, a server and a container as though they all face the same risks. That's the point. It's work happens in two parts. First, it looks for weak spots before trouble starts, known software weaknesses or missing security settings. Then it watches for signs of suspicious activity while the workload runs so it can help you find a weakness on a server before an attacker finds it. It can also alert you if activity on that server looks wrong, such as malware signals, unusual changes, or an attempt to use a known attack method. Microsoft groups these protections into Defender plans. You choose plans based on what you run. If you have virtual machines, you look at Defender for servers. If your business stores files in Azure Storage, you look at Defender for Storage. If you run containers or databases, there are plans and checks designed for those workloads. There isn't one large switch that gives every resource the same protection. That would create cost and noise where you may not need it. Instead, you decide which workloads hold important data, support important services, or face more exposure than turn on the right protection for them. Let's use a server as an example. Defender for servers can help find software weaknesses on Windows and Linux servers. It can report missing updates and show where a known weakness affects a machine. It can also monitor file changes, which matters when a file or system setting changes in a way that needs investigation, malware signals matter too. A server can look healthy from the outside while something harmful runs inside its operating system. That's where Defender for Endpoint can connect with Defender for Cloud. The name sound close, but their jobs are different. Defender for Endpoint watches the device itself. It sees activity inside the operating system, processes, files, and behavior on a laptop or server. Defender for Cloud looks at the Cloud resource around that device. It sees the server's cloud setting, its network exposure, the workload protection plan, and the broader risk connected to that resource. Together, they give you a fuller picture. Imagine Defender for Endpoint detects suspicious activity on a virtual machine. On its own, that alert tells you something may be wrong inside the server. Defender for Cloud adds context around it, is the virtual machine open to the internet. Which team owns it? Does it connect to a sensitive database? Is there a known weakness on the same machine? What should the Cloud or Infrastructure team fix while the security team investigates? It changes the conversation from "We have an alert" to "This server has suspicious activity, it has public exposure, and this is the person who needs to act." One practical feature for virtual machines is just in time access. Many administrators need RDP for Windows servers or SSH for Linux servers. The risky approach is to leave those management ports open all the time because somebody may need them later. Just in time access takes a different approach. It keeps the management door closed, then opens it for a shorter proof period when an administrator needs to connect. After that time expires the door closes again. You don't leave access available every day just because you might need it next week. Storage needs its own type of protection. A storage account may hold documents, backups, reports or files uploaded by customers. Defender for storage can scan uploaded files for malware and raise alerts around suspicious access. It can also help you understand when sensitive data may sit in a place that needs more attention. That matters because a harmful file in storage may not cause trouble until somebody downloads it or another service starts processing it. Containers and databases need different checks again. Containers often run quickly and in large numbers so their protection focuses on the images, settings and behavior connected to container workloads. Databases need attention around suspicious queries, log in activity and data related threats. The goal isn't to use one generic scan for everything. It's to apply protection that matches the job each workload performs. Still, every one of these protections depends on something very basic. Defender for cloud can only protect and report on resources it can see. And once you look beyond a single Azure subscription, that becomes a much bigger question. One view across Azure on premises and other clouds. Most companies don't keep every workload in one place. You might run most of your services in Azure while an older server still runs in your office. A business unit may use Amazon Web Services, often called AWS. Another team may have services in Google Cloud Platform or GCP that leaves you with separate portal, separate lists and separate ways to find problems. It's like having three different security guards who don't talk to each other. Defender for cloud can bring connected Azure on premises, AWS and GCP environments into one security view. The aim is simple. Instead of opening one dashboard to check Azure virtual machines, another for AWS accounts, and a third system for servers in your own building, you can view the security state of those connected environments in one place. That one view saves you from jumping between screens and losing context. Now that doesn't mean every cloud works exactly the same way. Azure, AWS, GCP and on premises systems each have their own services, access rules and connection methods. And Defender for cloud can collect security information from the environments you connect, then show the findings in a common view that reduces the chance of missing context. For example, an alert on a server means more when you can also see whether that server belongs to a cloud subscription sits in an AWS account or runs as part of an older on premises service. The security team can spend less time asking where is this resource and more time deciding what needs attention. Before you can protect something, you need to know it exists. This is where asset inventory matters. An asset inventory is simply a list of the things your company owns or runs in the cloud. That can include virtual machines, databases, storage accounts, container clusters and other services. It sounds obvious, but cloud resources appear fast. A project team may create a test environment, a supplier may create resources in another cloud account. An old workload may keep running after the person who built it has moved to another role. If it isn't in your inventory, it can easily fall outside your security work. Defender for cloud helps you see the resources. It knows about, along with their security coverage, you can see whether a resource has protection, has only part of the protection you expect or has no protection at all. That last group needs attention. An unprotected resource isn't always unsafe by itself, but if a production database or internet facing server has no planned coverage, that's a gap you need to understand. A coverage view turns vague assumptions into a list you can check. Are all our servers protected? Becomes a real question with a real answer. Permissions matter too. A large company doesn't want every person in the security portal to see and manage every resource. The infrastructure team may need to work with server findings. The database team may need to see database findings. A team responsible for one business area may only need access to that area's cloud resources. Cloud scopes and permissions help create those boundaries. Think of a cloud scope as a defined area someone can work with. You can connect a role to specific environments, subscriptions or resource groups, so people see what they are responsible for without gaining access to everything else. That keeps responsibility clear. The infrastructure team can focus on servers and their related findings. At the same time, the database team can review database findings and deal with the systems they own. Both teams work from the same connected security picture, but neither team needs to manage the other team's services. There is one limit you should always remember. Defender for cloud can only report on environments that you have connected and unborted. If an Azure subscription isn't included, it can become a blind spot. If an AWS account has not been connected, Defender for cloud can't report on the resources inside it. The same applies to GCP and on-premises servers that haven't been brought into the service. No dashboard can show what it doesn't know about. Incomplete onboarding causes a common problem. A company sees a need security dashboard assumes it covers the whole business and later finds a forgotten subscription or separate cloud account that never appeared in the view. So review your coverage before you trust the results. Ask which subscriptions exist. Ask who owns AWS and GCP accounts. Ask whether older servers are still in use. Then compare that list with what Defender for cloud can actually see. Once the view is connected, compliance becomes much more useful than a spreadsheet full of old checks. Compliance without the spreadsheet chase. Compliance means checking whether your cloud settings meet rules your company has agreed to follow. Those rules may come from a customer contract, a legal requirement, an industry standard, or your own internal security policy. In the past, this often meant someone collecting screenshots before an audit. They would ask whether encryption was enabled, whether logging was turned on or whether access rules matched company policy. By the time the spreadsheet reached the auditor, parts of the environment may already have changed. Cloud services don't wait for annual reviews. Defender for cloud gives you a way to check cloud resources against built in standards on an ongoing basis. You may see standards such as CIS, NIST, ISO 27001, HIPAA, PCI DSS, and the Microsoft Cloud Security benchmark. You don't need to memorize every standard to understand the basic idea. Each one contains controls. A control is a rule or expected safeguard. It might check whether a setting is enabled, whether access is restricted or whether a resource follows a required configuration. The compliance view shows which checks passed, which checks failed, and which resources cause the failed result. That makes a large standard easier to work with. Rather than seeing a line that says control failed, you can look deeper and see the affected resources. You can also see suggested repairs tied to the findings, so the person responsible for the resource has a starting point. Imagine an auditor asks whether your cloud storage follows a particular rule. Instead of searching through old notes, you can review the current control status, see the resources included in the check and identify any open issues. Your security team gets a work list, your auditor gets evidence based on the environment as it looks now. The checks keep updating as resources change. If someone changes a cloud setting after the last audit, that change can appear in the compliance view. This turns compliance from a once a year scramble into a regular part of managing cloud resources. That saves time, but it also creates accountability. A failed control shows that a rule needs attention. The team that owns the affected resource can fix it, document an accepted exception, or explain why the setting doesn't apply. The result becomes clearer than a spreadsheet where nobody knows who last updated a cell. Still, a high compliance score doesn't guarantee safety from every attack. Compliance checks whether you meet a defined set of rules. Attackers don't limit themselves to a checklist. A resource can meet a standard and still face a new software weakness, a stolen password, or suspicious activity that needs investigation. So use compliance as a way to check your agreed rules and keep evidence current. Use it to find gaps, assign work and show progress. All of this can feel large when you first open the portal, which is why the best next move is a simple first week plan. How to start without turning on everything. So how do you begin? First, make a simple map of what you actually run. List your Azure subscriptions, then your servers, storage accounts, databases, container services, and any workloads in AWS, Google Cloud, or your own data center. Keep it practical. You're trying to answer one question. What needs protection and where does it live? Once you have that map, connect the environments you want to fend off for Cloud to monitor. But before you dive into hundreds of recommendations, check the coverage view first. Findings only help when you know whether the right resources are showing up. Begin with Posture Management. Review your secure score, then look at the highest risk findings behind it. Don't try to clear every warning on day one. Instead look for problems that keep appearing across your environment. Public exposure, weak identity controls, open management ports, and missing patches. Those are often the fastest places to reduce risk. Next, choose Workload Protection Plans based on the services you really use and the risk they carry. A production server, holding business data, deserves different attention than a short-lived test system with no sensitive information. So turn on protection with a reason for servers that need deeper device level detection, connect Microsoft Defender for Endpoint. That gives you a better view of activity inside the operating system, while Defender for Cloud keeps the Cloud resource and its exposure in view. Then assign an owner to every finding that needs action. A recommendation without an owner becomes a reminder that nobody handles. Your infrastructure team may own server fixes, your app team may own a database setting, and your security team may track the work and review whether it was completed. Set a regular review time. Weekly may suit a busy environment, while monthly may suit a smaller one. The schedule matters less than making it routine. You aren't trying to reach a perfect score. You're removing the easy paths into your Cloud, one clear fix at a time. Think of Defender for Cloud as a security guard who checks how your Cloud is set up, protects the important rooms and points your teams towards the risks that deserve attention first. For a simple challenge, connect one Azure subscription this week. Check which resources appear in coverage, find the most exposed resource, and assign someone to fix it. That gives you a real starting point, not another security dashboard to ignore. The next, knowledge nugget to explore is Microsoft Defender for Endpoint versus Defender for Cloud. One watches what happens on devices, the other watches the Cloud resources around them, and together they help you see both sides of the same security problem.