SIEM alerts not correlating? Fix it in 3 steps

Why your SIEM correlation is broken

I've seen this a hundred times. You build a correlation rule—say, three failed logins followed by a successful one from the same IP—and nothing fires. Or it fires for everything and buries you in noise. Either way, your SOC team is blind. This tripped me up the first time too, back when I ran a help desk blog and managed a Splunk instance for a mid-size company.

The good news: 90% of correlation failures come from three things. Here's how to fix them, from the 30-second sanity check to the deep dive.

Step 1: Quick fix (30 seconds) — Check your rule logic

Stop and read your rule like you're a machine. Most SIEMs (Splunk, QRadar, ELK, Sentinel) use a window of time and a sequence of events. If the time window is too tight, the rule won't catch natural delays between logs. If it's too wide, you get false positives.

Fix this now

1. Open your correlation rule in the SIEM interface.
2. Look for the time window setting. In Splunk, that's the earliest and latest in the search. In QRadar, it's the Correlation Time Interval under rule properties.
3. If your rule expects events within 5 seconds, bump it to 60 seconds. Logs from different sources (like domain controller vs. VPN) can arrive up to 30 seconds apart.
4. Check that your sequence is correct. For example, if you want Event A then Event B, make sure the rule doesn't allow B before A. In Splunk, use transaction or stats with sort. In QRadar, sequence is set in the rule wizard.

Real-world example: A client had a rule for "brute force followed by success" that never fired. Their time window was 10 seconds. But the VPN server and AD server clocks were 8 seconds off. Fix: increased window to 120 seconds. Rule started firing within an hour.

If this didn't fix it, move on.

Step 2: Moderate fix (5 minutes) — Verify log sources are feeding correctly

Your correlation rule is only as good as the data it eats. If one of the log sources in your rule is missing, misconfigured, or sending garbled data, the rule will fail silently.

Check each source

1. In your SIEM, go to Log Sources or Data Inputs (varies by product).
2. Find every source that your rule depends on. For a login correlation rule, that's usually your domain controller, VPN gateway, and maybe a web proxy.
3. Look at the last event received timestamp. If any source shows a gap of more than 5 minutes, you have a problem.
4. For Syslog sources, check if the SIEM is receiving data at all. Run a test event from the source device. In Splunk, use index=* sourcetype=* | head 10 to confirm.
5. If a source is missing events, restart the SIEM agent or syslog service on that device. In Windows, that's net stop WinRM then net start WinRM. In Linux, systemctl restart rsyslog.

My opinion: Skip the fancy dashboards for this step. Raw log data is your friend. If you can't see recent events from a source, nothing else matters.

Still broken? Time for the deep dive.

Step 3: Advanced fix (15+ minutes) — Clean up noisy data and tune the rule

Most correlation failures in production SIEMs come from noise. Your rule is drowning in irrelevant events. Or the rule is too permissive and matches on things you didn't intend.

Step 3.1: Identify noise sources

Run a raw search for the events your rule uses, but without the correlation logic. For example, if your rule looks for failed logins (Event ID 4625 on Windows), run:

EventID=4625 | stats count by AccountName, IpAddress | sort count desc

Look at the top 10 results. Are there automated service accounts that fail constantly? Or a scanner that tries old passwords? Those will trigger your rule even if there's no real attack.

Step 3.2: Add exclusions

In your rule, add a filter to exclude known noise. In Splunk, use NOT AccountName=*svc* or NOT IpAddress=10.0.0.50. In QRadar, add a Test condition under the rule that checks for specific usernames or IPs.

Real-world fix: A company had a rule for "admin login from non-corporate IP". It fired 500 times a day. Turns out their IT team used a personal VPN. We added an exclusion for the VPN exit IPs. False positives dropped to 5 per day.

Step 3.3: Tune the correlation window and threshold

If your rule uses a threshold (e.g., 5 failed logins in 10 minutes), bump the threshold or window until false positives drop. Start with a 2x increase. So 5 fails in 10 minutes becomes 10 fails in 20 minutes. Then dial it back slowly.

My rule of thumb: A good correlation rule should fire no more than 10 times per day in a small environment (under 1000 users), or 50 times per day in a large one. If it fires more than that, you're tuning for noise, not for threats.

If nothing works — rebuild the rule from scratch

Sometimes you're better off deleting the rule and starting fresh. I've seen rules that were edited so many times they're a mess of nested conditions. Build a simple version first: one event type, one time window. Test it. Then add complexity.

Quick checklist before rebuilding:

• Did you restart the SIEM service after changing the rule? In Splunk, splunk restart. In QRadar, restart the Correlation Engine.
• Are your logs normalized correctly? Check that field names match what the rule expects. For example, some Windows logs use TargetUserName, others use AccountName.
• Is your SIEM license current? Some products stop correlation on expired licenses (looking at you, QRadar).

Correlation takes patience. You're teaching a machine to find needles in a haystack. But once it works, it's beautiful.