Sophos Next-Gen SIEM einordnen und Retention planen

Sophos Next-Gen SIEM ist ein optionales Add-on für Sophos XDR Powered by Secureworks und Sophos MDR. Vor der Nutzung muss der Account auf Sophos Fusion aktualisiert sein. Die technische Adminhilfe beschreibt 13 Monate Datenaufbewahrung als Standard und eine Erweiterungsmöglichkeit auf bis zu 10 Jahre. Hinzu kommen Threat- und Compliance-Telemetrie sowie Custom-Integrationen zusätzlich zu den vorgefertigten XDR-/MDR-Integrationen. Diese Einordnung hat den Prüfstand 28. Oktober 2026; die abweichende Ein-Jahr-Angabe der Produktseite wird unten für die Beschaffung eingeordnet.

Für die Entscheidung sollte man zuerst die benötigten Datenquellen und Aufbewahrungszeiträume erfassen. Danach lässt man den konkreten Add-on-Umfang für den eigenen Tenant bestätigen und prüft mit einer kleinen Pilotquelle, ob die vorgesehenen Ereignisse tatsächlich aufgenommen und wiedergefunden werden. Eine bestehende XDR- oder MDR-Lizenz allein ist kein Nachweis, dass das optionale Add-on freigeschaltet ist.

Wann Next-Gen SIEM zur Aufgabe passt

SIEM steht für Security Information and Event Management: Ereignisdaten werden zentral gesammelt und für Auswertungen nutzbar gemacht. Next-Gen SIEM ergänzt die gemeinsame XDR-/MDR-Datenarchitektur für längere Aufbewahrung und Compliance-Auswertungen. Es ist vor allem dann ein sinnvoller Prüfungskandidat, wenn man historische Ereignisse über längere Zeiträume benötigt oder eine Quelle über eine eigene Integration aufnehmen möchte.

Geht es dagegen zunächst um die Einrichtung einer vorhandenen Produktintegration, beginnt man mit MDR- und XDR-Integrationen in Sophos Fusion. Dieser Artikel erklärt deren Datenfluss und Betriebsprüfung. Die Syslog-Anbindung der Sophos Firewall behandelt den Transport von Firewall-Logs an einen Empfänger. Sie beantwortet nicht, welcher Next-Gen-SIEM-Umfang gekauft oder für eine Quelle aktiviert ist.

Die primäre Plattform für Erkennung, Untersuchung, Response und Automatisierung bleibt Sophos XDR. Next-Gen SIEM ergänzt diese Arbeitsabläufe um complianceorientierte Datenerfassung, historische Nachweise und längere Aufbewahrung. Das SIEM-Add-on ist deshalb keine pauschale Voraussetzung für bereits lizenzierte XDR-Erkennungs- oder Response-Funktionen; umgekehrt schaltet XDR allein die zusätzlichen SIEM-Leistungen nicht frei.

Avanet empfiehlt, das Add-on nicht allein wegen einer möglichst langen Retention zu wählen. Retention bedeutet hier Datenaufbewahrung. Entscheidend ist, welche Ereignisse man später für welche Frage braucht, wer sie auswertet und wie lange sie dafür verfügbar sein sollen. Eine längere Speicherung hilft wenig, wenn die benötigte Ereigniskategorie gar nicht geliefert wird oder wichtige Felder fehlen.

Sophos beschreibt auch vorgefertigte Compliance-Dashboards. Solche Auswertungen unterstützen die Nachweisarbeit, ersetzen aber weder die Prüfung der Datenabdeckung noch eine rechtliche Bewertung oder Zertifizierung. Aus dem Add-on lässt sich keine automatisch erfüllte Compliance ableiten.

Tenant und Angebot vor der Umsetzung klären

Vor der Beschaffung dokumentiert man den richtigen Tenant, das genutzte XDR-/MDR-Produkt und den tatsächlichen Fusion-Upgrade-Status. Eine Ankündigung oder ein geplanter Upgrade-Termin genügt nicht als Betriebsfreigabe. Anschliessend lässt man über den Sophos-Partner bestätigen, ob Next-Gen SIEM für diesen Account verfügbar ist und welche Aufbewahrung sowie Integrationsleistungen das konkrete Angebot enthält.

