Sentinel Automation: Rules, Playbooks, Retention, Purview…

Automation, retention, audit — the SOC operational stack

Simple explanation

Three SC-500 operational topics that complete the Sentinel story:

Automation rules — declarative rules that react to incidents (and alerts) — change owner, assign to a tier, set status, add tags, attach a playbook, suppress duplicates. They’re the lightweight automation layer.
Playbooks — Logic Apps that perform multi-step response actions: post to Teams, isolate a device via Defender for Endpoint, disable a user in Entra ID, look up a file hash in threat intel, ask a human for approval, then act. Triggered by automation rules or invoked manually.
Data retention — three tiers (Analytics, Auxiliary, Data Lake) with different cost/queryability trade-offs. Choose per table based on how the data is used.
Purview Audit in Defender XDR — Microsoft Purview’s Audit log is queryable from the Defender XDR Advanced Hunting surface, letting SOC analysts pivot from a Defender XDR incident into a unified KQL query across audit events without leaving the portal.

Automation rules

Automation rules are Sentinel-native declarative response automation. Three trigger types:

When alert is created — fires on any analytics rule output (single alert).
When incident is created — fires when an incident (one or more correlated alerts) appears.
When incident is updated — fires on incident updates (status change, owner change, tag added, etc.) — useful for “if SOC closes as false positive, capture the reason in a workbook” workflows.

Conditions match on alert/incident properties (severity, tactic, technique, source product, name patterns). Actions:

Change incident properties: assign owner, set status (New / Active / Closed), set severity, add tags
Add task — assign work items as part of the incident
Suppress (only on alert trigger) — don’t create incident
Run playbook — invoke one or more Logic Apps playbooks

Automation rules can be ordered (a sequence of evaluation) and scoped to specific analytics rules (run only for matching analytics rule outputs).

Playbooks (Logic Apps)

Playbooks are Logic Apps that use Microsoft Sentinel triggers and connectors. Standard plan or Consumption plan; Standard is the SOC-recommended for tenant isolation, VNet integration, and predictable performance.

Common playbook patterns:

Common Sentinel playbook patterns
Pattern	What it does
Enrich incident	Look up IPs in threat intel, look up file hashes in VirusTotal, look up users in HR data, post enrichment as incident comments
Notify and assign	Post to a Teams channel, email an on-call, page via ntfy/PagerDuty, assign to tier-1 analyst
Contain	Isolate a device via Defender for Endpoint, disable a user in Microsoft Entra ID, revoke sign-in sessions, block an IP in Azure Firewall / a CDN
Triage	Apply rules to auto-close false positives (e.g. expected scanning from approved IP), set severity based on enrichment results
Human-in-the-loop	Send a Teams approval card to a manager before performing a destructive action (disable user, isolate device); proceed on approval
Hand off to ITSM	Create a ServiceNow / Jira / Azure DevOps incident with the Sentinel incident details

Playbooks are triggered by automation rules or invoked manually from the incident view by an analyst with the Sentinel Playbook Operator (or Responder/Contributor) role.

Data retention tiers

Sentinel/Log Analytics now offers three retention tiers per table:

Sentinel data retention tiers — choose per table
Tier	Best for	Query model	Typical cost
Analytics	Active SOC data (last 30–90 days)	Interactive KQL, analytics rules, hunting, workbooks, dashboards	Highest per GB
Auxiliary (recent retention)	High-volume but lower-priority data (firewall logs, NetFlow, DNS) — searched on demand	KQL search jobs (jobs, not interactive); limited functions	~$0.15/GB ingested (significantly lower than Analytics)
Data Lake (long-term)	Compliance retention beyond 730 days, archival of unusable-day-to-day data	Search jobs or restore to Analytics for interactive query	Lowest — pure storage cost

Per-table retention is configurable. Standard pattern for SC-500-aligned environments:

Analytics tier: SecurityEvent, SigninLogs, AuditLogs, DeviceFileEvents, etc. — typically 90 days, with some up to 365 days
Auxiliary tier: high-volume firewall, NetFlow, DNS resolution logs — kept for search-on-demand for incident investigation
Data Lake: anything retained for compliance reasons beyond the Analytics retention max (typically 7+ years for some regulated industries)

Purview Audit in Defender XDR

Microsoft Purview Audit is the unified audit log for Microsoft 365 (Exchange, SharePoint, Teams, etc.) + Microsoft Entra audit events. Two query paths:

Microsoft Purview portal — Audit Search — interactive search UI in the Purview portal
Microsoft Defender XDR Advanced Hunting — KQL query against CloudAppEvents (and related tables) that include Purview Audit entries

The Defender XDR Advanced Hunting path is the SC-500 surface: SOC analysts working an incident in Defender XDR can pivot directly into KQL queries that join Defender XDR telemetry with Purview Audit entries — no portal-switching, one query surface.

Why query Purview Audit from Defender XDR?

When a Defender XDR incident involves an M365 entity — a user signed in unusually, then sent a suspicious email, then accessed an external SharePoint site — the SOC analyst’s natural question is “what else did this user do in M365 in this window?”

The Purview Audit log has the answer (every user action in Exchange / SharePoint / Teams is logged). Surfacing it in Defender XDR Advanced Hunting means the analyst writes one KQL query that joins IdentityLogonEvents + EmailEvents + CloudAppEvents and gets the full picture without leaving the portal.

This is the “Purview Audit in Defender XDR” SC-500 objective — operationally, it’s about reducing analyst context switching.

Scenario: Dom builds the SOC automation for a high-volume client

For Kestrel Cyber Co-op’s fintech client (200 users, 500 incidents/month estimated):

Automation rules:
- All incidents from the Microsoft Defender XDR source → assign to Kestrel SOC tier-1 queue, set status Active.
- Incidents with severity Informational from analytics rules tagged noise-tolerated → auto-close as Benign Positive with note.
- All incidents involving a labelled-sensitive SharePoint site → run Playbook: ContainAndEnrich.
Playbook: ContainAndEnrich:
- Look up involved IPs in MISP threat intel; post results as incident comments.
- Look up involved user accounts; post manager + group memberships.
- If high severity AND any IP is on MISP indicators → Teams approval card to on-call.
- On approval → disable user via Microsoft Graph + revoke sessions; isolate device via Defender for Endpoint.
Data retention:
- SecurityEvent, SigninLogs, AuditLogs: Analytics 90 days.
- Defender XDR Device tables: Analytics 90 days.
- Firewall logs from CEF: Auxiliary tier — searched on incident.
- Compliance archive: Data Lake for 7 years.
Purview Audit integration: Dom builds a saved hunting query in Defender XDR Advanced Hunting that joins IdentityLogonEvents, EmailEvents, and CloudAppEvents (including Purview Audit) to surface “what did this user do in M365 in the last 24 hours” — used as the standard first hunt on any user-involved incident.

After 30 days: ~60% of incidents auto-triaged or auto-closed; mean time to enrichment drops from 18 min to 3 min; Purview Audit queries cover ~85% of analyst pivots without portal switching.