Microsoft Defender for Cloud – Benefits from Defender for Endpoint Integration

I wrote about Microsoft Defender for Cloud (MDC) – Cloud Security Posture Management (CSPM) capabilities in a multi-cloud scenario a few weeks ago. Besides CSPM, Defender for Cloud has Cloud Workload Protection (CWP), called also ‘Enhanced Security Features’ capabilities that can be used to provide extra protection to certain workloads. Some of the capabilities are supported in the multi-cloud scenario, such as ‘Defender for Servers’.

In this blog post, I’ll cover some of the CWP capabilities and benefits of integrating MDC & MDE together. Also, you can expect to find some details on Defender for SQL leveraging Azure Arc.

Setting up the Scene

The best synergy advantages from the Microsoft security solutions come with the integrations between the products. Microsoft Defender for Cloud is integrated with Microsoft Defender for Endpoint by default when enabled.

When you enable Defender for Cloud enhanced security features you give consent for Microsoft Defender for servers to access the Microsoft Defender for Endpoint data related to vulnerabilities, installed software, and alerts for your endpoints.

Currently, Microsoft Defender for Cloud (MDC) provided enhanced protection the following workloads in the multi-cloud scenarios slightly depending on cloud platform (see differences with AWS & GCP):

Defender for CSPM features (free)
Microsoft Defender for servers
SQL on Machines (works with Azure Arc based on this article)
Microsoft Defender for Kubernetes

Side note: to benefit from all of the security features available from Defender for servers and Defender for SQL on machines, the plans must be enabled on both the subscription and workspace levels

Benefits of Integrating Defender for Endpoint with Defender for Cloud

In a nutshell Defender for Endpoint provides (from docs.microsoft.com):

Advanced post-breach detection sensors
Vulnerability assessment from the Microsoft threat and vulnerability management solution
Analytics-based, cloud-powered, post-breach detection
Threat intelligence

By integrating Defender for Endpoint with Defender for Cloud, benefits from the following extra capabilities:

Automated onboarding. Defender for Cloud automatically enables the Defender for Endpoint sensor on all supported machines connected to Defender for Cloud.
- When the enhanced security feature ‘Defender for Servers’ is enabled, the MDC will automatically onboard your machines to MDE.
- With Azure Arc managed servers deployment is automatically established after initial configuration.
Single pane of glass. The Defender for Cloud portal pages display Defender for Endpoint alerts. To investigate further, admin can pivot to Microsoft Defender for Endpoint’s portal pages where additional information is available, such as device timeline.

Events, Alerts & Incidents

Just to clarify because events, alerts & incidents are so often confused together (from Microsoft Sentinel documentation):

Event – is a description of a single occurrence of an action. For example, a single entry in a log file could count as an event. In this context, an event refers to a single result returned by a query in an analytics rule.

Alert – is a collection of events that, taken together, are significant from a security standpoint. An alert could contain a single event if the event had significant security implications – an administrative login from a foreign country outside of office hours, for example.

Microsoft security solutions create alerts that are shared between the security solutions.

Incidents – are groups of related alerts that together create an actionable possible threat that you can investigate and resolve.

When Defender for Endpoint detects a threat, it triggers an alert. The alert is shown in Defender for Cloud Alerts blade. From MDC, you can also pivot to the Defender for Endpoint console, and perform a detailed investigation to uncover the scope of the attack.

Test Alert

I initiated a ‘fileless attack’ from a test server named ‘WIN-CUVTVT6LVBJ’ (located in on-prem environment) to test the aforementioned scenario. After the attack is triggered the alert is created in MDE (and fast) where it’s synchronized to M365 Defender (M365D) and to Microsoft Defender for Cloud (MDC).

M365D also aggregates all related alerts, assets, investigations, and evidence from across devices, users, and mailboxes into an incident to give a comprehensive look into the entire breadth of an attack. In this case, the incident is found from M365D but not from MDC which contains only alerts.

Key takeaway – in MDC, only server OS-related alerts are synced from MDE to MDC.

When investigating alerts in the MDC portal the integration with MDE proves its value. The alert contains a deep link that opens the alert page of the specific alert in the M365D portal. From the alert page, it’s possible to navigate to the incident page that shows all related alerts, assets, investigations, and evidence from across devices, users, and mailboxes as mentioned before.

If you have both services enabled, MCA configured & MDE deployed to servers, you can leverage this integration and at the end of the day alerts from servers, no matter where they are located can be seen in both, MDC & MDE portals (+Microsoft Sentinel if in use).

Side note

