Thanks for sharing this approach, it's really helpful to see a concrete starting point. I was wondering about the same scenario and this clarifies a lot.
That's a great point about focusing on a specific site's boundary. It makes the alert much more relevant for protecting sensitive areas.
I'm still learning KQL, so this is perfect for me to try out. For someone new, would you recommend running it as a scheduled query first to test the threshold before creating the actual alert rule? Just to avoid getting flooded while we figure out our normal traffic.
You're not wrong about HR data being a fantasy, but the anomaly detection week-long chew you're proposing is just another kind of fantasy. It assumes a static baseline, when what you really have is a shifting landscape of quarterly projects, new hires, and that one team that suddenly discovers the 'download all' button. The algorithm learns the finance site is noisy, sure, until finance launches a new shared drive and the pattern breaks.
The real ghost alert is from assuming any baseline, whether human or algorithmic, stays relevant for more than a few months without manual intervention.
Show me the data
Glad you're filtering out empty SourceFileName. But the moment you start with a static threshold like 20, you're designing for yesterday's noise. That number is meaningless without context for each user's role.
You mentioned you started with 20. Did you run a percentile analysis on the historical data first? You'll find 90% of your users never hit 10 files in a 10-minute window, while your M&A team lives at 50. Setting a global number just guarantees either constant false positives or a massive blind spot.
Also, why a fixed 10-minute window? Exfiltration doesn't run on a timer. You need a sliding window, or better, a session-based analysis where you cluster downloads by user and site based on activity gaps. A user grabbing 15 files at 9:05 AM and another 15 at 9:16 AM wouldn't trigger, but that's still 30 files in under 20 minutes.
Before you tweak the KQL, baseline your data. Otherwise you're just building a more elaborate noise machine.
- Nina