Sentinel duplicate alerts and incidents

Question

In sentinel We have an alert "User Assigned Privileged Role" and it repeats every hour for a day or two. How do I stop it repeating itself.

The rule itself triggers when an administrator changes permissions for another user (or themselves) typically grants admin permissions.

I am unsure if I need to change the base rule, create a suppression, or some other technique. The fields it uses are:

1. TimeGenerated
2. ActivityDisplayName
3. UserPrincipalName
4. TargetUserPrincipalName
5. RoleName
6. Result
7. IPAddress
8. CorrelationId
9. ConditionalAccessStatus
10. Location

I need help on how to approach this issue. I am new to KQL and sentinel.

Thank you,

Answer 1

Hello, the answer maybe all of the above.

Some options:

1. If you trust your 'named' Administrators :-) then you could exclude them in a Watchlist added to the KQL or using an Automation Rule - this is a basic example:

Tip: If you do this, you may need a secondary rule to monitor the status of these in case of unexpected behaviour. Having a rule or even a report that looks for volume of closed Incidents is always a good thing, to detect spikes.

Option 2, Amended the KQL to look up Incidents for this rule for the previous Hour, for the same Admin user, if you find the Incident already for the same user and it was checked and closed, could you ignore it if it was previous deemed ok?

If you actually checked back for one day (not an hour), it means that the Admin gets alerted on once, the SOC checks it, then all alerts for the next 23hrs could be ignored?
You might also be able to do this in a Playbook?

Option 3
Anomaly detection can be useful here to look back on the last 14day pattern to see if the Admin is doing more work than normal. https://learn.microsoft.com/en-us/kusto/query/series-decompose-anomalies-function?view=microsoft-fabric and my "go to" article: https://m365internals.com/2021/02/16/hunting-for-anomalies-with-time-series/
This will take work to develop and test.

There are pros and cons for both solutions, I slightly favour option 2 as its reasonably simple, but your SOC may have an opinion? Option 3 is probably the best but could be complex if you are new to KQL.

1. If you have a bad admin you wont know about it, as they are always ignored.
2. If you have a bad admin, they may get away with it for up to 23hrs