10.12 Module Summary

Module 10 Summary: Create Detections and Perform Investigations Using Microsoft Sentinel

What you learned in this module

This module built the detection and investigation layer on top of the workspace (Module 7) and data connectors (Module 8). Without analytics rules, Sentinel is a queryable data lake. With them, it is an automated detection engine that identifies threats, creates incidents, and enables structured investigation and response.

Subsection 9.1 — Analytics Rules: Architecture and Rule Types. The four rule types: scheduled (custom KQL on a timer), NRT (sub-minute detection), Microsoft Security (pass-through from Defender), and anomaly (ML-based behavioural detection). The execution model: schedule, lookback, and the critical requirement to match lookback to schedule to avoid detection gaps. Alert grouping: no grouping, group all, or group by matching entities.

Subsection 9.2 — Creating Scheduled Analytics Rules. Step-by-step rule creation through the wizard. Five production query patterns: threshold detection, rare event detection, sequence detection, baseline deviation, and watchlist/TI match. Rule testing methodology: manual execution, volume estimation, entity mapping verification, and simulation deployment.

Subsection 9.3 — NRT and Microsoft Security Rules. NRT rules for critical, low-volume, high-fidelity detections. Microsoft Security rules for Defender product alert pass-through. The interaction with bi-directional sync — avoiding duplicate incidents. Anomaly rules: ML-based, pre-built, feeding UEBA with behavioural detections.

Subsection 9.4 — Entity Mapping and Alert Enrichment. Entity types (Account, Host, IP, URL, File, Process, FileHash, Mailbox, DNS) and their identifiers. Custom details for alert context. Alert detail overrides for dynamic severity and titles. The principle: map every entity the investigation needs.

Subsection 9.5 — Incident Management and Investigation Workflow. The incident lifecycle: creation → triage → assignment → investigation → classification → closure. The investigation graph for visual entity exploration. Investigation bookmarks for evidence preservation. SOC metrics: MTTT, MTTR, and true positive rate.

Subsection 9.6 — Automation Rules. No-code automation for instant incident management: assignment, tagging, severity escalation, suppression, and playbook triggering. Tactical suppression with expiration dates. Automation rule ordering.

Subsection 9.7 — Playbooks with Logic Apps. Multi-step automated response: user containment (revoke sessions, reset password, enforce MFA), device isolation, phishing remediation, threat intelligence enrichment, and notification. Trigger types: incident vs alert. Managed identity permissions. Playbook monitoring and failure handling.

Subsection 9.8 — User and Entity Behavior Analytics (UEBA). Behavioural baselines, anomaly scoring, investigation priority scoring, and peer group analysis. UEBA as investigation enrichment and proactive hunting tool. The 14-21 day baseline establishment period.

Subsection 9.9 — Workbooks and Security Reporting. SOC operational dashboard: open incidents, incident trend, attack types, team performance. Executive reporting workbook. Data source health workbook. Workbook sharing and access control.

Subsection 9.10 — ASIM Parsers and Data Normalisation. The normalisation problem: inconsistent column names across data sources. ASIM schemas, source-specific parsers, and unifying parsers. Writing cross-source analytics rules with ASIM. Performance considerations for NRT vs scheduled rules.

Subsection 9.11 — Detection Engineering Lifecycle. The continuous improvement cycle: threat modelling → coverage analysis → gap-driven rule development → operational tuning → retirement. Detection-as-code in Git. The MITRE ATT&CK coverage dashboard. The monthly detection review. False positive rate analysis and rule tuning.

SC-200 exam objectives covered

Domain 2 — Configure Protections and Detections (15-20%): Create detections using Microsoft Sentinel analytics. Configure analytics rules. Use ASIM parsers. Manage content in Microsoft Sentinel.

Domain 3 — Manage Incident Response (25-30%): Triage incidents in Microsoft Sentinel. Investigate incidents using Microsoft Sentinel. Use entity behavior analytics. Configure automation in Microsoft Sentinel. Configure playbooks.

Together, these domains represent 40-50% of the SC-200 exam — the largest content block of any single module.

Skills checklist

Before moving to Module 11, verify you can perform each of these tasks.

Analytics rule creation. Create a scheduled analytics rule with: a custom KQL query using one of the five detection patterns (threshold, rare event, sequence, baseline deviation, TI match). Configure schedule and lookback with no detection gaps. Set entity mappings for Account, IP, and Host. Add custom details for at least 3 context fields. Configure dynamic alert title and severity overrides. Map to MITRE ATT&CK techniques. Configure alert grouping by entity.

