SIEM Strategy

Microsoft Sentinel is a cloud-native SIEM and SOAR platform. While Defender XDR 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.

Why Sentinel for CMMC

CMMC Level 2 = NIST SP 800-171 Rev. 2's 110 practices. Three control families make a SIEM practically necessary:

• AU: Audit and Accountability (3.3.1 – 3.3.9). Create audit records, uniquely trace actions to users, review and correlate across sources, retain for the period your audit policy documents (NIST SP 800-171 sets none; this chapter plans three years and says so in the SSP), protect from tampering, and limit audit-management privileges. This is one evidence surface covering Entra, M365, Azure, and endpoints: not something you assemble from per-product log viewers at assessment time.
• IR: Incident Response (3.6.1 – 3.6.3). Operational incident handling with tracking and testing. Sentinel incidents and playbooks give assessors the case-management framework they expect, with automated evidence capture that raw ticket logs don't produce.
• SI: System and Information Integrity (3.14.6 – 3.14.7). Monitor for unauthorized use; identify anomalous access. Analytics rules and UEBA produce the behavioral evidence raw ingestion alone can't.

Sentinel isn't strictly required: any SIEM that aggregates across the boundary and retains immutably can pass, and Splunk, Elastic, and QRadar are viable in Azure Government. But for organizations already on M365 GCC High and Azure Government, Sentinel is the lowest-friction path:

• Native connectors for Entra ID, Microsoft 365, Azure Activity, and Defender XDR: no connector engineering.
• Log Analytics archive tier hits the 3-year retention expectation cheaply.
• Immutable audit storage and Azure RBAC satisfy AU.L2-3.3.8 (protect audit information) and AU.L2-3.3.9 (limit audit management) out of the box.
• CMMC-specific Content Hub solutions ship posture assessment rules and a compliance workbook: no custom authoring for the baseline assessment artifacts.

The rest of this chapter treats Sentinel as the choice; the conceptual deployment flow (connectors → posture rules → detection rules → retention) generalizes to other SIEMs, but the specific Content Hub solutions and Defender XDR unified-platform integration are Sentinel-only.

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. 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.

Sentinel Cost Planning

Sentinel costs are entirely consumption-based: no per-user license, just per-GB ingestion plus optional per-GB retention beyond the 90-day Analytics-tier default. The good news: for organizations already on M365 G5 (or the M365 G5 Security add-on), the practical cost can be near-zero if eligible benefits apply and high-volume tables are tuned. This section covers what's free, how Azure Government pricing differs, and two worked examples representing the most common GCC High customer shapes.

Free benefits: what you get without paying

Five distinct free programs apply, often stacking. Verify the eligibility and billing treatment of each before estimating cost:

Benefit	Allowance	Eligibility	Reference
Always-free data sources	Unlimited for in-scope sources	Every Sentinel workspace	Free data sources
Sentinel-enabled retention extension	90 days Analytics-tier (hot) retention free per table, vs. 31 days for Log Analytics workspaces without Sentinel	Sentinel enabled on the workspace	Sentinel costs and billing
Microsoft 365 E5/A5/F5/G5 benefit	5 MB / user / day for select Microsoft sources (Microsoft Entra ID, Microsoft Defender XDR / Office 365 / Endpoint / Identity / Cloud Apps, Microsoft 365)	M365 E5/A5/F5/G5 or M365 E5 Security add-on per eligible user	Microsoft Sentinel benefit for Microsoft 365 E5, A5, F5, G5 customers
Defender for Servers Plan 2 data ingestion benefit	500 MB / server / day for eligible security tables	Defender for Servers P2 enabled in Defender for Cloud on the workspace	Use the data ingestion benefit
31-day free trial	First 10 GB/day free for 31 days (up to 20 workspaces per tenant)	Newly-enabled Sentinel workspaces	Free trial

Always-free sources include Azure Activity Logs, Sentinel Health, Office 365 Audit Logs (SharePoint / Exchange admin / Teams), and security alerts from Microsoft Defender XDR, Defender for Cloud, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Defender for Endpoint. Note the distinction: alert summaries from those products are free; the raw logs underlying them (DeviceProcessEvents, EmailEvents, etc.) are paid ingestion.

Azure Government pricing notes

Same SKUs, same free benefits, roughly 25% higher per-GB rate to fund Gov ATO infrastructure. Recent observed Azure Government PAYG is approximately $5.38 / GB for Sentinel + Log Analytics combined, versus approximately $4.30 / GB for Azure commercial East. There is no Gov-specific Sentinel SKU. Use the Sentinel pricing page and Defender for Cloud pricing page with the US Gov region selector for tenant-accurate quotes. Commitment tiers are available starting at 100 GB/day and reduce per-GB cost substantially when sustained volume justifies the commitment.

Figures observed in our engagements

The ingestion mixes, per-table volumes, and cost figures throughout this cost-planning section are drawn from real GCC High deployments we've run. They illustrate the shape of the problem (which tables dominate volume and where the cost levers are), not a quote for your tenant. Your numbers will vary with user count, server count, connector mix, and which detection rules you run. Price against the Sentinel pricing page with the US Gov region selector for tenant-accurate figures.

Worked example: small Entra-focused GCC High customer

A representative small GCC High customer (≈100 users, mostly G5; no on-prem servers; Entra + Defender connectors only) running Sentinel for 90 days produced this ingestion mix:

Table	GB / 90 days	% of total
AADNonInteractiveUserSignInLogs	11.4	61%
MicrosoftGraphActivityLogs	6.5	35%
AuditLogs + SigninLogs + provisioning + risk events	0.7	4%
Total	18.6 GB	100%

The table totals 18.6 / 90 = 0.207 GB/day, or 6.2 GB per 30-day month. At the illustrative $5.38/GB rate, gross ingestion is $33.36/month, before free sources, eligible grants, and other charges.

For 100 eligible G5 users the grant is 0.5 GB/day, but only for the tables the offer lists. Both Entra rows are on the list, so their 12.1 GB over 90 days (0.134 GB/day) is covered in full. MicrosoftGraphActivityLogs is not on the list, so its 6.5 GB over 90 days stays billable: about $11.66/month at the illustrative rate. That is this profile's bill once the grant applies; the lever is the Graph activity log diagnostic setting, not the grant.

AADNonInteractiveUserSignInLogs is the biggest row, but it is inside the grant, so turning it off saves nothing for a G5 tenant. It matters only without the grant (a non-G5 tenant, or more eligible volume than seats cover). The table holds non-interactive user sign-ins (token refreshes, silent renewals); service-principal sign-ins have their own table, AADServicePrincipalSignInLogs. Removing it loses the refresh-token trail that several identity detections read, so check the analytics rules that query it before changing collection. Price long-term retention separately: 90 days of Analytics-tier retention is free on a Sentinel workspace, and anything past that is a retention charge at the tier you choose.

Worked example: mid-sized GCC High enclave with Defender for Servers

A mid-sized CMMC enclave (100 M365 E5 users, 50 on-premises Windows Servers, full Defender + firewall + Intune connectors) has substantially more free allowance because the per-server benefit kicks in:

Free source	Calculation	Daily allowance
Always-free data sources	Azure Activity, O365 audit, security alerts	≈few GB/day variable
M365 E5 benefit	100 users × 5 MB/day	500 MB/day
Defender for Servers P2 benefit (if adopted)	50 servers × 500 MB/day	25 GB/day
Total free allocation		≈25–30 GB/day

The two allowances do not pool. The server allowance (25 GB/day here) pays only for the server tables Learn lists: SecurityEvent, WindowsEvent (security stream only), SecurityAlert, SecurityBaseline, SecurityDetection, WindowsFirewall, ProtectionStatus, Update, MDCFileIntegrityMonitoringEvents, and the two DeviceCustom* tables. The MDE tables that dominate a fully instrumented enclave (DeviceProcessEvents, DeviceNetworkEvents, DeviceEvents, and the rest) are on the Microsoft 365 E5 list instead, where 100 users buy 0.5 GB/day. So 30 to 60 GB/day of total ingestion does not become a near-zero bill: price each table against the list it belongs to, per day, under the workspace's billing model.

Why P2 is the right server-licensing choice when Sentinel is in scope

Defender for Servers Plan 2 pays for itself only when the servers' eligible paid ingestion exceeds the license premium: at the illustrative Gov rate the break-even against Plan 1 is about 3 GB/day of eligible data across a 50-server fleet, and the allowance applies only to the eligible security tables and only in the workspace each server reports to. The worked calculation (a 50-server license comparison, the break-even arithmetic, and the with-and-without Plan 2 numbers) and its three caveats are on the web edition at docs.mindline.com/docs/m365security/siem-strategy#why-p2-is-the-right-server-licensing-choice-when-sentinel-is-in-scope; the server-licensing matrix is in the Defender for Endpoint chapter.

Plan 2 can cost less overall when savings on eligible ingestion exceed the license premium. The following is an illustrative calculation at 50 servers, not a universal recommendation:

	Per-server/mo	50 servers × 12 mo	Sentinel ingestion benefit
MDE for Server standalone	$3	$1,800	None
Defender for Servers P1	$5	$3,000	None
Defender for Servers P2	$15	$9,000	500 MB / server / day

The license premium for P2: $6,000/year over P1 ($500/month for 50 servers); $7,200/year over standalone ($600/month for 50 servers).

Maximum usable allowance: 50 servers x 0.5 GB/day = 25 GB/day, or 750 GB in a 30-day month. At the illustrative $5.38/GB unified rate, the maximum avoided charge is $4,035/month, but only when that much otherwise-billable eligible data is collected each day.

Break-even against P1: $500 / $5.38 = 92.94 GB/month of eligible ingestion, about 3.10 GB/day across the fleet. Count actual qualifying bytes, not total MDE telemetry. Microsoft's current benefit rules distinguish classic meters (Log Analytics ingestion only) from unified meters (Sentinel ingestion). They do not make every DeviceProcessEvents, DeviceNetworkEvents, or arbitrary Windows event row eligible for the server grant.

Worked numbers assuming 300 MB/server/day of otherwise-billable eligible data and unified meters:

	Without P2 (P1 + PAYG)	With P2
License cost	$250/month (P1, 50 × $5)	$750/month (P2, 50 × $15)
Sentinel ingestion at Gov PAYG (50 × 300 MB/day = 450 GB/month × $5.38)	$2,421/month	$0/month (within 25 GB/day allowance)
Total monthly	$2,671/month	$750/month
Annual delta		P2 saves ≈$23,000/year

When this argument doesn't apply

Three caveats:

1. No eligible paid ingestion = no ingestion savings. The allowance is a Log Analytics workspace benefit, so it applies with or without Sentinel, but it only saves money on eligible bytes that would otherwise be billed. If the fleet sends little to the listed tables, the $6,000/year premium over Plan 1 has to stand on the Plan 2-only features: agentless scanning (vulnerabilities, malware, secrets), premium Defender Vulnerability Management (baselines assessment, blocking vulnerable applications, browser extension and certificate assessment), file integrity monitoring, just-in-time machine access, and OS configuration assessment against the compute baselines. Regulatory compliance assessment is not a differentiator; it comes with any paid plan. Whether that list is worth $6,000/year depends on whether the customer would otherwise buy equivalent tooling separately.
2. Eligible tables only. The 500 MB/server/day applies to a defined list of eligible security tables, not arbitrary Sentinel ingestion. Do not infer eligibility merely from a security-related table name; check the documented list and collection stream.
3. Workspace placement matters. The benefit is applied to the Log Analytics workspace where each server reports. If servers report to a different workspace than the one where Sentinel is enabled, the benefit doesn't connect to the Sentinel ingestion bill. Verify single-workspace alignment before promising the cost flip in a CAB submission.

