SIEM Strategy

Microsoft Sentinel is a cloud-native SIEM and SOAR platform. While Defender XDR (Chapter 14) provides detection and response within the Microsoft security product family, Sentinel provides the aggregation layer: pulling signals from XDR plus infrastructure logs, non-Microsoft sources, and custom data, correlating them with analytics rules, and retaining them for the long-term audit period that Advanced Hunting's 30-day window cannot cover.

The XDR-Sentinel Relationship

Defender XDR is the detection plane — MDO, MDA, MDI, and MDE each generate their own alerts and aggregate them into XDR incidents (Chapter 14). Advanced Hunting covers 30 days.

Sentinel is the aggregation and analytics plane — it ingests XDR incidents plus additional log sources, applies analytics rules beyond what XDR provides, stores logs for 90 days hot plus configurable cold retention spanning years, and hosts workbooks and SOAR playbooks.

In practice, security analysts use both: the XDR incidents queue for day-to-day response, and Sentinel for threat hunting across longer time windows, compliance reporting, and cross-workload correlation rules.

Sentinel Workspace Setup

Deployment in Azure Government (GCC High) vs. Commercial

	GCC High	Commercial
Azure portal	portal.azure.us	portal.azure.com
Log Analytics endpoint	*.ods.opinsights.azure.us	*.ods.opinsights.azure.com
Sentinel region	usgovvirginia or usgovtexas	Any supported Azure region
Defender XDR connector	Available	Available

Steps to create a Sentinel workspace:

1. Azure portal → Create a resource → Microsoft Sentinel
2. Create a new Log Analytics workspace (or attach to existing) — use the same region as your Defender for Endpoint and Azure Government resources
3. Add Microsoft Sentinel to the workspace
4. In GCC High: ensure the workspace is in an Azure Government subscription, not a commercial subscription

Recommended Workspace Architecture

Use a single workspace per tenant for most organizations ingesting less than 100 GB/day. Multi-workspace architectures are appropriate only when compliance requirements or data residency mandates separating workload types.

Data Connectors

Connect the following sources immediately after workspace creation.

Priority 1 — Microsoft Security Products

Connector	What It Ingests	How to Connect
Microsoft Defender XDR	All XDR incidents, alerts, advanced hunting data, raw event tables (EmailEvents, DeviceProcessEvents, IdentityLogonEvents, etc.)	Sentinel → Data connectors → Microsoft Defender XDR → Connect
Microsoft Entra ID	Sign-in logs, audit logs, provisioning logs, risk events	Sentinel → Data connectors → Microsoft Entra ID → Connect
Microsoft 365	Exchange/SharePoint/Teams audit events, DLP alerts	Sentinel → Data connectors → Microsoft 365 → Connect
Azure Activity	Azure control plane operations (resource creation, deletion, RBAC changes)	Sentinel → Data connectors → Azure Activity → Connect
Microsoft Defender for Cloud	Azure resource security alerts	Sentinel → Data connectors → Microsoft Defender for Cloud → Connect

Priority 2 — Infrastructure

Connector	What It Ingests
Azure Firewall	Network traffic logs, threat intelligence hits, IDPS alerts
Azure Key Vault	Key access and management audit events
Azure Storage Account	Storage access logs for sensitive data stores
Windows Security Events	Windows Event Log from on-premises servers (via AMA agent)

Priority 3 — Non-Microsoft Sources

Use the Syslog and CEF connectors for:

• On-premises firewalls (Palo Alto, Fortinet, Check Point)
• Network devices
• Linux servers
• Any source that can forward syslog

Content Hub Solutions

The Microsoft Sentinel Content Hub is a marketplace of packaged solutions that deploy analytics rules, hunting queries, workbooks, and playbooks as a single unit. Rather than manually enabling individual rule templates, Content Hub solutions provide curated, compliance-aligned packages maintained by Microsoft.

Deploying the Microsoft Sentinel CMMC 2.0 Solution

The Microsoft Sentinel: CMMC 2.0 solution packages the analytics rules, hunting queries, and the CMMC workbook required to map Sentinel detections to NIST SP 800-171 controls. This is the recommended starting point for any GCC High deployment targeting CMMC Level 2 compliance.

Deployment steps:

1. Sentinel → Content management → Content hub
2. Search for CMMC 2.0
3. Select the solution → Install
4. After installation, go to Analytics → Rule templates and enable the newly available CMMC-tagged rule templates
5. Go to Workbooks → find the CMMC Workbook → Save to your workspace

What the solution deploys:

Component	Description
Analytics rules	Pre-built KQL rules mapped to CMMC practice families (AU, AC, IR, SI, IA)
Hunting queries	Proactive threat-hunting queries aligned to CMMC control objectives
CMMC Workbook	Interactive dashboard showing compliance posture across connected data sources

