Defender For Cloud - under the hood: Security alerts
Learn about Defender For Cloud Security Alerts
Your cloud might be elastic, but that doesn’t mean your luck is ignoring security alerts won’t make threats disappear. 🎩✨ In this blog you’ll learn all about Defender for Cloud Security Alerts what they are and where they come from.
‼️) This blog is part of a Defender For Cloud "Under the hood series" where we explore the various features, benefits and considerations that come with implementing Defender For Cloud (and other CNAPPs). You don't need any prior experience just a willingness to learn and develop. I don't quite know when the series will end but I hope you enjoy.
Before we start…
To get the most out of this blog, you should understand the context behind cloud workload protection and the value it provides. Don’t worry I’ve got you covered! Read my blog on CWPP here and then come back. In future blogs, we’ll explore each type of cloud workload protection plan in detail.
Where do Security alerts come from?
Microsoft Defender for Cloud’s cloud workload protection feature is designed to detect and respond to security threats across workloads in Azure, hybrid, and multi-cloud environments. Alerts are generated based on the cloud workload protection plan you have enabled. This is important because, as mentioned in previous blogs, the attack vectors for a container differ from those of a server. Therefore, we need a specific set of protections for each workload type.
In the Defender for Cloud console, you’ll find security alerts for your workloads in multiple places the dedicated Alerts page and under workload protections.
How Security Alerts Work
Security alerts are generated when Defender for Cloud detects unusual or malicious activity within your cloud resources (servers, APIs, containers, etc.). It’s a way to let you know, “Hey, something’s happening here take a look.” These alerts rely on a mix of threat intelligence, machine learning, and behavioural analytics, which typically differ per workload. As I mentioned, each workload type needs a dedicated protection plan.
Each alert includes details about the affected resource, the issue, and recommended next steps to resolve it. Even if the affected resource is deleted, the alert remains visible in the portal for 90 days, giving security teams plenty of time to investigate.
Under the hood: Alerts are based on the MITRE Attack Matrix
Let’s take a look within the console. Clicking into an alert, I’m met with contextualised information to help me understand the alert. Having worked in a SOC role before as an analyst, I know how important it is to get key details quickly and start triage.
In my example, I have selected an alert that I generated on purpose a file I uploaded contains malware. At a glance, I can see details such as the affected resource, file information (including the SHA file hash value and file location), and the MITRE ATT&CK framework tactic, which in this case is lateral movement.
Under the hood, the alert you see here was generated by the cloud workload protection plan Defender for Storage and its malware scanning capability. I’m planning to write further blogs on each plan, explaining their full capabilities, so stay tuned!
Classifying and Prioritising Alerts
Not all alerts are created equal, so Defender for Cloud assigns severity levels to help security teams prioritise their response:
High Severity 🚨 – Likely compromise, requires immediate action. Example: Detection of Mimikatz, a tool used for credential theft.
Medium Severity ⚠️ – Suspicious activity that might indicate a breach. Example: A login attempt from an unusual location.
Low Severity 🔍 – Potentially benign but worth noting. Example: A system log being cleared, which could be normal or an attacker covering tracks.
Informational 📄 – Not an immediate threat but useful in investigations.
If your curious you can view the alert matrix here
Under the hood: Severity is based on: the specific trigger, the confidence level that there was malicious intent behind the activity that led to the alert
From Alerts to Security Incidents
One alert might not tell the full story, but when combined with others, patterns emerge. Defender for Cloud groups related alerts into incidents if you’ve used Microsoft XDR, you’re probably familiar with this concept. Data and signal correlation make Microsoft XDR so powerful, and because Defender for Cloud is fully integrated with XDR, you get all the same benefits.
For example, a single failed login attempt might not raise concerns, but if it’s followed by unusual account activity and a failed MFA attempt, Defender for Cloud connects the dots, highlighting a possible account takeover attempt.
Integration with XDR
Defender for Cloud is fully integrated with Microsoft XDR meaning it benefits from the same core capabilities:
Threat Intelligence – Pulling insights from Microsoft’s global threat intelligence network, including Microsoft 365, Azure, and third-party sources.
Behavioural Analytics – Spotting threats by analysing real-world attack patterns.
Anomaly Detection – Using machine learning to identify unusual behavior that might indicate an attack.
Real time data collation Across: identities, cloud applications, endpoints, networks and infrastructure
I’ve switched to the Defender for Cloud portal to show you how the alert view looks. I’ve selected a newly generated alert notifying me that malware has been found in my blob container. Notice how the source is Microsoft Defender for Storage? This is a cloud workload protection feature of Defender for Cloud.
The alert contains the same information available in the Defender for Cloud console; it’s just presented in a different format that tells the alert’s story in a new way. The XDR portal enables SOC analysts to collaborate, fine-tune alerts, or quickly launch advanced hunting. The Ninja Show episode explains the integration in detail, and I highly recommend watching it.
To take advantage of the integration you’ll need to make sure you have the right role based access within the XDR portal as detailed here given that i’m using a demo subscription i’ve assigned all read and write but you should follow the least privlidge appraoch.
Exporting and Integrating Alerts
Defender for Cloud alerts aren’t just stuck in the portal you can integrate them into your security ecosystem:
CSV Export – Download alerts for offline analysis.
IT Service Management (ITSM) – Connect alerts to ticketing systems for smoother incident response.
SIEM and SOAR Integration – Stream alerts into Microsoft Sentinel or other SIEM/SOAR platforms.
If you use Sentinel, enable the Microsoft XDR tenant-based connector to take advantage of alerts and incidents flowing into Sentinel, not just from Defender for Cloud, but also from other solutions like Cloud Apps, MDI, and MDO.
Other Alert features
Let’s return to the Defender for Cloud portal and take a look at the header. Admins can change the status of alerts to "Active", "Dismissed", "In Progress", or "Resolved", and these changes will sync with the XDR portal.
Suppression rules:
Suppression rules allow us to suppress an alert and fine-tune it. You can adjust these rules either based on entities for more granular setup or based on alert types. Below, I’ve applied a custom entity and simulated tuning to see how it would affect an alert.
Alerts map:
This map presents security alerts that contain IP addresses targeting your resources. Markings on the map represent the sources of attacks on your resources.
Defender for Cloud allows you to create custom workbooks across your data, and it also comes with built-in workbook templates. These templates enable you to quickly gain insights as soon as you connect a data source. I’ve covered this in more detail as the prerequisites (Continuous Export) in other blogs within the series.
The workbook represents your active alerts over time, based on severity, resource type, and top alert types. The workbook is even integrated with the MITRE framework.
Detailed blog on the feature direct from Microsoft
Taking Action
Going back into a security alert you can obviously take action from the defender for cloud portal but most likely analysis will be working from the XDR portal. The actions you can take are the same.
To take action on an alert, open the Take action tab to see the recommended responses. If you need to manually investigate the issue, check the Mitigate the threat section for step-by-step guidance. the Prevent future attacks section will give you the recommendations you can follow to attack your attack surface and stop potential attacks on that resource or using those attack vectors in the future.
If you want to automate your response, go to Trigger automated response and select Trigger logic app. If the alert isn’t actually a threat, or you want to tune it you can stop similar ones from appearing in the future by creating a suppression rule in the Suppress similar alerts section.
You can also check who receives email notifications about security alerts by selecting Configure email notification settings.
Reference:
Defender For Cloud Security Alerts
Learn about KQL - A book by Rod Trent Must Learn KQL
Defender For Cloud GitHub Labs
Defender for Cloud Feature requests
Defender for Cloud in the field show
Defender For Cloud Ninja training
Have blog ideas, want to engage on a topic, or explore collaboration? Let’s take it offline reach out on LinkedIn. I’d love to connect and continue the conversation!