Skip to main content

​
Overview

The Microsoft Sentinel integration (INT-009) ingests Sentinel incidents into CaseBender and can push case dispositions back to Sentinel when a case is closed.

Inbound Ingestion

Sentinel incidents are ingested — either pulled automatically on a schedule (recommended) or pushed via a webhook / Logic App — then normalized and turned into alerts.

Outbound Disposition Sync

When a linked CaseBender case is closed, the Sentinel incident status and classification are updated with an audit comment.
Recommended: enable Automatic polling. CaseBender can pull new incidents on a schedule directly from your Log Analytics workspace — no Logic App, data connector, or inbound endpoint is required. See Automatic polling.
This integration uses the Azure Security Insights REST API and authenticates with an Azure AD (Entra ID) application using the OAuth2 client-credentials flow (scope management.azure.com).

​
Capabilities

​
Prerequisites

1

Register an Azure AD application

In the Microsoft Entra admin center, register an app and create a client secret. Record the Directory (tenant) ID, Application (client) ID, and secret value.
2

Assign the workspace role

Grant the app the Microsoft Sentinel Reader role on the Sentinel-enabled Log Analytics workspace (for inbound). For outbound close-back, grant Microsoft Sentinel Responder.
3

Collect workspace coordinates

Record the Subscription ID, Resource Group, and Log Analytics workspace name.
4

Network egress

The CaseBender poller must reach login.microsoftonline.com and management.azure.com.

​
Configure the integration in CaseBender

1

Open the integration catalog

Go to Settings → Integrations → Create, then choose Microsoft Sentinel from the SIEM category.
2

Enter Azure credentials and workspace

3

Enable automatic polling (recommended)

4

Configure auto-case creation

​
Inbound (automatic polling, recommended)

1

Scheduled pull

On each interval, CaseBender lists incidents from the workspace with properties/lastModifiedTimeUtc greater than the last cursor, ordered ascending. On the first run, incidents modified within pollingInitialLookbackHours are imported.
2

Cursor + deduplication

CaseBender advances a per-integration cursor to the newest lastModifiedTimeUtc. Incidents are deduplicated by incident name, so overlapping polling windows never create duplicates.
3

Normalization

Each incident is normalized into a CaseBender alert, and the Sentinel incident identifier is preserved so outbound close-sync can find it later.
Polling runs in CaseBender’s background poller service. Ensure it can reach login.microsoftonline.com and management.azure.com (directly or via your proxy).

​
Outbound: syncing case dispositions to Sentinel

When a linked case is closed, CaseBender updates the Sentinel incident status (to Closed) and classification, and adds an audit comment. Outbound requires the Microsoft Sentinel Responder role.

​
Security considerations

  • Least privilege — grant Sentinel Reader for inbound only; add Sentinel Responder only if you enable outbound close-back.
  • Secret handling — rotate the client secret on your organization’s schedule.
  • Network — restrict egress to login.microsoftonline.com and management.azure.com.

​
Troubleshooting

Verify the tenant/client IDs and secret, and that the app has the Sentinel Reader role on the workspace. Confirm the subscription ID, resource group, and workspace name are correct.
Confirm Enable automatic polling is on and the workspace coordinates are correct. Check the poller can reach management.azure.com. On first run only incidents within pollingInitialLookbackHours are imported.Make sure all CaseBender services are running — with Docker, docker compose ps should show the worker and misp-processor services Up.
Ensure the app has the Sentinel Responder role and the case is linked to a Sentinel incident. Check the case timeline for the sync result.

​
Related documentation