Hey everyone, has anyone else noticed a weirdly specific pattern with their Anomali correlation rules? I’ve been battling a persistent issue where a particular set of rules—ones that correlate login failures with unusual time-of-day access—keep triggering a flood of false positives, but *only* on Tuesdays. It's bizarre and starting to undermine our team's trust in the alerts.
Here’s what I’ve ruled out so far:
* It’s not a data source issue—the logs from our IdP and VPN are flowing in consistently every day.
* The rules themselves don't have any day-of-week logic built in.
* Our Tuesday activity isn't abnormally high compared to, say, Monday.
My current theory is that a scheduled internal system task (maybe a weekly vulnerability scan or a data sync job) runs on Tuesday mornings and generates a pattern that *looks* like a threat based on our current rule thresholds. I'm digging into that.
I'd love to hear if others have experienced something similar. Specifically:
1. How did you isolate the root cause for a periodic false-positive pattern?
2. Did you end up tweaking the rule logic, adding an exception, or just tightening the thresholds?
3. Any best practices for building "day-of-week" exclusions or conditions into correlation rules without breaking them?
I feel like there's a lesson here about the intersection of our internal workflows and threat detection logic. Sharing any war stories or quick wins would be a huge help!
—Emma
Your theory about a scheduled task is solid. I've seen nearly identical patterns before where a Tuesday-morning compliance scanner used shared service accounts, and its authentication attempts from a non-standard IP block triggered our "off-hours access" correlation. The logs looked exactly like a credential stuffing attack.
To isolate it, I'd check for any Tuesday-specific cron jobs or scheduled tasks on your bastion hosts or jump boxes. Adding a simple day-of-week exclusion felt like a band-aid, so we instead created a separate rule variant with adjusted thresholds for that specific time window and source system.
Have you considered if the false positives correlate with your team's deployment schedule? Some CI/CD pipelines set to deploy on Tuesdays can cause a spike in automated system logins.
Commit early, deploy often, but always rollback-ready.
That deployment schedule angle is a good catch. I've been burned by that exact scenario. A team moved their major weekly deployment to Tuesday "to avoid Monday chaos," and their pipeline's automated provisioning step started hitting service accounts from the build farm's IP range. Anomali saw it as a sudden cluster of logins from a new location.
The separate rule variant approach user56 mentioned is the right long-term fix, but for a quick stopgap, you can sometimes modify the original rule's threshold logic. Instead of a hard count of failures, use a percentage increase over the rolling 7-day average for that same time block. It'll still spike on a real attack, but it smooths out the weekly scheduled noise.
Of course, that assumes your historical data is clean. If last Tuesday was also flooded with false positives, your average is already poisoned. Then you're back to hunting cron jobs.
Speed up your build
"Only on Tursdays" is the classic signature of a forgotten service account tied to a maintenance window. You've ruled out the obvious, so look for the indirect.
> a scheduled internal system task
That's the start. Pull the authentication logs for the source IPs of the false positives and trace the service account. It'll likely be something with a Tuesday patch cycle, like an AV definition update or a cloud resource orchestrator. The key is that the rule is correlating failures with unusual time-of-day access. A service account that only wakes up weekly will always look unusual.
I never add day-of-week exclusions. It creates blind spots. Instead, create a separate watchlist for validated, noisy service accounts and have your rule suppress alerts if the source is in that list. It forces you to maintain an inventory, which you should have anyway.
If the historical data is polluted, your thresholds are meaningless. You'll need to baseline a clean period.
Trust but verify – and audit
Absolutely agree on the service account angle and the watchlist approach. Forcing that inventory is crucial hygiene.
One nuance I've run into, though, is when the service account is legitimate but its *failure count* is the anomaly. Maybe a downstream password rotation got out of sync, so every Tuesday it's throwing failures until it gets a cached success. In that case, the watchlist suppression would hide the real configuration drift. The rule is working as intended, telling us about a broken process.
So yeah, validate and list the noisy source, but sometimes that alert is a canary for a separate ops problem. It's a good prompt to ask if that Tuesday task is actually healthy, not just noisy.
Let's keep it real.