During tests, I had difficulties getting all detections synced from MDE to MDC when the AWS EC2 instance was the source of alerts. With an on-prem instance, everything worked as expected. I need to investigate this scenario more and will update the blog later on.

The same attack triggered in the servers

Summary

The following table describes alert & incident synchronization in Microsoft security solutions covered in this blog post. Take into account that if Microsoft Sentinel is in use it changes the game dramatically because it has native support for bi-directional sync between Microsoft Defender 365 (M365D) & Microsoft Defender for Cloud (MDC). With bi-directional sync between solutions, incident management is handled in one solution instead of multiple and the incident lifecycle is under much better control.

That being said, one of the benefits of having Microsoft Sentinel in the game is that it acts as a ‘hub’ that triggers alert/incident status synchronization between Microsoft security solutions.

Source Name	Target Name	Bi-directional sync possible	Notes
Defender for Endpoint (MDE)	M365 Defender (M365D)	Yes (automatic)	Services have their own data repositories but all configuration & reporting is located in security.microsoft.com (M365D) portal.
M365 Defender / Defender for Endpoint (M365D/MDE)	Defender for Cloud (MDC)	No	When alert/incidents are dismissed in M365D/MDE, status is not synchronized to MDC
Defender for Cloud (MDC)	M365 Defender (M365D)	No	When an alert is dismissed in MDC, status is not synchronized to M365D

Key takeaway – It depends on the detection source is alert synced (or found) from MDC / MDE:

If detection source is MDE, the alert status is synced from MDE to MDC
If detection source is MDC, the alert status is not synced from MDC to MDE

Alert Data underneath the Hood

As you can see from the pictures below, the alert is generated (source) in MDE where the detection initially triggered an alert. MDC contains links to the MDE alert but is an independent alert. The same alert is synced also to Intelligent Security Graph (ISG).

In the MDC alert blade, there is an ‘Open query’ button that redirects to the Azure Resource Graph where you can play with KQL by yourself. In the right picture below I have a resource graph query that lists all medium & high severity alerts with certain properties.

Azure Resource Graph query

//List active alerts with medium or high severity  
securityresources
  | where type =~ 'microsoft.security/locations/alerts'
  | where properties.Status in ('Active')
  |where properties.Severity in ('Medium', 'High')
  | extend SeverityRank = case(
    properties.Severity == 'High', 3,
    properties.Severity == 'Medium', 2,
    0
    )
  | sort by  SeverityRank desc, tostring(properties.SystemAlertId) asc
  | project-away SeverityRank
  |project name, properties.Severity, properties.AlertDisplayName, properties.TimeGeneratedUtc, properties.ProductName

Side note

One interesting finding was that in the multi-cloud scenario (when using Azure Arc) you can expect to find two (2) AWS EC2 instance objects from MDC. One is through API scanning (CSPM) and one is from Azure Arc.

Azure Defender for SQL on Machines

In the multi-cloud scenario, Defender for Servers, Defender for Kubernetes, and Defender for SQL are supported. This means that you can leverage Azure Defender Threat Protection capabilities no for these resource types no matter where they are located. In the following example, the SQL instance is running an on-prem environment on top of Windows Server 2019 OS.

Threat intelligence enriched security alerts are triggered when there’s (from docs.microsoft.com):

Potential SQL injection attacks – including vulnerabilities detected when applications generate a faulty SQL statement in the database
Anomalous database access and query patterns – for example, an abnormally high number of failed sign-in attempts with different credentials (a brute force attempt)
Suspicious database activity – for example, a legitimate user accessing an SQL Server from a breached computer which communicated with a crypto-mining C&C server

Azure Arc for SQL architecture from docs.microsoft.com

What’s needed:

Onboard server to Azure Arc
Onboard server to Azure Arc SQL
- Install the agent extension
- Provision Log Analytics agent to SQL server host
- Enable the MDC Defender plan for ‘SQL Servers on machines’
- Remember to register Microsoft.AzureArcData resource provider

After running the onboarding script, and onboarding the server to Azure Arc SQL you can find the servers from SQL Servers blade in Azure Arc. Detailed instructions for Azure Arc deployment are found here.

Azure Arc Dashboard

This example server is located in the on-prem environment and because of Azure Arc (+ agent extensions) it reports SQL vulnerabilities and security monitoring related events to security services and you can enjoy seeing related data on the Azure portal, quite cool I would say 🙂

Azure Arc security dashboard contains a summary of recommendations related to the operating system and SQL server. Most recent security incidents are also shown on the security dashboard.