NRT and Microsoft Security rules. Create an NRT rule for a high-priority, low-volume detection (security log cleared, honeytoken activation). Explain when to use NRT vs scheduled rules. Configure a Microsoft Security rule for a product without bi-directional sync (Entra ID Protection). Explain the duplicate incident problem when both sync and Microsoft Security rules are active for the same product.

Entity mapping. Map at least three entity types correctly. Explain the difference between Account → FullName and Account → Name. Configure custom details and alert detail overrides. Troubleshoot common entity mapping failures (empty entities, no cross-incident correlation). Maintain a cross-rule entity mapping standard.

Incident management. Manage incidents through the complete lifecycle: triage (30-second assessment from details pane), assignment, investigation (entity timeline analysis, scope assessment), evidence collection (investigation bookmarks), containment, classification (TP/FP/BP), and closure with documented comments. Use the investigation graph to visualise entity relationships. Correlate related incidents involving the same entities.

Automation rules. Build automation rules for: assignment routing, severity escalation, tagging, tactical false positive suppression (with expiration), and playbook triggering. Configure incident update triggers for workflow automation. Monitor automation rule execution health. Maintain a categorised automation rule library.

Playbooks. Describe the Logic Apps playbook architecture (triggers, connectors, managed identity). Build notification playbooks (Teams, email), enrichment playbooks (TI lookup, geolocation), and containment playbooks (revoke sessions, reset password, isolate device). Implement approval workflows for VIP users. Handle playbook failures gracefully. Test playbooks in staged rollout before production deployment.

UEBA. Enable UEBA with all available data sources. Explain the 14-21 day baseline establishment period. Navigate the entity page (timeline, insights, anomalies, investigation priority score). Use UEBA for incident enrichment (checking entity pages during investigation) and proactive hunting (reviewing high-priority entities). Explain peer group analysis and its value for insider threat detection.

Workbooks. Create a SOC operational dashboard with: open incidents by severity, daily incident trend, attack type distribution, analyst workload, and data source health. Create an executive reporting workbook with monthly KPIs. Add parameters for interactivity. Use conditional formatting for visual health indicators.

ASIM. Deploy ASIM parsers from Content Hub. Write analytics rules using ASIM unifying parsers (imAuthentication, imNetworkSession, imProcessCreate). Explain when to use ASIM vs source-specific queries. Create a custom ASIM parser for a bespoke data source. Use ASIM for cross-source investigation.

Detection engineering. Conduct a MITRE ATT&CK coverage analysis. Identify detection gaps. Follow the gap-driven rule development process (research → write → test → deploy → monitor). Calculate and interpret the false positive rate per rule. Follow the systematic tuning playbook for rules exceeding 30% FPR. Conduct the monthly detection review.

Key decisions recap

Rule type selection — scheduled for 90% of detections (full KQL, flexible scheduling). NRT for critical, high-fidelity detections (sub-minute latency). Microsoft Security for products without sync. Anomaly for ML-based behavioural detection feeding UEBA.

Alert grouping — entity-based grouping for most rules (one incident per affected entity). No grouping for rare, high-fidelity events (each instance warrants independent investigation). Group-all for noisy enrichment rules that should create one incident regardless of entity count.

Entity mapping standard — Account → FullName from UserPrincipalName, IP → Address from IPAddress, Host → HostName from DeviceName. Consistent across all rules for cross-incident correlation.

Automation strategy — automation rules for instant no-code triage (assign, tag, escalate). Playbooks for complex multi-step response (containment, notification, enrichment). Combined: automation rule triggers playbook for the richest automated response.

Detection engineering cadence — monthly detection review. Quarterly rule library audit. Continuous tuning based on false positive metrics.

What comes next

Module 11 — Threat Hunting in Sentinel. Analytics rules detect known threat patterns automatically. Module 11 teaches proactive hunting — finding threats that analytics rules miss. Hunting queries, bookmarks, livestream, search jobs, and hunt management. The combination of automated detection (Module 10) and proactive hunting (Module 11) provides comprehensive threat coverage.

Together, Modules 7-10 complete the Sentinel operational capability: workspace (M7) → data (M8) → detection (M10) → hunting (M11). After Module 11, you have a fully operational Sentinel deployment with automated detection, investigation workflow, response automation, and proactive threat hunting.