Full Report
The Uncomfortable Truth About Your Telemetry Let me start with an observation that might hit close to home. In my years working Incident Response cases and running Tabletop Exercises, I've noticed a pattern that…
Analysis Summary
# Best Practices: Building a Detection Foundation
## Overview
These practices address the "Single-Source Problem" in cybersecurity telemetry. Relying solely on an EDR (Endpoint Detection and Response) or Antivirus creates a single point of failure. These recommendations focus on building a redundant, vendor-independent logging foundation using native Windows capabilities and supplemental tools to ensure visibility even when primary security tools are bypassed or disabled.
## Key Recommendations
### Immediate Actions
1. **Audit EDR Coverage:** Verify if your EDR is actually deployed and functional on all critical assets.
2. **Verify Native Logging:** Determine exactly what Windows Security Events are currently being collected. Avoid the "we have it enabled" assumption without verifying policy settings.
3. **Enable Process Creation Events:** Ensure Windows Event ID 4688 (Process Creation) is enabled to track what applications are running across the environment.
### Short-term Improvements (1-3 months)
1. **Enable Advanced Audit Policies:** Configure specific Windows auditing for logon tracking (Event ID 4624) and session-level visibility.
2. **Deploy PowerShell Logging:** Enable Script Block Logging (Event ID 4104) and Module Logging to capture "Living-off-the-Land" (LotL) attacks and obfuscated scripts.
3. **Implement Log Aggregation:** Ensure logs are not just residing on the endpoint but are being shipped to a central, immutable location (SIEM or log manager).
### Long-term Strategy (3+ months)
1. **Deploy Sysmon:** Implement System Monitor (Sysmon) with a curated configuration to capture network connections, registry changes, and file creation events that native logs miss.
2. **Cross-Source Correlation:** Build detection logic that flags discrepancies between EDR telemetry and native Windows logs.
3. **Establish a "Foundation Mindset":** Shift from tool-based security to data-based security, ensuring telemetry survives even if a specific vendor tool is compromised or uninstalled.
## Implementation Guidance
### For Small Organizations
- Focus on enabling **Windows Event Forwarding (WEF)** for critical servers to a central collector.
- Prioritize PowerShell Script Block logging, as many entry-level EDRs struggle with script-based execution.
### For Medium Organizations
- Implement **Sysmon** using a well-known community configuration (e.g., SwiftOnSecurity or Olaf Hartong) to reduce the engineering overhead of building your own.
- Focus on "LogonID" correlation to track lateral movement across the network.
### For Large Enterprises
- Establish **Redundant Telemetry:** Ensure that every critical alert in your EDR can be corroborated by a native OS event.
- Use automation to audit the health of your logging pipeline, ensuring "blind spots" are detected programmatically if logging services are stopped.
## Configuration Examples
While technical details are expanded in further parts of the series, the following are the recommended "pillars" of the configuration:
- **Windows Security Events:** Focus on Audit Policy -> Detailed Tracking -> Audit Process Creation.
- **Logon Events:** Monitor Audit Logon/Logoff -> Audit Logon.
- **PowerShell:** Group Policy Object (GPO) -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Script Block Logging.
## Compliance Alignment
- **NIST SP 800-53:** AU (Audit and Accountability) controls.
- **CIS Controls:** Control 8 (Audit Log Management).
- **ISO/IEC 27001:** A.12.4 (Logging and Monitoring).
- **MITRE ATT&CK:** Directly addresses the "Data Sources" requirements for robust technique detection.
## Common Pitfalls to Avoid
- **The "Single Source" Trap:** Assuming your EDR is a silver bullet that captures 100% of activity.
- **Blind Enablement:** Turning on "all logging" without a plan, resulting in a "denial of service" on your SIEM due to ingestion costs and noise.
- **Missing Correlation:** Collecting logs but never linking a Process ID or Logon ID across different log types.
- **Lack of Baseline:** Not knowing what "normal" PowerShell or administrative activity looks like before turning on alerts.
## Resources
- **MITRE ATT&CK Framework:** [https://attack.mitre.org/datasources/]
- **Sysmon (Windows Sysinternals):** [https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon]
- **TrustedSec Blog Series:** Refer to Parts 2-5 for specific Audit Policy and Sysmon configuration files.