Azure Sentinel

What Azure Sentinel Is and Where It Fits

Azure Sentinel (now called Microsoft Sentinel) is a cloud-native SIEM and SOAR platform. Unlike traditional SIEMs that require provisioning servers and managing infrastructure, Sentinel is fully SaaS — you pay for data ingestion and get the analytics engine, storage, and automation built in.

• Sentinel runs on Azure Log Analytics workspaces. All log data is stored in tables — SecurityEvent, SigninLogs, AzureActivity, CommonSecurityLog, DeviceEvents — and queried with KQL.
• Sentinel ingests data from Microsoft sources (Microsoft 365 Defender, Azure AD, Azure Activity, Microsoft Defender for Cloud) and third-party sources (Syslog, CEEE, Windows Event Forwarding, AWS CloudTrail, GCP logs).
• The key difference from Splunk: Sentinel does not have its own search-time indexing. All queries use KQL. Data is stored in a columnar store (Azure Data Explorer technology) and queried at read time. This makes storage very cheap but means KQL optimization matters.

MITRE ATT&CK maps log enumeration to T1654. Sentinel’s strength is that it enumerates across Microsoft’s entire security stack — Defender, Azure AD, and cloud infrastructure.

Log Ingestion — What Goes Where

Sentinel organizes data into Log Analytics tables. Each table has a schema defined by the connector.

Data Retention and Cost

Built-In Analytics Rules

Sentinel comes with hundreds of built-in analytics rules organized by MITRE ATT&CK tactic. These rules are Microsoft’s detection engineering — tuned for common attack patterns.

Rule Types

High-Value Built-In Rules

Rule Tuning — What Every Analyst Should Know

Custom Analytics Rule Template

// Custom rule: Detect brute force success
let threshold = 10;
let timeWindow = 15m;
let FailedLogins = SecurityEvent
    | where TimeGenerated > ago(timeWindow)
    | where EventID == 4625
    | summarize FailedCount = count() by Account, Computer;
let SuccessfulLogins = SecurityEvent
    | where TimeGenerated > ago(timeWindow)
    | where EventID == 4624
    | distinct Account, Computer;
FailedLogins
| where FailedCount > threshold
| join kind=inner SuccessfulLogins on Account, Computer
| project Computer, Account, FailedCount

Incident enrichment: Sentinel can enrich alerts with:

• Threat intelligence match — is the IP in a known threat feed?
• UEBA profile — is this behavior normal for this user?
• Asset information — is this server critical, sensitive, or public-facing?
• Watchlist lookup — is this user in the “high-value targets” list?

UEBA — User and Entity Behavioral Analytics

UEBA builds behavioral profiles for users and entities (devices, IPs, applications) and detects anomalies.

What UEBA Tracks

UEBA Detection Examples

Fusion Detections

Fusion is Sentinel’s ML-based correlation engine. It combines signals across the Microsoft security ecosystem to detect multi-stage attacks.

How Fusion Works

Fusion correlates alerts from:

• Microsoft Defender for Endpoint (endpoint detections)
• Microsoft Defender for Identity (AD identity detections)
• Microsoft Defender for Cloud Apps (SaaS application detections)
• Azure AD Identity Protection (authentication risk detections)
• Custom analytics (your scheduled and NRT rules)

Example Fusion detection chain:

1. Azure AD → "User logged in from Tor exit node" (Identity Protection)
2. Defender for Cloud Apps → "User downloaded company SharePoint to unmanaged device"
3. Defender for Endpoint → "Device running suspicious PowerShell"
→ Fusion correlates these → "Multi-stage supply chain or insider threat incident"

Fusion Alert Categories

Playbooks — SOAR Automation

Sentinel playbooks are built on Azure Logic Apps. They automate incident response actions without writing code.

Playbook Triggers

Common Playbook Actions

Sample Playbook Flow

1. Trigger: Incident created ("Multiple failed logins")
2. Action: Enrich source IP → VirusTotal lookup
3. Action: Check user in Azure AD → MFA status, last login, group membership
4. Condition: If IP is known malicious → "HIGH" severity; if IP is unknown → "MEDIUM"
5. Action: Create ServiceNow incident with enriched data
6. Action: Post alert details to SOC Teams channel
7. Action: (Approval step) "Block source IP?" — waits for analyst approval
8. Action: If approved → Add firewall block rule via Azure Firewall

Popular Playbook Templates

Hunting in Sentinel

Hunting is the proactive phase — searching for threats before they trigger alerts. Sentinel provides a dedicated hunting interface.

Hunting Workflow

1. Choose a hunting query → Built-in or custom KQL query
2. Run the query → Returns potential findings
3. Bookmark findings → Tag suspicious events for investigation
4. Create livebook → Document the hunting session, findings, and actions
5. Convert to analytics rule → Turn a successful hunting query into an alert

Built-In Hunting Queries

Related

• CyberChef — detection and response for T1654 techniques
• Elastic Security — detection and response for T1654 techniques
• Log Sources Overview — covers the log sources overview concepts
• MFA Fatigue — detection and response for T1110.004, T1621 techniques
• MITRE ATT&CK for Triage — covers the mitre att&ck for triage concepts

Sources

• Microsoft Sentinel Documentation
• Microsoft Sentinel UEBA Documentation
• Microsoft Sentinel Fusion Documentation
• Microsoft Sentinel Playbook Templates
• Sentinel GitHub — Detection Rules