Data collection rules (DCRs) are used to control ingestion into Microsoft Sentinel workspaces
ZTA.41205 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”Data Collection Rules (DCRs) are the Azure Monitor primitive that defines what telemetry is collected, how it is parsed and transformed (KQL ingestion-time transforms), and which workspace and table it lands in. Without DCRs, ingestion is uncontrolled: agents collect default Windows Event Log channels and Syslog facilities verbatim, every line is sent to the workspace at the Analytics tier price, and there is no opportunity to filter informational noise, redact sensitive fields, drop high-volume low-value events, or split records between Analytics, Basic, and Auxiliary plans. The security consequences are twofold. First, runaway ingestion drives the customer to lower retention or disable connectors to manage cost — both of which directly degrade detection coverage, so threat actor activity that depends on long-tail telemetry becomes invisible. Second, the absence of ingestion-time transforms means PII, secrets in command lines, and other sensitive payloads land in the workspace where they widen blast radius if a workspace reader account is compromised. DCRs paired with Azure Monitor Agent (AMA) are the documented modern path for collecting Windows Security events, Syslog, CEF, custom text logs, and Logs-Ingestion-API telemetry into Sentinel workspaces. The check confirms at least one data collection rule targets each Sentinel-onboarded workspace and flags rules that have no ingestion-time transform configured.
Remediation
Section titled “Remediation”- Data collection rules in Azure Monitor
- Collect Windows Security Events with the Azure Monitor agent
- Ingestion-time transformations in Azure Monitor
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 | Medium |
| 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
- Medium
- Impact on users
- Low
- Product
- Azure
- Feature
- Microsoft Sentinel
- Area
- Logging and detection
- Pack
- Microsoft Zero Trust Assessment