Skip to content
Avanet
Sign in

Sophos SIEM: connect customer-managed and Sophos-managed S3

Sophos Fusion Admin Sophos SIEM

Sophos Next-Gen SIEM offers three S3 transports: a bucket in your AWS account and a Sophos-managed destination with or without an ownership token. Choose according to the log exporter and operating model. An S3 bucket alone does not produce normalized, usable XDR events.

Prerequisites are a Next-Gen SIEM subscription, access to integration configuration and the AWS or vendor permissions needed for the chosen method. The custom transport guide explains alternatives. Transfer only approved logs and retain existing destinations until acceptance.

Select the option and assign responsibilities

Customer-Managed S3 suits logs that should remain in a bucket in your AWS account. The operator provides the bucket, CloudFormation/Lambda resources and trigger, including cost ownership and a reviewed IAM model.

With Sophos-Managed S3, Sophos manages the ingest destination. The source needs its specific alias, path and possibly role parameters. If the vendor requires a file or token proving bucket ownership before exporting, choose with token. Otherwise choose without token. The ownership token is neither a general API credential nor proof that subsequent logs are arriving completely.

Before the pilot, record the source, AWS account/region, log prefix, expected format, identity and owners. Real IAM ARNs and tokens come from the relevant vendor/AWS configuration; do not copy someone else’s example values. Store secrets and access-enabling parameters securely.

Customer bucket: integration and Lambda forwarding

1. Prepare Sophos Fusion

  1. Open Security Operations > Integrations > Marketplace > Custom.
  2. Under Customer-Managed S3, click Set Up.
  3. Read the S3 information, click Next, enter a unique integration name and finish with Done.
  4. Download the generated CloudFormation template for Lambda forwarding securely. It belongs to this integration and must not be confused with a collector or NDR template.

2. Run CloudFormation in the correct AWS account

The bucket must already contain the logs to be ingested. Deploy in the same region as that log bucket. Permissions are needed for CloudFormation, Lambda, IAM and other resources specified in the template. Review the generated template against security and cost requirements before executing it.

  1. In the correct AWS region, open CloudFormation > Create stack; if a stack list is displayed, select With new resources (standard).
  2. Under Prepare template, select an existing template and upload the downloaded YAML file under Specify template. Alternatively use its approved S3 URL; no bucket needs to be made public.
  3. Enter a stack name without spaces. Set IntegrationType to the type matching the source. If the bucket contains multiple log types or the mapping is unclear, Sophos specifies generic; this does not establish detection support.
  4. Enter only the bucket name in NotificationBucket, not a URL or S3 URI. If SNS is deliberately used instead of S3 notifications, enter its ARN in SNSNotificationarn. Change other settings only to meet reviewed template requirements.
  5. Review the proposed IAM resources, explicitly acknowledge their creation in CloudFormation and, after checking parameters, create the stack with Submit.
  6. Check events and ultimately CREATE_COMPLETE. A completed stack does not prove a correct trigger or usable events.

In this standard approach, the bucket, stack and Lambda reside in the same AWS account and region. Do not infer support for another architecture from these steps.

3. Add the log bucket as a trigger

  1. In AWS Lambda, open the function created by the stack. Sophos describes the name pattern {STACKNAME}-sophos-xdr-lambda-{INTEGRATIONTYPE}; use the function actually created.
  2. Open Function overview > Add Trigger and select S3. An SNS alternative requires a separately configured topic.
  3. Select the log bucket and choose All Object Create Events under Event Type.
  4. In Prefix, enter only the intended log prefix; leave it empty if there is none. Leave Suffix empty in this standard procedure. An overly narrow prefix misses relevant files; an overly broad one may ingest unwanted data and increase costs.
  5. Review the Lambda cost notice and finish with Add. Check the trigger association and a newly created test object.

An object-create trigger does not establish automatic ingestion of all pre-existing bucket contents. Confirm and plan historical ingestion separately without indiscriminately rewriting existing files.

Sophos destination without an ownership token

  1. Open Security Operations > Integrations > Marketplace > Custom and select Set Up for S3 Ingest – Sophos-Managed (without Ownership token).
  2. Select the identity required by the source vendor: IAM User, Canonical User ID or IAM Role. Enter the corresponding vendor-provided value and create it with Done.
  3. Open the new integration and its Details tab. Store the displayed parameters securely.
  4. In the source exporter, use AccessPointAlias as the bucket name, LogFolderPath as the destination path and AWSRegion if required. The chosen IAM identity must match the one used at creation. For the role option, also use IAMAssumeRole as the role ARN to assume on the source side.
  5. Start export with a new test event and verify ingestion as described below. No ownership challenge is invented for this method.

Sophos destination with an ownership token

Use the same starting point but select S3 Ingest – Sophos-Managed (with token). After Set Up, enter the identity type and corresponding vendor value, then open the integration and Details.

On the source side, use AccessPointAlias, AWSRegion, LogFolderPath and the matching identity; IAM Role also uses IAMAssumeRole. Additionally use the displayed OwnershipToken according to the source vendor’s ownership-verification procedure.

Verification may involve multiple stages: the vendor writes an ownership-challenge file or equivalent object to the configured destination. Reload Details in Sophos, retrieve the new OwnershipToken and give it to the vendor to complete verification. The vendor’s procedure is authoritative; do not substitute an invented token or homemade test object. Validate log delivery only after that verification succeeds.

Validate all options and plan removal

The integration appears under Configured integrations. Verify a new harmless test event in the source, then compare the tenant, source, timestamp and required fields in Sophos. For customer-managed S3, also examine the bucket object, trigger and Lambda/stack errors. For Sophos-managed S3, first verify identity, alias, path and any required ownership verification.

Custom S3 initially provides transport. Supported log types are normalized according to their product integrations; others may arrive in generic. The SIEM guide separates transport, parsing and detection. A green status or a successfully written file proves neither complete historical ingestion nor a detection.

For removal, first stop export or the dedicated trigger in a controlled way and verify the required previous log path. Do not indiscriminately delete shared buckets, IAM identities, topics or Lambda dependencies. Before removing the integration or cloud resources, establish retention, remaining costs, dependencies and the supported deletion procedure. Deleting an integration does not prove that historical SIEM data is deleted or that all AWS charges have ended.