Hey folks,
I’ve been running Microsoft Sentinel in our B2B environment for about 18 months now, and there’s one persistent quirk that our whole security team keeps tripping over: the default incident severity assignments often feel completely off-base. 😅
I’m curious if this is a shared experience in the community. We’ve had clear, multi-stage credential stuffing attempts against an external-facing app get tagged as “medium,” while a single, blocked PowerShell script from an internal dev machine (with a known, benign purpose) sometimes gets elevated to “high.” It creates a lot of noise and can really disrupt our triage workflow, especially for newer analysts who might rely heavily on that initial classification.
I understand that out-of-the-box analytics rules are designed to be broad and that tuning is expected. We’ve definitely made progress by adjusting the severity logic within our custom rules and using the incident classification and labeling features. But the baseline rules—particularly around common threats like phishing, lateral movement, or data exfiltration—seem to have a severity logic that doesn’t always match the actual risk context of a modern, hybrid environment.
Has anyone else found this to be a significant starting point? What’s been your strategy? Did you:
* Massively customize the built-in rule severities from the get-go?
* Lean more heavily on creating entirely custom analytics rules with your own risk scoring?
* Use a different layer (like SOAR playbooks or a third-party integration) to re-score incidents after creation?
I’m especially interested in approaches that balance maintaining the useful aspects of Microsoft’s default content with the need for accurate, context-aware prioritization. There’s probably a discussion here about the ethics of automation, too—if a “high” severity alert constantly cries wolf, teams start to ignore it.
Looking forward to hearing your experiences and any wisdom you’ve gathered.
— Alex
Let's keep it real.
Oh, I absolutely hear you on this one. That discrepancy between the perceived risk and the default severity tag is something a lot of teams wrestle with, especially when you're trying to build a consistent triage rhythm. I think you've nailed the core issue: those out-of-the-box rules have to make assumptions for a hypothetical "average" environment, but context is everything. A high-severity signal in one org might be Tuesday afternoon for another.
Your example about the credential stuffing versus the blocked PowerShell script is spot on. It really highlights how the default logic can miss the narrative of an attack. A series of lower-fidelity events that tell a clear story of persistence often carries more real-world risk than a single noisy-but-contained event. Tuning is expected, sure, but it feels like the starting point can sometimes steer newer analysts in the wrong direction before they learn the context of your own shop.
Have you found that certain rule categories, like the ones for identity or cloud apps, are more consistently off than others? I'm curious if patterns emerge.
Let's keep it real.