Security tables are provisioned on the appropriate Log Analytics storage plan (Analytics, Basic, or Auxiliary)
ZTA.41217 is in Maester 3.0.0-preview and not in the stable 2.3.0 release yet. It will be in the next stable release. To use it now, install the preview:
Install-Module Maester -AllowPrerelease -ForceHow to get the preview, and go backUse the preview in GitHub Actions
Overview
Section titled “Overview”Log Analytics tables can be provisioned on three plans, each with a different ingest cost, query cost, and detection capability: Analytics (full KQL, real-time analytics rule support, UEBA, scheduled rules; highest ingest cost), Basic (KQL with limitations, no scheduled analytics rules, search jobs over 8-day interactive window; mid ingest cost), and Auxiliary (very low ingest cost, no scheduled rules, queryable only via search jobs and Summary Rules over 30-day interactive window). Putting a high-fidelity, low-volume detection source like SigninLogs, SecurityAlert, or IdentityLogonEvents on Auxiliary breaks every analytics rule and incident-creation workflow that depends on it (the rules cannot run against Auxiliary tables) — meaning attacker-relevant signals such as impossible-travel sign-ins, DCSync, or token-replay silently stop generating Sentinel incidents even though the data is technically retained. Conversely, putting high-volume verbose telemetry like CommonSecurityLog, Syslog, or DeviceNetworkEvents on Analytics costs roughly 4–10× more per GB than Basic/Auxiliary while delivering little marginal detection value because most of those events are used in retrospective hunting rather than scheduled rules. The plan choice is therefore a security-and-cost decision: detection-critical tables must remain on Analytics, and high-volume tables that are only hunted retrospectively are candidates for Basic or Auxiliary. This check verifies the plan assignment of the security-relevant tables in each Sentinel workspace.
Remediation
Section titled “Remediation”Run it
Section titled “Run it”The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
Install-Module ZeroTrustAssessment -Scope CurrentUserConnect-MaesterInvoke-Maester -Pack ZTA -SkipBuiltInLeave out -SkipBuiltIn to run Maester’s own checks in the same run.
About this check
| Severity | Medium |
| Effort to fix | Low |
| Impact on users | Low |
| Pillar | SecOps |
| Category | Security information and event management |
| Product | Azure |
| Feature | Microsoft Sentinel |
| Area | Logging and detection |
| Licence | Consumption-based: Microsoft Sentinel |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester’s: the assessment does not record them, so Maester keeps them in the pack’s taxonomy.json.
A Microsoft check, part of the Zero Trust Assessment pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, MIT licence.
About this check
- Severity
- Medium
- Effort to fix
- Low
- Impact on users
- Low
- Product
- Azure
- Feature
- Microsoft Sentinel
- Area
- Logging and detection
- Pack
- Microsoft Zero Trust Assessment