For the underlying server-licensing comparison and the recommendation matrix that distinguishes Sentinel-adopting customers from EDR-only customers, see Defender for Endpoint § Licensing.

Activating the M365 E5/G5 benefit

The M365 offer applies automatically: there is no sign-up and no workspace toggle. Eligibility is the license and the agreement: an eligible SKU per user (the offer's FAQ lists E5_USGOV_GCCHIGH and E5 Security_USGOV_GCCHIGH alongside the commercial E5 SKUs) and an Enterprise Agreement, Enterprise Subscription, or Cloud Solution Provider agreement. Confirm it is landing three ways: the Usage and estimated costs page of the Log Analytics workspace prints a sentence under the cost table giving the benefit volume used over the last 31 days; the Cost Management usage export shows the meter Free Benefit - M365 Defender Data Ingestion (service Azure Monitor) against the workspace; and the Operation table carries a daily row per benefit, Detail starting Benefit amount used: and OperationKey starting Benefit type used:, which the Learn query under View data allocation benefits charts. If none of the three shows the grant after eligible data has been ingested for a day, the problem is entitlement or the agreement, not a switch.

The server benefit is separate: Defender for Servers P2 must be enabled on the reporting workspace. Confirm the actual benefit in usage exports before promising savings.

Cost optimization patterns

In rough order of leverage:

Pattern	Typical impact	When to apply
Verify automatic M365 E5/G5 benefit	Reduces eligible ingestion up to the daily grant	Check actual entitlement and metered usage
Review non-interactive user sign-in collection	Depends on measured volume	Retain required detection and investigation coverage before reducing collection
Move high-volume noisy tables to Auxiliary or Basic log tier	70–90% per-GB reduction on those tables	High-volume telemetry that must be retained but isn't queried real-time (raw network logs, verbose process telemetry)
Adopt commitment tier (100 GB/day+)	25–60% per-GB reduction	Workspace ingesting >100 GB/day sustained for 30+ days
Long-retention to Sentinel data lake tier	Substantial reduction on cold storage	Compliance retention requirements beyond the 90-day Analytics-tier free window

Deployment at a Glance

This chapter covers two phases: one-time Workspace Setup and sequential Content Deployment.

Workspace Setup: Azure Government infrastructure to host Sentinel:

Substep	Output
1. Create resource group (skip if reusing a workspace)	rg-sentinel-prod-usgovva exists
2. Create or reuse the Log Analytics workspace	law-sentinel-prod-usgovva exists, or an existing tenant workspace is designated
3. Add Microsoft Sentinel	Sentinel blade is operational
4. Verify sovereign-cloud alignment	Workspace confirmed in USGov region
5. Connect the workspace to the Defender portal	Defender XDR ↔ Sentinel incident/alert sync is active

Content Deployment: seven sequential steps from bare workspace to compliance-ready SIEM:

Step	Produces
1. Install Content Hub solutions	Data connector cards appear in the connectors list
2. Configure each data connector	Telemetry flowing (SigninLogs, OfficeActivity, AzureActivity, etc.)
3. Enable CMMC 2.0 posture assessment	Defender for Cloud prereqs complete; CMMC posture rule templates created
4. Save workbook templates	Tier 1 workbooks + CMMC 2.0 workbook saved and parameterized
5. Demonstrate immediate operation	Eight shared KQL queries produce compliance-evidence screenshots
6. Verify NIST 800-171 data arrival	SecurityRegulatoryCompliance returns NIST rows; CMMC workbook tiles and posture rules now fully operational
7. Enable detection rule templates	Threat-detection analytics rules active from product solutions

Step 3 triggers a 12–24h Defender for Cloud assessment pass, but the only things gated by that wait are CMMC workbook tile rendering and first-fire of the CMMC posture rules, both verified in Step 6. Steps 4 and 5 proceed immediately and produce the full client-demo deliverable without waiting.

Sentinel Workspace Setup

Portal differences: 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

Workspace creation steps

1. Create the resource group

Reuse check first: Sentinel is enabled on a Log Analytics workspace, so if the tenant already has one (e.g., law-avd-usgovva from AVD Runbook Step 5, or any workspace already collecting Entra, M365, or Defender telemetry), do not create a second one. Skip substeps 1 and 2, substitute the existing workspace's name everywhere this chapter says law-sentinel-prod-usgovva, and resume at substep 3. One workspace for both operational and security data is the right call at this scale: analytics rules can only see data in the Sentinel-enabled workspace, the Defender for Servers ingestion benefit only connects when servers report to that same workspace, and Sentinel's 90-day Analytics-tier retention beats the 31-day non-Sentinel default. The trade-off to know: Sentinel pricing applies to data ingested into the enabled workspace, including operational tables like AVD performance counters (billing); at enterprise ops-data volumes that argues for a dedicated workspace, but not at this book's scale.

For a greenfield deployment with no existing workspace, proceed: all Sentinel-related resources (the Log Analytics workspace, the Sentinel solution, any automation account, and later data-collection rules) live in a single resource group scoped to the Azure Government subscription.

1. Azure portal (portal.azure.us for GCC High) → Resource groups → Create.
2. Subscription: select the Azure Government subscription tied to the GCC High tenant.
3. Resource group name: use a standard naming convention that encodes purpose, environment, and region:
   • rg-sentinel-prod-usgovva (Virginia)
   • rg-sentinel-prod-usgovtx (Texas)
4. Region: USGov Virginia or USGov Texas: must match the region you will use for the Log Analytics workspace and must be an Azure Government region, not a commercial region.
5. Click Review + create → Create.

2. Create or reuse the Log Analytics workspace

The workspace is where Sentinel stores all ingested log data. Reusing an existing workspace? Confirm it lives in an Azure Government region (USGov Virginia or USGov Texas), apply the retention plan from item 7 of the list below to it, and skip ahead to substep 3. Otherwise, create the workspace inside the resource group created in the previous step.

1. Azure portal → Log Analytics workspaces → Create.
2. Subscription: same Azure Government subscription.
3. Resource group: select the resource group from the previous step (e.g., rg-sentinel-prod-usgovva).
4. Name: use a naming convention that pairs with the resource group:
   • law-sentinel-prod-usgovva
5. Region: same region as the resource group. This determines where log data is stored at rest: for GCC High this must be an Azure Government region.
6. Pricing tier: Per-GB (default). Commitment tiers are available at 100 GB/day and above; evaluate after 30 days of ingestion data.
7. Retention: workspace default is 30 days. CMMC audit requirements typically call for 3 years: plan on 365 days hot plus 2 years archive as the baseline. See Log Retention for the per-table configuration model; the workspace default can stay at 30 days for now and be tuned per-table once ingestion is live.
8. Click Review + create → Create.

3. Add Microsoft Sentinel to the workspace

Sentinel is an overlay on top of Log Analytics: it adds the incidents queue, analytics rules, data connectors, content hub, SOAR playbooks, and workbooks.

1. Azure portal → Microsoft Sentinel → Create (or Add).
2. Select the Log Analytics workspace from the previous step: the one you created (e.g., law-sentinel-prod-usgovva) or the existing tenant workspace you're reusing.
3. Click Add. Sentinel provisions in under a minute. Once complete, the Sentinel blade opens with an empty workspace ready for data connectors.

4. Verify sovereign-cloud alignment

Before connecting any data, confirm the workspace is in the correct cloud. The Sentinel workspace overview has moved from the Azure portal to the Defender portal:

1. Open the Defender portal: security.microsoft.us/sentinelsettings/siem-workspace?tid=[YOUR-TENANT-ID] (replace [YOUR-TENANT-ID] with your GCC High tenant ID).
2. Confirm the workspace Region shows an Azure Government region (USGov Virginia or USGov Texas), not a commercial region.
3. Confirm the Subscription shows your Azure Government subscription, not a commercial subscription.
4. If either check fails, the workspace was created in a commercial subscription or region: delete it and start over. A commercial workspace cannot ingest GCC High log data.

5. Connect the workspace to the Defender portal

This step is required plumbing even though this chapter's instructions run in the Azure portal: the Microsoft Defender XDR incident and alert sync (the first connector you'll rely on in Content Deployment) flows through the Defender portal workspace connection, not through a traditional connector card. Workspaces onboarded to Sentinel after July 1, 2025 are auto-connected "in many cases," but auto-onboarding explicitly excludes Azure Lighthouse-delegated users (Microsoft), so partner-managed (CSP/Lighthouse) deployments should always expect to run it manually. The unconnected symptom: a "Get your SIEM and XDR in one place / Connect a workspace" banner on the Defender portal home page.

