Sophos SIEM: eigene und verwaltete S3-Quellen anbinden

Für Sophos Next-Gen SIEM gibt es drei S3-Transportwege: einen Bucket im eigenen AWS-Konto sowie ein von Sophos verwaltetes Ziel mit oder ohne Ownership-Token. Man wählt den Weg anhand des Logexporters und des gewünschten Betriebsmodells. Ein S3-Bucket allein erzeugt noch keine normalisierten oder auswertbaren XDR-Ereignisse.

Vorausgesetzt sind eine Next-Gen-SIEM-Subscription, Zugriff auf die Integrationskonfiguration und die im jeweiligen Verfahren benötigten AWS- beziehungsweise Anbieterrechte. Die Custom-Transportauswahl ordnet Alternativen ein. Logs werden nur im freigegebenen Umfang übertragen; bestehende Logziele bleiben bis zur Abnahme erhalten.

Variante und Verantwortlichkeiten festlegen

Customer-Managed S3 passt, wenn die Logdateien in einem Bucket des eigenen AWS-Kontos bleiben sollen. Der Betreiber stellt Bucket, CloudFormation-/Lambda-Ressourcen und Trigger bereit. Dazu gehören Kostenverantwortung und ein geprüftes IAM-Modell.

Bei Sophos-Managed S3 verwaltet Sophos das Aufnahmeziel. Die Quelle benötigt dessen konkreten Alias, Pfad und gegebenenfalls Rollenparameter. Verlangt der Anbieter vor dem Export eine Datei oder einen Token zum Nachweis des Bucket-Besitzes, ist with token erforderlich. Ohne diese Anforderung verwendet man without token. Das Ownership-Token ist kein allgemeines API-Credential und kein Nachweis, dass die späteren Logs bereits vollständig ankommen.

Vor dem Pilot werden Quelle, AWS-Konto/Region, Logprefix, erwartetes Format, Identität und verantwortliche Personen dokumentiert. Reale IAM-ARNs und Tokens stammen aus der eigenen Anbieter-/AWS-Konfiguration; fremde Beispielwerte werden nicht übernommen. Secrets und zugriffsermöglichende Parameter werden geschützt gespeichert.

Eigener Bucket: Integration und Lambda-Weiterleitung

1. In Sophos Fusion vorbereiten

1. Security Operations > Integrations > Marketplace > Custom öffnen.
2. Unter Customer-Managed S3 auf Set Up klicken.
3. Die S3-Hinweise lesen, Next wählen, einen eindeutigen Integrationsnamen erfassen und mit Done abschliessen.
4. Das generierte CloudFormation-Template für die Lambda-Weiterleitung geschützt herunterladen. Es gehört zu dieser Integration und wird nicht mit einem Collector- oder NDR-Template verwechselt.

2. CloudFormation im passenden AWS-Konto ausführen

Der Bucket muss bereits die zu übertragenden Logs enthalten. Die Bereitstellung erfolgt in derselben Region wie dieser Logbucket. Benötigt werden Rechte für CloudFormation, Lambda, IAM und die weiteren im Template ausgewiesenen Ressourcen. Das generierte Template wird vor der Ausführung gegen die eigenen Sicherheits- und Kostenvorgaben geprüft.

1. In der richtigen AWS-Region CloudFormation > Create stack öffnen; bei vorhandener Stackliste With new resources (standard) wählen.
2. Unter Prepare template ein vorhandenes Template auswählen und unter Specify template die heruntergeladene YAML-Datei hochladen. Alternativ kann deren freigegebene S3-URL verwendet werden; dafür muss kein Bucket öffentlich gemacht werden.
3. Einen Stacknamen ohne Leerzeichen angeben. Bei IntegrationType den zur Quelle passenden Typ wählen. Enthält der Bucket mehrere Logtypen oder ist die Zuordnung noch unklar, nennt Sophos generic als Auswahl; daraus folgt keine bestätigte Detection-Unterstützung.
4. Unter NotificationBucket ausschliesslich den Bucketnamen eintragen, keine URL oder S3-URI. Falls bewusst SNS statt S3-Notifications verwendet wird, die dafür vorgesehene SNSNotificationarn angeben. Andere Werte nur nach geprüfter Template-Anforderung ändern.
5. Die vorgesehenen IAM-Ressourcen prüfen, die entsprechende CloudFormation-Bestätigung bewusst setzen und nach Kontrolle der Parameter den Stack mit Submit erstellen.
6. Die Events und schliesslich CREATE_COMPLETE prüfen. Ein vollständiger Stack ist noch kein Beleg für einen richtig gesetzten Trigger oder brauchbare Ereignisse.

Bucket, Stack und Lambda liegen bei diesem Standardweg im selben AWS-Konto und derselben Region. Abweichende Architektur wird nicht aus diesem Ablauf abgeleitet.

3. Den Logbucket als Trigger anbinden

