Reducing False Positives in “Privileged User Logon from New ASN” (Across Multiple Tenants in Sentinel)? #163258
Unanswered
JMichael02
asked this question in
Programming Help
Replies: 2 comments 1 reply
-
|
It can be done if you have a list of known ASNs and can whitelist them. But I'm curious to know how it can be dealt with in multi-tenant environments. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thanks for posting in the GitHub Community, @JMichael02! We're happy you're here. You are more likely to get a useful response if you are posting your question in the applicable category, the Discussions category is solely related to conversations around the GitHub product Discussions. This question should be in the |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Discussion Type
Question
Discussion Content
Hello All!
We're reviewing how to best fine-tune a detection in Microsoft Sentinel that alerts when a privileged user logs in from a new ASN.
Reference: https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/PrivilegedUserLogonfromnewASN.yaml
The default rule flags any successful logon by a privileged user from an ASN not seen across the entire organization in the past 14 days.
While this works in theory, it often causes false positives due to:
Common VPNs or cloud infrastructure with rotating ASNs
Remote/mobile users changing networks frequently
Shared ASNs reused across multiple users
Proposed Change: Per-User ASN Baseline
We tested an alternative where each user's ASN history is tracked individually, and alerts only trigger if the ASN is new to that user (not just new to the org).
This improves precision but in testing, we saw more alerts overall, especially from shared or widely-used ASNs (e.g., mobile carriers, VPNs).
Question to the Community:
What detection strategy do you recommend to reduce false positives in ASN-based logon anomaly rules?
Is per-user ASN tracking considered a best practice in your experience?
For environments where this detection needs to be deployed MDR-wide across many tenants, how would you balance:
Accuracy
Noise reduction
Maintainability
We’re looking to tune this logic for broader deployment MDR-wide across many Sentinel customers and would love to hear how others are handling this trade-off.
Any insights, examples, or best practices would be greatly appreciated!
Beta Was this translation helpful? Give feedback.
All reactions