Sophos SIEM: Custom-Transport und HTTP Ingest einrichten

HTTP Ingest nimmt Logmeldungen über einen von Sophos bereitgestellten HTTPS-Endpunkt entgegen. Die Quelle muss HTTP-POST an einen Webhook beziehungsweise HTTP-Endpunkt mit Bearer-Token-Authentisierung unterstützen. Dafür benötigt man eine Sophos Next-Gen-SIEM-Subscription; eine vorhandene XDR-Lizenz allein genügt nicht.

Der Ablauf besteht aus drei getrennten Aufgaben: passenden Transport wählen, die Quelle verbinden und danach die tatsächlichen Ereignisse prüfen. Ein erfolgreich angelegter Connector belegt noch keine korrekte Normalisierung oder Erkennung. Die SIEM-Grundlagen und Lizenzprüfung gehören deshalb vor den Pilot.

Welcher Custom-Transport passt zur Quelle?

Custom ist für Datenquellen vorgesehen, die Sophos nicht bereits mit einer passenden optimierten Integration abdeckt. Zuerst prüft man im Marketplace die vorhandene Produktintegration und deren tatsächliche Ereigniskategorien. Ein bekannter Herstellername bedeutet nicht automatisch, dass jeder Logtyp dieses Produkts unterstützt wird.

Für eigene Quellen stehen sechs Wege zur Verfügung:

• HTTP Ingest: Die Quelle kann direkt per HTTPS-POST mit Bearer-Token senden; eigene Cloud-Infrastruktur ist dafür nicht nötig.
• Customer-Managed S3: Die Logs liegen in einem eigenen AWS-Bucket; eine bereitgestellte Lambda-/CloudFormation-Konfiguration leitet sie weiter.
• S3 Ingest – Sophos-Managed (with token): Der Anbieter schreibt in ein von Sophos verwaltetes Ziel und verlangt einen Ownership-Nachweis.
• S3 Ingest – Sophos-Managed (without token): Dasselbe Besitzmodell ohne diese Ownership-Challenge.
• Azure Event Hubs: Die Quelle liefert einen Ereignisstrom in einen erreichbaren Event Hub.
• Azure Storage Account: Die Quelle schreibt Logdateien in Blob Storage; eine Azure Function übernimmt die Weiterleitung.

Die S3-Anleitung erklärt die drei unterschiedlichen Bucket-Varianten. Die Azure-Anleitung trennt Event Hubs von Storage und Azure Function. Ein Syslog-Gerät benötigt hingegen gegebenenfalls einen XDR Data Collector; dessen IP ist kein Ersatz für den HTTP-Ingest-Endpunkt.

Pilot und Zugangsdaten vorbereiten

Vor der Anlage dokumentiert man Tenant, SIEM-Entitlement, Quelle, Logkategorie und verantwortliche Person. Für die allgemeine Integrationseinrichtung verwendet man eine passende Admin- oder Super-Admin-Rolle. Zusätzlich braucht man Zugriff auf die Exportkonfiguration der Quelle. Die Quellanleitung muss erklären, wie deren HTTP-Export URL, Bearer-Token, Meldungsformat und Übertragungsverhalten verwendet. Dieser Artikel setzt keinen universellen JSON-Aufbau voraus.

Als Pilot eignet sich eine freigegebene Testquelle mit einem harmlosen, eindeutig wiederauffindbaren Ereignis. Man notiert Quellzeit mit Zeitzone, Testkennung und erwartete Felder. Bestehende Logpfade bleiben bis zur Abnahme bestehen; eine zusätzliche Weiterleitung darf weder unbeabsichtigte Duplikate noch unerlaubte personenbezogene Daten erzeugen.

Integration Key und URL werden nur einmal angezeigt. Vor dem Erstellen muss deshalb ein freigegebener Secret-Store bereitstehen. Schlüssel gehören weder in Screenshots noch in Tickets, öffentliche Repositorys oder Testbefehle mit dauerhaft gespeicherter Shell-Historie. Besitzer und kontrollierter Rotationsweg werden dokumentiert. Der Integration Credential Manager unterstützt nur bestimmte Credential-Typen und ist kein universeller Speicher für jeden Ingest-Schlüssel.

HTTP Ingest in Sophos Fusion anlegen