Prerequisite for the CMMC Workbook: The workbook's compliance posture panels pull resource compliance data from Microsoft Defender for Cloud. Before the workbook will populate correctly, two prerequisites must be in place: (1) the NIST SP 800-171 regulatory compliance initiative must be assigned in Defender for Cloud → Regulatory Compliance, and (2) continuous export must be configured to route Defender for Cloud assessments to the Sentinel Log Analytics workspace. Without these, the compliance posture panels in the workbook will be blank.

The Content Hub solution does not replace the custom analytics rules documented below — it provides the CMMC-mapped baseline. Layer the custom rules on top to cover organization-specific detection gaps.

---

Analytics Rules

Analytics rules run KQL queries against ingested logs on a schedule and generate Sentinel incidents when thresholds are met.

Built-In Templates (Enable Immediately)

Sentinel ships with hundreds of analytics rule templates from Microsoft and the community. Enable at minimum:

Rule Template	Purpose
Sign-in from IP address associated with threat intelligence	Entra sign-in from known-bad IP
Multiple users signing in from the same IP	Credential stuffing detection
Rare user-agent	Unusual application accessing M365 APIs
New admin account creation	Detect unauthorized privilege escalation
Mass download from SharePoint	Data exfiltration signal
PIM elevation outside business hours	Suspicious privileged access
Multiple failed sign-ins followed by success	Brute force followed by successful compromise

Enable templates: Sentinel → Analytics → Rule templates → filter by data source → bulk enable.

Custom Analytics Rules — Examples

// GCC High: PIM activation outside business hours (ET)
AuditLogs
| where OperationName == "Add member to role in PIM completed (permanent)"
| extend ActivationHour = datetime_part("hour", TimeGenerated)
| where ActivationHour < 7 or ActivationHour > 19  // outside 7am-7pm ET
| project TimeGenerated, InitiatedBy, TargetResources, ActivationHour

// Conditional Access block spike — potential attack
SigninLogs
| where ResultType == "53003"  // CA block
| summarize BlockCount = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where BlockCount > 10
| project TimeGenerated, UserPrincipalName, BlockCount

// Sensitive label downgrade followed by external email
AuditLogs
| where OperationName == "SensitivityLabelUpdated"
| where parse_json(tostring(AdditionalDetails))["LabelEventType"] == "2"  // 2 = Downgrade
| join kind=inner (
    EmailEvents
    | where RecipientEmailAddress !endswith "@yourdomain.com"
    | where SentDateTime > ago(4h)
) on $left.UserId == $right.SenderFromAddress
| project TimeGenerated, UserId, SubjectLine=SubjectLine1

// External sharing: anonymous link creation or external guest invitation in SharePoint/Teams
// Maps to AC.L2-3.1.3 (CUI flow control) and MP.L2-3.8.7 (media sanitization / external sharing)
OfficeActivity
| where RecordType in ("SharePoint", "SharePointSharingOperation")
| where Operation in (
    "AnonymousLinkCreated",
    "AnonymousLinkUsed",
    "SharingInvitationCreated",
    "AddedToGroup"
)
| where TargetUserOrGroupType == "Guest" or Operation startswith "Anonymous"
| project TimeGenerated, UserId, Operation, ObjectId, SiteUrl, TargetUserOrGroupName

// Log tampering: audit log cleared (Windows Security and System logs) or diagnostic settings modified
// Maps to AU.L2-3.3.8 (protect audit information) and AU.L2-3.3.9 (limit audit management)
union
(
    SecurityEvent
    | where EventID in (1102, 104)  // 1102 = Security audit log cleared; 104 = System log cleared
    | project TimeGenerated, Computer, EventID, Activity, Account
),
(
    AzureActivity
    | where OperationNameValue =~ "Microsoft.Insights/diagnosticSettings/delete"
        or OperationNameValue =~ "Microsoft.Insights/diagnosticSettings/write"
    | where ActivityStatusValue == "Success"
    | project TimeGenerated, CallerIpAddress, Caller, OperationNameValue, ResourceId
)
| sort by TimeGenerated desc

Note on PIM and elevated privilege coverage: The existing PIM activation outside business hours rule above, combined with the built-in template "New admin account creation," satisfies the elevated privilege monitoring requirement for AC.L2-3.1.6 and IA.L2-3.5.3. No additional rule is required for that control family.

Workbooks

Sentinel workbooks are interactive dashboards built on Log Analytics queries. Use them for executive security reporting, compliance evidence preparation, and threat hunting visual analysis.

Recommended Built-In Workbooks

Workbook	Use
Microsoft Entra ID	Sign-in analysis, risky users, MFA status
Microsoft Sentinel Overview	Alert trends, incident volume, top threats
Azure Activity	Control plane changes to Azure resources
Zero Trust (TIC 3.0)	US Government-specific: TIC 3.0 compliance dashboard aligned to CISA guidance
Insecure Protocols	Legacy auth usage (NTLM, basic auth)
CMMC	CMMC practice family compliance posture (deployed via Content Hub — see above)