Sophos beschreibt ein nutzer- und serverbasiertes Preismodell ohne Ingestion-Gebühren, also ohne eine Gebühr nach eingelesenem Datenvolumen. Das ist eine Beschreibung des Preismodells, kein Preisangebot und keine Zusage unbegrenzter technischer Kapazität. Vor einer Bestellung müssen Zählweise, Laufzeit, gewünschte Retention-Erweiterung, Integrationsumfang und mögliche Voraussetzungen des Drittprodukts geklärt sein. Insbesondere darf man aus dieser Beschreibung weder kostenlose Drittanbieterlizenzen noch garantierte Durchsatz- oder Ereignisgrenzen ableiten.

Für Custom-Integrationen ist die Möglichkeit bestätigt, eigene Datenintegrationen zu erstellen. Daraus folgt noch kein belegter Einrichtungsweg für jede Quelle. Vor dem Pilot braucht man deshalb eine zur konkreten Quelle passende Beschreibung von Übertragung, Authentisierung, Ereignisformat, Feldzuordnung und unterstützter Auswertung. Bestehende Connector-Menüs oder Abfragen dürfen nicht ungeprüft auf eine Custom-Integration übertragen werden. Der Dashboard-Einstieg ist unten beschrieben; ein universeller Einrichtungsweg für jede Custom-Quelle wird daraus nicht abgeleitet.

Lizenzmenge und Collector-Pfad ausdrücklich bestätigen

Next-Gen SIEM ist nicht als eigenständiges Produkt kaufbar. Die Anzahl seiner Subscriptions muss der Gesamtzahl der lizenzierten XDR- und MDR-Benutzer und Server entsprechen; Server dürfen bei der Mengenermittlung nicht fehlen. Den konkreten Bestand und das Angebot mit dem Partner abgleichen, statt nur eine Pilotgruppe oder das Datenvolumen als Lizenzmenge anzusetzen. Zusätzlich zu den standardmässigen 13 Monaten sind Retention-Erweiterungen auf drei, fünf, sieben oder 10 Jahre kaufbare Optionen, keine automatische Freischaltung durch eine bestehende XDR-/MDR-Lizenz. Sie stellen abgelaufene Historie nicht nachträglich wieder her und belegen keine rechtliche Compliance.

Die Lizenzrichtlinie mit Wirksamkeitsdatum 16. Oktober 2026 nennt zusätzlich eine Nutzungsgrenze von 1 GB Rohdatenaufnahme pro Tag, über alle Datenquellen aggregiert. Ihre Tabelle lizenziert nach Benutzern und Servern; der Satz zur Datenmenge benennt aber nicht ausdrücklich, ob diese Menge je Subscription oder für den Tenant gilt. Deshalb wird weder mit 1 GB × Benutzer und Server gerechnet noch eine feste 1-GB-Tenantgrenze angenommen. Vor Dimensionierung oder Bestellung braucht man eine verbindliche Bestätigung der Bezugsgrösse, der Zusammenrechnung und des Verhaltens bei Überschreitung. Ein Preis ohne volumenabhängige Ingestion-Gebühr bedeutet keine unbegrenzte Nutzung.

Auch die Anzahl der Retention-Add-on-Subscriptions muss der gesamten Anzahl der NG-SIEM-Subscriptions entsprechen. Eine verlängerte Aufbewahrung nur für eine frei gewählte Teilmenge oder einzelne Quelle lässt sich daraus nicht ableiten.

Bei Syslog-Integrationen unterstützen alte Sophos-Log-Collector nicht den vollständigen Retention-Umfang von Next-Gen SIEM. Dafür empfiehlt Sophos den Wechsel zu XDR Data Collectors; das vorhandene Collector-Migrationsrunbook erklärt Provisionierung, Deployment, Quellenumschaltung und Abnahme. Bestehende API-Integrationen benötigen allein wegen dieses Collector-Wechsels keine Neukonfiguration. Auf einer gemeinsamen SVA bleibt NDR eine getrennte Arbeitslast und darf beim Syslog-Cutover nicht unbeabsichtigt abgeschaltet werden. Der neue Collector ist kein Ersatz für die Prüfung von Add-on-Entitlement, Quellformat und wirksamer Aufbewahrung.

