Having recently completed a multi-tenant Kubernetes migration for a financial services client, one of the most persistent post-migration operational issues we've encountered is alert fatigue specifically from commodity malware detections via CrowdStrike Falcon. While the platform's depth is exceptional, the volume of low-priority alerts for things like generic trojans, script kiddie tools, and widespread ransomware variants was drowning out more subtle, targeted activity. The SOC was spending cycles on what were essentially background noise events.
Our approach was to implement a layered filtering strategy within the Falcon console, moving beyond simple severity adjustments. The goal was not to *ignore* these detections, but to categorize and route them differently to prevent console flooding. This is highly environment-dependent, but the core logic we applied can be adapted.
We built a custom IOA rule group focused on **contextual suppression**. The key was combining multiple conditions to reduce false positives. A simple example filter logic we used to demote (not hide) commodity malware alerts:
* **File Reputation:** `Is known malware` AND `Prevalence > 100,000` (leveraging CrowdStrike's own telemetry).
* **Execution Context:** Combine with `Parent Process` being a common browser or email client (`chrome.exe`, `outlook.exe`) AND `Command Line` contains common script interpreter patterns (`powershell -ep bypass`, `cmd /c`).
* **Target Path:** Check if the file is written to temporary user directories (`AppDataLocalTemp`, `Downloads`) rather than system or sensitive locations.
* **Exclusion:** Crucially, we added an **exception clause** to ensure any detection that ALSO had a `Technique` (MITRE ATT&CK) mapping to `T1059.001` (PowerShell) or `T1566` (Phishing) with a high-confidence `Objective` (like "Credential Access") would retain its original severity.
We implemented this primarily through Falcon's **Custom IOA** and **Event Stream Filters**. For Event Stream, a filter sent to our SIEM looked something like this (conceptual):
```sql
(behaviors.detect_description:"*Trojan.Generic*" OR behaviors.detect_description:"*Ransom.Win32*")
AND behaviors.file_occurrences > 100000
AND NOT behaviors.technique:"T1059.001"
AND behaviors.objective:"Impact"
```
This routed high-prevalence, impact-focused malware to a low-priority SIEM queue, while ensuring any PowerShell-based delivery (even of common malware) kept its priority.
The pragmatic takeaway: Blindly filtering on detection name is dangerous. The effectiveness comes from stacking prevalence, execution context, and MITRE technique data. This reduced our commodity malware console alerts by ~70%, allowing the team to focus on the novel TTPs and post-exploitation behavior that actually matters for our threat posture. Regular review of filtered events is mandatory to tune exceptions.
Has anyone else implemented a similar multi-attribute filtering approach? I'm particularly interested if you've found reliable ways to incorporate CrowdStrike's Threat Graph context (like if the host is internet-facing) into automated alert prioritization logic.
- Mike
Mike