Skip to content
Avanet
Sign in

Sophos SIEM: choose a custom transport and set up HTTP Ingest

Sophos Fusion Admin Sophos SIEM

HTTP Ingest receives log messages through an HTTPS endpoint provided by Sophos. The source must support HTTP POST to a webhook or HTTP endpoint using bearer-token authentication. A Sophos Next-Gen SIEM subscription is required; an existing XDR licence alone is insufficient.

There are three separate tasks: choose the appropriate transport, connect the source, then verify the actual events. Successfully creating a connector does not prove correct normalization or detection. Review the SIEM fundamentals and licensing checks before the pilot.

Which custom transport suits the source?

Custom is intended for sources not already covered by a suitable Sophos-optimized integration. First check the Marketplace for an existing product integration and its actual event categories. A familiar vendor name does not mean every log type from that product is supported.

Six options are available for custom sources:

  • HTTP Ingest: The source can send directly using HTTPS POST and a bearer token; no customer-operated cloud infrastructure is needed.
  • Customer-Managed S3: Logs reside in a bucket in your AWS account; a supplied Lambda/CloudFormation configuration forwards them.
  • S3 Ingest – Sophos-Managed (with token): The vendor writes to a Sophos-managed destination and requires proof of ownership.
  • S3 Ingest – Sophos-Managed (without token): The same ownership model without that challenge.
  • Azure Event Hubs: The source delivers an event stream to an accessible event hub.
  • Azure Storage Account: The source writes log files to Blob Storage; an Azure Function forwards them.

The S3 guide explains the three bucket options. The Azure guide distinguishes Event Hubs from Storage and Azure Function. A syslog device may instead need an XDR Data Collector; its IP address is not a substitute for the HTTP Ingest endpoint.

Prepare the pilot and credentials

Before creating the integration, record the tenant, SIEM entitlement, source, log category and owner. General integration setup requires an appropriate Admin or Super Admin role. Access to the source’s export configuration is also needed. Its documentation must explain how the HTTP exporter uses the URL, bearer token, message format and delivery behaviour. This guide assumes no universal JSON structure.

Use an approved test source and a harmless event that can be identified reliably. Record the source time and time zone, test identifier and expected fields. Keep existing log paths until acceptance; additional forwarding must not cause unintended duplicates or transfer unauthorized personal data.

The Integration Key and URL are displayed only once. Have an approved secret store ready before creating the integration. Keys must not appear in screenshots, tickets, public repositories or test commands retained in shell history. Record the owner and controlled rotation procedure. The Integration Credential Manager supports specific credential types and is not a universal store for every ingest key.

Create HTTP Ingest in Sophos Fusion

  1. Open Security Operations > Integrations > Marketplace and select Custom.
  2. Under HTTP Ingest, click Set Up.
  3. Enter a unique name, such as BusinessApplication-Test-HTTP, and click Done. This is a freely chosen label that should identify the source and environment.
  4. Immediately save the displayed Integration Key and URL in the designated secret store. Neither will be displayed again. If they have not been stored securely, pause source onboarding and establish the supported replacement procedure; this guide does not promise retrieval.
  5. Configure the source’s documented HTTPS export using these exact values. Check bearer authentication, format and any retry or buffering behaviour against the source documentation. Do not use an invented payload or an unrelated API template.
  6. Find the new connection under Configured integrations on the Custom page. Send the planned event and verify ingestion separately.

The HTTP/parser practical example describes a synthetic source, a complete parser template and search queries. It explicitly separates expected results from the practical tenant test that is still outstanding.

Validate transport, normalization and analysis

A custom integration initially provides transport into XDR. Sophos uses existing normalization for supported log types. Unsupported or custom formats may arrive in the generic schema. The parser model in the SIEM guide explains why a custom parser and appropriate required fields may also be necessary.

For acceptance, open Security Operations > Integrations > Configured Data Sources and select the relevant source. In the source details, Advanced Search shows a prepared search for its sensor ID over the last 24 hours. Narrow the time window to the test and compare the tenant, source identifier, event time, action, and required fields with the event that was sent. Accept integrations explains the starting point, and Data Lake Search explains further filtering.

A green integration status indicates connectivity; it proves neither complete ingestion nor the correct schema. Finding generic raw text does not establish that the desired detector can use it. Missing basic search results do not rule out generic data.

Approve the pilot only when transport, usable field mapping and the intended search are independently traceable. Test a detection only if a suitable supported detection is intended for the source. An ordinary audit or sign-in event need not trigger an alert.

Isolate errors and plan removal

If data is missing, first check that the source actually sent it, used the correct endpoint and applied the stored key as the required bearer credential. Then examine source errors, the network path, time range and integration status. HTTP success alone does not replace event verification. If data exists but is mapped incorrectly, investigate the log format and parser rather than creating a second connector as a precaution.

For a planned pause, stop export using the source’s documented procedure. Before removal, establish active dependencies, historical evidence and any retention obligations. Then stop only this forwarding path and verify that the required previous log path still works. Deleting an integration, revoking a key and deleting historical data are separate operations; this guide promises no universal control for them. If a key is compromised or lost, establish the supported replacement/revocation procedure with Sophos instead of improvising an untested rotation process.