12.2 Azure Security Operations with Microsoft Sentinel

The Microsoft Cloud Security Ecosystem: Identity, Workloads, and SIEM

Microsoft's cloud security architecture unifies identity governance, workload protection, and security analytics into an integrated ecosystem. For the enterprise SOC, navigating this environment requires understanding the relationship among three core platforms: Microsoft Entra ID (formerly Azure Active Directory), the Microsoft Defender XDR family, and Microsoft Sentinel.

[Microsoft Enterprise Security Architecture]
┌────────────────────────────────────────────────────────────────────────┐
│                     Microsoft Sentinel (SIEM & SOAR)                   │
│     - Log Analytics Workspace         - Scheduled / NRT Analytic Rules │
│     - Data Connectors (Native / AMA)  - Automation Rules & Playbooks   │
└──────────────────────────────────▲─────────────────────────────────────┘
                                   │ Ingestion (Events, Logs, Alerts)
        ┌──────────────────────────┴──────────────────────────┐
        │                                                     │
┌───────┴────────────────────────┐       ┌────────────────────┴────────────────┐
│       Microsoft Entra ID       │       │        Microsoft Defender XDR       │
│  - Interactive SigninLogs      │       │  - Defender for Endpoint (MDE)      │
│  - NonInteractiveUserSignInLogs│       │  - Defender for Identity (MDI)      │
│  - Directory AuditLogs         │       │  - Defender for Cloud Apps (MDA)    │
│  - AADRiskyUsers / Risk Events │       │  - Defender for Cloud (CWPP / CSPM) │
└────────────────────────────────┘       └─────────────────────────────────────┘

1. Microsoft Entra ID: Identity Telemetry Streams

Because identity is the primary control boundary in Azure, Microsoft Entra ID generates high-fidelity telemetry that serves as the foundation for modern SOC monitoring. Entra ID logs are routed to Sentinel via native diagnostic settings and populate several distinct tables in the Log Analytics workspace:

• SigninLogs (Interactive User Sign-Ins): Captures user authentications where a human enters credentials (password, FIDO2 key, Microsoft Authenticator push) through a browser or client application. Critical fields include UserPrincipalName, IPAddress, Location (city/country), ConditionalAccessStatus, AuthenticationRequirement (single vs. multi-factor), and ResultType (where 0 indicates success, and specific codes like 50126 represent invalid credentials or 50074 represent failed MFA challenges).
• NonInteractiveUserSignInLogs: Captures background authentications executed on behalf of a user without direct human interaction—such as mobile email clients refreshing OAuth refresh tokens or desktop applications maintaining persistent sessions. Because non-interactive volume often exceeds interactive logins by a factor of ten, isolating anomalies here is essential for catching session hijacking.
• AADServicePrincipalSignInLogs: Records authentications performed by non-human identities, such as applications and service principals utilizing client credentials (app IDs and secret certificates) to access Azure resources or Microsoft Graph APIs.
• AuditLogs: Records directory-level changes and their actors. Retention and tamper resistance depend on licensing, export, access controls, and storage design; the table should not be assumed immutable. Important supported events include user provisioning, group membership changes, app registrations, conditional-access changes, and privileged-role assignments. Analysts should verify event coverage, licensing, latency, and export configuration for the activity under investigation.
• AADRiskyUsers and AADUserRiskEvents: Populated by Entra ID Identity Protection using real-time and offline machine learning algorithms. Flags anomalous events such as unfamiliarFeatures, leakedCredentials, anonymousIPAddress (Tor/VPN exit nodes), impossibleTravel, and maliciousIPAddress.

2. Microsoft Defender for Cloud and Defender XDR

• Microsoft Defender for Cloud: Serves as the cloud-native CSPM and CWPP engine for Azure, AWS, and GCP. It audits compliance against the Microsoft Cloud Security Benchmark (MCSB) and generates actionable alerts for server workloads (Defender for Servers), containerized clusters (Defender for Containers), and storage assets (Defender for Storage).
• Microsoft Defender XDR: Unifies telemetry across end-user environments, correlating alerts from endpoints (Defender for Endpoint), on-premises Active Directory domain controllers (Defender for Identity), cloud applications (Defender for Cloud Apps), and email infrastructure (Defender for Office 365) into centralized, multi-stage attack incidents.

---