1. In the Defender portal, go to System → Settings → Microsoft Sentinel → Connect a workspace (or use the home-page banner's Connect a workspace button).
2. Select the workspace, mark it as the Primary workspace, review the product changes, and select Connect (connect Sentinel to the Defender portal).

Why this chapter's day-to-day navigation uses the Azure portal

Substeps 4 and 5 above are this chapter's two deliberate Defender-portal exceptions: one-time plumbing that lives on the Defender portal's settings surface (System → Settings → Microsoft Sentinel), which renders for the deploying admin even when the Sentinel operational menus do not. Everything operational from here on (Content hub, data connectors, workbooks, KQL) navigates the Azure portal instead. The reason: Sentinel's menus in the Defender portal render only for accounts holding directly assigned Azure RBAC (Microsoft Sentinel Reader or higher); Microsoft states GDAP/Azure Lighthouse delegation is not supported for Sentinel data there (prerequisites). In partner-delivered GCC High deployments, that reliably means a connected, healthy workspace whose Sentinel navigation simply never appears for the deploying consultant. The Azure portal's Sentinel experience renders for every properly authorized identity, delegated or direct, so this chapter uses it throughout: Azure portal → Microsoft Sentinel → [workspace], with the same Threat management / Content management / Configuration menu structure. Plan around the horizon: Microsoft Sentinel in the Azure portal retires March 31, 2027 (retirement notice), so tenant-member accounts with direct RBAC should adopt the Defender portal surface before then.

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.

Sentinel Content Deployment

After workspace creation, deploy Sentinel content in six steps: install Content Hub solutions, configure data connectors, enable CMMC 2.0 posture assessment, save workbook templates, demonstrate operation, and enable detection rule templates.

The Sentinel data connectors page is at Azure portal → Microsoft Sentinel → [workspace] → Configuration → Data connectors (portal.azure.us for GCC High). A fresh workspace shows only the pre-installed Microsoft 365 Insider Risk Management (Preview) connector. The remaining connectors are installed via Content Hub solutions: each solution bundles its data connector, analytics rules, hunting queries, and workbooks as a single package.

Step 1: Install Content Hub solutions

Content Hub solutions deploy the data connectors you need. Install solutions before attempting to configure individual connectors: the connectors do not appear in the Data connectors list until their parent solution is installed.

Navigate to Azure portal → Microsoft Sentinel → [workspace] → Content management → Content hub. (The same page exists in the Defender portal under Microsoft Sentinel → Content management for accounts with direct RBAC: see the note in Workspace Setup substep 5.)

Install the following solutions in priority order:

Priority 1: Microsoft Security Products

Content Hub Solution	Connector it installs	What it ingests
Microsoft Defender XDR	Microsoft Defender XDR	All XDR incidents, alerts, advanced hunting data, raw event tables (EmailEvents, DeviceProcessEvents, IdentityLogonEvents, etc.)
Microsoft Entra ID	Microsoft Entra ID	Sign-in logs, audit logs, provisioning logs, risk events
Microsoft 365	Microsoft 365	Exchange/SharePoint/Teams audit events, DLP alerts
Azure Activity	Azure Activity	Azure control plane operations (resource creation, deletion, RBAC changes)
Microsoft Defender for Cloud	Microsoft Defender for Cloud	Azure resource security alerts

Priority 2: Infrastructure

Content Hub Solution	Connector it installs	What it ingests
Azure Firewall	Azure Firewall	Network traffic logs, threat intelligence hits, IDPS alerts
Azure Key Vault	Azure Key Vault	Key access and management audit events
Azure Storage	Azure Storage Account	Storage access logs for sensitive data stores
Windows Security Events	Windows Security Events via AMA	Windows Event Log from servers (via Azure Monitor Agent)

Priority 3: Non-Microsoft Sources (Syslog / CEF)

Content Hub Solution	Connector it installs	What it ingests
Common Event Format	CEF via AMA	On-premises firewalls (Palo Alto, Fortinet, Check Point), network devices that emit CEF-formatted logs
Syslog	Syslog via AMA	Linux servers, appliances with raw syslog output, any source that can forward syslog

Both solutions install a data connector whose configuration pane walks through AMA installation, Linux forwarder deployment, and Data Collection Rule creation. Install the solution first, then configure the connector in the Data connectors blade.

Common sources routed through CEF or Syslog:

• On-premises firewalls (Palo Alto, Fortinet, Check Point, SonicWall)
• Network devices (switches, routers, wireless controllers)
• Linux servers
• Any appliance that can forward syslog or CEF

For all Content Hub solutions: select the solution → Install → wait for installation to complete before moving to the next.

Step 2: Configure each data connector

After the Content Hub solutions are installed, the connectors appear in Microsoft Sentinel → Configuration → Data connectors. Each connector now shows a status of Not connected. Open each connector and follow its configuration pane:

1. Microsoft Defender XDR: in the unified Defender portal, this often does not appear as a connector card in the Data connectors blade. The Sentinel-to-Defender integration is handled through the platform unification rather than through a traditional data connector. If your Sentinel workspace shows Connected under the Defender portal's Microsoft Sentinel settings, XDR incident and alert sync is already active through the unified platform: no connector configuration required.

   To verify:

   • Defender portal → System → Settings → Microsoft Sentinel: confirm your workspace shows as Connected.
   • Once at least one XDR workload (MDE, MDO, MDI, or MDCA) is onboarded, run SecurityIncident | take 10 and SecurityAlert | take 10 in Sentinel → Logs to confirm data is flowing.

   If you do see a Microsoft Defender XDR connector card (older tenants or certain configurations may still show it), open it and click Connect incidents & alerts. That connection is free: SecurityIncident and SecurityAlert ingest at no charge (Sentinel billing). Every raw event table checkbox below it is billable, and the same telemetry stays queryable in Defender advanced hunting for 30 days regardless (XDR integration): ingestion buys longer retention and Sentinel-side correlation, not visibility. CMMC's audit-record requirements are carried by the free OfficeActivity table and the Entra logs, not by raw EDR telemetry, so a cost-conscious greenfield baseline enables 7 of the 21 tables unfiltered, plus DeviceEvents behind a filter:

   Connector group	Enable	Rationale
   Microsoft Defender Alerts	AlertInfo, AlertEvidence	Tiny volume; KQL-joinable alert detail that SecurityAlert's JSON blobs make painful. Best value on the page.
   Defender for Endpoint	DeviceInfo, DeviceNetworkInfo, DeviceLogonEvents; DeviceEvents behind the App Control filter below	Low-volume asset inventory context plus the endpoint authentication trail (3.1.7 / 3.3.2 monitoring value), and the App Control decision events that only DeviceEvents carries (3.4.8). Leave the other six high-volume tables (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceImageLoadEvents, DeviceFileCertificateInfo) off; enable one temporarily during an incident if you need more than 30 days of it.
   Defender for Office 365	EmailEvents, UrlClickEvents	One row per message plus click telemetry covers phishing triage, the most common incident class. The three enrichment tables stay in the Defender portal.
   Defender for Cloud Apps	none	CloudAppEvents substantially duplicates the free OfficeActivity table: the classic Sentinel cost mistake.
   Defender for Identity	none (cloud-only)	These tables only populate from an on-premises MDI sensor. Hybrid tenants: add IdentityLogonEvents.

   DeviceEvents is the only table in this connector that carries the App Control for Business decision events the Open Intune Baseline Deployment chapter relies on for CM.L2-3.4.8 (Authorized Software: Deny by Exception). It is high-volume, so it enters the baseline behind a transformation that keeps the four decision action types. The filter is free on Analytics tables in a Sentinel workspace, and what lands counts toward the G5 grant. The full reasoning and the Defender-portal Filter rule alternative are on the web edition:

   Why DeviceEvents is in the list, and only behind a filter. The App Control for Business audit and block events that the Open Intune Baseline Deployment chapter works in Advanced Hunting reach Sentinel through the DeviceEvents table and nothing else in this connector; without it, Sentinel holds no App Control record and the CM.L2-3.4.8 (Authorized Software: Deny by Exception) monitoring evidence expires with Advanced Hunting's 30-day window. The table is high-volume, though: it also carries antivirus, exploit-protection, and attack-surface-reduction telemetry, and Microsoft publishes no per-device figure for it. So it enters the baseline behind a transformation that keeps the four decision action types and drops everything else, the 3092 native-image storm included:

   source
   | where ActionType in ("AppControlCodeIntegrityPolicyAudited", "AppControlCodeIntegrityPolicyBlocked", "AppControlCIScriptAudited", "AppControlCIScriptBlocked")

   Three billing facts make the result close to free. Dropping most of a table normally incurs a data-processing charge; Learn waives it for Analytics tables in a Sentinel-enabled workspace "regardless of how much data the transformation filters" (transformation costs). What lands counts toward the Microsoft 365 G5 grant, whose eligible sources include Microsoft 365 advanced hunting data (offer); the 100-user tenant in the worked example above has about 0.3 GB/day of that pool unused. The Defender for Servers Plan 2 allowance does not apply, since its eligible list is SecurityEvent, the Security stream of WindowsEvent, and the baseline, update, and custom file and registry tables (data ingestion benefit): a session-host fleet earns no server credit here. Apply the filter as a workspace transformation on the table (create a transformation) or, with no DCR authoring, as a Filter rule on the table under Microsoft Sentinel → Configuration → Tables in the Defender portal, where the condition is written the other way round, true for the rows to discard (ActionType !in (...)) (filter and split transformations). That rule was not verified in GCC High at the time of writing; confirm it exists in your tenant before relying on it. Transformations take up to an hour to apply, Advanced Hunting keeps showing the unfiltered table for its own 30 days, and the Usage query below tells you what the table costs: keep it on only if that number is what you expected.

   Review the decision after 30 days from Azure portal → Microsoft Sentinel → [workspace] → Logs:

   Usage
   | where TimeGenerated > ago(30d)
   | summarize IngestedGB = sum(Quantity) / 1024 by DataType
   | order by IngestedGB desc

   If EmailEvents dominates and nobody has hunted in it, turn it off; if an incident left you wishing for process history past 30 days, add DeviceProcessEvents knowingly.

   Note: this connector only produces data once at least one XDR workload is onboarded. On a fresh workspace with no XDR workloads, the SecurityIncident and SecurityAlert tables will not exist yet: this is expected, not a configuration error.

2. Microsoft Entra ID: select which log categories to enable: Sign-in logs, Audit logs, Non-interactive sign-in logs, Service principal sign-in logs, Managed identity sign-in logs, Provisioning logs, ADFS sign-in logs (if applicable), and Risky users / Risk detections (requires Entra ID P2). Enable all categories relevant to your CMMC evidence requirements. Data appears within 5 minutes: validate with SigninLogs | take 10.

3. Microsoft 365: select workloads: Exchange, SharePoint, Teams. Enable all three for CMMC audit coverage. M365 audit logs can take 15–30 minutes to appear. Validate with OfficeActivity | take 10. (UEBA is not configured on this connector: it is enabled once from Sentinel's settings, covered in the UEBA note below.)

4. Azure Activity: this connector may not appear as a card in the Data connectors blade. Configure it directly through subscription diagnostic settings:

   1. Azure portal → Subscriptions → select your Azure Government subscription.
   2. Activity log (left nav) → Export Activity Logs (or Diagnostic settings).
   3. Click Add diagnostic setting.
   4. Name: diag-activity-to-sentinel.
   5. Under Category details, check all categories: Administrative, Security, ServiceHealth, Alert, Recommendation, Policy, Autoscale, ResourceHealth.
   6. Under Destination details, check Send to Log Analytics workspace → select your Sentinel workspace.
   7. Click Save.
   8. Data starts flowing within 5–10 minutes. Validate with AzureActivity | take 10: resource group and workspace creation events from the current session should appear.

5. Microsoft Defender for Cloud: no configuration is needed for alerts, and there is no bi-directional sync option to look for. With the workspace connected to the Defender portal (Workspace Setup substep 5), Defender for Cloud alerts arrive through the unified Defender XDR integration, and incident-status synchronization is native to the unified platform; the bi-directional sync toggle exists only on the Azure-portal connector page for workspaces that are not onboarded (prerequisites). If a Subscription-based Microsoft Defender for Cloud (Legacy) connector card appears, leave it disconnected: enabling it alongside the unified path produces duplicate alerts (duplicate-prevention guidance). Still required: the Continuous export configuration on the subscription (Step 3, Prereq 3 below), which is what populates the SecurityRegulatoryCompliance table the CMMC workbook depends on; the unified alert path does not carry compliance data.

6. Azure Firewall: configure via Azure Firewall diagnostic settings pointing to the Sentinel workspace. Send both Azure Firewall Application Rule Logs and Azure Firewall Network Rule Logs.

7. Infrastructure connectors (Key Vault, Storage, Windows Security Events): each uses diagnostic settings or Data Collection Rules (DCRs) pointing to the workspace. Follow the configuration pane for each. For Windows Security Events via AMA, scope the data collection rule the pane creates to the AVD session hosts and any Windows servers, and pick the Custom event set with the XPath Security!*[System[(EventID=1102)]]: event 1102 (Security log cleared) is the Windows half of the log-tampering rule below, and it lands in SecurityEvent. The Minimal set also carries 1102 but adds 4624, 4625, and 4688 volume per host that the Defender for Servers allowance does not cover on a client OS (Windows security event sets). Event 104 (System log cleared) is a System-log event that no security event set carries; Chapter 11-6 adds it to the session-host data collection rule, where it lands in Event.

Use the Logs blade for KQL, not a portal search bar

Run every KQL block in this chapter from Azure portal → Microsoft Sentinel → [workspace] → Logs (or Log Analytics workspace → Logs, the same editor). The Defender portal's top-level search bar is a global navigation search, not a KQL surface: it will mangle your queries.

After connecting, allow 15–30 minutes for initial data to appear. Each connector bullet above names the table to validate against; use those per-connector | take 10 queries rather than a workspace-wide scan.

Microsoft 365 connector: what each workload covers

The connector exposes three workload checkboxes (Exchange, SharePoint, Teams), but they don't map 1:1 to the products users see. This table makes the routing explicit so you can answer client questions about coverage before they ask:

Workload checkbox	What lands in OfficeActivity	What does NOT come through this pipe
Exchange	Mailbox audit events, mail flow rules, transport changes, role assignments, eDiscovery actions, MFA-on-mailbox events	Message tracking (separate Get-MessageTrace stream); raw mail content (eDiscovery only)
SharePoint	SharePoint site operations plus OneDrive activity: file access, sharing changes, sync operations, permission grants, anonymous link creation. OneDrive does not have its own checkbox; it rides on the SharePoint workload as OfficeActivity | where Workload == "OneDrive".	Full file content scanning (Purview DLP / auto-labeling, not OfficeActivity)
Teams	Team / channel create-modify-delete, member adds and removes, federation events, app installs, settings changes, guest invites: OfficeActivity | where Workload == "MicrosoftTeams"	Chat message content (Microsoft Graph Export API or eDiscovery hold only); call records (Graph callRecords API); call quality (Call Quality Dashboard)

For CMMC L2 audit / control evidence the three checkboxes together are sufficient: they cover the "who did what to which CUI workload" questions an assessor asks. Teams chat content and call records are out of scope for CMMC L2 by default; ingest them via the relevant Graph APIs as a separate workstream only if a contractual flow-down or insider-risk policy explicitly requires them.

Common omissions worth raising with clients

The M365 + Defender + Azure Activity connectors cover most of the CMMC L2 audit surface, but a few signals clients sometimes assume are in Sentinel by default actually require additional ingestion. Confirm which of these the client expects to query in Sentinel before locking down the connector list: each one missing from the assumed list is an SSP-narrative gap that surfaces during audit scoping.

Source	How to ingest if needed
Power Platform audit logs (Power Apps, Power Automate, Dataverse)	Install the Microsoft Power Platform Content Hub solution; not part of the M365 connector
Dynamics 365 audit	Install the Microsoft Dynamics 365 Content Hub solution; separate from M365
On-premises Active Directory (DC events, Kerberos, LDAP)	Install Microsoft Defender for Identity (MDI) sensors on DCs, or stream the Security event log via AMA + DCRs
Exchange Online message tracking	Separate Get-MessageTrace PowerShell pull; not in OfficeActivity
Raw Defender XDR event tables (EmailEvents, DeviceProcessEvents, IdentityLogonEvents)	Free benefit covers them, but the Defender XDR connector must explicitly opt in to raw-table ingestion (off by default)
App Control for Business audit and block events (3076, 3077, 8028, 8029)	Ride the DeviceEvents table, which most deployments leave off as high-volume; the Step 2 baseline enables it behind a filter that keeps only the App Control decision events
AVD session and session-host telemetry (WVDConnections, WVDErrors, host Event and Perf)	No connector exists. The host pool's Diagnostic settings (every category, created in AVD Runbook Step 7) and the Insights data collection rule on the session hosts feed the workspace; the AVD chapter's Monitoring section walks both. A Sentinel deployment that stops at the connector list captures no AVD session record for AC.L2-3.1.12.
MDE Live Response session recordings	Stored in MDE; not exported to Sentinel: pull via Defender API if forensic capture is required
Teams chat content / call records / call quality	See the workload-coverage table above: three separate Graph or admin-center pipelines

UEBA (User and Entity Behavior Analytics)

Enable UEBA once from Sentinel's settings surface, which (like the workspace connection in Workspace Setup substep 5) lives in the Defender portal: System → Settings → Microsoft Sentinel → SIEM workspaces → [workspace]. The workspace flyout carries both controls: under Entity behavior analytics, click Configure UEBA and toggle Turn on UEBA feature. The page renders progressively: only the toggle and a role banner appear until the feature is turned on, after which the directory-service and data-source selections load. Select Microsoft Entra ID as the directory service (leave Active Directory off unless a Defender for Identity sensor runs on an on-premises domain controller), then click Connect available data sources: it auto-selects every eligible source, which for this deployment is exactly Signin Logs, Audit Logs, and Azure Activity. A grayed-out Security Events row reading "Data source is not ingested to Sentinel" is expected: that source requires the AMA-based Security Events connector on Windows servers, which this chapter does not deploy. Then back on the same workspace flyout, expand Anomalies and turn on Detect Anomalies (enable UEBA). The toggle requires Global Administrator or Entra Security Administrator (the page says so in a banner), plus Sentinel Contributor and Log Analytics Contributor on the Azure side. Note that OfficeActivity is not a UEBA data source: baselines build from the Entra sign-in/audit and Azure Activity streams, so the M365 connector needs no UEBA configuration. Enable it. UEBA builds behavioral baselines per user and entity by analyzing sign-in patterns, resource access, and activity volume, then flags anomalies (impossible travel, atypical access, unusual data movement) as enriched incidents.

Why it matters for CMMC:

• NIST 3.14.6 (monitor organizational systems) and 3.14.7 (identify unauthorized use) are directly served by behavioral anomaly detection.
• When a C3PAO asks "how do you detect compromised accounts or insider threats?" UEBA is the answer: it produces the evidence that raw log ingestion alone does not.

What it costs: UEBA analyzes data you are already ingesting (Entra sign-in and audit logs, Azure Activity). It creates a few additional tables (BehaviorAnalytics, UserAccessAnalytics, UserPeerAnalytics) but the storage increment is small relative to the source tables. You are not paying for a new data source: you are paying for ML enrichment on existing data.

Expectation: UEBA needs 14–21 days of ingested data to build meaningful behavioral baselines. Until then, anomaly scores will be noisy or absent. Do not evaluate its usefulness until it has had three weeks to learn.

Step 3: Enable CMMC 2.0 posture assessment

The Microsoft Sentinel: CMMC 2.0 solution provides compliance posture assessment, not threat detection. It ships two analytics rule templates and a compliance workbook. Detection rules come from the individual product solutions installed in Step 1 (Entra ID, M365, Defender XDR, etc.).

The CMMC posture rules query the SecurityRegulatoryCompliance table, which is populated by Microsoft Defender for Cloud. Complete Prereq 1 → Prereq 2 → Prereq 3 so the table exists and begins receiving data, then install the solution and enable its rule templates. The 12–24h wait only affects when tiles render and posture incidents first fire: you can complete the install, rule-template creation, workbook saves (Step 4), and the client-demo artifact captures (Step 5) immediately.

Prereq 1: Enable Defender for Cloud plans

The Workload Protection page in Defender for Cloud may show "your subscriptions are not protected by Microsoft Defender for Cloud" with an Enable button that launches a blank Getting Started page. Skip the Getting Started page entirely: it is a known GCC High UX issue. Enable plans through Environment settings:

1. Azure portal (portal.azure.us) → Microsoft Defender for Cloud.
2. Management → Environment settings in the left nav.
3. Expand the hierarchy until your Azure Government subscription appears. Click the subscription name (not the expand arrow).
4. Enable the Defender plans relevant to your environment:

Plan	Recommendation for AVD / CMMC	Why
Foundational CSPM	On, automatic and free	Baseline capability enabled by default on every subscription. Populates MCSB only: it does not run non-MCSB compliance standards. Cannot be turned off.
Defender CSPM	On: required for CMMC/NIST posture assessment	The paid CSPM plan. Non-MCSB compliance standards (NIST SP 800-171, CMMC, FedRAMP, etc.) only run under Defender CSPM. Without it, enabling NIST SP 800-171 in Prereq 2 appears to succeed but produces no data in SecurityRegulatoryCompliance and no tiles in the CMMC workbook. This is the single most common trap in Sentinel-for-CMMC deployments.
Defender for Servers (P1 or P2)	On if you have servers (AVD session hosts count)	VM vulnerability assessment, adaptive application controls, file integrity monitoring
Defender for Resource Manager	On	Monitors Azure management-plane operations (suspicious ARM calls, control-plane lateral movement)
Defender for Key Vault	On if using Key Vault	Anomalous access to secrets and certificates
Defender for Storage	On if using storage accounts	Malware upload detection, anomalous access patterns
Defender for DNS	On	Detects communication from your VNet to known-bad domains
Databases, App Service, Containers	Off unless you run those workloads	Don't pay for plans covering workloads you don't run

5. Click Save at the top.

Prereq 2: Enable the NIST SP 800-171 compliance standard

Defender CSPM must be enabled first

Before toggling NIST on, confirm Defender CSPM is On in the subscription's Defender plans (Prereq 1 table). Toggling NIST while only Foundational CSPM is active appears to succeed: the standard shows as enabled in the UI, but nothing assesses the subscription and SecurityRegulatoryCompliance never receives NIST rows no matter how long you wait.

1. Defender for Cloud → Regulatory compliance (left nav).
2. Click Manage compliance standards at the top of the blade (label may also appear as "Manage compliance policies" in some portal versions, same destination).
3. Select your Azure Government subscription.
4. Select Security policies in the left nav. The list of security standards appears, each with an On/Off toggle.
5. Toggle NIST SP 800-171 Rev. 2 to On.
6. You will be prompted to configure parameters for two Azure Policy built-ins that evaluate VM local Administrators group membership:
   • "Audit Windows machines missing any of specified members in the Administrators group": inclusion list. Specify the Entra group containing authorized VM administrators (e.g., EID_VM_Administrators).
   • "Audit Windows machines that have the specified members in the Administrators group": exclusion list. Specify accounts or groups that must not have local admin rights on VMs.
7. These parameters map to NIST control 3.1.1 (Limit system access to authorized users). The parameters are optional: the standard assigns regardless. If you do not have an approved admin group defined yet, leave the parameters empty and populate them later. The policy will audit only what you configure.
8. Click Save.

Prereq 3: Configure continuous export to the Sentinel workspace

1. Defender for Cloud → Environment settings → [your Azure Government subscription] → Continuous export → + Add continuous export.
2. Configure the dialog:
   • Export name: export-defender-to-sentinel (or similar).
   • Export target: Log Analytics workspace (not Event hub).
   • Exported data types: check all four: Security recommendations, Security alerts, Secure score, and Regulatory compliance. The last one populates SecurityRegulatoryCompliance; if unchecked, no posture data flows regardless of other settings.
   • Export frequency: Streaming for alerts and recommendations; Regulatory compliance is Snapshots-only (fine).
   • Target workspace: your Azure Government subscription → rg-sentinel-prod-usgovva → law-sentinel-prod-usgovva.
3. Scroll through the entire dialog before saving. The UI will accept a rule with unchecked data-type boxes without error: the rule appears Enabled in the list but produces no data. Re-open the saved rule and verify every field, especially the four Exported data types checkboxes.

Data begins flowing in 15–30 minutes for most types, but Regulatory compliance specifically takes 12–24 hours: Defender for Cloud's initial compliance scan must run before there's anything to export. Don't wait for it. Proceed immediately to the install below and complete Steps 4 and 5: install, rule templates, workbook saves, and the full client-demo deliverable all work without NIST data. Only CMMC workbook tile rendering and first-fire of the two CMMC posture rules depend on that data, and Step 6 verifies both.

Install the solution and enable the rule templates

This subsection installs the CMMC 2.0 solution and creates the two posture rule templates. The CMMC compliance workbook itself is saved and configured later in Step 4 → Save and configure the CMMC 2.0 workbook alongside the other client-demo workbooks.

1. Microsoft Sentinel → Content management → Content hub → search for CMMC 2.0 → Install.
2. After installation, go to Microsoft Sentinel → Configuration → Analytics → Rule templates → filter by source CMMC 2.0. You will see two posture rule templates:
   • CMMC 2.0 Level 1 (Foundational) Readiness Posture: evaluates the 17 Level 1 practices.
   • CMMC 2.0 Level 2 (Advanced) Readiness Posture: evaluates the 110 Level 2 practices.
3. Create both rules. Enable Level 1 immediately for clients doing L1 self-attestation; enable Level 2 for clients targeting L2 assessment. No harm enabling both early: Level 2 shows gaps you will close during implementation.

Known issue: incorrect MITRE ATT&CK mapping on the posture rule templates

The default CMMC posture rule templates may carry a MITRE ATT&CK mapping (e.g., Discovery / T1082 System Information Discovery) that does not reflect the rule's actual purpose: the rules assess compliance posture, not adversary activity. This is a metadata labeling error in Microsoft's template. It does not affect rule function, but incident triage dashboards will show an incorrect MITRE tactic for posture-generated incidents. Consider editing the MITRE mapping on the created rule to remove the inaccurate tactic, or add a comment in the rule description noting that this is a posture assessment, not a detection.

Step 4: Save workbook templates for client demonstration

Save each workbook below from Microsoft Sentinel → Threat management → Workbooks → Templates. Open to verify it renders: first open may take 30–60 seconds while queries execute against your workspace. The CMMC 2.0 workbook requires additional parameter configuration (covered in its own subsection below); the rest are save-open-screenshot. The set is grouped by client-demo readiness.

Saving parameter changes requires the Azure portal

Edit workbooks in the Azure portal: open the workbook → Edit → set parameter values → Done Editing to persist them as the saved defaults. (If you view a workbook from the Defender portal instead, its viewer is read-only: the toolbar exposes only Open in Azure, Share, Refresh, and Auto-refresh, and parameter changes there last only for the session. Click Open in Azure to reach the editable view; saved defaults then apply from either portal.)

Tier 1: Save now, renders demo-worthy data today. These are the client-facing wins for the interim status update:

Workbook	Why it's demo-gold
Microsoft Entra ID Sign-in Logs	Sign-in map, MFA status, Conditional Access outcomes. Strongest visual in the library. Evidence for AU.L2-3.3.1, SI.L2-3.14.6.
Microsoft Entra ID Audit Logs	Role changes, directory operations, application management. Evidence for AC.L2-3.1.5, AC.L2-3.1.7, AU.L2-3.3.2.
Conditional Access SISM (Summaries, Insights, Security & Monitoring)	CA policy outcomes visualized: high-impact client visual tied directly to the Conditional Access chapter.
Office 365	M365 activity panorama: Exchange, SharePoint, Teams in one consolidated view.
SharePoint & OneDrive	External-sharing detail. Direct evidence for AC.L2-3.1.3 (CUI flow control).

Tier 2: Save, but expect sparse content until Defender XDR signal or UEBA baselines accumulate. Useful dashboards once incident telemetry or behavioral analytics mature; save them now so they're configured and ready:

• Identity & Access: leans heavily on UEBA-derived tables (IdentityInfo, BehaviorAnalytics, UserAccessAnalytics). UEBA needs 14–21 days of ingested data to build baselines; until then the workbook renders empty even with valid sign-in and audit data in the workspace. Revisit at the week-3 check-in.
• Exchange Online: populates from OfficeActivity for mailbox audit events; rich panels need MDO alerts to fire.
• Microsoft Defender for Office 365 Detection and Insights: requires MDO incident telemetry. Dashboard is ready when alerts arrive.

Tier 3 workbooks (CMMC 2.0, Azure Firewall, Key Vault, CEF, Syslog, Linux, Defender for Endpoint, Defender for Identity) are saved only when their data source is streaming; the per-workbook conditions are on the web edition at docs.mindline.com/docs/m365security/siem-strategy#step-4-save-workbook-templates-for-client-demonstration. The CMMC 2.0 workbook is the one exception and is saved now, below.

Tier 3: Defer until preconditions are met. Save each when the listed condition becomes true, not before:

Workbook	Save when
CybersecurityMaturityModelCertification(CMMC)2.0	Save and configure in the subsection below: waiting for NIST 800-171 Rev. 2 data to populate SecurityRegulatoryCompliance before tiles render.
Azure Firewall	Azure Firewall is deployed in the subscription and firewall diagnostic settings stream to the workspace.
Azure Firewall Structured Logs	Structured log format is enabled on the firewall (preview/GA-dependent).
Azure Key Vault Security	At least one Key Vault has diagnostic settings sending AuditEvent to the workspace.
Common Event Format Logs Overview	A network appliance or third-party source is shipping CEF to the workspace via AMA.
Syslog Connectors Overview Workbook	A Linux forwarder or appliance is sending Syslog via AMA.
Event Analyzer	Power-user tool for exploring raw event payloads, not client-facing. Skip for demo deliverables.
Linux Machines	Linux VMs are onboarded to the workspace via AMA.
Microsoft Defender for Endpoint	At least one device is fully onboarded to MDE and generating DeviceProcessEvents.
Microsoft Defender for Identity	Skip permanently for cloud-only tenants: MDI requires on-premises AD sensor deployment.

Save the CMMC 2.0 workbook (configuration deferred to Step 6)

The CMMC compliance workbook depends on NIST SP 800-171 Rev. 2 rows in SecurityRegulatoryCompliance: data that takes 12–24 hours to populate after Prereq 3. Save the template now so it's available; opening it and setting parameters before the data lands triggers per-tile "parameter not set" errors that resolve only after the first Defender for Cloud assessment pass. The save is a one-click operation; the open-and-configure flow happens in Step 6 → Finalize the CMMC workbook and posture rules.

1. Go to Microsoft Sentinel → Threat management → Workbooks. Switch to the Templates tab (not "My workbooks": installed workbooks start there).
2. Search for CMMC → the CybersecurityMaturityModelCertification(CMMC)2.0 template card appears.
3. Click the Save button on the template card: before clicking View template. Save is available from the Templates tab but hidden from the live template preview. Clicking View template first puts you into preview mode where only Refresh and Auto refresh are exposed; you have to return to Templates and click Save directly on the card.
4. Select the Azure Government region matching your Sentinel workspace (USGov Virginia or USGov Texas).

Stop here. The workbook is saved and visible in My workbooks, but unconfigured. Continue to Step 5 to assemble the immediate-operation deliverable; return to this workbook in Step 6 once the discovery query confirms NIST 800-171 data has landed.

Two things about this workbook look wrong and are not. First, Defender for Cloud offers a NIST SP 800-171 Rev. 2 standard and no CMMC Level 2 standard. CMMC Level 2 is the same 110 practices, so the CMMC workbook reads the NIST rows, and its CMMC 2.0 Level parameter offers only All. Second, the saved workbook opens with text that calls itself a "solution." That text came from the Content Hub solution it shipped in. What you save and edit is a workbook. Both points are explained in full on the web edition at docs.mindline.com/docs/m365security/siem-strategy#save-the-cmmc-20-workbook-configuration-deferred-to-step-6.

NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 are the same 110 practices

CMMC 2.0 Level 2 was built to adopt NIST SP 800-171 Rev. 2 wholesale: identical control set, no additions. This is why Defender for Cloud typically does not offer CMMC 2.0 Level 2 as a separate assessable standard in its Manage Compliance Standards list: it would be literally duplicative. What you do see in the catalog:

• NIST SP 800-171 Rev. 2: the correct standard to enable for CMMC Level 2 assessment.
• CMMC Level 3: the enhanced-requirements tier (adds NIST SP 800-172 practices on top of Level 2). Only relevant for clients targeting Level 3.

The CMMC workbook renders from NIST 800-171 data: same controls, same evidence, just differently labeled in the source table. This equivalence is also why the workbook's CMMC 2.0 Level parameter (encountered in Step 6) defaults to All and offers no Level 1 / Level 2 alternatives: Defender for Cloud doesn't ship those as discrete standards, so the dropdown has nothing to populate with.

"Solution" vs. "workbook": the same artifact, two layers

When you open the saved CMMC workbook from My workbooks in Step 6, its body header introduces itself with marketing copy starting "This solution enables Compliance Teams, Architects, SecOps analysts and Consultants...", which is accurate but easy to misread as "this is a solution, not a workbook." Both labels describe different layers of the same package.

Sentinel content ships through Content Hub solutions: bundles that typically include a workbook plus a set of analytics rule templates, and sometimes hunting queries or playbooks. The CMMC 2.0 solution installed in Step 1 bundles two artifacts referenced throughout this chapter:

• The CMMC 2.0 workbook (saved here in Step 4, configured in Step 6).
• The two CMMC 2.0 Readiness Posture analytics rule templates (turned into rules in Step 3).

The artifact you save and edit is a workbook (Azure Workbooks resource type). The descriptive prose introducing it was authored once at the solution level by Microsoft and rendered inside the workbook header, which is why the workbook describes itself as a "solution."

Step 5: Demonstrate immediate operation of Sentinel and key workbooks

The eight queries below produce audit evidence for specific CMMC Level 2 practices. Save them once, screenshot their results, and present them alongside the Tier 1 workbooks saved in Step 4 for a complete client deliverable. This demonstrates same-day value from the Sentinel deployment and reassures the client that compliance-relevant telemetry is already flowing, independent of the 12–24h wait for NIST 800-171 assessment data to populate the CMMC workbook tiles.

The deliverable combines three artifact categories, assembled in the order below.

1. Plumbing-evidence portal screenshots: prove the deployment is operational:

1. Azure portal → Microsoft Sentinel → [workspace] → Configuration → Data connectors → filter by Connected status: shows the active connectors (Entra ID, Microsoft 365, Azure Activity, Defender XDR, etc.), direct proof the wiring is live.
2. Azure portal → Microsoft Sentinel → [workspace] → Content management → Content hub → Installed filter: the list of installed solutions establishes deployment breadth.
3. Azure portal → Microsoft Sentinel → [workspace] → Configuration → Analytics → Rule templates: filtered count of available templates per source, proving detection coverage is available to activate.
4. Azure portal → Log Analytics workspaces → law-sentinel-prod-usgovva → Usage and estimated costs: GB/day ingestion chart and per-table breakdown, proving data is actively flowing into the workspace.

2. Workbook narrative for the client deck (uses only Tier 1 workbooks saved in Step 4): this sequence answers five separate questions a compliance stakeholder cares about, mapping cleanly to CMMC practice families AC, AU, CM, and SI:

1. Sign-in Logs (global sign-in map): who is signing in.
2. Conditional Access SISM (policy outcomes): whether CA enforced correctly.
3. Audit Logs (role activations, directory changes): what administrators did.
4. SharePoint & OneDrive (external sharing): how CUI is flowing externally.
5. Office 365 (cross-workload activity): the overall M365 activity envelope.

3. KQL evidence queries: eight saved queries that each produce audit evidence for specific CMMC Level 2 practices. Screenshot each with results rendered for the client deliverable; the mapping table below doubles as a one-page client handout:

Saved name (Category: Security, Label: CMMC L2 Demo)	CMMC L2 practices
Sign-in Volume by Country (7d)	AU.L2-3.3.1, SI.L2-3.14.6
Privileged Role Activations (30d)	AC.L2-3.1.5, AC.L2-3.1.7, AU.L2-3.3.2
Failed Sign-ins: Top 20 Users (7d)	AC.L2-3.1.8, SI.L2-3.14.6, SI.L2-3.14.7
Azure Control-Plane Activity by Caller (7d)	CM.L2-3.4.3, AU.L2-3.3.1
OfficeActivity - Events by RecordType (7d)	AU.L2-3.3.1
External Sharing Events - Sharepoint + Teams	AC.L2-3.1.3, AC.L2-3.1.22
MIP Label Activity - Exchange (7d)	MP.L2-3.8.1, SC.L2-3.13.11
DLP Policy Matches - Exchange (7d)	AC.L2-3.1.3, SC.L2-3.13.8

Save each under Sentinel → Logs → Save → Query (Shared) using the settings below.

Save-dialog settings for all eight queries:

• Name: the recommended name shown in each comment header.
• Description: paste the Evidence for: practice list from the comment header (e.g., Evidence for AU.L2-3.3.1, SI.L2-3.14.6).
• Category: Security: the Category dropdown is a fixed picklist; pick Security for all eight.
• Labels: CMMC L2 Demo: Labels is the free-text field that creates the custom grouping. Typing this on the first save creates the label; reuse it on the remaining seven so all eight queries share the label and surface together when filtering by label in the saved-query pane.
• Save to: ensure the workspace-shared option is selected (not personal/"my queries"), so the client team can see the saved queries too.

Five quirks of the Save Query dialog are documented on the web edition at docs.mindline.com/docs/m365security/siem-strategy#step-5-demonstrate-immediate-operation-of-sentinel-and-key-workbooks; the two that matter most are that Category is a fixed picklist (use Security) while Labels is the free-text grouping, and that forward slashes are rejected in query names.

Saving queries in Sentinel is non-intuitive: five stacked gotchas

Sentinel's Save Query experience has five quirks that together make it easy to "lose" a query you just saved. Know these up front and you won't waste time hunting:

1. Category is a fixed picklist; Labels is free-text. The naming feels inverted: in most systems Categories are customizable and Labels are fixed tags; in Sentinel's Save dialog it's the reverse. Pick a Category from the fixed list (Security for compliance/evidence work) and use Labels for custom groupings like CMMC L2 Demo.
2. Saves land in a Query Pack resource whose own blade does not show queries. The DefaultQueryPack-{region} resource opens to Resource Visualizer; there is no "list of queries in this pack" page at the resource level in the portal. Don't hunt for your query there: it's not a bug, it's the blade design.
3. The Queries pane in the Logs editor hides workspace-authored queries by default. The Source / Provider filter defaults to Microsoft / Solutions built-ins, which excludes your Query Pack saves. Toggle Source → Query Packs (or Workspace) to see what you actually saved.
4. Group by defaults to Category, not Labels. Your label-based grouping won't appear until you change Group by: Category to Group by: Labels in the Queries pane.
5. Forward slashes are not allowed in saved query names. The Save dialog silently rejects the save (or strips the name). Use +, -, or & instead: e.g., External Sharing Events - Sharepoint + Teams, not External Sharing Events — SharePoint/Teams.

Workflow that works every time

Sentinel → Logs → open the Queries pane (icon on left side of the editor) → set filter Source = Query Packs → set Group by = Labels → the CMMC L2 Demo group appears with exactly the queries saved under that label.

The eight query bodies are online rather than printed. KQL is meant to be pasted into a query window. Each query, with the comment header carrying its recommended save name and the CMMC practices it evidences, is at:

docs.mindline.com/docs/m365security/siem-strategy#step-5-demonstrate-immediate-operation-of-sentinel-and-key-workbooks

The mapping table above lists all eight by name and practice, so the printed deliverable and the client handout are unaffected.

// Sign-in volume by country over last 7 days — quickly shows global identity activity
// Save as: Sign-in Volume by Country (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AU.L2-3.3.1 (create and retain audit records),
//               SI.L2-3.14.6 (monitor organizational systems for unauthorized use)
SigninLogs
| where TimeGenerated > ago(7d)
| summarize SignInCount = count() by Location, bin(TimeGenerated, 1d)
| render timechart

// Privileged role activations in the last 30 days (PIM or direct assignments)
// Save as: Privileged Role Activations (30d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AC.L2-3.1.5 (principle of least privilege),
//               AC.L2-3.1.7 (prevent non-privileged users executing privileged functions),
//               AU.L2-3.3.2 (ensure actions of individual users can be uniquely traced)
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName contains "Add member to role"
| project TimeGenerated,
    Actor = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName),
    OperationName,
    TargetRole = tostring(TargetResources[0].displayName)
| sort by TimeGenerated desc

// Failed sign-ins — top 20 users (potential password spray / brute force signal)
// Save as: Failed Sign-ins — Top 20 Users (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AC.L2-3.1.8 (limit unsuccessful logon attempts),
//               SI.L2-3.14.6 (monitor unauthorized use),
//               SI.L2-3.14.7 (identify unauthorized use)
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType !in ("0", "50140")  // 50140 = Keep me signed in interrupt
| summarize FailedCount = count() by UserPrincipalName, Location
| top 20 by FailedCount desc

// Azure control-plane changes by caller — admin-activity board
// Save as: Azure Control-Plane Activity by Caller (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: CM.L2-3.4.3 (track, review, approve/disapprove, and log configuration changes),
//               AU.L2-3.3.1 (create and retain audit records for control-plane operations)
AzureActivity
| where TimeGenerated > ago(7d)
| where ActivityStatusValue == "Success"
| where OperationNameValue !endswith "/read"  // filter noisy read ops
| summarize Operations = count() by Caller, OperationNameValue
| top 50 by Operations desc

// OfficeActivity events by RecordType — workload-level M365 audit summary
// Run first to see which workloads (Exchange, SharePoint, Teams, MIP, DLP) are emitting audit data
// Save as: OfficeActivity - Events by RecordType (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AU.L2-3.3.1 (create and retain audit records across M365 workloads)
OfficeActivity
| where TimeGenerated > ago(7d)
| summarize Events = count() by RecordType
| top 20 by Events desc

// External sharing activity from SharePoint / Teams
// Save as: External Sharing Events - Sharepoint + Teams    |  Category: Security  |  Label: CMMC L2 Demo
// Note: forward slashes are not allowed in saved query names — use "+" or another separator.
// Evidence for: AC.L2-3.1.3 (control CUI flow in accordance with approved authorizations),
//               AC.L2-3.1.22 (control information posted or processed on publicly accessible systems)
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType in ("SharePoint", "SharePointSharingOperation")
| where Operation in ("AnonymousLinkCreated", "SharingInvitationCreated", "AddedToGroup")
| project TimeGenerated, UserId, Operation, OfficeObjectId, Site_Url, TargetUserOrGroupName
| top 100 by TimeGenerated desc

// MIP label activity — sensitivity labels being applied or changed on Exchange items
// Save as: MIP Label Activity - Exchange (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: MP.L2-3.8.1 (protect CUI on media, including digital),
//               SC.L2-3.13.11 (employ cryptographic protection of CUI — labels drive encryption)
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType == "MIPLabel"
| summarize Events = count() by Operation, UserId
| top 20 by Events desc

// DLP policy matches on Exchange — CUI flow controls enforcing today
// Save as: DLP Policy Matches - Exchange (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AC.L2-3.1.3 (control CUI flow in accordance with approved authorizations),
//               SC.L2-3.13.8 (implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission)
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType == "ComplianceDLPExchange"
| summarize Events = count() by Operation, UserId
| top 20 by Events desc

Step 6: Verify NIST 800-171 data arrival

12–24 hours after Prereq 3, run this discovery query in Sentinel → Logs to confirm NIST SP 800-171 data has landed in SecurityRegulatoryCompliance:

SecurityRegulatoryCompliance
| summarize count() by ComplianceStandard

Interpret the output:

Output	Meaning
Zero rows	Continuous export isn't yet producing SecurityRegulatoryCompliance data. Re-verify Prereq 3's data-type checkboxes: the most common cause is that Regulatory compliance was never actually checked.
Only Microsoft-cloud-security-benchmark appears after 24h	Defender CSPM is not enabled on the subscription. MCSB is the only compliance standard the free Foundational CSPM plan runs. Return to Prereq 1 and toggle Defender CSPM to On, then wait another 12–24h: NIST rows arrive on the next assessment pass after enablement, not immediately. This is the canonical symptom of the Defender CSPM trap.
NIST-SP-800-171-Rev-2 (or similar) appears with any count	NIST data is live. Proceed to the finalization tasks below.

If NIST rows have not arrived and you do not want to wait for the first scheduled pass, an Azure Policy compliance scan (Start-AzPolicyComplianceScan, or az policy state trigger-scan) brings the end-to-end wait to about two to six hours; the procedure and its prerequisites are on the web edition at docs.mindline.com/docs/m365security/siem-strategy#optional-force-an-immediate-assessment-pass.

Optional: force an immediate assessment pass

Skip this subsection if NIST-SP-800-171-Rev-2 already appears in the discovery query above. The scan only helps when data hasn't yet arrived: running it once data is live just re-runs the same assessment for no change.

When the scan is useful: you've just enabled Defender CSPM or toggled the NIST standard and don't want to wait 12–24 hours for the first scheduled pass, or you corrected a Prereq 1 or 3 misconfiguration and want a fresh pass on-demand. The scan triggers an Azure Policy compliance evaluation, which re-evaluates every policy initiative assigned to the subscription, which is what Defender for Cloud's regulatory compliance view is built from.

Prerequisite: Defender CSPM must already be On and the NIST standard already toggled. Triggering the scan beforehand has no effect: there is no NIST initiative assigned yet.

From Azure Cloud Shell (inside portal.azure.us) or a local PowerShell with Connect-AzAccount -Environment AzureUSGovernment:

Set-AzContext -Subscription "<your-subscription-id>"
Start-AzPolicyComplianceScan -AsJob

Or via Azure CLI:

az cloud set --name AzureUSGovernment
az login --tenant "<your-tenant-id>"
az account set --subscription "<your-subscription-id>"
az policy state trigger-scan --no-wait

Expected timing after triggering: Microsoft describes the scan itself as "a long time to run": 30 minutes to several hours, depending on subscription size. After it completes, Defender for Cloud still has to aggregate the policy-state results into the regulatory compliance view, and continuous export still has to snapshot that data to Log Analytics. Realistic end-to-end: 2–6 hours versus the default 12–24 hours. Re-run the discovery query every hour or so until NIST-SP-800-171-Rev-2 appears.

Finalize the CMMC workbook and posture rules

Once NIST data is live, finalize the two CMMC artifacts saved earlier: the CMMC workbook from Step 4 and the two CMMC 2.0 Readiness Posture analytics rules from Step 3:

1. Open the saved CMMC workbook: Azure portal → Microsoft Sentinel → [workspace] → Threat management → Workbooks → My workbooks → click CybersecurityMaturityModelCertification(CMMC)2.0. A pane opens with three buttons: View saved workbook, View template, Delete. Click View saved workbook: View template opens the read-only original and does not honor your parameters.

2. Confirm workspace-scope parameters at the top of the workbook: The parameter row at the top of the workbook contains three workspace-scope parameters:

   • Subscription: your Azure Government subscription.
   • Workspace: your Sentinel workspace.
   • Time range: Last 7 days (or whatever range you want for initial render).

   In a fresh save these typically already target the right workspace. The CMMC 2.0 Level parameter is not in this top row: it's a section-scoped parameter that only renders after a Control Family column is expanded (instruction 3).

3. Expand a Control Family column to reveal tiles and the Level parameter: The workbook body presents two columns of Control Family group checkboxes (column 1: Executive Summary, Controls Crosswalk, Access Control, etc.; column 2: Maintenance, Media Protection, Personnel Security, Physical Protection, etc.). Click the master Control Family checkbox at the top of either column. The column expands and a section appears below it containing per-tile data visualizations and the CMMC 2.0 Level dropdown, already defaulting to All. Confirm Level = All; do not change it. All is the only valid setting because Defender for Cloud doesn't ship CMMC 2.0 Level 1 / Level 2 as discrete standards (see the equivalence note in Step 4).

4. Verify Control Family tiles render and capture screenshot: With the column expanded and Level = All, per-tile queries resolve against NIST-tagged rows in SecurityRegulatoryCompliance and produce evidence for each practice family. Capture a screenshot to supplement the client deliverable from Step 5.

5. (Optional) Persist a top-row parameter default: Skip this unless you want to change the saved default for Time range (e.g., Last 30 days instead of Last 7 days). Only the top-row parameters can be persisted to the saved workbook resource; the Control Family expand state and the section-scope Level dropdown are per-session interactions: every time anyone reopens this workbook, the column will be collapsed and Level will default to All. This is by design in Azure Workbooks.

   To change a top-row default (in the Azure portal; if you opened the workbook from the Defender portal, click Open in Azure first, since that viewer is read-only):

   • Click Edit to enter edit mode and change the parameter.
   • Click the Save icon (floppy disk) in the workbook toolbar to persist the new default.
   • Click Done Editing to exit edit mode.

6. Confirm posture rules have fired: Azure portal → Microsoft Sentinel → [workspace] → Configuration → Analytics → open each of the two CMMC 2.0 Readiness Posture rules from Step 3 → verify recent execution time and any incidents produced. If neither has run in the last hour, the scheduled query trigger hasn't fired yet; give it another scheduling cycle.

After Step 6 passes, the CMMC posture assessment surface is fully operational and the deliverable set is complete.

Step 7: Enable detection rule templates from product solutions

Threat detection rules do not come from the CMMC 2.0 solution: they come from the individual product Content Hub solutions installed in Step 1. Each solution ships its own analytics rule templates.

Rule templates arrive with each product solution installed in Step 1 and are listed under Configuration → Analytics → Rule templates, filterable by source; the CMMC 2.0 solution's two Readiness Posture templates are posture assessment, already enabled in Step 3, not threat detection. Most templates are Scheduled (a KQL query on a cadence with a lookback window); NRT templates run every minute against one table. The example-template table and the rule-type note are on the web edition at docs.mindline.com/docs/m365security/siem-strategy#step-7-enable-detection-rule-templates-from-product-solutions.

After the Content Hub solutions are installed, go to Microsoft Sentinel → Configuration → Analytics → Rule templates (no source filter). Browse or filter by source to see rule templates from each connected product:

Source	Example rule templates
Microsoft Entra ID	Modified domain federation trust settings, MFA Spamming followed by Successful login, Azure RBAC (Elevate Access), Suspicious application consent similar to O365 Attack Toolkit, Bulk Changes to Privileged Account Permissions
Microsoft 365	Malicious Inbox Rule, Mail redirect via ExO transport rule, Multiple users email forwarded to same destination, SharePointFileOperation via previously unseen IPs, Office Policy Tampering
Azure Activity	Resource deletion alerts, RBAC role assignment changes, policy modifications. The Azure Activity source only appears in the filter after the Azure Activity solution is installed from Step 1 → Priority 1; if you don't see it, install the solution first.
Microsoft Defender XDR	LSASS Credential Dumping with Procdump, Service Accounts Performing Remote PS, C2-NamedPipe, Imminent Ransomware, AV detections related to specific malware families. Templates are present immediately on solution install; rules only fire once MDE / MDO / MDI telemetry is flowing into the workspace.
CMMC 2.0	CMMC 2.0 Level 1 (Foundational) Readiness Posture (evaluates the 17 Level 1 practices) and CMMC 2.0 Level 2 (Advanced) Readiness Posture (evaluates the 110 Level 2 practices). Posture assessment, not threat detection: created and enabled in Step 3. Out of scope for this step.

Examples observed April 2026; Microsoft adds and removes templates over time, so this list is illustrative rather than canonical. Filter Rule templates by source in your own tenant for the live set.

Scheduled vs. NRT rule types

The Rule type column on the Rule templates page is mostly Scheduled or NRT (Near Real-Time): Sentinel's two main analytics rule kinds.

• Scheduled runs a KQL query on an author-defined cadence (typically every 5 minutes to every 24 hours) against a configurable lookback window. The query can join across tables, summarize over time windows, and use the full KQL surface: most useful detections live here.
• NRT runs every minute against the last minute of data. To keep that cadence cheap across every workspace, NRT restricts queries to a single table with simple filtering: no multi-table joins, no cross-table summarize, no lookups against externaldata. Fires within ≈1–2 minutes of an event landing.

Most templates are Scheduled because most useful detections need a wider window than one minute or need to correlate across tables (e.g., "5 failed sign-ins in 10 minutes followed by success": Scheduled; "federation trust setting changed": NRT). The template author chose the rule type; you cannot convert between them when enabling, only adjust the cadence and lookback within the type's allowed bounds.

Other rule types you may see less frequently: Microsoft Security (creates Sentinel incidents from alerts already generated by Microsoft security products; largely superseded by direct alert sync), Fusion (Microsoft's managed ML correlation engine, not customizable), Anomaly (ML behavioral anomaly detection, surfaced under the Anomalies tab), and Threat Intelligence (auto-matches incoming logs against TI feeds).

Minimum set to enable immediately: seven Microsoft Entra ID rule templates that fire on data you already have post-Step 2 (no MDE / MDO / Linux onboarding required). Ranked by attack-pattern severity and false-positive ratio:

#	Rule Template	Why it's in the minimum set	CMMC L2 mapping
1	Modified domain federation trust settings	Federation trust manipulation is a top-tier persistence TTP (the SolarWinds technique). An adversary who edits the trust can mint forged tokens and bypass MFA tenant-wide. Extremely low false-positive rate: federation trust changes are deliberate and rare.	AC.L2-3.1.5, AC.L2-3.1.7, IA.L2-3.5.3
2	Authentication Methods Changed for Privileged Account	Adversary adds their own MFA method (FIDO2 key, Authenticator app) to a compromised admin account for persistence after a phishing or token-replay compromise. Very high fidelity.	AC.L2-3.1.5, IA.L2-3.5.3
3	MFA Spamming followed by Successful login	Catches MFA fatigue / push-bombing attacks that ultimately succeed: currently a leading initial-access vector against MFA-enabled users.	IA.L2-3.5.3, SI.L2-3.14.6
4	Conditional Access - A Conditional Access user/group/role exclusion has changed	Adversary or insider excludes a backdoor account from CA enforcement to bypass MFA / device-compliance controls. High fidelity: CA exclusions are infrequent administrative actions.	AC.L2-3.1.5
5	Admin promotion after Role Management Application Permission Grant	Multi-step pattern: a service principal granted directory role permissions, then a user promoted via that principal. Specific to a documented adversary attack chain.	AC.L2-3.1.5, AC.L2-3.1.7
6	New User Assigned to Privileged Role	General privilege-escalation detection: catches role assignments performed outside approved PIM workflows.	AC.L2-3.1.5
7	Privileged Accounts - Sign in Failure Spikes	Brute-force or password-spray activity targeting admin accounts.	AC.L2-3.1.8, SI.L2-3.14.6

Pair with NRT and Fusion. NRT Modified domain federation trust settings is the same event as row 1 with ≈1-minute latency; enable both: NRT for fastest fire, Scheduled for redundancy on a high-stakes event. Advanced Multistage Attack Detection (Fusion), Microsoft's managed ML correlation engine, ships enabled by default and creates cross-source incidents at no additional cost; confirm it shows status Enabled under Active rules.

How to enable additional rules as data sources come online. Sort Rule templates by Severity (High first), then check the Data sources column. A template that queries DeviceProcessEvents (MDE) won't fire until MDE is onboarded; templates against OfficeActivity need M365 audit logs streaming. Enable templates whose data sources are already populated, and revisit the rest (e.g., LSASS Credential Dumping with Procdump, Files Copied to USB Drives, AV detections related to Ukraine threats, Local Admin Group Changes, Unusual Volume of file deletion by users) as you onboard MDE, M365 audit logging, and other workloads.

---

Reference sections below

The sequential deployment flow ends with Step 7. The sections that follow (Analytics Rules, Workbooks, Log Retention, and SIEM: Compliance Control Mapping) are reference material to return to during tuning and as detection coverage matures.

Two parts of that material are web-only: the custom KQL detection-rule examples and the SOAR playbook table.

Two parts of that material are web-only: the custom KQL detection-rule examples at docs.mindline.com/docs/m365security/siem-strategy#custom-analytics-rules-examples and the SOAR playbook table at docs.mindline.com/docs/m365security/siem-strategy#soar-playbooks.

Analytics Rules

Analytics rules run KQL queries against ingested logs on a schedule and generate Sentinel incidents when thresholds are met. Step 7 above covered enabling Microsoft-provided templates; this section focuses on custom KQL rules you author to fill detection gaps the templates don't cover.

The example rule queries are online rather than printed. KQL is meant to be pasted into a query window, not retyped from a page. The full set, with the comment headers that document what each rule detects and its scheduling guidance, is at:

docs.mindline.com/docs/m365security/siem-strategy#custom-analytics-rules-examples

Custom Analytics Rules: Examples

// GCC High: PIM activation outside business hours (ET)
// Detection-tuned variant of the panoramic demo query "Privileged Role Activations (30d)" in Step 5.
// Same AuditLogs source, narrowed to a specific PIM-complete event and off-hours trigger.
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

// AVD: remote-access session from a client this user has not used before (AC.L2-3.1.12)
// WVDConnections is filled by the host pool's Connection diagnostic category (AVD Runbook Step 7).
// State == "Connected" is the brokered session; the baseline is the user's client OS and client type over the prior 14 days.
let lookback = 14d;
let window = 1h;
let baseline = WVDConnections
    | where TimeGenerated between (ago(lookback + window) .. ago(window))
    | where State == "Connected"
    | summarize by UserName, ClientOS, ClientType;
WVDConnections
| where TimeGenerated > ago(window)
| where State == "Connected"
| join kind=leftanti baseline on UserName, ClientOS, ClientType
| project TimeGenerated, UserName, ClientOS, ClientType, ClientVersion, ClientSideIPAddress, SessionHostName, TransportType, GatewayRegion, CorrelationId

// Label removed or set to a below-CUI label, then outbound email from the same user within the window.
// Prerequisites (Step 2): the Microsoft 365 connector with SharePoint and Exchange selected writes
// OfficeActivity; the Defender XDR connector with email events writes EmailEvents. Sentinel fails a
// query on a table that does not exist, so check first:
//   union isfuzzy=true OfficeActivity, EmailEvents | summarize count() by Type
// returns one row per table present. OfficeActivity records the NEW label only (SensitivityLabelId),
// no old label and no LabelEventType, so this rule cannot tell a downgrade from an upgrade: a file
// moving from Public to Internal matches the same as one moving from CUI//SP-CTI to Internal. It is a
// triage signal, not a downgrade detection. The analyst confirms the previous label in the Purview
// activity explorer or in the audit record's detail before opening an incident. A reduction within
// the CUI sublabels (CUI//SP-CTI to CUI (Basic)) is out of this rule's scope. Fill lowLabels from
// Get-Label (ImmutableId) with every label below CUI: Public and Internal in this book's taxonomy.
let window = 4h;
let lowLabels = dynamic(["<Public label GUID>", "<Internal label GUID>"]);
let lowLabelEvents = union isfuzzy=true OfficeActivity
    | where TimeGenerated > ago(1d)
    | where Operation in ("SensitivityLabelUpdated", "FileSensitivityLabelChanged",
                          "SensitivityLabelRemoved", "FileSensitivityLabelRemoved")
    | where Operation endswith "Removed" or SensitivityLabelId in (lowLabels)
    | project LabelTime = TimeGenerated, UserId = tolower(UserId), Operation, OfficeObjectId, SensitivityLabelId;
let outbound = union isfuzzy=true EmailEvents
    | where TimeGenerated > ago(1d)
    | where EmailDirection == "Outbound"
    | project EmailTime = TimeGenerated, SenderFromAddress = tolower(SenderFromAddress),
              RecipientEmailAddress, Subject, NetworkMessageId;
lowLabelEvents
| join kind=inner outbound on $left.UserId == $right.SenderFromAddress
| where EmailTime between (LabelTime .. (LabelTime + window))
| project LabelTime, EmailTime, UserId, Operation, OfficeObjectId, SensitivityLabelId,
          RecipientEmailAddress, Subject, NetworkMessageId

// External sharing: anonymous link creation or external guest invitation in SharePoint/Teams
// Detection-tuned variant of the panoramic demo query "External Sharing Events - Sharepoint + Teams" in Step 5.
// Adds AnonymousLinkUsed to the operations list and narrows via TargetUserOrGroupType == "Guest" filter.
// Maps to AC.L2-3.1.3 (control the flow of CUI): guest invitations and anonymous links are flow events, not media events
OfficeActivity
| where RecordType in ("SharePoint", "SharePointSharingOperation")
| where Operation in (
    "AnonymousLinkCreated",
    "AnonymousLinkUsed",
    "SharingInvitationCreated",
    "AddedToGroup"
)
| where TargetUserOrGroupType == "Guest" or Operation startswith "Anonymous"
| project TimeGenerated, UserId, Operation, OfficeObjectId, Site_Url, TargetUserOrGroupName

// Log tampering: Windows event log cleared or diagnostic settings modified.
// Maps to AU.L2-3.3.8 (protect audit information) and AU.L2-3.3.9 (limit audit management).
// Prerequisites: 1102 (Security log cleared) arrives in SecurityEvent through the Windows Security
// Events via AMA connector (Step 2, Custom set, XPath on EventID 1102). 104 (System log cleared)
// arrives in Event through the session-host data collection rule's custom XPath (chapter 11-6).
// Sentinel fails a query on a table that does not exist, so union isfuzzy=true keeps the rule
// running when one table has no rows yet. Ingestion health is the chapter 11-6 configuration
// workbook's Session hosts list: a host that is silent there cannot report a cleared log, and that
// is an operations item, not an incident.
union isfuzzy=true
(
    SecurityEvent
    | where EventID == 1102
    | project TimeGenerated, Computer, EventID, Activity, Account
),
(
    Event
    | where EventLog == "System" and Source == "Microsoft-Windows-Eventlog" and EventID == 104
    | project TimeGenerated, Computer, EventID, Activity = RenderedDescription, Account = UserName
),
(
    AzureActivity
    | where OperationNameValue =~ "Microsoft.Insights/diagnosticSettings/delete"
        or OperationNameValue =~ "Microsoft.Insights/diagnosticSettings/write"
    | where ActivityStatusValue == "Success"
    | project TimeGenerated, Computer = ResourceId, EventID = 0, Activity = OperationNameValue, Account = Caller
)
| sort by TimeGenerated desc

Note on PIM and elevated privilege coverage: The PIM activation outside business hours rule above and the built-in template New admin account creation are audit evidence for privileged-account activity: AU.L2-3.3.1 (audit records) and AC.L2-3.1.7 (capture the execution of privileged functions in audit logs). They do not implement AC.L2-3.1.6, which PIM eligibility with just-in-time activation implements (non-privileged accounts for nonsecurity functions), or IA.L2-3.5.3, which the Conditional Access MFA policies implement; each of those is assessed on its own objectives, with these rules as the monitoring half of the evidence.

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.

For the GCC-High-specific list of which templates to save and when, grouped Tier 1 (save now), Tier 2 (save but expect sparse content), Tier 3 (defer until preconditions are met), see Step 4: Save workbook templates for client demonstration above.

CMMC 2.0 workbook prerequisites. The CybersecurityMaturityModelCertification(CMMC)2.0 workbook requires NIST SP 800-171 Rev. 2 enabled in Defender for Cloud, continuous export configured to the Sentinel workspace, and 12–24 hours for the initial assessment pass to complete. See Step 3: Enable CMMC 2.0 posture assessment for the full prerequisite chain and validation query.

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-EID-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

Free retention floor

A Sentinel-enabled Log Analytics workspace includes 90 days of free retention in the Analytics (hot) tier for every table: substantially more than the 31-day default for Log Analytics workspaces without Sentinel. Anything beyond 90 days incurs storage cost; the per-table retention controls (Log Analytics workspace → Tables → [Table] → Manage table) let you set total retention up to 12 years and configure the Archive boundary independently.

Why 90 days is not enough for CMMC

The control text doesn't pin a number. NIST SP 800-171 Rev. 2 (and CMMC L2 control AU.L2-3.3.1: create and retain audit records) requires that audit records be retained "for an organization-defined time period." NIST SP 800-171A (the assessment guide) reads the same. Technically a documented 90-day period passes the control text, but it fails the forensic purpose audit retention exists to serve:

Driver	Period
DoD CIO Logging Requirements memo (Aug 2021, follow-on to EO 14028)	12 months minimum for audit and event-log data on DoD systems
Mandiant M-Trends median dwell time	≈10 days median in recent reports, but the tail extends to 6+ months for sophisticated APTs: 90 days routinely misses the initial-compromise window
DFARS 252.204-7012(c): CUI cyber incident reporting	Requires preservation of forensic images, packet captures, and contractor system images for at least 90 days "to support DoD-led damage assessment": separate from baseline log retention but signals DoD's expectation that you retain enough to investigate
DCMA / DCSA assessment practice	Typically expects 1–3 years of audit log retention as evidence of a mature audit program

Practical bar for a CUI enclave: 365 days Analytics-tier (hot) + 2 years long-term/archive = 3 years total. The 365-day hot window covers most forensic investigation depth at queryable speed; the 2-year archive satisfies long-tail "we kept it" requirements at low cost via on-demand restore. Document the period in the SSP and the Audit Log Retention Policy: assessors care more about the documented policy and its adherence than the exact number.

Retention tiers and how to choose

Tier	Cost shape (approximate, Azure Government PAYG: verify with the Sentinel pricing calculator)	Query performance	Use
Analytics (hot)	Free for first 90 days on a Sentinel-enabled workspace; ≈$0.16/GB-month beyond	Fastest: full KQL real-time	Active investigation, detection rule lookback. CMMC sweet spot is 365 days.
Auxiliary plan	≈$0.06/GB ingestion + ≈$0.005/GB-month retention beyond included	Slower KQL on long lookback; no joins	High-volume noisy tables that must be retained but rarely queried in real time (raw network logs, verbose process telemetry)
Basic Logs plan	≈$0.80/GB ingestion + ≈$0.005/GB-month retention beyond included	Limited query (no joins, no summarize)	Intermediate option: cheaper than Analytics but still queryable for compliance lookbacks
Long-term / Archive	≈$0.025/GB-month storage + restore-job cost when accessed	Requires restore (hours)	Cold-storage retention beyond 1 year
Sentinel data lake tier	New tier; substantially cheaper than Analytics for cold compliance archives	KQL via promotion jobs	Long-retention compliance archives where queries are rare but historical depth is non-negotiable

Cost example: small CUI enclave at 3-year retention

For a 100-user GCC High tenant ingesting 0.5 GB/day (the same profile as §Sentinel Cost Planning: small Entra-focused customer), the retention bill works out roughly as:

Component	Calculation	Approximate cost
90 days hot: Sentinel-enabled free tier	included	$0/month
91–365 days hot: Analytics tier extension	≈275 days × 0.5 GB/day = ≈137 GB at ≈$0.16/GB-month	≈$22/month
366 days–3 years long-term/archive	≈730 days × 0.5 GB/day = ≈365 GB at ≈$0.025/GB-month	≈$9/month
Total retention cost beyond ingestion		≈$31/month

Sustaining 3-year retention at this scale costs roughly the price of a daily coffee. Larger tenants scale linearly with daily ingestion: a 50-server enclave at 30 GB/day will see retention costs in the $1,500–2,000/month range at full 3-year hot-plus-archive depth, still small relative to the ingestion savings the M365 G5 and Defender Servers P2 free benefits deliver.

Configuration mechanics

Configure per-table retention: Log Analytics workspace → Tables → [Table] → Manage table: set the Analytics (interactive) retention for each table individually. The workspace-level default retention (set during creation) applies to any table that doesn't have a per-table override. For CUI environments, leave the workspace default at 30 days and override the following seven tables to 365 days of Analytics-tier (hot) retention. These are the minimum load-bearing tables for CMMC L2 audit evidence; extending others (raw MDE event tables, non-interactive sign-ins, Windows AMA event logs; a DeviceEvents table filtered to App Control decisions in Step 2 is small enough to join the 365-day list) is appropriate when the data is flowing and incident-response lookback depth matters, but is not required for assessor evidence:

Table	What it proves	CMMC controls
SigninLogs	Who signed in, when, from where, MFA outcome, CA policy evaluation	AC.L2-3.1.1, AC.L2-3.1.2, AU.L2-3.3.1, IA.L2-3.5.3
AuditLogs	Entra admin actions: role assignments, group membership, app consents, policy changes	AU.L2-3.3.1, CM.L2-3.4.3
OfficeActivity	M365 audit: Exchange mailbox access, SharePoint/OneDrive file ops, Teams changes, MIP label events, DLP rule matches	AU.L2-3.3.1, AC.L2-3.1.3, AC.L2-3.1.22, MP.L2-3.8.1, SC.L2-3.13.11
AzureActivity	Azure control plane: resource creation/deletion, diagnostic-setting changes, subscription-level role assignments	AU.L2-3.3.1, CM.L2-3.4.3
SecurityIncident	Sentinel and Defender XDR incidents: "investigation occurred" evidence	IR.L2-3.6.1, IR.L2-3.6.2
SecurityAlert	The raw alerts that fed incidents: demonstrates that detection rules are firing	SI.L2-3.14.6, SI.L2-3.14.7, IR.L2-3.6.1
WVDConnections	Every remote-access session brokered through the AVD Gateway: user, client IP, client OS and type, session host, transport (from the host pool's Connection diagnostic category, AVD Runbook Step 7)	AC.L2-3.1.12, AU.L2-3.3.1

SIEM: Compliance Control Mapping

GCC High (CMMC)

SIEM CMMC Control Mapping

NIST Control	Sentinel Capability
AC.L2-3.1.12: Monitor and control remote access sessions	WVDConnections records every session brokered through the AVD Gateway (user, client IP, client OS and type, session host, transport); the AVD rule under Custom Analytics Rules alerts on a user's first connection from a new client; retained 365 days (Log Retention)
AU.L2-3.3.1: Audit records (create and retain)	Sentinel ingests and retains audit logs from all connected sources (Entra, M365, Azure, Intune); long-term retention configured to 3+ years, immutable in Log Analytics
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: Time stamps	Correlate source timestamps in Log Analytics and retain endpoint/server clock-synchronization evidence. A UTC timestamp or ingestion time alone does not establish synchronization with an authoritative time source.
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.

DFARS 252.204-7012: contract clause coverage

CMMC L2 implements NIST 800-171, but the contractual instrument most DIB customers actually sign is DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting. The clause has its own evidence and reporting requirements that overlap with, but aren't identical to, the NIST controls above. Sentinel covers the audit and forensic-preservation elements directly:

DFARS clause	Requirement	Sentinel coverage
252.204-7012(b)	Implement NIST SP 800-171 controls	All AU.L2 controls in the table above; CMMC posture rules from Step 3 produce the per-control compliance evidence
252.204-7012(c)(1)	Report cyber incidents to DoD within 72 hours of discovery	SOAR playbooks (Notify-SOC-on-MDE-Isolation, custom DIBNet-submission playbook) automate the 72-hour reporting workflow with a timestamped audit trail of who notified, when, and what was sent
252.204-7012(c)(1)(ii)	Preserve forensic images, packet captures, and system images for at least 90 days	Log Analytics archive tier holds 90 days of audit data minimum (recommendation is 3 years). For VM-level forensic images, pair Sentinel with Azure Backup snapshot retention on the affected VM
252.204-7012(c)(7)	Provide DoD with media or images on request during damage assessment	Sentinel restore-from-archive (cold tier) plus Recovery Services Vault snapshots together produce the response artifacts

Reference the DFARS clause directly in the SSP narrative for the audit-and-incident-response control family: assessors recognize the DFARS-to-NIST mapping and a direct citation often shortens the conversation.

Commercial

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

NIST SP 800-171 Rev. 3

Control	Sentinel Capability
3.1.12: Remote access	WVDConnections session records from the AVD host pool; new-client detection rule; 365-day retention
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.