Skip to main content

Export Security Incidents to Microsoft Sentinel

Tasks

Send security incidents to your Microsoft Sentinel workspace as OCSF Detection Findings. AIControls gets a short-lived Microsoft Entra token with a client secret or a certificate and posts each incident to a data collection rule (DCR) stream. No gateway is needed.

Before you start​

  • You need the admin role in AIControls, and in Azure the rights to create a custom table, a data collection endpoint (DCE) and a DCR in the Log Analytics workspace that Sentinel uses, and to register an application in Microsoft Entra ID.
  • AIControls must be able to reach login.microsoftonline.com and your DCE over HTTPS. Sovereign clouds (US Government, China) are not supported: the Entra authority and the *.ingest.monitor.azure.com endpoint host are fixed.
  • The event is the same OCSF 1.9.0 Detection Finding as the OCSF JSON format, wrapped in a one-element JSON array. Know which data leaves the product: see what is never exported. The same Redact actors and Include finding summaries options apply.

Create the table, endpoint and rule​

  1. Create the custom table. The columns are listed in the Sentinel table and rule schema, with a ready az monitor log-analytics workspace table create command. The table name must end in _CL, for example AIControlsFindings_CL.
  2. Create a data collection endpoint in the same region as the workspace. Copy its Logs Ingestion URI, for example https://aicontrols-ab12.eastus-1.ingest.monitor.azure.com.
  3. Create a data collection rule that uses the endpoint, declares the stream Custom-AIControlsFindings_CL with the columns in the schema reference, and sends it to the workspace table with the transform source | extend TimeGenerated = unixtime_milliseconds_todatetime(time). The reference has the full rule definition.
  4. Open the rule's JSON view and copy its immutableId, which starts with dcr-.

Register the application​

  1. In Microsoft Entra ID, go to App registrations → New registration. Copy the Application (client) ID and the Directory (tenant) ID.
  2. Under Certificates & secrets, create a client secret and copy its value. Choose a short expiry and set a reminder to rotate it; the destination reports token_invalid_client_7000222 after it expires. To use a certificate instead, upload its public part under Certificates on the same page, and keep its unencrypted RSA private key (2048 bits or more) in PEM form for the next section. Elliptic-curve keys are not supported.
  3. On the data collection rule, open Access control (IAM) and assign the role Monitoring Metrics Publisher to the application. This is the least privilege that Logs Ingestion needs; assign it on the rule only, not on the workspace or the subscription. A new role assignment can take up to 30 minutes to apply.

Configure the destination​

  1. Go to Integrations → Security export and select Add destination.
  2. Enter a unique Name and set Format to Microsoft Sentinel (Logs Ingestion).
  3. Enter the Tenant ID and Client ID, then choose the Credential: a Client secret, or a Certificate with its Private key, both in PEM form. Use one, not both. The secret and the private key are hidden after you save; leave the masked value to keep the saved one. The form checks that the key matches the certificate and shows the certificate's expiry.
  4. Enter the Data collection endpoint URL, the Rule immutable ID and the Stream name.
  5. Set the Severity filter, Event types, Automatic export, Redact actors and Include finding summaries as for any other destination.
  6. Turn the integration on, select Send Test, then Save. The test gets a token and posts one event titled AIControls export test with low severity, so it appears as a row in the table. A failure shows a short reason.

Rows can take a few minutes to appear in the workspace after the first post.

How delivery works​

  • Token. AIControls requests a client-credentials token, proving the app's identity with the secret or with a signed assertion (RFC 7523: valid for 10 minutes, signed RS256 with the private key, carrying the certificate's SHA-256 thumbprint), for the scope https://monitor.azure.com/.default and reuses it until five minutes before it expires (halfway through its life for a token that lives under ten minutes). If Logs Ingestion answers 401, it gets a new token once per delivery and sends again; a second 401 fails the delivery. The token is never written to a log, the audit trail or an API response.
  • One event per request. Each incident is one request, far below the 1 MB request limit. An event larger than that is refused with the reason payload_too_large.
  • Retries. A network error, 429 or 5xx, from Entra or from Logs Ingestion, is retried up to 3 attempts in total; an attempt is a token lookup (a request to Entra only when no valid token is cached) and one post. The wait is 1 then 2 seconds, or the Retry-After value when the service sends one. A Retry-After longer than 5 seconds is not cut short: the delivery fails with the reason of that response (http_429 from Logs Ingestion, token_http_429 or token_<error> from Entra) and automatic export tries again on its next run.
  • Automatic export. Works as for the other destinations: each incident is sent once per destination across all replicas, and a failed delivery is retried until it leaves the 24-hour window. A rejected credential stops the run, so it does not retry every incident: a failed token request, a 403, or a 401 that persists after the one new token. If you change the destination while an export is running, nothing more is sent to it under the old settings, and the incident goes to the saved destination on the next run. Automatic events carry a stable metadata.uid; add a rule to deduplicate on it if a repeat after a crash matters to you.

Check what was sent​

Every attempt is recorded in Security → Activity → Configuration as security_incident.exported, with the actor, the trigger, the destination name, the endpoint host, the event ID, the attempt count and the outcome. A failure carries a short reason. The attempt records never carry the tenant ID, client ID, client secret, private key, rule ID, tokens or response bodies. When you change the destination, the configuration audit records the change and redacts the client secret and the private key; the tenant ID, client ID, endpoint and rule ID are identifiers, not secrets, and appear in it. Scrape aicontrols_security_export_total to alert on failures.

Troubleshooting​

ReasonCheck
token_invalid_client_7000215The client secret value is wrong. Copy the secret value, not its ID.
token_invalid_client_7000222The client secret expired. Create a new one and save it in the destination.
token_invalid_client_700027With a certificate: the certificate is not uploaded to the app registration, or does not match the private key.
invalid_certificateThe saved certificate or key could not be used, for example because the certificate expired. Replace it.
token_invalid_client_700016The client ID is not an application in that tenant.
token_invalid_request_90002The tenant ID is wrong.
token_network_error, token_timeoutAIControls cannot reach login.microsoftonline.com.
http_401, http_403The application has no Monitoring Metrics Publisher role on the rule, or the assignment is still applying.
http_404The endpoint URL or the rule immutable ID is wrong, or the rule does not use that endpoint.
http_400The stream name or the declared columns do not match the event. Compare with the schema reference.
http_429, http_5xxThrottled or unavailable. Automatic export retries.
payload_too_largeThe event exceeds 1 MB, so it cannot be delivered.

See Sentinel table and rule schema for the columns, and Security Incident OCSF Mapping for every exported field.