Every false alarm costs an analyst a few minutes. The bigger cost comes later: after the hundredth harmless “brute force” alert from the same backup server, people stop reading that rule’s alerts carefully, and the real attack arrives looking exactly like the noise. That is alert fatigue. Joint SIEM guidance published in May 2025 by the Australian Cyber Security Centre (ACSC), the US Cybersecurity and Infrastructure Security Agency (CISA) and partner agencies names the same risk: a flood of false positives leads teams to miss or delay their response to real incidents.
This guide shows how to cut false positives without creating blind spots, using a loop any SIEM team can run every month. It ends with the specific tools UTMStack provides for each step; we build UTMStack, so weigh that part accordingly.
The short answer: reduce SIEM false positives rule by rule, not all at once. Measure which rules produce the most false alarms, read a sample of their alerts to find what the harmless ones have in common, and apply the narrowest fix: tighten the condition, adjust the threshold, exclude one known system, or group repeats into one alert. Test the change against both the noise and a real attack sample, document every exclusion with an owner and a review date, and never fix noise by switching off logs.
False positive, benign or real: name the problem first
Not every unwanted alert is a false positive, and the fix depends on which kind it is.
| Verdict | What happened | Example | The right fix |
|---|---|---|---|
| True positive | The rule fired on real malicious activity | An attacker guessing passwords | Respond |
| Benign true positive | The rule worked, but the activity was authorized | A vulnerability scanner probing every port | A narrow exclusion or an automatic tag |
| False positive | The rule fired on something it was not meant to catch | A “ransomware” rule firing on a backup job rewriting files | Fix the rule’s logic |
| False negative | No alert, though an attack happened | A rule reading a field the parser never fills | Fix the data or the rule, then test |
The last row matters as much as the first three. The same guidance warns that teams come to rely on their alerts, so a rule tuned into silence can be worse than a noisy one.
Where SIEM false positives come from
- Default rules never adapted to your environment. In a 2026 SANS Institute survey of 307 practitioners, run with Anvilogic, 66% of false positives came from vendor-provided rules, about the same as the 64% reported in 2025. Built-in rules are a starting point written for an average network, not yours.
- Thresholds and windows that do not fit. A limit of 3 failed logins in 10 minutes will fire every Monday morning.
- Missing context. The rule cannot tell a scanner, a backup server or an administrator from an attacker.
- Repeats. One attack, or one misconfigured service, raises the same alert hundreds of times.
- Change. A new application, a migration or a new admin tool makes yesterday’s baseline wrong.
- Too much low-value data. The joint guidance notes that ingesting too many logs costs money and leads to false positive alerts.
Teams measure false positives more than they fix them
Survey of 307 practitioners by the SANS Institute with Anvilogic, State of Detection Engineering 2026
The tuning loop, step by step
The monthly tuning loop
Work on the noisiest rules first, one at a time
- MeasureAlerts and false positives per rule over 30 days
- DiagnoseRead 10 to 20 alerts; find what the harmless ones share
- Fix narrowlyCondition, threshold, one exclusion or grouping
- TestThe noise stops; a real attack sample still fires
- DocumentWhat, why, who, and a review date
- ReviewEvery exclusion again within six months
1. Measure noise per rule
You cannot tune what you do not count. Ask analysts to record a verdict every time they close an alert: true positive, benign or false positive. After 30 days, list your rules by the number of false positive and benign closures. Tune from the top of that list. A handful of rules usually account for most of the noise, so ten rules a month is a realistic pace for a small team.
2. Diagnose before you touch anything
Open 10 to 20 alerts from the noisy rule and look at the raw events, not just the alert title. Ask what the harmless ones have in common: the same host, the same service account, the same process, the same time of day, the same source address range? Ask the system owner when you are unsure. During this step the guidance gives a warning worth repeating: if a system is already compromised, its malicious activity can look “normal”, so confirm that the pattern really is legitimate before you exclude it.
3. Pick the narrowest fix
| What you found | Narrowest fix | Example |
|---|---|---|
| The condition matches more than intended | Tighten the logic | Require a failed result and an external source address |
| The threshold fires on normal peaks | Change the count or window, based on a normal week | 10 failed logins in 5 minutes instead of 3 in 10 |
| One known, authorized system or account | Exclude that system and account pair, not the whole account | The vulnerability scanner’s address, only for the port scan rule |
| One attack produces many alerts | Group repeats under one alert, or suppress duplicates | One alert per attacker and target, with later hits attached |
| Activity is normal only at certain times | Add a time condition | Admin logins outside working hours stay alerts |
| The events have no security value | Drop them at the parser or agent | Health checks and debug messages |
| The rule does not apply to you at all | Switch it off and record why | A rule for a product you do not run |
Avoid broad exclusions. “Ignore all alerts for domain admins” removes exactly the accounts attackers want. “Ignore this rule for the backup service account when it runs on the backup server” removes one known pattern and nothing else.
4. Test the change both ways
Run the changed rule against the harmless events you saw, to confirm they no longer alert, and against a sample of the real attack, to confirm it still does. A test playground or a lab with simulated attacks makes this a five-minute job instead of a hope.
5. Document every exclusion
Record the rule, exactly what is excluded, why, who approved it, the date, and a review date no more than six months out. An exclusion without a reason becomes a permanent blind spot that nobody remembers creating.
6. Review on a schedule and after change
Review the ten noisiest rules monthly, all exclusions at least twice a year, and the affected rules after any migration, new application or reorganization. Also look at rules that have not fired in 90 days: some are quiet because nothing happened, and some are quiet because their logs stopped arriving.
What not to do
- Do not stop collecting logs to stop alerts. You lose the evidence for the next investigation.
- Do not raise thresholds until a rule goes silent. That turns a noisy rule into a blind one.
- Do not delete alerts. Close or tag them so the history stays searchable and auditable.
- Do not let automated response act on a noisy rule. Fix the noise first, then automate.
Measure whether it is working
| Metric | How to calculate it | What good looks like |
|---|---|---|
| False positive rate per rule | False positive closures divided by all alerts from that rule | Falling month on month for your top rules |
| Alerts per analyst per shift | Alerts reaching people divided by analysts on shift | A number your team can actually investigate |
| Time to triage | Time from alert to first verdict | Shorter, as alerts carry better context |
| Exclusions past their review date | Count from your exclusion register | Zero |
| Silent rules | Rules with no alerts in 90 days, tested to confirm they still work | Every silent rule tested |
There is no universal “good” false positive rate. The useful number is your own trend, rule by rule.
Where AI helps, and where it does not
AI assistants are now good at the first read of an alert: summarizing what happened, pulling related events and suggesting whether it looks harmless. That saves time on every alert. It does not fix the rule that keeps producing the same harmless alert, and it should not quietly decide what gets excluded. Keep rule changes and exclusions as human decisions with a record, and let AI handle the reading. For a broader look at deduplication, correlation and suppression, see what noise reduction means in a SIEM.
How UTMStack helps
UTMStack checks each log against more than 600 rules mapped to MITRE ATT&CK as it arrives, and gives you a control for each step of the loop:
- Close as false positive. When closing an alert, analysts can choose “Complete + false positive”, which tags it so you can count false positives per rule.
- Tagging rules. Create a rule from an alert with conditions that must all match, such as a rule name plus a host name. If it applies the “False positive” tag, matching future alerts are closed automatically with a note explaining why. They are kept, so they remain searchable.
- Grouping and deduplication. Rules can file repeat hits under the first alert as “echoes”, or suppress a repeat if the same alert was raised in the past seven days.
- Rule flood guard. If one rule raises 50 open, untagged alerts from the same data source within 24 hours (the default settings, which you can change), it is switched off for that tenant and you are notified with the fix to apply.
- Precise rule edits. The rule editor supports exclusions by address range, working days and time of day, and a test mode runs your changed rule against a sample log before you save it. See SIEM correlation rules for how rules are built.
- Drop noise at the source. Parsers can drop events that have no security value; the built-in Windows parser already drops a long list of low-value event codes. On macOS, filtering at the agent cut one endpoint’s output from about 287,000 events an hour to about 465, checked against production data.
- Safe automation. Response flows can exclude named hosts, so a rule that is still being tuned cannot isolate a critical server.
- AI triage (Enterprise). The SOC-AI assistant reviews each new alert, labels it a possible incident, possible false positive or standard alert, and writes its reasoning as a note. It changes alert status only if you allow it.
If your team needs help with nights, weekends or overflow while you tune, UTMStack’s SOC Extension service backs up your existing analysts rather than replacing them. To see these controls, open the live demo, read about threat detection in UTMStack, or install the free Community edition.
Frequently asked questions
What is a false positive in a SIEM? An alert raised on activity that is not malicious and not what the rule was meant to catch. It differs from a benign true positive, where the rule worked correctly but the activity was authorized, such as a penetration test.
What causes SIEM alert fatigue? A steady stream of alerts that turn out to be harmless, often from a few untuned rules. Over time analysts start closing those alerts quickly, which is how real attacks get missed.
How do I reduce false positives in my SIEM? Count false positives per rule, start with the noisiest, find what the harmless alerts share, and apply the narrowest fix. Test the change against both the noise and a real attack, and document every exclusion with a review date.
Should I turn off a noisy rule? Only if it does not apply to your environment, and record why. Otherwise tune it. A switched-off rule detects nothing, and nobody notices until an incident review.
How long does SIEM tuning take? The first round takes weeks. The CISA and ACSC guidance says a baseline of normal activity takes at least several weeks of collecting logs and tuning alerts to build, and tuning continues for as long as your environment changes.
Can AI eliminate false positives? No. AI can speed up triage and flag likely false positives, but the rule producing them still needs fixing. Use AI to read alerts and keep humans in charge of exclusions.
Sources
- CISA: Guidance for SIEM and SOAR implementation, May 27, 2025, and the practitioner guidance PDF by ASD’s ACSC, CISA and partners
- SANS Institute and Anvilogic: State of Detection Engineering Report 2026, 307 practitioners
- UTMStack source on GitHub: rule flood guard, alerts plugin with tagging and deduplication and rule coverage methodology (macOS agent filtering figures)
