How can DLP alerts be filtered before reaching into Alerts and Incidents table in Sentinel?

[wonder_wolf]

Goal - how to stop dlp alerts before reaching to the tables. Not interested in using any automation or playbooks.

There is a single data connector which has defender suite alerts. Even If, no dlp alerts and incidents are enabled, it reaches to alert and incidents. No analytics rules are enabled. 

We have separate team for SOC and DLP under different organization, and every team needs to see their own alerts. How do we stop them reaching to the tables in Sentinel?  

[#2]

@wonder_wolf 

From your description it sounds like you are getting these alerts from the Microsoft 365 Defender connector.  

The only way I know is to use an Automation Rule to action these.  You could take an Action of "Change Status" to "Closed" as an example, adding a comments or even a Tag.  

[#3]

Will it impact any ML in the Purview? DLP is owned by separate team not SOC. Is there a work around for this limitation?

[#4]

@wonder_wolf if its from M365 it's not the same as Purview.  Personally I'd look at some of them and assess if you want to drop them in Sentinel.  They will still be in the source system.

[#5]

Thank you indeed for your response. Is it the same for MDCA alerts since it also creates alerts info protection alerts that is also related to other teams?

[#6]

Its the same for the ~12 products listed in my second screen shot. If you are confident your other teams are looking at those portals then you can supress these in Sentinel/SOC. Even if the other teams own those solutions the SOC might want to look for spikes or trends even if you are not acting on them. e.g. There are usually 50 DLP alerts per week, but today you saw 50 which you believe is an anomaly that you can alert the other team on. Or maybe you see a high closure rate from a person not seen before (is that an attacker, hiding the alerts) etc...

[#7]

There is a bidirectional forwarding turned on, is it not still changing or impacting source-system?

[#8]

Correct, so if updating the source system where people may be working those Incidents is a concern.
Rather than changing Status you may want to set a tag - something like "This Alert mustn't be worked in Sentinel by the SOC or its Status changed".

Of course having open tickets in Sentinel isnt good, but the tagging might help - depending on how you deal with your Incidents. If you manage the tickets in a ITSM tool, then those often have other status or severities you can set that are not sync'd back to Sentinel.

[#9]

I have received suggestion of filtering at LAW table level by SME. Have you had experience doing that? To my knowledge, DCRs are only good for IaaS level/AMA agent level filtering?