Skip to content
Avanet
Sign in

Sophos SIEM: connect Azure Event Hubs and Blob logs

Sophos Fusion Admin Sophos SIEM

Sophos Next-Gen SIEM can ingest custom log sources through Azure Event Hubs or an Azure Storage Account. Event Hubs delivers an event stream; with Storage, a supplied Azure Function reads log files from a blob path and forwards them. The two setups are not interchangeable.

Both require a Next-Gen SIEM subscription, an active Azure subscription and the necessary permissions in Sophos Fusion and Azure. A prepared source must actually write the required logs to the event hub or blob container. General integration setup requires appropriate Admin/Super Admin permissions; restrict Azure permissions to the resources and deployment that have been approved.

The custom transport overview helps with selection. This connection is neither a syslog data collector running in Azure nor an automatic replacement for an existing cloud or Microsoft 365 integration.

Event Hubs: prepare prerequisites and access

Supported tiers are Standard, Premium and Dedicated, not Basic. The current Sophos guide requires an internet-accessible event hub and explicitly mentions all IPv4 addresses. This is a security-relevant architectural prerequisite, not a blanket recommendation to expose an existing private hub. If it conflicts with network policy, clarify the connection with the responsible teams and Sophos before changing firewall rules.

Before configuring Sophos, selected log categories must actually stream into this hub, for example through Azure Monitor diagnostic settings. The source configuration determines which data it provides; a successful connection does not retroactively enable all audit logs.

  1. In Azure, open the Event Hubs namespace to integrate and record Host name on Overview.
  2. Under Entities > Event Hubs, open the correct hub and record its Name. Do not confuse namespace and hub name.
  3. In the hub, open Settings > Shared access policies > Add and create a dedicated policy for Sophos.
  4. Select Listen. The described read path does not additionally require send or management permissions.
  5. Open the new policy and securely save its Primary Connection String. It contains a secret; namespace, policy name and any EntityPath must identify the intended hub.

Never copy the real connection string into tickets or this KB. Record ownership and Azure’s supported rotation procedure in the operating documentation.

Connect Event Hubs in Sophos Fusion

  1. Open Security Operations > Integrations > Marketplace > Custom.
  2. Under Azure Event Hubs, click Set Up and enter a unique name in Add an integration.
  3. Enter the verified values in Event Hubs Namespace Hostname, Event Hubs Name and Event Hubs Primary Connection String.
  4. Create the integration with Done and check it under Configured integrations.
  5. Trace a new approved source event into the hub and then Sophos. Source, tenant, time and required fields must agree.

The Sophos consumer dynamically uses available partitions up to 200 partitions. This is not a throughput guarantee. The hub operator is responsible for suitable server-side capacity. ServerBusyException in API Query Log can indicate a throughput limit. Before adding partitions or consumers, check event volume and Azure capacity; Sophos directs requests for additional parallel consumers to support. Repeatedly recreating the integration does not fix capacity problems.

Storage: choose the blob path and Function plan

The Storage method requires a Storage Account, a Blob Container containing the logs and a supported Azure Function service plan. Isolated is unsupported. Sophos lists these combinations:

  • Basic: B1, B2, B3.
  • Dynamic: Y1.
  • Premium: P0V3, P1MV3, P1V2, P1V3, P2MV3, P2V2, P2V3, P3MV3, P3V2, P3V3, P4MV3, P5MV3.

This list reflects documentation dated 5 October 2026. Check the offered plan, region, capacity and Azure costs before deployment. An Event Hubs tier is not a Function plan selection.

Data Source Key identifies the container folder where log files are created. For a path such as MicrosoftInsights/2024-02-03/02hr/part=01/00004.json, Sophos gives MicrosoftInsights as the example key. Use the actual log prefix, not that example or the complete filename indiscriminately. An incorrect prefix may exclude relevant files or ingest other data.

Deploy the Storage integration and Azure Function

  1. Identify the storage account and blob container names, log prefix and intended Function plan in the correct Azure account. First establish that a current test object exists at the intended container path.
  2. In Sophos, open Security Operations > Integrations > Marketplace > Custom and select Set Up under Azure Storage Accounts.
  3. Enter an integration name, Storage Account Name, Function App Name and Data Source Key. A Function name describes its purpose, for example BusinessApplicationLogsForwarder; it does not replace inspection of the resources actually created.
  4. Select Azure Function Service Plan Type, Azure Function Service Plan Code and Azure Function Service Plan Num Workers. The documented worker default is 1; for Basic B2/B3, Sophos specifies a maximum of 3. Do not add workers as a blanket troubleshooting step.
  5. Click Done. The generated AzureFunction.json ARM template downloads automatically. Store it securely and review its resources, permissions and costs before execution.
  6. In Azure, open custom-template deployment, select Build your own template in the editor, load AzureFunction.json and click Save.
  7. Select or create the appropriate resource group. The Storage Account may be in a different subscription or resource group from the Function. Adjust Storage Account Subscription ID and Storage Account Resource Group only to reflect that actual difference.
  8. Use Review + Create to verify parameters, then Create after internal approval. Check deployment status and the Function actually created, then the integration in Sophos.

The source must continue writing logs to the correct blob container. Successful ARM deployment proves neither this source path nor forwarding. Do not assume complete retroactive ingestion of old container files; confirm required history separately.

Validate data flow and isolate faults

Sophos lists Azure Commercial Cloud and the documented US Government/DoD/GCC/GCC-High environments. This does not establish automatic availability in every tenant or Azure region; verify the specific environment and endpoint before deployment.

For either transport, record a new harmless test event. For Event Hubs, check the source, stream, Listen policy and connection details. For Storage, check the blob path, then Function deployment and its errors. Only then compare integration status and the search method confirmed for that source in Sophos.

Supported log types normalize according to their product integrations; others may arrive in generic. The SIEM guide to parsers and detection limits explains the additional checks. A green connector, file or Event Hubs counter proves neither complete normalization nor detection. If only some events are missing, check categories, time ranges and fields before expanding credentials.

Plan pauses and removal

Before removal, document sources sharing the hub, container, policy or Function. Pause using the supported source-specific export procedure and verify the result. Do not delete a shared hub or Storage Account for this purpose.

Only after history, required evidence, dependencies and restart have been clarified should the dedicated connection and unused Azure resources and secrets be removed through their documented procedures. Removing the Sophos entry guarantees neither historical-data deletion nor the end of all Azure charges. Following reversal, validate the required previous log path again with a test event.