After several months of running Cybereason in our production environment, we found ourselves grappling with a classic signal-to-noise problem. The platform was generating thousands of alerts daily, a significant portion of which were benign or related to sanctioned administrative activities. This volume was causing alert fatigue and obscuring genuine threats. Through a methodical process of analyzing alert causality and refining exclusion policies, we managed to reduce our daily alert volume by approximately 60% without compromising security posture. This post details the methodology and specific configurations that yielded these results.
The key insight was moving beyond simple path-based exclusions and towards context-aware rules that consider process lineage, user context, and digital signatures. We started by exporting a week's worth of alert data and categorizing the root cause for each high-volume alert type.
Our analysis revealed three primary categories of noise:
* **Legitimate IT administrative tools** (e.g., PDQ Deploy, administrative RDP sessions).
* **Signed internal development and deployment software** (e.g., Jenkins agents, in-house installers).
* **Expected, non-malicious behavior from specific approved servers** (e.g., scheduled tasks invoking PowerShell for log rotation).
We then constructed exclusions using a layered approach, combining multiple conditions where possible to avoid over-broad rules. The most effective exclusions were those that incorporated certificate thumbprints and parent process constraints.
Here is an example of a more sophisticated exclusion rule we implemented to handle a noisy but legitimate software deployment process. This rule prevented alerts when the Jenkins deployment agent, signed with our internal code-signing certificate, spawned specific child processes.
```json
{
"exclusionName": "Approved Jenkins Deployment Chain",
"description": "Excludes alerts from the signed Jenkins agent executing approved deployment scripts.",
"enabled": true,
"process": {
"commandLine": ["deploy_script.vbs", "update_package.bat"],
"operator": "ContainsAny"
},
"parentProcess": {
"signer": "COMPANY_INTERNAL_CODE_SIGNING_CA",
"sha2": "a1b2c3d4e5f6789012345678901234567890123456789012345678901234567890"
},
"user": {
"name": ["svc-jenkins-prod"],
"operator": "ContainsAny"
}
}
```
Crucially, we avoided excluding by process path alone. We also adopted a practice of creating monitoring-specific detection rules for our administrative workstations and servers, which had a higher threshold for certain behaviors (like PowerShell usage), rather than globally excluding those behaviors.
The implementation required careful validation. We deployed each exclusion in a "log-only" mode for 48 hours, reviewing the suppressed alerts to ensure no true positives were being caught. The entire process was iterative, taking place over several sprint cycles.
The outcome was a much more manageable alert stream, allowing the SOC to focus on higher-fidelity investigations. It's important to note that this is not a "set and forget" configuration; we review the exclusion list quarterly as our toolset and environment evolve. The principle is to exclude based on *trusted context*, not just on a single, easily mimicked attribute.
testing all the things
throughput first