1. In AWS Lambda die neu erzeugte Funktion öffnen. Sophos beschreibt das Namensmuster {STACKNAME}-sophos-xdr-lambda-{INTEGRATIONTYPE}; massgebend ist die tatsächlich im Stack erstellte Funktion.
2. Function overview > Add Trigger öffnen und S3 wählen. Eine SNS-Variante setzt den vorher separat eingerichteten Topic voraus.
3. Den Logbucket wählen und bei Event Type All Object Create Events einstellen.
4. Unter Prefix nur den für die Logs vorgesehenen Bucketprefix eintragen; ohne Prefix bleibt das Feld leer. Suffix bleibt in diesem Standardweg leer. Ein zu enger Prefix verliert relevante Dateien, ein zu breiter kann unerwünschte Daten und zusätzliche Kosten verursachen.
5. Den Hinweis auf Lambda-Kosten prüfen und mit Add abschliessen. Anschliessend Triggerzuordnung und ein neu erstelltes Testobjekt kontrollieren.

Ein Object-Create-Trigger belegt keine automatische rückwirkende Übernahme des gesamten vorhandenen Bucketinhalts. Eine gewünschte historische Aufnahme wird separat bestätigt und geplant, ohne bestehende Dateien unkontrolliert erneut zu schreiben.

Sophos-Ziel ohne Ownership-Token

1. Security Operations > Integrations > Marketplace > Custom öffnen und bei S3 Ingest – Sophos-Managed (without Ownership token) Set Up wählen.
2. Die vom Quellanbieter verlangte Identitätsart wählen: IAM User, Canonical User ID oder IAM Role. Den dazugehörigen, vom Anbieter bereitgestellten Wert eintragen und mit Done erstellen.
3. Den neuen Integrationsnamen öffnen und auf Details wechseln. Die dort angezeigten Parameter geschützt übernehmen.
4. Im Export des Quellprodukts AccessPointAlias als Bucketnamen, LogFolderPath als Zielpfad und bei Bedarf AWSRegion eintragen. Die gewählte IAM-Identität muss der beim Erstellen verwendeten entsprechen. Bei der Rollenvariante wird zusätzlich IAMAssumeRole als zu übernehmende Rollen-ARN auf der Quellseite verwendet.
5. Mit einem neuen Testereignis den Export starten und Datenaufnahme wie unten prüfen. Für diesen Weg wird keine Ownership-Challenge erfunden.

Sophos-Ziel mit Ownership-Token

Der Einstieg entspricht dem vorigen Verfahren, verwendet aber S3 Ingest – Sophos-Managed (with token). Nach Set Up werden erneut Identitätsart und der passende Anbieterwert erfasst. Danach öffnet man die Integration und Details.

Auf der Quellseite werden AccessPointAlias, AWSRegion, LogFolderPath und die passende Identität verwendet; bei IAM Role kommt IAMAssumeRole hinzu. Zusätzlich wird der angezeigte OwnershipToken nach dem Verfahren des Quellanbieters für dessen Besitzprüfung verwendet.

Die Prüfung kann mehrere Schritte benötigen: Der Anbieter schreibt eine Ownership-Challenge-Datei oder ein entsprechendes Objekt in das konfigurierte Ziel. Danach lädt man Details in Sophos erneut, liest den neuen OwnershipToken und gibt diesen dem Anbieter zur abschliessenden Verifikation. Der genaue Anbieterablauf ist massgebend; man ersetzt ihn nicht durch einen erfundenen Tokenwert oder ein selbstgebautes Testobjekt. Erst nach dessen erfolgreicher Prüfung folgt die Logabnahme.

Alle Varianten fachlich abnehmen

Die Integration erscheint unter Configured integrations. Man prüft daneben im Quellprodukt ein neues, harmloses Testereignis und vergleicht in Sophos Tenant, Quelle, Zeitstempel und Pflichtfelder. Bei eigenem S3 werden zusätzlich Bucketobjekt, Trigger und Lambda-/Stackfehler geprüft; bei verwaltetem S3 zuerst Identität, Alias, Pfad und gegebenenfalls die abgeschlossene Ownership-Verifikation.

Custom S3 sichert zunächst den Transport. Unterstützte Logtypen werden entsprechend ihrer Produktintegration normalisiert, andere können im generic-Schema ankommen. Der SIEM-Artikel trennt Transport, Parser und Erkennung. Ein grüner Status oder eine erfolgreich geschriebene Datei beweist weder die vollständige historische Übernahme noch eine Detection.

Für den Rückbau stoppt man zuerst den Export oder den dedizierten Trigger kontrolliert und prüft den weiterhin benötigten alten Logpfad. Gemeinsame Buckets, IAM-Identitäten, Topics oder Lambda-Abhängigkeiten werden nicht pauschal gelöscht. Vor Entfernen der Integration oder Cloud-Ressourcen müssen Datenaufbewahrung, Kostenreste, Abhängigkeiten und der unterstützte Löschweg geklärt sein. Das Löschen einer Integration ist kein Nachweis, dass historische SIEM-Daten gelöscht oder sämtliche AWS-Kosten beendet sind.