CMMC Workbook prerequisites: The CMMC workbook requires the NIST SP 800-171 initiative assigned in Defender for Cloud and continuous export configured to the Sentinel workspace. See the Content Hub Solutions section above for full prerequisites before saving this workbook.

The Zero Trust (TIC 3.0) workbook is specifically designed for US Government environments and maps Sentinel data to CISA's Trusted Internet Connections 3.0 framework — relevant for GCC High organizations subject to TIC reporting requirements.

SOAR Playbooks

Sentinel playbooks are Logic Apps that trigger automatically on incident or alert events.

Playbook	Trigger	Action
Enrich-IP-with-TI	New incident	Query threat intelligence for IPs in the incident; add verdict to incident
Block-AAD-User-on-High-Risk	High-severity Entra Identity Protection alert	Call Graph API to block sign-in for the risky user
Revoke-Sessions-on-PIM-Anomaly	PIM activation outside hours alert	Revoke all active sessions for the user via Graph API
Notify-SOC-on-MDE-Isolation	Device isolation action in MDE	Send Teams notification to SOC channel with device and analyst details
Post-Incident-to-ServiceNow	Incident created	Create a ServiceNow ticket (or Jira issue) with incident details

Create playbooks: Sentinel → Automation → Create → Playbook (Logic App designer). For GCC High, Logic Apps must use Azure Government Logic Apps (logic.azure.us endpoints).

Log Retention

Retention Tier	Cost	Query Performance	Use
Interactive (hot)	Higher	Fastest (Log Analytics)	Default for active investigation; 90-day default
Long-term (cold)	Lower	Slower (restore required)	CMMC 3-year audit retention; SOC 2 1-year
Archive	Lowest	Requires restore job	7+ year retention for regulatory requirements

Configure retention per table: Log Analytics workspace → Tables → [Table] → Manage table — set total retention period up to 12 years.

NIST SP 800-171 Rev. 2 does not specify a minimum log retention period, but NIST SP 800-171A (assessment guide) requires that audit records be retained "for an organization-defined time period." Industry practice for regulated organizations is 3 years. Set Log Analytics retention to 365 days hot plus 2 years archive at minimum.

SIEM — Compliance Control Mapping

GCC High (CMMC)

SIEM CMMC Control Mapping

NIST Control	Sentinel Capability
AU.L2-3.3.1 — Audit records	Sentinel ingests and retains audit logs from all connected sources (Entra, M365, Azure, Intune)
AU.L2-3.3.2 — Audit review	Analytics rules provide automated review; workbooks support periodic manual review
AU.L2-3.3.5 — Audit analysis	Custom KQL analytics rules correlate events across sources
AU.L2-3.3.7 — Audit retention	Long-term retention configured to 3+ years; audit records immutable in Log Analytics
IR.L2-3.6.1 — Incident response	Sentinel incidents provide the case management and evidence collection framework
IR.L2-3.6.2 — Incident reporting	Sentinel playbooks automate notification workflows to the security team and stakeholders
SI.L2-3.14.6 — Monitoring for unauthorized use	Behavioral analytics rules detect anomalous access patterns
SI.L2-3.14.7 — Identify unauthorized use	Entity behavior analytics (UEBA) profiles users and devices for deviation detection

For CMMC assessors, Sentinel provides the technical evidence that AU.L2-3.3.1 and AU.L2-3.3.2 are implemented: audit records exist, are being reviewed analytically, and are retained. Export Sentinel analytics rule configurations and workbook screenshots as part of the audit evidence package.

Commercial

NIST SP 800-171 Rev. 3 and SOC 2 Mapping

NIST SP 800-171 Rev. 3

Control	Sentinel Capability
3.3.1 — Audit records	Multi-source log aggregation with configurable retention
3.3.2 — Audit review	Analytics rules and workbooks for continuous and periodic review
3.3.5 — Audit analysis	KQL correlation rules across all log sources
3.14.6 — Monitoring	Behavioral detection rules; UEBA

SOC 2 Type II

Trust Service Criteria	Sentinel Implementation
CC7.2 — Monitoring for anomalies	Analytics rules detecting anomalous sign-ins, privilege changes, data access
CC7.3 — Evaluate security events	Sentinel incidents with automated enrichment and severity classification
CC7.4 — Respond to identified anomalies	SOAR playbooks for automated response; incident management workflow
A1.2 — Monitoring for availability	Azure resource health alerts ingested via Azure Monitor connector

For SOC 2 Type II audits, provide the auditor with: the analytics rule list (exported), 12 months of incident data (Sentinel incidents export), and workbook screenshots showing monitoring dashboards were actively used during the audit period.