1. Security Operations > Integrations > Marketplace öffnen und Custom wählen.
2. Bei HTTP Ingest auf Set Up klicken.
3. Einen eindeutigen Namen eingeben, etwa Fachanwendung-Test-HTTP, und mit Done abschliessen. Der Beispielname ist frei wählbar; er sollte Quelle und Umgebung erkennen lassen.
4. Den angezeigten Integration Key und die URL sofort in den vorgesehenen Secret-Store übernehmen. Beide Werte werden nicht erneut angezeigt. Sind sie nicht sicher gespeichert, wird die Quellanbindung angehalten und der unterstützte Ersatzweg geklärt; ein erneuter Abruf wird hier nicht versprochen.
5. In der Quelle deren dokumentierten HTTPS-Export mit genau diesen Werten konfigurieren. Bearer-Authentisierung, Format und gegebenenfalls Retry-/Pufferungsverhalten anhand der Quellanleitung prüfen. Keine erfundene Payload oder fremde API-Vorlage übernehmen.
6. Die neue Verbindung unter Configured integrations auf der Custom-Seite suchen. Danach das geplante Ereignis senden und dessen Aufnahme gesondert prüfen.

Eine eigene synthetische Quelle samt vollständiger Parser-Vorlage und Suchabfragen beschreibt das HTTP-/Parser-Praxisbeispiel. Dort sind erwartete Ergebnisse und der noch ausstehende praktische Tenant-Test ausdrücklich getrennt.

Transport, Normalisierung und Auswertung abnehmen

Eine Custom Integration sichert zunächst den Transport in XDR. Für unterstützte Logtypen nutzt Sophos deren vorhandene Normalisierung. Nicht unterstützte oder eigene Formate können im generic-Schema landen. Das Parser-Modell im SIEM-Artikel erklärt, warum ein Custom Parser und passende Pflichtfelder zusätzlich erforderlich sein können.

Für die Abnahme Security Operations > Integrations > Configured Data Sources öffnen und die eigene Quelle auswählen. In den Quelldetails zeigt Advanced Search eine vorbereitete Suche für deren Sensor-ID in den letzten 24 Stunden. Den Testzeitpunkt eingrenzen und Tenant, Quellkennung, Ereigniszeit, Aktion sowie benötigte Felder mit dem gesendeten Ereignis vergleichen. Den Einstieg erklärt Integrationen abnehmen, die weitere Eingrenzung Data Lake Search.

Ein grüner Integrationsstatus ist ein Verbindungshinweis; er beweist weder vollständige Datenaufnahme noch ein passendes Schema. Ein Treffer als generischer Rohtext ist ebenfalls kein Beleg, dass ein gewünschter Detector mit diesen Daten arbeiten kann. Fehlende einfache Suchtreffer schliessen generic-Daten nicht aus.

Erst wenn Transport, brauchbare Feldzuordnung und die gewünschte Suche separat nachvollziehbar sind, wird der Pilot freigegeben. Eine Detection prüft man nur, wenn für diese Quelle eine passende unterstützte Erkennung vorgesehen ist. Ein gewöhnliches Audit- oder Anmeldeereignis muss keinen Alarm auslösen.

Fehler und Rückbau eingrenzen

Bei fehlenden Daten prüft man zuerst, ob die Quelle tatsächlich gesendet hat, den richtigen Endpunkt verwendet und den gespeicherten Schlüssel als vorgesehenes Bearer-Credential nutzt. Danach folgen Quellfehler, Netzwerkweg, Zeitfenster und Integrationsstatus. HTTP-Erfolg allein ersetzt den Ereignisnachweis nicht. Sind Daten vorhanden, aber falsch zugeordnet, untersucht man Logformat und Parser statt vorsorglich einen zweiten Connector anzulegen.

Für eine geplante Pause stoppt man den Export über den dokumentierten Weg der Quelle. Vor dem Rückbau werden laufende Abhängigkeiten, historische Nachweise und gegebenenfalls Aufbewahrungspflichten geklärt. Danach beendet man nur diese Weiterleitung und kontrolliert, dass der weiterhin benötigte alte Logpfad funktioniert. Eine angebotene Integrationslöschung, der Widerruf eines Schlüssels und die Löschung historischer Daten sind getrennte Vorgänge; dieser Artikel behauptet dafür keinen universellen Schalter. Bei einem kompromittierten oder verlorenen Schlüssel wird der unterstützte Ersetzungs-/Widerrufsweg mit Sophos geklärt, statt einen nie geprüften Rotationsablauf zu improvisieren.