Filter Azure AD, Microsoft 365 defender event, logs in Microsoft Sentinel

Eduards 791 Reputation points
2022-11-09T11:39:06.37+00:00

Hi,

We have 1 tenant, but this tenant contains 2 different organizations. We want to implement sentinel, but at this moment i see that there is no option to filter out data and send only related to our organizaion.

If we connect Azure AD, Identity Protection, Azure Activity + M365 defender stuff, we will receive also data and incidents not related to our organization but also from other, but we don't want it.

Is there possibility to somehow filter data and exclude specific users from ingestion into log analytics database?

Our goal is to implement sentinel, and send all data only related to our Organization. For Azure AD, activity level etc. we could filter analytics rules and write down rows with exclusion of seconds organization domain, but still we will need to pay for it ingested data...

What are the options?

Microsoft Sentinel
Microsoft Sentinel
A scalable, cloud-native solution for security information event management and security orchestration automated response. Previously known as Azure Sentinel.
990 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Andrew Blumhardt 9,576 Reputation points Microsoft Employee
    2022-11-09T13:54:45.203+00:00

    I recommend balancing cost over complexity. The largest tables will be Syslog/CEF from network equipment, Security Events from servers, and raw data form the M365D portal. Azure Activity logs and security alerts from Microsoft security solutions are free. Syslog and servers are easy enough, only connect what you manage. There is no ingestion filter for the M365D or AAD data to my knowledge.

    You don't need to collect the raw M365D data. Also the M365D connector replaces the solution-specific rules. There are stand-alone connectors for MDE and MDI for example. Going back to these rules will provide some level of filtering in the rule properties.

    I would only split where is it easy or results in major savings. Setup an automated watchlist and filters to identify Side-A from Side-B. Use a logic app to auto close incidents related to entities from Side-B. You can also filter out Side-B from critical workbooks, email notifications, etc. Some duplication or overlap will be avoided but most will be in smaller tables that do not have a major impact on cost. I would not do anything extremely complex unless it is cost justified. Also, because you share the same tenant, both have a direct impact on security. If Side-B is compromise so are you.