filter and convert specific Microsoft Defender for Cloud (MDC) alerts into tailored Microsoft Sentinel Incidents,

techhadoop azure, security

To filter and convert specific Microsoft Defender for Cloud (MDC) alerts into tailored Microsoft Sentinel Incidents, you write custom Kusto Query Language (KQL) rules using the SecurityAlert table.

1. Understand How MDC Alerts Are Stored

When Defender for Cloud streams alerts into Sentinel, they populate the SecurityAlert table. The key fields used for filtering are:

  • ProviderName: For MDC alerts, this is typically ProtectionCenter, MDFC, or specific engines like Azure Security Center.
  • AlertName: The title of the alert (e.g., “Unfamiliar ASP.NET app execution”, “Potential SQL Injection”).
  • AlertSeverity: Severity level (High, Medium, Low, Informational).
  • Entities: JSON array containing detailed entity metadata (IPs, Hosts, Accounts, Azure Resources).
  • ExtendedProperties: JSON dictionary containing alert-specific context (e.g., process command line, query text).

2. Crafting Custom KQL Alert Queries

Example 1: High-Severity Storage & Database Alerts

Filter only for High severity MDC alerts targeting Storage Accounts or SQL Databases:

Code snippet

SecurityAlert
| where TimeGenerated >= ago(1h)
| where ProviderName in ("ProtectionCenter", "MDFC", "Azure Security Center")
| where AlertSeverity == "High"
// Filter by specific alert types or resource categories
| where AlertName has_any ("SQL", "Storage", "Blob", "Key Vault")
| extend CompromisedResource = Properties
| project TimeGenerated, SystemAlertId, AlertName, AlertSeverity, Description, CompromisedResource, Entities
Example 2: Suspicious Process Execution on VMs (Excluding Approved Dev Machines)

Filter for server alerts related to suspicious processes while suppressing noise from non-production resource groups:

Code snippet

SecurityAlert
| where TimeGenerated >= ago(1h)
| where ProviderName in ("ProtectionCenter", "MDFC")
| where AlertName has_any ("Suspicious Process", "Malware", "Execution")
// Parse entities to extract the targeted computer name or Azure resource
| extend ExtractedHost = tostring(parse_json(Entities)[0].HostName)
| extend ResourceGroup = tostring(parse_json(ExtendedProperties)["Resource Group"])
// Suppress noise from non-prod/test resource groups
| where ResourceGroup !has "rg-dev-" and ResourceGroup !has "rg-test-"
| project TimeGenerated, SystemAlertId, AlertName, AlertSeverity, ExtractedHost, ResourceGroup, Entities

3. Step-by-Step: Creating the Analytics Rule in Sentinel

1.Open Analytics Rules:Sentinel Navigation.

  1. In the Azure Portal, open Microsoft Sentinel.
  2. Under Configuration on the left menu, select Analytics.
  3. Click + Create at the top and select NRT query rule (for real-time evaluation) or Scheduled query rule.

2.Set General Properties:Rule Details.

  1. Name: Give your rule a descriptive title (e.g., MDC: High-Severity SQL Injection Attempts).
  2. Description: State the purpose of the custom filter.
  3. Tactics and Techniques: Map to MITRE ATT&CK categories (e.g., Initial Access, Execution).
  4. Severity: Set the severity level for the generated incident.

3.Set Query, Mapping, and Scheduling:Rule Logic.

  1. Set rule logic: Paste your refined KQL query into the Set rule logic field.
  2. Entity Mapping: Map query fields to Sentinel entities so incident analysts see structured context:
    • Host$\rightarrow$ExtractedHost
    • IP$\rightarrow$IPAddress
    • Azure Resource$\rightarrow$ResourceGroup
  3. Query scheduling: Set Run query every (e.g., 1 hour) and Lookup data from the last (e.g., 1 hour).

4.Configure Grouping and Alert Suppression:Incident Settings.

  1. Incident creation: Ensure Create incidents from alerts triggered by this analytics rule is Enabled.
  2. Alert grouping: Choose whether to group multiple matching alerts into a single incident (e.g., group alerts triggered within 5 hours for the same resource).

5.Validate and Save:Review.

  1. Click Review + create and select Save.
  2. The custom rule will now periodically run against incoming Defender for Cloud alerts and automatically create high-fidelity Sentinel incidents.

Best Practice Tip: Suppress Duplicate Incidents

Because the native Microsoft Defender for Cloud data connector can create default Sentinel incidents, turn off the default incident creation setting on the connector page OR disable specific rules if you are replacing them with custom KQL rules. This prevents duplicate incidents from cluttering your SOC queue.

Leave a Reply