Der SIEM-Hub ordnet die vorhandenen Anleitungen nach Planung, Quellenaufnahme, Transport und Parserprüfung. Das HTTP-/Parser-Praxisbeispiel verbindet diese Schritte mit einer synthetischen Laborquelle; seine praktische Tenant-Abnahme ist noch offen.

Custom-Daten: Transport, Normalisierung und Erkennung trennen

Eine Custom Integration transportiert Daten aus einer nicht von Sophos optimierten Quelle in XDR. Daraus folgt noch keine bestätigte Normalisierung, Suche oder Detection für diese Quelle. Custom Parser ordnen die Logfelder den unterstützten standardisierten XDR-Ereignisschemas zu. Erst danach lässt sich prüfen, ob die erforderlichen Felder für die gewünschte Suche, einen Detector oder eine Custom Detection Rule vorhanden sind.

Für Custom Parser ist eine Next-Gen-SIEM-Subscription erforderlich. Verwalten dürfen sie Admin und Super Admin; andere Rollen können nur die Liste konfigurierter Parser ansehen. Nachrichten, auf die kein Parser passt, fallen auf das generic-Schema zurück. Sie können Kontext für Cases und Custom Rules liefern, erscheinen aber nur mit erweiterten Suchparametern in Suchergebnissen. Kein Treffer in einer einfachen Suche beweist deshalb nicht, dass keine Daten aufgenommen wurden.

Auch korrekt normalisierte Daten lösen nicht automatisch jeden zum Schema passenden Detector aus. Sophos nennt bestimmte unterstützte Detector-Pfade mit erforderlichen Feldern; andere Detectors sind nicht garantiert. Deshalb wird die gewünschte Erkennung separat mit passenden Testereignissen abgenommen. Die beworbene KI-Unterstützung ersetzt diese Prüfung nicht.

Ein neu erstellter Custom Parser ist standardmässig ausgeschaltet. Er wird mit unterschiedlichen Beispielmeldungen wiederholt getestet, gespeichert und erst danach separat aktiviert. Änderungen an einem bereits aktiven Parser werden dagegen beim Speichern sofort wirksam; deshalb vor dem Speichern sorgfältig testen. Überlappende Confirm Strings können Nachrichten dem falschen Parser zuordnen; deshalb gehört der tatsächlich verwendete extractor path zur Prüfung.

Sophos pflegt oder aktualisiert Custom Parser nicht. Ein verantwortlicher Betreiber muss Feldzuordnung, Zeitstempel und Such- beziehungsweise Erkennungsresultate nach Quellformat- oder Parseränderungen erneut prüfen. Für den Pilot werden Datenaufnahme, Normalisierung und gewünschte Auswertung als drei getrennte Ergebnisse dokumentiert; ein grüner Transportstatus reicht nicht.

Die praktische Einrichtung behandeln Custom HTTP Ingest, die S3-Varianten, Azure Event Hubs und Storage und das Custom-Parser-Runbook. Für jede Variante bleiben Transport, Schema und gewünschte Auswertung getrennte Abnahmeergebnisse.

NG-SIEM-Dashboard zur Nachweisprüfung öffnen

Mit aktiviertem Add-on lässt sich die bereitgestellte Ansicht so zur persönlichen Dashboard-Liste hinzufügen:

1. Dashboards > Manage dashboards öffnen.
2. Find dashboards wählen und NG-SIEM zur Liste hinzufügen.
3. Das Dashboard aus der Liste öffnen und die angezeigten Daten mit Quelleninventar, Zeitraum und erwarteten Ereignissen abgleichen.