Microsoft Sentinel Architecture & Data Ingestion Pipeline

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform. Sentinel operates on top of an Azure Log Analytics Workspace (LAW), which provides the underlying data store, indexing engine, and query execution fabric.

Ingestion Mechanisms & The Azure Monitor Agent (AMA)

Sentinel ingests data across diverse environments utilizing three primary mechanisms:

1. Service-to-Service Native Connectors: Direct, API-based integrations that ingest logs from Microsoft Entra ID, Microsoft 365, Azure Activity, and Microsoft Defender XDR with single-click activation and zero infrastructure overhead.
2. Azure Monitor Agent (AMA) with Data Collection Rules (DCR): Replaces the legacy Log Analytics Agent (MMA/OMS). The AMA is deployed across Windows and Linux virtual machines (in Azure, on-premises via Azure Arc, or in other clouds). Ingestion behavior is centrally configured using Data Collection Rules (DCRs), which define precisely which Windows Security Event IDs, Syslog facilities, or Common Event Format (CEF) log streams are filtered at the host level before transmission, drastically reducing bandwidth and log ingestion costs.
3. Codeless Connector Framework (CCF) & REST APIs: Facilitates custom log ingestion from third-party SaaS vendors, network appliances, and external threat intelligence feeds using Azure Functions, Logic Apps, or direct REST API posts.

Data Storage Tiers in Log Analytics

To optimize security monitoring costs, Sentinel supports multiple log storage tiers:

• Analytics Logs: High-performance, fully indexed tier supporting real-time alerting, scheduled analytic rules, and interactive KQL hunting. Standard retention ranges from 30 to 730 days.
• Basic table plan: Discounted ingestion for troubleshooting and incident-response data, with 30 days of interactive single-table querying under the current Azure Monitor Logs model.
• Long-term/Data Lake retention: Lower-cost retention beyond the interactive period. Current Microsoft Sentinel data-lake options can extend total retention up to 12 years; access method, features, and cost differ from the Analytics tier. Archived data can be restored or queried via search jobs.

---

Kusto Query Language (KQL) for SOC Analysts

Kusto Query Language (KQL) is the specialized, read-only query language utilized by Microsoft Sentinel, Azure Monitor, and Defender XDR. KQL structures data flow using a Unix-style pipe syntax (|), where the output of one operator becomes the input to the next operator. Designed for big data analytics, KQL executes complex correlations across billions of records in sub-second timeframes.

KQL Operator Reference Matrix

---

Production-Grade KQL Detection Rules & Triage

To understand how SOC engineers translate threat intelligence and adversary tactics into actionable detections, examine two concrete, production-grade KQL analytic rules.

Detection Rule 1: Privileged Entra ID Role Assignment (Global Administrator Abuse)

Adversaries who compromise a cloud environment frequently seek persistence and complete administrative dominion by granting themselves the Global Administrator or Privileged Role Administrator role.

// Detection Rule: New Privileged Entra ID Role Assigned
AuditLogs
| where TimeGenerated >= ago(1h)
| where OperationName =~ "Add member to role"
| where Result =~ "success"
| mv-expand TargetResources
| extend RoleName = tostring(TargetResources.modifiedProperties[1].newValue)
| where RoleName in~ ("Global Administrator", "Privileged Role Administrator", "Security Administrator")
| extend TargetUserUPN = tostring(TargetResources.userPrincipalName)
| extend InitiatedByUPN = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend InitiatedByIP = tostring(parse_json(tostring(InitiatedBy.user)).ipAddress)
| project TimeGenerated, OperationName, RoleName, TargetUserUPN, InitiatedByUPN, InitiatedByIP, CorrelationId

Line-by-Line Technical Breakdown:

1. AuditLogs | where TimeGenerated >= ago(1h): Scopes the query to directory audit events logged within the preceding 60 minutes.
2. where OperationName =~ "Add member to role": Filters specifically for directory role membership additions (=~ denotes case-insensitive matching).
3. where Result =~ "success": Discards failed or rejected role assignment attempts.
4. mv-expand TargetResources: Expands the dynamic JSON array of targeted assets, turning each targeted resource into an individual row for tabular inspection.
5. extend RoleName = ...: Extracts the assigned role name from the nested modifiedProperties JSON structure.
6. where RoleName in~ (...): Restricts alerts to tier-0 privileged roles capable of enterprise-wide compromise.
7. extend TargetUserUPN ... InitiatedByUPN ...: Extracts the identity receiving the privilege and the administrative identity that authorized the transaction.
8. project ...: Formats the final output table, presenting only relevant forensic artifacts (target, actor, source IP, correlation ID) for the Tier 1 triage analyst.

