Hey everyone, I've been diving into the world of EDR as my team is evaluating a few options. I keep seeing the term "telemetry" thrown around in vendor datasheets, but it feels a bit like a black box. They all promise great detection, but I'm naturally a bit cautious about what's actually being collected and transmitted.
From a practical standpoint, how do you all verify what data your EDR agent is sending back to the vendor's cloud? I'm thinking about things like:
- Process creation events (are command-line arguments included? What about full parent/child trees?)
- Network connection attempts (just destination IP/port, or the full payload?)
- File system changes (which directories are watched, and what metadata is logged?)
Is this something you typically trust from the vendor's documentation, or are there technical methods to audit this traffic directly? For instance, would you set up a proxy to intercept the agent's outbound traffic, or use host-based logging to see what the agent is accessing before it sends? I'm especially curious about balancing security with privacy/bandwidth concerns, and if there are common things you've asked vendors to clarify during procurement.
Also, has anyone compared the default telemetry levels between major players like CrowdStrike, SentinelOne, or Microsoft Defender? Do they let you granularly control the data volume, or is it mostly an all-or-nothing configuration? Thanks in advance for shedding some light on this
Trust but verify is the only approach here. Vendor documentation is a starting point, but it's often outdated or deliberately vague about the most sensitive data points, like command-line arguments or file content sampling.
For a technical audit, you'll need a layered approach. On the host, use a kernel tracing tool like ETW on Windows or eBPF/dtrace on Linux to log the agent's system calls - this shows you what it's reading. Then, you must intercept the traffic. A simple MITM proxy with a custom CA deployed to a test machine works, but be aware many agents will pin certificates or use proprietary serialization. You'll often need to decrypt the traffic at the network boundary instead, using your firewall's TLS inspection capability if you have it.
The real friction comes from the volume. I've seen agents easily hit several gigabytes per day per host when verbose logging is enabled, which is why most have sampling or filtering rules. Your procurement questions should force them to detail these exact thresholds and the specific triggers for high-fidelity collection.
The technical methods user568 mentioned are correct but operationally heavy. My team's compromise was to use the audit capabilities already in our data warehouse.
We spun up a test VM, installed the agent, and funneled all its traffic through a logging proxy we built in Python. That proxy didn't try to break TLS, it just logged connection metadata and payload sizes. We then correlated this with host-level ETW logs over a controlled 24-hour period of scripted activity (known processes, network calls, file touches).
This gave us a quantitative baseline: "When we generate X events, the agent sends Y MB with peaks at Z events/minute." We presented this data back to the vendor to pressure them into clarifying their sampling rates and retention windows. You'd be surprised how often "continuous monitoring" in the datasheet actually means "batched, sampled 10% of events under load."
The network egress volume is the practical constraint that often forces vendors to be selective, so that's a good angle for procurement questions.
That layered approach you're considering is the only sane one, but I've found most teams stop at the proxy. The real devil is in what the agent *doesn't* send during quiet periods. You get a nice baseline from scripted activity, then a month later you find it's been quietly streaming a full process memory dump during what it deems a "suspicious" API call, blowing your bandwidth projections out of the water.
Never trust the documentation on sampling or exclusions. I once had a vendor swear their agent only watched user directories, only to find it enumerating every file in /etc and /opt every six hours because their "threat model" included config file changes. You have to ask them point-blank for the exact registry keys or config files that control every collection module, and even then they'll often omit the "advanced" telemetry enabled by a support ticket.
And for the love of budget, don't forget to ask about egress costs. That "few hundred MB per host per day" can turn into a five-figure AWS bill surprise when you scale.
Your k8s cluster is 40% idle.
You're right to focus on those specific data points, as they're exactly where the privacy and bandwidth rubber meets the road. Trusting the documentation for command-line capture or filesystem watch lists is a recipe for surprise.
Your idea of a proxy for outbound traffic is necessary, but insufficient on its own. You must pair it with granular host-level auditing to see what the agent *could* send. On Windows, enable detailed Process Creation auditing (Event ID 4688) with command line, and use Sysmon to log file accesses. Then you can correlate those local logs with the encrypted blobs leaving your network. The delta between what's generated locally and what's transmitted shows you their actual sampling rate and filters.
During procurement, we forced vendors to specify the exact registry keys controlling every collection module and the data retention period on the agent before compression and transmission. If they couldn't answer that, they were out. The quiet period behavior user320 mentioned is critical, ask for their default heartbeat payload and what triggers a "burst" mode outside of explicit detections.
Benchmarks or bust.