Das NG-SIEM-Dashboard enthält Widgets zu Zugriffskontrolle, Netzwerksicherheit und Auditereignissen. Sophos beschreibt ausserdem ein ISO-27001-Dashboard-Beispiel, das Authentifizierung, Änderungen, Netzwerk-/Firewall-Ereignisse, E-Mail-/Dateiaktivität sowie Detection- und Case-Abläufe zusammenführt. Welche Informationen für den eigenen Nachweis tatsächlich vorliegen, hängt von den angebundenen Quellen und deren Datenqualität ab; die Darstellung ist keine ISO-Zertifizierung oder automatische Compliance-Bestätigung.

Die allgemeine Dashboard-Anleitung erklärt persönliche Listen, verfügbare Ansichten und den PDF-Export. Fehlt NG-SIEM, werden zuerst Tenant, Add-on und Berechtigung geprüft; eine leere Ansicht wird gegen Datenherkunft und Zeitraum untersucht. Weder fehlende noch grüne Widgets ersetzen die Prüfung der zugrunde liegenden Ereignisse.

Die aktuelle produktspezifische NG-SIEM-Hilfe vom 1. Oktober 2026 beschreibt diesen Einstieg. Die ältere gemeinsame Dashboard-Hilfe vom 17. September nennt noch nur das TAC-Dashboard. Das ist ein Dokumentationsunterschied, keine Garantie für eine ungeprüfte Tenant-Ansicht. Fehlt der Eintrag trotz passendem Angebot, wird die konkrete Bereitstellung geklärt; keine zweite Integration auf Verdacht anlegen.

Aufbewahrung, Suchfenster und Rohdaten unterscheiden

13 Monate in der Adminhilfe, ein Jahr auf der Produktseite

Die technische Übersicht vom 1. Oktober 2026 nennt 13 Monate Standardaufbewahrung. Die öffentliche Produktseite nennt mit Prüfstand 28. Oktober dagegen ein Jahr. Beide nennen Erweiterungen auf drei, fünf, sieben oder zehn Jahre. Der Unterschied wird nicht als bestätigte Produktänderung oder als bloss andere Rundung ausgelegt; dafür fehlt eine eindeutige Erklärung von Sophos.

Für die technische Einordnung dieses Artikels sind die 13 Monate aus der produktspezifischen Adminhilfe die Referenz. Vor einer Bestellung oder einer verbindlichen Aufbewahrungszusage lässt man trotzdem den für den konkreten Tenant, die Datenarten und das Angebot geltenden Zeitraum bestätigen. Die Bestätigung gehört ins Quelleninventar. Benötigt der Betrieb beispielsweise mehr als zwölf Monate Historie, darf die zusätzliche Zeit nicht allein aus der allgemeinen Produktwerbung vorausgesetzt werden. Das Retention-Inventar und die Abnahme unten prüfen den vereinbarten Umfang; sie lösen den Quellenwiderspruch nicht durch eine angenommene Frist auf.

Suchzeitraum und Zugriff auf Rohdaten

Eine lange Retention bedeutet nicht, dass eine beliebig grosse Abfrage am Stück möglich ist. Die aktuelle Schemahilfe erlaubt bei normalisierten Events höchstens 31 Tage pro Abfrage, mit einem beliebigen Startdatum innerhalb tatsächlich aufbewahrter Daten. Längere Untersuchungszeiträume werden in passende Zeitfenster geteilt. Die Suche in Detections ist davon getrennt.

Für @raw und original_data nennt der neuere SQL-zu-QL-Migrationsleitfaden vom 15. September 2026 eine gesonderte Zugriffsgrenze von 20 Tagen. Eine Anfrage ausserhalb dieses Umfangs wird zurückgewiesen, nicht still auf den erlaubten Bereich gekürzt. Die ältere Query-Language-Hilfe spricht zusätzlich von 20-Tage-Schritten; daraus wird keine garantierte Verfügbarkeit älterer Rohdaten abgeleitet. Aufteilen macht ältere Raw-Daten nicht automatisch zugänglich. Diese Suchgrenze belegt weder eine physische Löschung nach 20 Tagen noch eine allgemeine Verkürzung der normalisierten Retention.

