In many environments where I work, the Microsoft security solutions are deployed, and the icing on the cake, there is also Azure Sentinel in use. From an integrations perspective, the data connectors between native Microsoft products are extremely easy to deploy.

But, when you have 3rd party SIEM in use and you want to have security events/alerts sent from the cloud to another location, things might not be so straightforward.

The motivation for this blog came from the community, basically, the question was “How can I send Azure AD Identity Protection (IPC) events to 3rd party SIEM”?

Kudos to my highly skilled colleague Joosua Santasalo (@santasalojoosua) for help with the Azure Logic Apps part.

Background

Azure AD Identity Protection (IPC) is a tool that allows organizations to discover, investigate, and remediate identity-based risks in the environment. I have written multiple IPC related blogs and the latest entries can are found from the links below:

Azure AD Identity Protection APIs were announced in Microsoft Ignite 2019 those are:

  • riskDetection
  • riskyUser
  • signIn (Azure AD)
  • identityRiskEvent – this API is deprecated

From these APIs, you can query information of both user and sign-in linked risk detections and naturally all information related to the detections (descriptions from docs.microsoft.com)

riskDetection – Query Microsoft Graph for a list of both user and sign-in linked risk detections and associated information about the detection. Risk detections in Azure AD Identity Protection include any identified suspicious actions related to user accounts in the directory.

riskyUsers – Query Microsoft Graph for information about users that Identity Protection detected as risky. User risk represents the probability that a given identity or account is compromised. These risks are calculated offline using Microsoft’s internal and external threat intelligence sources, including security researchers, law enforcement professionals, security teams at Microsoft, and other trusted sources.

signIn – Query Microsoft Graph for information about Azure AD sign-ins with specific properties related to risk state, detail, and level. A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. These risks can be calculated in real-time or calculated offline using Microsoft’s internal and external threat intelligence sources, including security researchers, law enforcement professionals, security teams at Microsoft, and other trusted sources.

Architecture

With 3rd party SIEM solutions, there are more components included to achieve the desired scenario. In a nutshell, the following resources are needed to achieve the aimed scenario, have IPC events in a 3rd party SIEM solution:

  • Azure AD Identity Protection (requires AAD P2 license)
  • Azure Logic Apps
  • Azure Event Hub
  • SIEM – IBM QRadar in this scenario

Azure Logic Apps Configuration

Azure Logic Apps is needed to connect to the IPC APIs, pull the data and send it to Azure Event Hub. In this example (just to verify the functionality) I made an HTTP request to IPC APIs and sent received data to the Event Hub. Both APIs tested:

  • riskDetections
  • riskyUsers

Remember to grant necessary permissions to your app that is connecting to the APIs.

  • IdentityRiskEvent.Read.All
  • IdentityRiskyUser.Read.All

Verify Events From API

Before creating Logic Apps I would verify that APIs contain the needed data

Create Logic Apps

Created Logic Apps that connects to both APIs, riskyUsers & riskDetections.

Azure Event Hub

Azure Event Hub is a standard integration method for many 3rd party SIEM’s. Needed configurations for the Event Hub are:

Create Event Hub Namespace

  • This is the top level of your Event Hub hierarchy and the place where you create the actual Event Hubs. For me, it reminds DFS service and DFSRoot on a conceptual level from the on-prem and Active Directory world
  • Allow access from all networks. If you don’t, QRadar is not able to connect to the Event Hub.
Machine generated alternative text: fetaeb I Networking O fetids subs p Search (Ctrl+/) Activity log Access control (IAM) Tags Diagnose end solve problems Events Settings Shared access policies Cå Scale Geo-Recovery Networking Encryption Properties Firewalls and virtual networks Private endpoint connections (previevv) Save X Discard C_) Refresh Allow access from @ All networks C) Selected networks All networks, including the internet, can access this Event Hubs Namespace.

Create Event Hub and configure it to support the integration

  • Select a logical name for your Event Hub. Mine is ”IPC-Events” to identify what’s the reason for this EH later on
  • Create shared access policies to EH. What’s needed is: “Listen”
  • Create a consumer group. The name doesn’t matter in here as long as you don’t use ”$Default” which is the default EH consumer group name
  • Enable the capture feature to test the integration. I highly recommend enabling capture after the initial configuration to verify that EH contains ISG alerts
    • Be aware that capture adds consumption and I normally use it only for testing purposes

How to use Event Hub capture feature?

The Azure Event Hub capture feature was a game-changer for troubleshooting Event Hub connections and integrations. With the capture feature, you can deliver the streaming data in Event Hubs to Azure blob storage or Azure Data Lake Store account.

When you enable the capture feature ”avro” file is created to storage account of your choice. It can be converted to JSON with java developer tools. It took a while until I found proper tools to convert the files and for saving your time here is a short instruction on how to do it.

How to convert *.avro to json?

IBM QRadar

When the Azure side is configured it’s time to configure the receiving end, IBM QRadar. More information from:

To summarize IBM QRadar needs following parameters to be configured:

  • Azure Event Hub connection string
  • Azure Event Hub consumer group name
  • Azure Storage Account connection string

Next phase – validating the incoming data. After configuration was deployed we saw that the IPC events were received by QRadar.

At the time of writing, IBM Radar doesn’t have a supported connector for Azure AD Identity Protection which means that the SOC personnel needs to do ”magic” in the QRadar end to get the most out of this integration.

Hope this helps in cloud security monitoring journey!