Building Correlation Rules That Don't Cry Wolf
More Rules Don't Mean Better Detection. Better Rules Do
If you have worked in a SOC for any length of time, you know the feeling. You open the alert queue on Monday morning and there are 1,800 alerts waiting. You spend the first two hours closing obvious false positives. By the time you reach anything worth investigating, half the day is gone. Alert fatigue is not just an inconvenience — it is a security risk. When analysts stop trusting the tool, real incidents get buried in the noise. The root cause, more often than not, is poorly written correlation rules.
Why bad rules happen in the first place
Most SIEMs ship with default content packs written for a generic environment. They are a reasonable starting point, but your environment is not generic. When teams enable everything out of the box without tuning, they get alerts that technically fire correctly but mean nothing in their specific context. The platform is working as designed — the problem is the design was never adapted to fit the organization.
What makes a rule generate noise
Noise cause | What it looks like |
No asset context | "Failed login" fires on a printer, a server, a BYOD phone equally |
Wrong threshold | 5 failed logins in 60 min triggers — fine for a user, wrong for a service account |
Missing whitelist | Vulnerability scanner IPs trigger port scan rules every night |
Broad event category | "Firewall deny" rule fires on every blocked ad-tracking domain |
No time window tuning | Rule fires during business hours and 3 AM with the same priority |
No severity mapping | All alerts land at High regardless of the actual event significance |
The two questions to ask before writing any rule
First — is this event actually relevant to my environment? A port scan detection rule that fires every night when your vulnerability scanner runs is not a detection. It is scheduled noise. Second — is the data source reliable enough to act on? A rule built on a log source that drops events under load, or that has known parsing gaps, will produce both false positives and false negatives. Garbage in, garbage out — no matter how well-written the rule.
Asset context is the single biggest improvement you can make
Most SIEM platforms allow you to tag assets — by function, criticality, network zone, or owner. A failed authentication threshold for a domain controller should be different from the threshold for a developer workstation. A lateral movement detection rule should behave differently inside a server subnet versus a guest wireless network. Building that asset context into your rules transforms generic detections into environment-aware ones.
One practical approach: maintain a small reference set of high-value assets — domain controllers, PAM vaults, jump servers, HR systems. Any event touching these assets gets elevated priority automatically, regardless of the rule's base severity.
How to test a rule before enabling it
Never enable a new correlation rule directly in production without testing it first. Run it against 30 days of historical log data and count how many times it would have fired. If the number is in the thousands with no clear triage pattern, the rule is not ready. Adjust the threshold, narrow the asset scope, or add a whitelist condition. Repeat until the historical hit rate is something your team can realistically investigate.
Maintaining rules over time
Rules decay. The environment changes — new tools are deployed, IP ranges shift, service accounts are added. A rule that was well-tuned 18 months ago may be generating noise today because the context it was built on no longer reflects reality. Schedule a quarterly rule review where each active rule is evaluated for its true positive rate over the last 90 days. Disable rules with zero true positives. Tune rules with high false positive rates. Retire rules for technologies that are no longer in use.
Review frequency | Activity |
Weekly | Review top 10 highest-volume rules — are they generating value? |
Monthly | Check for new default content from vendor — tune before enabling |
Quarterly | Full rule audit — true positive rate, false positive rate, retirement candidates |
After major changes | Re-validate any rule touching the changed system or network segment |
Closing
A correlation rule is only as good as the data and context behind it. Start with five high-fidelity rules that your team trusts completely, rather than fifty that trained analysts to click "close" without reading. Build from there, test everything, and maintain what you have. A smaller, well-tuned rule set is always more valuable than a large, noisy one.
