Guide: Setting up custom alerts for SharePoint anomalous downloads in under 30 minutes

The query structure is sound, but you should explicitly filter on `RecordType` equals `14` for SharePoint activity to avoid pulling in other Office 365 operation logs. Also, including `SiteUrl` as a grouping column alongside `UserId` is crucial, as a user downloading 20 files across 10 different sites is very different from 20 files from a single repository.

You might also consider binning the `TimeGenerated` by minute within that window. It can help distinguish between a steady pace and a sudden burst, which is useful context for triage.

Good baseline query. The `SourceFileName isn't empty` check is critical, a lot of noise events have null there. Your first version is probably missing a `RecordType` filter for SharePoint though.

The 10-minute window is fine for a first pass. Anyone worried about bypass can layer in a daily rolling count later.

Test it with a lower threshold first, like 10, to see the event volume. You'll likely need to exclude a list of known service accounts or IP ranges for things like backup scripts.

Yes, testing with a scheduled query first is exactly what I did. I set mine to run every 3 hours for a couple days and just reviewed the results manually. It helped me find two internal backup processes I needed to exclude before turning on the actual alert.

I'd also add that it lets you confirm the `RecordType` filter is working right, which saved me a lot of initial noise.

You're spot on about the need for a data baseline. A static threshold chosen without it is just guessing.

Percentile analysis is the right starting point. I'd add that you should run it not just per user, but per user-and-site pairing. The context of *which* SharePoint site they're accessing matters as much as their department. A finance analyst grabbing 50 files from the public templates library is very different from grabbing 50 from the acquisitions folder.

Your point on session-based analysis is the logical next step, but it's a heavier lift for a first alert. My pragmatic take is to use that percentile analysis to create a short list of high-volume user/site pairs, then set a *separate*, higher threshold just for them. That at least moves you from one noisy global rule to a few tailored ones while you build out the session logic.

Percentile analysis is great, right up until you realize you're just building a more sophisticated lock-in. You're not paying for the compute, you're paying for the log storage to run those historical baselines in the first place.

The moment you start tailoring thresholds per user-and-site pair, you've built a monitoring snowflake that only runs in your specific Sentinel instance. Try moving that logic to another SIEM without a full rewrite. That's the real vendor trap, not the license cost.

You've correctly identified the policy problem, but policy can't be encoded into a query without data. The threshold for "finance's data" is meaningless until you know what volume that specific group actually generates. You'll just swap a global false positive for a departmental one.

Policy dictates which log source to monitor, not what number constitutes an anomaly.

You've got the dependency backwards. The data doesn't inform policy, it validates it. The policy for "finance's data" starts with a clear requirement from the business: what's the unacceptable act? Is it 10 files in a minute? 50? The number comes from the risk assessment, not the log tail. You run the percentile analysis after to see if your policy is completely insane and will fire every hour.

Otherwise you're just building a descriptive model of existing behavior and calling it governance. That's how you end up with an alert that ignores a real incident because "well, that user's 95th percentile is 120 files, so 115 downloads is fine."

That initial threshold of 20 files in 10 minutes is a great starting point, but you'll definitely need to tweak it after you see your own data. I found that on our team, 20 was way too low for some public-facing document libraries where people grab entire folders of assets regularly.

Have you considered setting up a secondary alert for repeated hits by the same user? A one-time burst might be a project, but if the same user trips the alert three times in a week, that's a much stronger signal for manual review.

Sentinel's great until you get the bill for that Office 365 connector's log ingestion. That "under 30 minutes" setup doesn't include the months of log retention you'll need to buy to establish any meaningful baseline. You're just setting up a very expensive, very basic counter.

> a monitoring snowflake that only runs in your specific Sentinel instance

Yeah, that's a real concern. I've seen this kind of thing happen in AWS when we built super-custom CloudWatch alarms for a specific VPC setup. It worked great, until we tried to replicate it.

But isn't some level of lock-in inevitable when you move beyond basic detection? Or is there a way to keep the logic portable from the start, maybe by storing thresholds in a config file instead of baking them into the KQL?

Exactly. That "basic counter" runs you about $2.50 per GB ingested. A few weeks of SharePoint audit logs while you dial in your query and you're already funding someone's Azure Christmas party.

The real joke is you'll pay that just to learn you need to exclude the same three marketing users downloading the whole image library every Monday.

That's the operational cost people gloss over. You're not just paying for detection, you're paying to discover your own noise floor.

Even when you exclude the marketing team, you'll find the quarterly financial report package download or the HR all-hands deck. The baseline period becomes a project to manually identify and whitelist every legitimate business process.

Then your "anomaly" alert just catches the one new thing you haven't seen yet.