Data Lake Search und Export erklärt Schemawahl, Query-Limits, historische Zeitfenster und den vollständigen Exportnachweis. Der Regelbetrieb unterscheidet eine erfolgreiche Suche von einer dauerhaft ausgewerteten Detection- oder Suppression-Regel.

Ein Retention-Inventar pro Quelle anlegen

Das Inventar gehört in die Betriebsdokumentation, nicht nur ins Angebot. Pro Quelle erfasst man die folgenden Angaben; verschiedene Ereigniskategorien derselben Anwendung können eigene Einträge benötigen:

• Quellsystem, Quell-Tenant, Ereigniskategorien und verantwortliche Person.
• Zweck der Datenaufnahme und konkrete spätere Such- oder Nachweisfrage.
• Benötigte Felder, beispielsweise Ereigniszeit mit Zeitzone, Aktion, Ergebnis und eine für die Untersuchung geeignete Identität.
• Datenklassifikation, zulässiger Inhalt und Freigabe für Übermittlung und Zugriff.
• Gewünschte Aufbewahrung mit Begründung sowie den bestätigten, tatsächlich geltenden Umfang.
• Integrationsmethode, benötigte Berechtigungen und Besitzer der Zugangsdaten, ohne Secrets in das Inventar zu kopieren.
• Aufnahmebeginn, erwartete Verarbeitungsverzögerung und ein reproduzierbares Testereignis.
• Verifizierter Suchweg, ältester gefundener Datensatz, letzte erfolgreiche Prüfung und nächster Review-Termin.
• Vorgehen bei Ausfall, Quellenwechsel, Aufbewahrungsänderung und Rückbau.

Die Produktangabe 13 Monate, erweiterbar auf bis zu 10 Jahre wird nicht automatisch als wirksame Frist für jeden bestehenden Datensatz eingetragen. Für die eigene Quelle müssen Geltungsbereich, Beginn und Zugriff auf historische Daten geklärt sein. Auch eine rückwirkende Übernahme alter Daten oder die Wiederherstellung bereits abgelaufener Daten darf nicht vorausgesetzt werden.

Beispiel für eine Pilotquelle

Das folgende Beispiel ist ein Planungsdatensatz, keine Sophos-Konfiguration und kein nachgewiesener Connector. Die Werte sind frei gewählte Anforderungen eines fiktiven Betriebs:

Quelle: interne Fachanwendung, Testumgebung
Ereignisse: erfolgreiche Anmeldung und administrative Rollenänderung
Zweck: nachvollziehen, wer eine Berechtigung geändert hat
Pflichtfelder: Ereigniszeit mit Zeitzone, Testkonto, Aktion, Ergebnis
Gewünschte Aufbewahrung: 24 Monate
Begründung: intern genehmigter Untersuchungszeitraum
Bestätigter Umfang: vor Bestellung und Pilot noch zu klären
Verbindung und Suchweg: für diese Custom-Quelle noch zu bestätigen
Test: genehmigte Rollenänderung an einem dedizierten Testkonto
Rückweg: Ausgangsrolle wiederherstellen und Änderung kontrollieren
Owner: Anwendungsteam gemeinsam mit Security Operations

24 Monate sind hier eine interne Anforderung, keine allgemeine gesetzliche Frist und kein Produktstandard. Sie liegen über der beschriebenen Standard-Retention; eine passende Erweiterung muss daher vor der Freigabe bestätigt werden. Konten und Ereignisse ersetzt man durch die eigenen freigegebenen Testdaten. Produktive Berechtigungen werden für diesen Test nicht verändert.

Datenaufnahme und Aufbewahrung getrennt abnehmen

Für den Pilot hält man den Ausgangszustand und den Aufnahmebeginn fest. Bestehende Logpfade bleiben erhalten, bis die neue Quelle abgenommen ist. Danach erzeugt man ein harmloses, genehmigtes Ereignis, das zur geplanten Ereigniskategorie gehört. Im Beispiel wird die Rolle des Testkontos geändert und anschliessend wieder auf den dokumentierten Ausgangswert gesetzt.

Im für diese Quelle bestätigten Such- oder Auswertungsweg prüft man nach der erwarteten Verarbeitungszeit:

