[Quick Tip] Understanding different Azure integrat...

ylandovskyy

Hey folks!

Today I would like to spend some time and describe the differences between different Azure integrations. I've seen that there is a lot of confusion in this area (especially around ingestion), so I would take this opportunity and make it more clear.

Microsoft 365 Defender

This integration should be your go-to integration for ingestion. It's built on top of Graph API using the latest endpoints (Alerts V2). As this connector is using Graph API, it means that every available source for alerts will feed into it (including Azure Sentinel alerts). If you want to see the list of available sources, refer to this page.

The main beauty is that it's very easy to confirm in this connector, if it's working as expected, because the same exact data is highlighted on the Alerts page in Microsoft 365 Defender portal.

Additionally, the Incidents Connector has dedicated logic in it to replicate the core experiences as much as it is to the Microsoft handling:

You can force alerts to be grouped under the same case, the same way they are grouped under incident (using SourceGroupingIdentifier)
If an alert is updated with information about new Assets/IOCs, then it will be re-ingested again
Key filters for severity, service sources, detection sources are in place to ensure that you fully control the data that goes into the system

There is a very high chance that if you are using any other connector from Azure stack in parallel to this, then you will have duplication of data somewhere.

From the automation POV, this integration doesn't offer that much, but it does support triaging actions and ability to run hunting queries.

Microsoft Graph Security

This integration was the original attempt of creating a generic integration that will be able to ingest alerts from all Azure sources. At its core, it was also built on top of the same API that is used in Microsoft 365 Defender.

So, if you don't really care about additional incidents logic that is available in "Microsoft 365 Defender - Incidents Connector", then "Microsoft Graph Security Connector" is a good replacement as it also can ingest alerts from all sources.

Recently, we added support for V2 API, so it's fully up-to-date and in terms of actions it offers everything needed for incident/alert management.

Microsoft Defender ATP (nowadays know as Microsoft Defender for Endpoint)

If you are using Microsoft Defender for Endpoint as your main EDR, then this integration is the one that you need to use for enrichment and remediation. Everything in this integration is focused on endpoint security.

The V2 connector in this integration is built on top of Microsoft Defender for Endpoint API and Graph API, but at it's core, Microsoft Defender for Endpoint API doesn't really return anything different from the Graph API.

So, at the end of the day, to make the operational overhead simpler, you can skip creating a dedicated connector for this product and instead use M365 Defender connector.

Azure Active Directory (nowadays known as Microsoft Entra ID)

This integration is your go-to for identity and access management. Enrichment of users, disabling of users, resetting password - these are the use cases for this integration.

Generally speaking, this integration is useful in any playbook that works with Azure stack.

Azure AD Identity Protection (nowadays known as Microsoft Entra ID Protection)

This integration provides additional enrichment for identities. It returns information about the risk level associated with users and you can mark users as compromised.

The connector here is focused on the Risk Detections. It's built on top of its own special API, but from our observation, the Graph API returns the same data, but it's just structured in a different way. I wouldn't say there is a lot of benefit of having this connector running in parallel to Microsoft365 Defender API.

Azure Security Center (nowadays know as Microsoft Defender for Cloud)

This integration was built to manage Azure cloud posture and ingest related alerts. It also supports triaging capabilities for the alerts that are originated in this product.

From the ingestion POV, this connector was built on the mix of Graph API and Azure Security Center API, but it's the similar situation as with Azure AD Identity Protection, where the data returned is the same, but with different structure.

Office 365 CloudApp Security (nowadays known as Microsoft Defender for Cloud Apps)

This integration was design to monitor all activity between cloud service users and cloud applications. There is additional useful information about IP and User activity that can be fetched for this service, so it definitely has it's place.

From the ingestion POV, it was built on top of its own unique API, but it's also in the scope of M365 defender, so at the current moment, there is no real reason to have it installed separately.

Office365ManagementAPI

This integration is unique as it's not tied to specifically to a product. It uses it's own special API that allows you to fetch audit information for DLP events and other audit information.

Even though M365 connector inside of it supports Microsoft Defender For Office365 service, we are not 100% confident it will pick up all events that are available via Office365 Management API (if you know more about it, then please share in the comments).

Microsoft Intune

Another complementary product for Endpoint Security. If you are using it in your tech stack, then this would be the integration to use.

Microsoft Azure Sentinel (nowadays known as Microsoft Sentinel)

This integration is designed to work the Azure Sentinel. You can do triaging of alerts/incidents, run KQL queries, run Hunting Rules.

From the ingestion POV, working with Azure Sentinel is very tricky as the product itself can behave in unexpected ways. In Azure Sentinel everything is built around incidents. For example, you can't really see what kind of IOCs/Assets were involved in the individual alerts.

This has made integration quite complex. Our main connector - "Microsoft Azure Sentinel Incident Connector v2" has a lot of backup workflows to try and fetch the necessary context. We've seen situations, where the Alert in Azure Sentinel was created almost empty with no context initially and only in several minutes it was updated. We've seen situations, where for the same rule, for one Alert the data is being available from API, while for the other one it's missing.

If you have a test environment, I would really suggest to give M365 Defender connector a try and make it the source for ingestion of Azure Sentinel data. Main reason - the data from Graph API is significantly more transparent. If you will see some major gaps, then raise it to our team and we will investigate.

Microsoft itself has already highlighted in the platform that they want to move Microsoft Sentinel data under M365 Defender umbrella. So, it's also good to be in the front of the changes.

If you have any questions, feel free to share them in the comments!