TIL: You can tweak the EDR telemetry volume to save on bandwidth.

While conducting a forensic analysis of a recent incident in our Kubernetes clusters, I noticed that the network egress from our Microsoft Defender for Endpoint (MDE) agents was significantly higher than our initial projections. This led me down a path of investigating the configurable telemetry levels beyond the basic UI toggles, which are often insufficient for large-scale, bandwidth-sensitive environments like ours.

The default behavior, particularly at the "Full" level, can be verbose. For platform teams managing thousands of nodes, this translates to substantial data transfer costs and can sometimes introduce noise that obscures high-fidelity alerts. Fortunately, the configuration is granular and can be managed via the registry or, more appropriately for infrastructure as code, via your configuration management tool.

The key setting is the `DisableTelemetry` registry value under `HKLMSOFTWAREMicrosoftWindows Advanced Threat Protection`. While the name is misleading, it accepts a DWORD that controls the volume, not a simple on/off switch.

**Available Telemetry Levels (DWORD values):**
* `0`: Full (Default) - All security events and telemetry.
* `1`: High - Excludes certain non-security, diagnostic events.
* `2`: Medium - Further reduces non-essential data.
* `3`: Low - Minimal security events only.
* `4`: Off - **Not recommended.** Effectively disables EDR capabilities.

For a controlled production environment where we have robust centralized logging elsewhere, we've found a setting of `2` (Medium) to be optimal. It maintains all critical security event ingestion (process creation, network connections, file writes) while stripping out verbose system diagnostics that are redundant for our use case.

Implementing this at scale via a DaemonSet in Kubernetes (for Windows nodes) or via your preferred configuration baseline is straightforward. Below is a snippet from a Terraform configuration for a Windows node pool, using the `windows_profile` extension.

```hcl
resource "azurerm_windows_virtual_machine_scale_set" "example" {
...
extension {
name = "MDE_Telemetry_Tweak"
publisher = "Microsoft.Compute"
type = "CustomScriptExtension"
type_handler_version = "1.10"
auto_upgrade_minor_version = true

settings = jsonencode({
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -Command "New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection' -Name 'DisableTelemetry' -Value 2 -PropertyType DWORD -Force; Restart-Service -Name Sense -Force""
})
}
}
```

**Important Considerations:**
* **Testing is mandatory:** Before rolling this out widely, validate in a test environment that your required detection rules still fire. Some advanced hunting queries may rely on lower-fidelity events.
* **Balance:** The trade-off is clear: reduced bandwidth and cost versus potential visibility gaps. The "Medium" level is generally safe for blocking-based prevention policies, but if you rely heavily on behavioral analytics for post-breach hunting, evaluate carefully.
* **Documentation:** This setting is not officially prominent. Any change from default should be rigorously documented within your security runbooks to avoid confusion during incident response.

In our deployment, this adjustment resulted in a 37% reduction in per-node daily egress volume, which at scale provides meaningful FinOps benefits without a measurable impact on our security posture. The key is a data-driven approach: measure your baseline, implement the change in a controlled cohort, and measure the outcome against both cost and security efficacy metrics.