1. Ist genau das Testereignis im richtigen Tenant vorhanden?
2. Stimmen Quellsystem, Ereigniszeit, Aktion und Ergebnis mit dem Quellnachweis überein?
3. Sind die benötigten Felder verständlich zugeordnet, statt nur als unbrauchbarer Rohtext vorzuliegen?
4. Lassen sich weitere erwartete Ereignisse über den Pilotzeitraum nachvollziehen?

Ein neu gefundener Datensatz beweist die Datenaufnahme für diesen Test, nicht bereits eine mehrjährige Aufbewahrung. Für die Retention-Abnahme vergleicht man zusätzlich den bestätigten Umfang mit der wirksamen Einstellung oder einer tenantbezogenen Bestätigung. Bereits vorhandene historische Daten werden mit einem gezielten Zeitfenster geprüft; den ältesten gefundenen Datensatz und bekannte Lücken hält man fest. Bei einer neuen Quelle ohne Historie dokumentiert man, dass die langfristige Aufbewahrung noch nicht durch verstrichene Zeit nachgewiesen ist, und plant spätere Kontrollen.

Die Aufnahmeprüfung erwartet keinen Sicherheitsalarm. Ein gewöhnliches Auditereignis kann als Datensatz benötigt werden, ohne dass daraus ein Incident entsteht. Vorhandene XDR-Abfragen erklärt Data Collection und Live Discover; daraus ergibt sich aber keine universelle Abfrage für eine neue Custom-Quelle.

Fehler eingrenzen und Änderungen sicher zurücknehmen

Fehlt das Add-on oder eine Funktion, prüft man zuerst Tenant, tatsächlichen Fusion-Upgrade-Status und bestätigten Add-on-Umfang. Man legt nicht auf Verdacht eine zweite Integration an und ändert keine Endpoint-Schutzrichtlinie, um eine vermutete Lizenzlücke zu beheben.

Fehlen aktuelle Ereignisse, vergleicht man zuerst den Quellnachweis mit Aufnahmebeginn, Ereigniskategorie, Authentisierung, Format und der vereinbarten Verarbeitungsverzögerung. Sind Datensätze vorhanden, aber unbrauchbar, werden Feldzuordnung und Zeitbezug geprüft. Fehlen nur ältere Ereignisse, untersucht man getrennt Aufnahmebeginn, Datenlücken, wirksame Retention und Suchzeitfenster. Eine nachträgliche Retention-Verlängerung ist kein zugesicherter Reparaturweg für bereits fehlende Daten.

Vor einer Verkürzung der Aufbewahrung oder einem Rückbau klärt man mit den verantwortlichen Stellen, welche Daten weiterhin benötigt werden und wie sie, soweit unterstützt und erforderlich, gesichert werden können. Man darf nicht davon ausgehen, dass eine spätere Rückkehr zum alten Wert verlorene Historie wiederherstellt. Ebenso ist das Entfernen einer Integration kein Nachweis der Löschung bereits aufgenommener Daten.

Bei einem fehlgeschlagenen Pilot nimmt man nur die dokumentierte Änderung an der Pilotquelle über deren bestätigten Rückweg zurück. Gemeinsam verwendete Zugangsdaten, Collector oder andere Quellen bleiben unangetastet. Danach prüft man den wiederhergestellten Quellzustand und den weiterhin benötigten alten Logpfad. Datenlöschung und Add-on-Kündigung werden separat mit dem Partner beziehungsweise den zuständigen Stellen geklärt; dieser Artikel verspricht dafür keinen universellen Schalter.

Für die Betriebsübergabe müssen Quelleninventar, bestätigter Umfang, Pilotnachweis, offene historische Lücken, Ausfallverantwortung und Review-Termin vorliegen. Bleiben Datenformat, Suchweg oder Retention für eine benötigte Quelle ungeklärt, ist diese Quelle noch nicht abgenommen. Zur Eskalation genügen zunächst Tenant-Zuordnung, Zeitfenster, Ereigniskategorie und bereinigte Fehlernachweise; Secrets und unnötige personenbezogene Rohdaten gehören nicht in die Anfrage.