Detection Rule 2: Brute-Force Password Spray Followed by Successful Authentication

A common adversary pattern involves executing multiple failed login attempts against an account (or spraying a common password across thousands of accounts) followed by a successful authentication from the same IP address.

// Detection Rule: Multiple Failed Logins Followed by Successful Interactive Sign-In
let LookbackPeriod = 2h;
let FailureThreshold = 10;
let FailedAttempts = 
    SigninLogs
    | where TimeGenerated >= ago(LookbackPeriod)
    | where ResultType in (50126, 50053, 50055) // Invalid password, account locked, expired password
    | summarize FailedCount = count(), FirstFailure = min(TimeGenerated), LastFailure = max(TimeGenerated)
        by IPAddress, UserPrincipalName
    | where FailedCount >= FailureThreshold;
let SuccessfulLogins = 
    SigninLogs
    | where TimeGenerated >= ago(LookbackPeriod)
    | where ResultType == 0 // Successful authentication
    | project SuccessTime = TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, Location, ClientAppUsed;
FailedAttempts
| join kind=inner (SuccessfulLogins) on IPAddress, UserPrincipalName
| where SuccessTime > LastFailure
| extend CompromiseWindowMinutes = datetime_diff('minute', SuccessTime, LastFailure)
| project FirstFailure, LastFailure, SuccessTime, CompromiseWindowMinutes, UserPrincipalName, IPAddress, FailedCount, AppDisplayName, Location

Line-by-Line Technical Breakdown:

1. let LookbackPeriod = 2h; let FailureThreshold = 10;: Declares reusable variables defining time boundaries and sensitivity thresholds.
2. FailedAttempts = SigninLogs ...: Isolates failed authentication error codes (such as 50126 for incorrect credentials) and aggregates failed attempts by source IP and user principal name.
3. SuccessfulLogins = SigninLogs ...: Creates a secondary virtual table isolating successful sign-in events (ResultType == 0) occurring across the same window.
4. FailedAttempts | join kind=inner (SuccessfulLogins) on IPAddress, UserPrincipalName: Merges both datasets where both the source IP and target user match exactly.
5. where SuccessTime > LastFailure: Ensures the successful login occurred chronologically after the brute-force flurry, eliminating benign logons that preceded the attack.
6. extend CompromiseWindowMinutes = ...: Calculates the operational delay between the final brute-force attempt and the successful breach.

---

Sentinel Incident Management & SOAR Automation Rules

When an Analytic Rule detects a threat, Microsoft Sentinel automatically generates an Incident. An incident correlates multiple alerts containing overlapping entities (e.g., matching IP addresses, user accounts, or hostnames) into a single operational dossier, preventing alert fatigue in the SOC queue.

Incident Triage & The Investigation Graph

During triage, analysts utilize Sentinel's Investigation Graph, an interactive visual interface that maps relationships between entities. Analysts can expand entities (e.g., pivoting on a compromised user account to reveal all IP addresses utilized over the last 48 hours) without writing manual queries.

Automation Rules vs. Playbooks (Azure Logic Apps)

Sentinel differentiates between lightweight triage automation and complex orchestration workflows:

• Automation Rules: The primary triage automation engine. Evaluated immediately upon incident creation or update. Operates without code to assign incidents to specific SOC tiers, append analytical tags (e.g., MitreATT&CK:T1078), alter severity ratings, or automatically close known false positives.
• Playbooks: Built upon Azure Logic Apps, playbooks deliver enterprise-grade SOAR capabilities. A playbook contains pre-configured connectors and conditional logic to execute automated, cross-platform containment workflows:
  1. Identity Containment: Calling Microsoft Graph POST /users/{id}/revokeSignInSessions invalidates Entra refresh tokens and Entra browser session cookies after propagation. Already issued access tokens and application-owned sessions require additional controls.
  2. Network Containment: Modifying an Azure Network Security Group (NSG) rule to block a malicious external IP address or quarantine a compromised virtual machine.
  3. ITSM Synchronization: Opening a critical incident ticket in ServiceNow SecOps, updating notes in real time, and notifying the on-call Tier 2 incident responder via a Microsoft Teams webhook.