Microsoft Sentinel turns the Log Analytics foundation from the earlier Monitor post into a SIEM: detections over your telemetry, incidents with entity correlation, and automated response. The technology is the easy part. The hard part is the same as every SIEM ever: ingesting the right data instead of all data, and writing detections your SOC can actually work.

Workspace and Data Strategy

Sentinel enables on a Log Analytics workspace, and the guidance from the observability post evolves here: a dedicated security workspace is usually right, because security data has different retention (regulators like years), different access (SOC, not every developer), and different cost dynamics. Connect sources in tiers. Tier one, the identities and control planes: Entra ID sign in and audit logs, Azure Activity, Microsoft 365, Defender XDR via the unified connector. Tier two, the network and endpoints: firewall logs, DNS, the flow logs from yesterday. Tier three, everything else on justification only. The costliest Sentinel mistake is symmetrical ingestion, shoveling verbose operational logs into the security workspace because the pipe exists; use the Basic and Auxiliary table plans for high volume low fidelity sources you keep for hunting rather than real time detection, and data collection rule transformations to drop noise before it bills.

Analytics Rules That Earn Their Alerts

Start from the Microsoft supplied rule templates and the solutions in the content hub for your connected sources, enable deliberately, and tune before enabling more. A scheduled rule is KQL over a window with a threshold; the craft is in making the query encode the attack, not the symptom. A classic example, impossible travel refined to reduce noise:

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
| summarize locations = make_set(pack("country", LocationDetails.countryOrRegion,
    "time", TimeGenerated)), ips = dcount(IPAddress)
    by UserPrincipalName
| where array_length(locations) > 1 and ips > 1
| mv-expand locations
| summarize minTime = min(todatetime(locations.time)),
    maxTime = max(todatetime(locations.time)),
    countries = make_set(locations.country)
    by UserPrincipalName
| where array_length(countries) > 1
| where datetime_diff('minute', maxTime, minTime) < 120

Map entities (account, IP, host) on every rule, because entity mapping is what lets Sentinel correlate five weak signals about the same user into one incident instead of five ignorable alerts. Use the anomaly and UEBA engines as enrichment, feeding rules and investigations, rather than as alert sources themselves; behavioral anomalies alone page people into numbness. And measure your rules like a product: per rule, track incidents raised, true positive rate, and median triage time, then fix or retire the worst performers monthly. A SOC that trusts its queue investigates; one that does not, tab switches.

Automation: Triage First, Response Second

Automation rules route and enrich: auto close known benigns (the vulnerability scanner tripping port scan detections), tag and assign by entity or technique, and attach playbooks. Logic Apps playbooks then do the hands work: enrich the incident with geo and threat intel on the IPs, post to the SOC channel, open the ticket. Response actions, disabling a user, isolating a machine via Defender, blocking an IP on the firewall, belong behind either an approval step in the playbook or a human clicking run, at least until your false positive rate has earned unattended execution. Automating containment on a rule with ten percent precision automates outages.

Deploy all of it as code, rules, automation, and workbooks export to ARM and sit happily in the same repo and pipeline discipline as the rest of this series, because a SIEM configured by clicks is a SIEM nobody can rebuild after a bad Friday.

Cheers
Osama