SEE - Setup with Microsoft Sentinel

3 min read

Table of contents

Overview

This guide connects the Unique Security Events Export to Microsoft Sentinel.

The pattern is: Event Hub → Logic App → Data Collection Endpoint → Data Collection Rule → Log Analytics workspace → Sentinel.

see-sentinel-pipeline.png

The Logic App reads the events from the Event Hub and sends them to Azure Monitor through the Logs Ingestion API.

Do not use the older Log Analytics Data Collector connector. Microsoft retires its API on September 14, 2026.

Prerequisites

  • The Event Hub connection data from Unique: namespace hostname, Event Hub name, consumer group, and the listen-only connection string.

  • An Azure subscription where you can create resources and role assignments.

  • A sample event record. Unique provides a sanitized sample during onboarding.

Part A: Log Analytics workspace and Sentinel

If you already operate a Sentinel workspace, use it and continue with Part B.

  1. Create a resource group for the integration.

  2. Create a Log Analytics workspace in this resource group.

  3. Open Microsoft Sentinel in the portal and add Sentinel to this workspace.

Part B: Data collection endpoint

  1. Create a Data collection endpoint (DCE) in the same region as the workspace.

  2. Open the DCE and copy the Logs Ingestion URI. You need it in Part D.

Part C: Custom table and data collection rule

  1. Open the Log Analytics workspace and go to Tables → Create → New custom log (DCR-based).

  2. Set the table name to UniqueSecurityEvents. Azure appends _CL.

  3. Create a new Data collection rule (DCR) in the wizard and select the DCE from Part B.

  4. Upload the sample event as JSON, wrapped as {"EventData": { ...record... }}.

  5. In the transformation editor, enter: source | extend TimeGenerated = now(). This is necessary because the records contain no TimeGenerated column.

  6. Complete the wizard.

  7. Open the DCR, select JSON View, and copy the immutableId.

  8. Note the stream name: Custom-UniqueSecurityEvents_CL.

Part D: Logic App

  1. Create a Logic App (Consumption) in the same region.

  2. Open Settings → Identity and enable the system-assigned managed identity.

  3. Open the DCR from Part C, go to Access control (IAM), and assign the role Monitoring Metrics Publisher to the managed identity of the Logic App. The assignment can take up to 30 minutes to become active.

  4. Open the Logic App designer and add the trigger When events are available in Event Hub from the Event Hubs connector.

  5. Create the connection with the connection string from Unique.

  6. Set the Event Hub name and the consumer group to the values from Unique. Set the content type to application/json.

  7. Add a Parse JSON action. Set the content to the trigger body and the schema to {"type": "object", "properties": {"records": {"type": "array"}}}.

  8. Add a Select action. Set From to the records array. Map one field: EventData to item().

  9. Add an HTTP action:

    • Method: POST

    • URI: <Logs-Ingestion-URI>/dataCollectionRules/<immutableId>/streams/Custom-UniqueSecurityEvents_CL?api-version=2023-01-01

    • Header: Content-Type: application/json

    • Body: the output of the Select action

    • Authentication: Managed identity, audience https://monitor.azure.com

  10. Save the Logic App.

Part E: Validation

  1. Wait for the trigger to fire, or start it with Run trigger.

  2. Make sure the run history shows successful runs.

  3. In the workspace, run the query: UniqueSecurityEvents_CL | take 10.

  4. The first records can take some minutes to appear.

  5. Do the connection test with Unique: Unique generates sample alerts in Microsoft Defender for Cloud. Confirm that the alerts appear in the table.

If the HTTP action returns 403, the role assignment from Part D step 3 is not yet active. Wait and retry.

Part F: Sentinel content

  1. In Sentinel, create Analytics rules on the new table. Two starting points:

    • Defender alerts with high severity

    • Role management operations in the Activity Log, for example PIM activations

  2. Route the incidents into your standard SOC triage process.

Last updated