Lesson 37 — Microsoft Sentinel Integration
Microsoft Defender for Cloud detects threats against cloud workloads. Microsoft Sentinel brings those alerts into a wider security operations workflow.
Depending on how Sentinel is deployed, Defender for Cloud alerts can be ingested through the Defender for Cloud connector in the Azure portal or surfaced through the unified Microsoft Defender XDR and Sentinel experience in the Microsoft Defender portal.
This lesson explains the integration architecture, alert and incident flow, synchronisation, entity correlation, KQL investigation, automation rules, playbooks, hunting and the operational choices required to avoid duplicate incidents and fragmented investigations.
What you will learn
This lesson follows a Defender for Cloud alert into Sentinel for correlation, investigation, automation and response.
Defender for Cloud and Sentinel integration flow
↓
Microsoft Defender for Cloud generates security alerts
↓
Alerts flow through the configured integration path
↓
Azure-portal connector or unified Defender XDR integration
↓
Microsoft Sentinel receives alert and incident context
↓
Entities are mapped across users, hosts, IPs and cloud resources
↓
Analysts correlate identity, endpoint, Azure activity and workload logs
↓
KQL hunting expands the investigation
↓
Automation rules assign and enrich the incident
↓
Playbooks notify, ticket or contain
↓
Status synchronisation updates connected security products
↓
The incident is validated, documented and closed
Integration choices
| Operating model | Integration path | Important consideration |
|---|---|---|
| Sentinel in Azure portal | Microsoft Defender for Cloud data connector. | Confirm subscription or tenant coverage and incident creation. |
| Tenant-based connector | Tenant-wide Defender for Cloud alert collection. | Validate preview status, workspace scope and permissions. |
| Sentinel in Microsoft Defender portal | Unified Defender XDR and Sentinel incident experience. | Avoid duplicate standalone incident-generation paths. |
| Hybrid transition | Mixed portal and connector configuration. | Document the correlation owner and test synchronisation. |
Learning objectives
- Explain why Defender for Cloud integrates with Microsoft Sentinel.
- Understand Azure-portal and Defender-portal integration paths.
- Connect and validate Defender for Cloud alert ingestion.
- Understand alert and incident synchronisation.
- Investigate entities and related telemetry.
- Use KQL, automation rules and playbooks.
- Avoid duplicate or fragmented incident workflows.
Why integrate with Sentinel?
Defender for Cloud provides workload detections. Sentinel combines those alerts with identity, endpoint, email, network, application and third-party telemetry for broader investigation.
SIEM and SOAR
Microsoft Sentinel provides security information and event management together with security orchestration, automation and response.
Defender for Cloud role
Defender for Cloud protects Azure, hybrid and multicloud workloads and generates alerts and incidents from enabled Defender plans.
Sentinel role
Sentinel centralises incidents, investigation, hunting, analytics, automation, threat intelligence and cross-platform response.
Two current integration paths
The integration path depends on whether Sentinel is primarily operated in the Azure portal or onboarded to the Microsoft Defender portal.
Azure portal connector
In Azure-portal Sentinel, the Microsoft Defender for Cloud connector can ingest Defender for Cloud security alerts into the selected Sentinel workspace.
Tenant-based connector
The tenant-based Defender for Cloud connector can collect alerts across the tenant without maintaining separate connector enrolment for every subscription where supported.
Subscription connector
Legacy or subscription-scoped connector configurations require coverage to be reviewed for every Defender-enabled subscription.
Microsoft Defender portal
When Sentinel is onboarded to the Microsoft Defender portal, Defender for Cloud alerts are already available through the unified Defender XDR integration path.
Defender XDR bridge
Defender XDR correlates alerts and incidents across Microsoft security products before Sentinel extends investigation, hunting and response.
Workspace selection
Choose a Sentinel workspace that matches the organisation's data residency, access, retention, operating model and incident ownership requirements.
Permissions
Connector setup requires appropriate permissions on the Sentinel workspace and the Defender for Cloud scopes being connected.
Defender plans
Defender for Cloud plans must be enabled for the relevant workload types before they can generate security alerts.
Data connector solution
Install the Microsoft Defender for Cloud solution where needed to obtain the connector and associated Sentinel content.
Alert ingestion
The connector ingests Defender for Cloud security alerts so analysts can view and investigate them in a broader organisational context.
Incident creation
Depending on the integration model, Sentinel or Defender XDR can correlate incoming alerts into incidents.
Avoid duplicate incidents
Do not enable overlapping incident-creation paths without understanding the result. Duplicate connectors or analytics can create parallel incidents for the same activity.
Alert synchronisation
Alert status can synchronise between Defender for Cloud and Sentinel so closure or status changes remain aligned.
Bidirectional synchronisation
Where supported and enabled, closing a Sentinel incident can update the original Defender for Cloud alert status.
Incident synchronisation
In the unified Defender experience, incident state and alert context can synchronise through Defender XDR integration.
SecurityAlert table
Defender alerts ingested into Log Analytics can be queried through the SecurityAlert table, depending on the active connector and schema.
SecurityIncident table
Sentinel incident records can be queried through SecurityIncident for workflow, ownership, status and classification analysis.
AzureActivity table
AzureActivity provides control-plane operations such as role assignments, network changes and resource modifications.
Resource-specific logs
Storage, Key Vault, database, application and network logs provide the data-plane evidence around a cloud alert.
Identity telemetry
Microsoft Entra sign-ins, audit logs and Identity Protection context help explain who or what authenticated.
Endpoint telemetry
Defender for Endpoint can show processes, files, network connections and device evidence related to a compromised cloud workload.
Entity mapping
Entities such as users, hosts, IP addresses, Azure resources, URLs and applications help analysts pivot across the incident.
Incident graph
The investigation graph visualises relationships between alerts and entities so analysts can follow the attack across systems.
Entity pages
Entity pages combine alerts, activities, insights and related incidents for a specific user, host, IP address or other entity.
Timeline
The incident timeline orders alerts, bookmarks and investigation activity to help reconstruct what happened.
Bookmarks
Bookmarks preserve important query results and add them to the incident investigation record.
Tasks
Incident tasks can standardise the investigation steps analysts must complete before closure.
Comments
Use incident comments to record decisions, evidence references, owner communication and response actions.
Analytics rules
Analytics rules identify suspicious behaviour in connected telemetry and can create alerts and incidents beyond the original Defender detection.
Scheduled analytics
Scheduled rules run KQL queries at defined intervals and can group results into alerts or incidents.
Near-real-time analytics
Near-real-time rules provide low-latency detection for supported query patterns and data sources.
Microsoft security rules
Microsoft security incident-creation rules apply to specific connected Microsoft security solutions in Azure-portal workflows.
Unified incident model
When Defender XDR incident integration is enabled, Defender XDR becomes the correlation layer and separate Microsoft incident-creation rules should not duplicate that function.
Automation rules
Automation rules can assign incidents, change severity or status, add tags, run playbooks and apply consistent workflow.
Playbooks
Sentinel playbooks use Azure Logic Apps to perform enrichment, notification, ticketing and response actions.
Enrichment
A playbook can enrich an alert with threat intelligence, asset ownership, geolocation, vulnerability or identity context.
Notification
Automation can notify analysts, resource owners, incident commanders or business teams through approved channels.
Ticketing
Playbooks can create or update cases in service-management systems while preserving the Sentinel incident reference.
Containment automation
Approved playbooks can isolate devices, block indicators, disable identities, remove role assignments or restrict cloud resources.
Approval gates
Use human approval for disruptive actions when false containment could affect critical production services.
Hunting
Sentinel hunting queries help analysts search for related cloud activity that was not included in the original alert.
KQL investigation
Kusto Query Language can correlate alerts with control-plane, identity, workload and network evidence.
Threat intelligence
Threat-intelligence indicators can add reputation and campaign context to IP addresses, domains, URLs and hashes.
Watchlists
Watchlists can provide approved administrator addresses, critical assets, service accounts, business owners or high-value systems for query enrichment.
Workbooks
Sentinel workbooks visualise incidents, alert trends, connector health, entities, data volume and response performance.
Data retention
Retention must support investigation timelines, compliance requirements and delayed discovery of cloud attacks.
Cost control
Monitor ingestion, analytics and retention so useful evidence is collected without uncontrolled cost growth.
Schema awareness
Alert fields and scoping can differ between standalone Defender for Cloud connectors and the Defender XDR connector.
Tenant scope
Tenant-based and Defender XDR integration can provide broader tenant coverage than older subscription-scoped connector models.
Primary workspace
In unified designs, Defender for Cloud alerts may be associated with the tenant's primary Sentinel workspace. Confirm workspace routing during design.
Connector health
Review connector status, last data received, connected scopes and workspace health regularly.
Test alerts
Use approved validation methods to prove alerts appear in the correct workspace and create the expected incident workflow.
Operational ownership
Define who owns the connector, the Sentinel workspace, incident triage, playbooks and downstream remediation.
Common mistake: connector only
Connecting alerts without ingesting supporting logs leaves analysts with detection but insufficient evidence.
Common mistake: duplicate correlation
Overlapping Defender XDR, Microsoft security and custom analytics can duplicate alerts or incidents.
Common mistake: no synchronisation
Closing an incident in one portal without status synchronisation can leave conflicting records elsewhere.
Common mistake: missing subscriptions
Subscription-scoped connector models can miss newly created subscriptions unless onboarding is automated.
Common mistake: unsafe playbooks
Do not grant broad Logic App permissions or automate destructive containment without review and testing.
Validation
Confirm ingestion, incident creation, synchronisation, entity mapping, playbook permissions and investigation evidence before declaring the integration operational.
Example KQL investigation
This starting query identifies recent Defender for Cloud alerts. Analysts should then pivot to AzureActivity, identity, endpoint and resource-specific tables using the entities and time window from the alert.
Agent Foskett investigation: “The cloud alert wasn’t the investigation…”
↓
The alert appeared in Microsoft Sentinel
↓
Sentinel grouped it with an identity alert
↓
The same user had activated a privileged role shortly beforehand
↓
Defender for Endpoint showed a PowerShell process on the VM
↓
AzureActivity showed a new role assignment
↓
Key Vault logs showed secret retrieval
↓
Storage logs showed a large download from an unfamiliar IP address
↓
Agent Foskett bookmarked the key events
↓
A KQL query found the same IP across two subscriptions
↓
An automation rule assigned the incident to cloud response
↓
A playbook enriched the IP and notified the resource owners
↓
The compromised identity was disabled
↓
The VM was isolated and secrets were rotated
↓
The incident timeline documented the complete attack chain
↓
The cloud alert was not the investigation
↓
It was the first piece of evidence
Sentinel integration validation checklist
| Area | Question | Evidence |
|---|---|---|
| Connector | Which integration path is active? | Data connector or Defender portal onboarding. |
| Scope | Are all intended subscriptions and tenants covered? | Connector configuration and test alerts. |
| Ingestion | Are Defender alerts arriving? | SecurityAlert records and connector health. |
| Incidents | Who creates and correlates incidents? | Sentinel or Defender XDR configuration. |
| Synchronisation | Do status changes remain aligned? | Close and reopen testing. |
| Entities | Are users, hosts, IPs and resources mapped? | Incident graph and entity pages. |
| Telemetry | Can analysts pivot beyond the alert? | Identity, AzureActivity and resource logs. |
| Automation | Do rules and playbooks have safe permissions? | Automation testing and Logic App identity. |
| Ownership | Who maintains the integration and response? | Operating model and escalation matrix. |
Key takeaways
- Defender for Cloud generates workload alerts; Sentinel coordinates broader investigation and response.
- The integration path differs between Azure-portal Sentinel and Sentinel in the Microsoft Defender portal.
- Azure-portal deployments can use the Defender for Cloud data connector.
- Unified deployments use Defender XDR incident integration and tenant-level correlation.
- Avoid overlapping incident-creation paths that produce duplicates.
- Alert and incident status can synchronise between connected products.
- Entities allow analysts to pivot across cloud, identity, endpoint and network evidence.
- KQL hunting expands the investigation beyond the original alert.
- Automation rules and playbooks can enrich, route and contain incidents.
- Connector health, scope, synchronisation and permissions must be tested continuously.
What Agent Foskett checked
- Sentinel workspace
- Connector type
- Subscription coverage
- SecurityAlert records
- Incident correlation
- Status synchronisation
- Entity mapping
- AzureActivity
- Identity telemetry
- Endpoint evidence
- Automation rules
- Playbook permissions
Best practices
- Choose one incident-correlation model.
- Validate tenant and subscription scope.
- Ingest supporting telemetry.
- Test alert synchronisation.
- Map entities consistently.
- Use KQL for correlation.
- Automate low-risk workflow first.
- Use approval for disruptive actions.
- Monitor connector health.
- Document ownership and escalation.
Related Agent Foskett resources
Continue learning
How does Microsoft Defender for Cloud integrate with Microsoft Sentinel?
Defender for Cloud security alerts can be integrated with Microsoft Sentinel through the Defender for Cloud data connector in Azure-portal deployments or through the unified Defender XDR and Sentinel experience in the Microsoft Defender portal.
Microsoft Sentinel Integration Lesson
This Agent Foskett lesson explains connectors, alert ingestion, incident correlation, synchronisation, entities, KQL hunting, automation rules, playbooks and validation.
