Skip to main content

​
Overview

The Microsoft Sentinel destination forwards Ocean events to the Log Analytics workspace that backs your Sentinel instance, using Azure’s HTTP Data Collector API. Events arrive as rows in a custom table named OceanSecurity_CL, where you can query them with KQL alongside the rest of your Sentinel data. For an introduction to event types, payloads, and delivery semantics, see the SIEM Forwarding Overview.
Microsoft has announced that the HTTP Data Collector API will be retired on September 14, 2026. After that date, Microsoft will no longer provide incident support for connectors and custom tables that rely on this API. Ocean’s Sentinel integration uses this API today; we are tracking a migration to Microsoft’s successor — the Logs Ingestion API — and will provide a forward path before the cutoff. See Microsoft’s official deprecation notice for context.

​
Prerequisites

Before configuring the destination in Ocean, gather two values from the Log Analytics workspace that backs your Sentinel:
  • The Workspace ID — a GUID, e.g. 11111111-2222-3333-4444-555555555555.
  • The Primary shared key — a long base64 string. Treat this as a secret.
You also need:
  • An Azure account with at least Log Analytics Contributor permission on the workspace (so you can read the shared keys).
  • The Azure CLI (or Azure PowerShell) installed locally. The shared key is no longer exposed in the Azure portal UI, so a command-line tool is required to retrieve it.
Ocean currently supports the public Azure commercial cloud (*.ods.opinsights.azure.com). Sovereign clouds (Azure Government, Azure China) are not yet supported.
The HTTP Data Collector API does not support Azure Monitor Private Link Scope (AMPLS). If your Log Analytics workspace is locked behind a private link, this integration cannot reach it. Wait for our Logs Ingestion API migration before connecting an AMPLS-protected workspace.

​
Get the workspace ID

You can get the Workspace ID from either the Azure CLI or the Azure portal — both show the same value. 
az monitor log-analytics workspace show \
  --resource-group <resource-group-name> \
  --workspace-name <workspace-name> \
  --query customerId -o tsv
FlagMeaning
--resource-group (-g)The Azure Resource Group that contains the Log Analytics workspace.
--workspace-name (-n)The Log Analytics workspace name (the workspace your Sentinel is connected to).
The command prints a single GUID — that’s the Workspace ID.

​
Get the primary shared key

Per Microsoft’s current guidance, workspace shared keys are no longer visible in the Azure portal. The legacy “Primary Key” and “Secondary Key” fields belonged to the older Log Analytics agent (MMA) configuration; with the move to the Azure Monitor Agent (AMA), the Settings → Agents blade has been refactored around Data Collection Rules, and the keys panel has been removed. Use one of the commands below.

​
Configure the destination in Ocean

1

Open the SIEM section

In the Ocean Portal, navigate to Integrations and find the SIEM section.
2

Connect Microsoft Sentinel

Click Connect on the Microsoft Sentinel card.
3

Fill in the basics

FieldValue
NameA friendly name (e.g. SOC Sentinel Prod).
Workspace IDThe GUID you copied above.
Workspace KeyThe primarySharedKey you copied above. Ocean stores this encrypted; it is never displayed again.
The Sentinel ingestion URL is composed automatically from the Workspace ID — you don’t enter a URL.
4

Pick events to forward

Under Events to forward, select at least one:
  • Inbound Protection — malicious cases
  • Inbound Protection — spam cases
  • AI Response — report phishing
  • AI Response — quarantine release
  • Audit Logs
5

Save

Click Create. The destination starts forwarding within a few minutes.

​
How events arrive in Sentinel

Log Analytics receives each batch of events and writes them to a custom table named OceanSecurity_CL. The first batch creates the table; later batches add rows. A few Log Analytics behaviors to know about — these come from Microsoft’s HTTP Data Collector API reference:
  • Table name has _CL appended by Azure to mark it as a custom log.
  • Column names get a type suffix. Log Analytics infers a type for each field on first ingestion and appends a suffix: _s for string, _d for double, _b for boolean, _t for datetime, _g for GUID. So event_type becomes event_type_s, is_remediated becomes is_remediated_b, and so on.
  • TimeGenerated is the ingestion time, not the event time. Ocean does not set the API’s time-generated-field header, so Log Analytics populates TimeGenerated with the moment the row was received. When you care about when Ocean actually processed the email, use the processed_at_t column (from the event payload) instead.
  • Explore the schema before writing complex queries. Different event types share the same table but have different fields. Run OceanSecurity_CL | getschema | order by ColumnName asc once after the first ingest to see the exact column names and types Log Analytics created for your payloads — Azure’s inference rules around nested objects can vary, so the schema is the source of truth.
  • First-ingest latency. It can take 5–10 minutes after the first event for the _CL table to appear in the schema browser. The table is queryable immediately once it shows up.
See the event payload reference for the full schema of each event type.

​
KQL examples

These examples query the OceanSecurity_CL table using only top-level scalar fields. Run OceanSecurity_CL | getschema first to see the exact columns in your workspace, then adapt the queries to project the fields you need. Count events by type over the last 24 hours: 
OceanSecurity_CL
| where TimeGenerated > ago(24h)
| summarize count() by event_type_s
| order by count_ desc
Find malicious inbound emails Ocean remediated in the last 24 hours: 
OceanSecurity_CL
| where TimeGenerated > ago(24h)
| where event_type_s == "inbound_protection"
| where is_remediated_b == true and verdict_s == "malicious"
| project TimeGenerated, subject_s, verdict_s, remediation_action_s, attack_type_s
| order by TimeGenerated desc
Phishing reports per day this week: 
OceanSecurity_CL
| where TimeGenerated > ago(7d)
| where event_type_s == "report_phishing"
| summarize reports = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated asc
Nested objects in the JSON payload (for example recipient.address, analysis.verdict) are stored by Azure under columns derived from the top-level key. The exact representation depends on Azure’s type inference at first ingest — getschema will show you whether nested fields appear as their own columns or as JSON-encoded strings that you need to read with parse_json().

​
Troubleshooting

SymptomLikely causeResolution
Destination shows Authentication failedWrong Workspace ID or Workspace Key, or the key was rotated.Re-fetch the Workspace ID and the primarySharedKey via the Azure CLI and update the destination.
Destination shows Endpoint unreachableWorkspace ID is malformed or the workspace was deleted.Verify the GUID and that the workspace still exists in Azure.
Destination shows Invalid request with InvalidAuthorizationThe shared key has been regenerated in Azure since the destination was created.Re-fetch and update the Workspace Key.
Table doesn’t appear in SentinelLog Analytics takes 5–10 minutes to materialize a brand-new _CL table.Wait ~10 minutes after the first export and refresh the schema browser.
Table exists but column names look wrongLog Analytics added type suffixes (_s, _b, _d, _t, _g) on first ingest.Use the suffixed names in KQL — see the examples above.
Cannot read shared keysYour Azure account lacks Log Analytics Contributor on the workspace.Ask your Azure admin to grant the role on the workspace’s resource group.
For the full event schema, see the SIEM Forwarding Overview.