SVA-Log-Collector zu Sophos XDR Data Collectors migrieren

Bei der Umstellung auf die erweiterte Sophos-XDR-Lösung provisioniert Sophos für geeignete Sophos Security Virtual Appliance (SVA)-Log-Collector eine neue XDR Data Collector-Konfiguration. Die VM wird dadurch weder automatisch in der eigenen Umgebung installiert noch aktiviert. Man muss den Ersatz ausrollen, den Syslog-Weg umschalten und neue Ereignisse nachweisen. Bei gleicher IP-Adresse darf der alte Collector nicht laufen, wenn der neue startet.

Der XDR Data Collector ist ein virtueller Syslog-Empfänger vor Ort oder in AWS, Azure beziehungsweise GCP. Er leitet die aufgenommenen Logs an Sophos XDR weiter. Eine direkte API-Integration benötigt diesen Syslog-Empfänger nicht. Das Integrationsrunbook erklärt Data Ingest, Response Actions und diese Verbindungstypen.

Wenn bereits Sophos Next-Gen SIEM eingesetzt wird, empfiehlt Sophos den Ersatz der bisherigen SVA-Syslog-Collector durch XDR Data Collectors, um die volle vom SIEM-Produkt unterstützte Datenaufbewahrung nutzen zu können. Bestehende API-Integrationen müssen für diesen Syslog-Collector-Wechsel nicht neu konfiguriert werden. Daraus folgt weder eine bestimmte Aufbewahrungsdauer noch ein SIEM-Aufbewahrungsanspruch für alle XDR-Tenants; massgeblich bleiben die für das eigene SIEM-Produkt geltenden Aufbewahrungsbedingungen.

Prüfstand 11. Oktober 2026: Der Migrationsleitfaden vom 1. Oktober 2026 ergänzt den September-Rollout. Der frühere EAP-Dokumentationspfad ist Versionsprovenienz und keine Zusage, dass jeder Tenant die Funktion bereits besitzt. Prüfe zuerst den tenantbezogenen Upgrade-Zustand und den tatsächlich angebotenen Collector unter Security Operations > Integrations > Data Collectors. Dieses Runbook beschreibt den Syslog-Cutover und ein konkretes On-Premises-Deployment auf vSphere; Cloud-Adressen werden eingeordnet, die Erstellung der jeweiligen Cloud-Ressourcen ist nicht Gegenstand der vSphere-Schritte.

Vorhandene Arbeitslasten und nicht migrierte Einstellungen erfassen

Für jeden alten SVA-Collector braucht man Plattform, Name, Hostname, statische Netzwerte oder DHCP-Lease, alle sendenden Quellen sowie deren Syslog-Ziel, Port und Protokoll. Notiere zusätzlich Datenformat, Event-Type-Auswahl, Domain- und Protokoll-Exclusions, Passthrough-Einstellungen und benötigte Credentials. Dokumentiere den letzten nachweisbaren Dateneingang pro Quelle; so lässt sich nach dem Cutover ein stiller Datenstrom von einem Fehler unterscheiden.

Automatisch übernommen werden Collector-Name, Hostname beziehungsweise dessen Ableitung, statische IP-Adresse, Subnetzmaske, Gateway und DNS oder die DHCP-Einstellung sowie Syslog-Port-/Protokollzuordnungen. Die ursprünglichen Quellports bleiben erhalten und werden auf die Standard-Syslog-Ports UDP/514 beziehungsweise TCP/601 abgebildet. Der Plattformtyp bestimmt den neuen Cloud- oder On-Premises-Collector.

Nicht automatisch übernommen werden:

• NDR-Integrationen: NDR verwendet keinen Syslog-Forwarding-Pfad. Bei einer gemischten SVA wird nur deren Syslog-Anteil migriert; eine reine NDR-SVA erhält dafür keinen XDR Data Collector.
• Event-Type-Filter, Domain- und Protokoll-Exclusion-Listen.
• SVA-spezifische Syslog-Format- und Passthrough-Einstellungen.
• Integration-Credentials.
• Investigation Consoles, Nessus Scanner und andere VM-Typen ausserhalb der SVA-Log-Collector.
• Physische Hardware-Appliances: Sie werden nicht automatisch zu virtuellen Collectors migriert.

Prüfe für die neue Integration ausdrücklich, welche Filter und Formate weiter benötigt werden und welche Konfiguration der Connector dafür anbietet. Fehlende Filter können mehr Daten als vorgesehen aufnehmen; ein falsches Format kann Logs nur als generische Ereignisse verarbeiten. Credentials nicht aus Tickets oder alten Screenshots kopieren, sondern über das dafür vorgesehene Secret-Management neu bereitstellen.

Bei NDR auf derselben SVA darf ein Syslog-Cutover nicht nebenbei den Sensor abschalten. Die Variante mit gleicher IP verlangt das Ausschalten der alten SVA und unterbricht damit auch deren NDR-Arbeitslast. Plane deren Betrieb getrennt oder wähle für den neuen Syslog-Collector eine andere IP, damit die SVA für NDR weiterlaufen kann. Das NDR-Betriebsrunbook behandelt diese Arbeitslast; die Provisionierung eines Syslog-Ersatzes ist keine NDR-Migration.

Adressvariante vor dem Download festlegen

Die Zieladresse entscheidet darüber, ob beide VMs gleichzeitig laufen dürfen und ob die Quellen geändert werden müssen.

Bei statischer gleicher IP ist eine kurze Umschaltphase einzuplanen: alte SVA ausschalten, dann die neue VM starten. Die Quellen behalten ihr Ziel. Eine garantiert verlustfreie Übergabe folgt daraus nicht; ob während des Unterbruchs Ereignisse erhalten bleiben, hängt auch von Pufferung und Transport des Quellsystems ab.

Für einen schrittweisen Wechsel wird die neue statische IP vor dem ISO-Download festgelegt. Beispiel: Der alte Collector verwendet 192.0.2.10, der neue 192.0.2.20. Diese Dokumentationsadressen sind nicht in Produktion zu übernehmen. Wähle stattdessen eine freie Adresse im richtigen eigenen Netz und prüfe Subnetz, Gateway, DNS sowie Erreichbarkeit aus den Quellnetzen. Eine neue IP erleichtert den Rückweg und lässt Quellen einzeln umschalten; sie erfordert aber angepasste Ziel- und Firewall-Regeln.

Bei DHCP mit Wiederverwendung der alten IP vor der Umschaltung die alte und neue VM-MAC-Adresse, die bisherige IP-Reservation und den aktuellen Lease-Zustand dokumentieren. Dann die Reservation für die neue VM-MAC-Adresse auf die alte IP umstellen beziehungsweise anlegen; dabei das dokumentierte Reservations- und Lease-Verfahren der eingesetzten DHCP-Plattform beachten. Danach die alte SVA ausschalten und erst dann den neuen Collector booten. Prüfe dessen tatsächlichen Lease und die zugewiesene IP vor der Datenabnahme. Eine Reservation verhindert nicht, dass eine noch laufende alte VM dieselbe Adresse verwendet.

Für Cloud-Collector ändert sich die Adresse immer. Bei AWS mit CloudFormation steht im Stack unter Outputs der Wert CTPxCollectorDnsName bereit. Er ist der DNS-Name des Network Load Balancer und für Syslog-Quellen gegenüber einer fest eingetragenen IP zu bevorzugen. Bei Azure die Adresse der VM-Netzwerkschnittstelle im Azure-Portal prüfen, bei GCP die interne Adresse unter Compute Engine > VM instances. DHCP-Adressen lassen sich über die Lease-Tabelle anhand der neuen MAC-Adresse oder über Data Collectors ermitteln. Verwechsle diese Zieladresse für Quellen nicht mit den regionalen Sophos-Uplink-Adressen.

Netzwerkweg und Collector-Ressourcen vorbereiten

Der Upload vom Collector zu Sophos XDR läuft über mTLS mit TLS 1.3 und ausgehendem TCP/443. Das bedeutet nicht, dass keine eingehenden Ports erforderlich wären: Die eigenen Syslog-Quellen müssen den Collector auf ihrem konfigurierten Port und Protokoll erreichen. Die Standardziele sind UDP/514 und TCP/601; migrierte Portzuordnungen sind zusätzlich mit der bisherigen Konfiguration zu vergleichen. Keine pauschale Internetfreigabe auf den Syslog-Empfänger erstellen.

Regionalen Uplink, DNS und Zeitversorgung freigeben

Die folgenden Collector-Uplink-Ziele sind ein Snapshot mit Prüfstand 11. Oktober 2026. Die US1/US2/US3/EU1/EU2-Zuordnung stammt aus der XDR-Collector-Konfiguration, nicht aus einer geratenen Gleichsetzung mit einer AWS-Central-Region. Verwende nur die tatsächlich zugewiesene Region. Der bestehende Sophos-IP-Satz für eingehende API-Aufrufe beim Drittanbieter ist eine andere Allowlist.

Wenn die eigene Firewall IP-basierte Freigaben verlangt, gehören zu diesem Snapshot folgende Zieladressen. Keine Regionen zusammenfassen:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Vor einer produktiven Änderung Region und Zielwerte mit der aktuellen Tenant-Konfiguration und der vom Betriebsverantwortlichen gepflegten Collector-Safelist abgleichen. Abweichungen gehören in einen geprüften Change, nicht in eine vorsorglich breitere Freigabe. Die technische Endpoint-Schreibweise secureworks.com bleibt unverändert.

Der Collector benötigt ausserdem UDP und TCP/53 zu den bei der Provisionierung eingetragenen DNS-Servern. Für den Zeitabgleich sind UDP/123 zu den gewählten NTP-Servern nötig. Ohne eigene NTP-Vorgabe verwenden Nicht-AWS-Collector 0.pool.ntp.org bis 3.pool.ntp.org; für AWS ist das Standardziel 169.254.169.123. Bei lokalem NTP muss der Verkehr zwischen Collector und Zeitserver in beide Richtungen zugelassen sein. Für den On-Premises-Collector dienen diese NTP-Werte dem Bootstrap; nach der Verbindung übernimmt der XDR-Backend-Kanal die Zeitsynchronisation. Windows-Domain-Controller sind laut Plattformanleitung kein NTP-Ziel für diesen Nicht-Domain-Host.

Ein Forward-Web-Proxy kann über Host Proxy eingetragen werden. Die Collector-Übersicht schliesst fest konfigurierte authentifizierte Proxys aus, während die On-Premises-Anleitung auch eine URL-Syntax mit Benutzer und Passwort zeigt. Diese Angaben sind nicht deckungsgleich. Plane daher keinen produktiven authentifizierten Proxy-Pfad ohne geklärte Sophos-Freigabe; den Konflikt nicht durch eingebettete Zugangsdaten im ISO umgehen. Bei TLS-Inspection muss der konkrete mTLS-Uplink ohne MITM-Eingriff funktionieren. Eine Ausnahme ist auf die erforderlichen Collector-Verbindungen zu begrenzen.

On-Premises-VM nicht nach alten SVA-Werten dimensionieren

Die neue On-Premises-VM benötigt 4 vCPUs mit mindestens 2 GHz, 8 GB RAM, eine 20-GB-Systemdisk und eine 200-GB-Datendisk. Die Plattformanleitung nennt vSphere ESXi 6.7 oder neuer, Hyper-V 8.0 unter Windows Server 2016 oder neuer sowie Nutanix 6.8.x oder neuer als empfohlene Umgebungen. Die VM muss x86-64-v2-CPU-Funktionen sehen; eine ungeeignete CPU-Kompatibilitätsmaske kann den Start verhindern.

Die Angabe bis zu 200'000 EPS ist eine Obergrenze für passend konfigurierte Cloud- und On-Premises-Collector, keine Durchsatzgarantie für diese Mindestressourcen. Dimensioniere nach Anzahl, Grösse und Spitzenlast der Ereignisse und kontrolliere den realen Datenfluss. Auf dem Collector dürfen keine Drittanbieter-Tools oder zusätzlichen Anwendungen installiert werden. Updates erfolgen automatisch, üblicherweise im 24-Stunden-Rhythmus, wenn die Verbindung gesund ist.

Vorprovisionierten On-Premises-Collector auf vSphere ausrollen

Verwende für eine bestehende Migration die zugehörige Konfiguration unter Security Operations > Integrations > Data Collectors. Vergleiche Name, Netzwerte und Syslog-Zuordnungen mit der alten SVA. Lade die ISO mit der Collector-Konfiguration und die OVA für die VM herunter. Beide gehören zusammen; eine ISO eines anderen Collectors würde den falschen Zustand provisionieren. Bewahre Konfigurationsdateien zugriffsbeschränkt auf.

Fehlt die Konfiguration, prüfe zuerst die Ausschlüsse und Netzfehler im nächsten Abschnitt. Für einen bewusst manuell neu angelegten Ersatz bietet die Oberfläche Actions > Add Collector > On-Premises > Next. Dort Name und Hostname, gegebenenfalls Beschreibung, Host Proxy und NTP sowie DHCP oder vollständige statische Netzwerte erfassen und mit Create Collector erstellen. Das ist kein Grund, neben einer bereits vorhandenen Migration einen unkontrollierten Doppel-Collector anzulegen.

Auf vSphere erfolgt das Deployment so:

1. In der vSphere Web Console Virtual Machines > Create / Register VM öffnen und Deploy a virtual machine from an OVF or OVA file wählen.
2. Einen eindeutigen VM-Namen, etwa sophos-xdr-collector, vergeben und die heruntergeladene OVA auswählen. Der Name ist frei wählbar; er soll die VM im Hypervisor von der alten SVA unterscheiden.
3. Einen Datastore mit mindestens 220 GB freiem Platz für die zwei Disks wählen. Netzwerkzuordnung und Disk-Konfiguration kontrollieren, die Zusammenfassung prüfen und mit Finish abschliessen. Die VM vorerst ausgeschaltet lassen.
4. Unter Storage > Datastore Browser die passende Konfigurations-ISO hochladen.
5. Bei der VM Edit Settings öffnen. Das CD-ROM von Client Device auf Datastore ISO File ändern, die hochgeladene ISO auswählen und speichern. Prüfe vor dem ersten Start, dass die ISO tatsächlich eingebunden ist und die VM das richtige Quellnetz erreicht.
6. Bei gleicher IP die alte SVA jetzt ausschalten. Erst danach die neue VM starten. Bei neuer IP darf die alte SVA laufen; die Quellen werden anschliessend einzeln umgestellt.
7. Unter Security Operations > Integrations > Data Collectors warten, bis der neue Collector Ready zeigt. Erst dann darf die ISO ausgehängt werden. Ready bestätigt noch nicht, dass jede Quelle korrekt aufgenommen wird.

Für Hyper-V stellt Sophos statt OVA ein VHD-Paket bereit, für Nutanix QCOW2-Dateien; die zweite Datendisk und die beim ersten Boot eingebundene ISO bleiben erforderlich. Die vSphere-Klickfolge ist nicht auf diese Plattformen zu übertragen. Ebenso sind Cloud-Collector mit ihren jeweiligen Plattformressourcen auszurollen, nicht als OVA in vSphere.

Quellen umschalten und Datenfluss abnehmen

Bei geänderter Zieladresse alle betroffenen Geräte und Anwendungen auf die neue Collector-IP beziehungsweise den neuen DNS-Namen umstellen. Dabei nur das Ziel ändern, nicht ungeprüft Port, Protokoll oder Logformat: Diese Zuordnungen sollen aus der SVA übernommen werden. Sendete eine Quelle bisher per UDP/514, bleibt es für diesen Migrationsfall bei UDP/514. Ein Transportwechsel auf TCP ist ein eigener Change mit Prüfung des Quellsystems.

Schalte bei verschiedenen IPs zunächst eine überschaubare Quelle um. Erzeuge dort ein harmloses, vom Connector erfasstes Ereignis und notiere Quelle, Ereignistyp und Uhrzeit mit Zeitzone. Suche es über den für diese Integration angebotenen Daten- oder Abfrageweg in XDR. Der Nachweis muss den richtigen Tenant, die Quelle, den Zeitstempel und das passende Ereignisformat zeigen. Erwartete Verzögerungen des Connectors berücksichtigen; ein Testevent muss nicht zwingend einen Case oder eine Detection erzeugen.

Erst nach dieser Prüfung die übrigen Quellen umstellen. Vergleiche pro Quelle die letzten Ereignisse vor und die ersten nach dem Cutover. Eine identische Dauer oder Ereignisrate ist nicht für jede Quelle zu erwarten; entscheidend sind ihre tatsächliche Aktivität und fehlende unerklärte Zeiträume. Vermeide ungeplantes gleichzeitiges Senden desselben Datenstroms an beide Collector, weil dies Duplikate erzeugen kann.

Die bisherige SVA kann während der Planung weiterarbeiten. Historische, bereits aufgenommene SVA-Daten bleiben in XDR abfragbar; der Ersatz muss sie nicht noch einmal senden. Daraus folgt keine neue, unbegrenzte Aufbewahrungszusage. Der 200-GB-Spool des neuen Collectors puffert Logs bei langsamem oder vorübergehend unterbrochenem Uplink. Er ersetzt weder die Prüfung der Quelle noch eine Garantie für beliebig lange Ausfälle.

Die Betriebsabnahme ist erst erreicht, wenn alle erwarteten Quellen aktuelle, richtig zugeordnete Daten liefern, Filter und Exclusions bewusst geprüft sind, DNS, Zeitversorgung und Uplink funktionieren und gegebenenfalls NDR separat weiterarbeitet. Dokumentiere den Umschaltzeitpunkt und den Beobachtungszeitraum. Die alte SVA und ihre Konfiguration bis dahin für einen möglichen Rückweg bewahren; anschliessend erst deren verbliebene Arbeitslasten und sichere Ausserbetriebnahme entscheiden.

Fehler eingrenzen und ohne IP-Konflikt zurückschalten

Kein neuer Collector vorhanden: Eine Hardware-Appliance, reine NDR-SVA oder Nicht-SVA-VM wird nicht automatisch migriert. Bei einer aktiv verwendeten Syslog-SVA prüfen, ob Port und Protokoll konfiguriert und die statischen Netzwerte vollständig sind. Fehlende Gateway- oder DNS-Werte können die Migration verhindern. Ungültige Netzkonfiguration in Fusion korrigieren und mit Support die erneute Migration klären oder einen ausdrücklich geplanten manuellen Collector anlegen. Keine Platzhalteradressen einsetzen, nur damit ein Formular akzeptiert wird.

Neue VM startet nicht: ISO-Zuordnung, zweite Disk, RAM, vCPUs und die der VM sichtbaren x86-64-v2-Funktionen prüfen. Keine Reparatur- oder Monitoringsoftware auf dem Collector installieren.

Collector bleibt offline: Zuerst die tatsächlich vergebene IP beziehungsweise den Lease, Gateway, DNS und Bootstrap-Zeitversorgung prüfen. Danach die Firewall-/Proxy-Logs für den regionalen TCP/443-Uplink kontrollieren. Ein offener ausgehender Port allein beweist keinen erfolgreichen mTLS-Kanal. Bei gleichem IP-Szenario zusätzlich sicherstellen, dass die alte SVA wirklich aus ist.

Collector ist Ready, eine Quelle fehlt: Zieladresse der Quelle, Route und eingehenden Syslog-Port prüfen. Vergleiche Portzuordnung und Format mit der alten Integration. Ein vorgeschalteter Log-Forwarder muss das erwartete Integrationsformat erhalten; sonst können Daten als generische Ereignisse statt im erwarteten Schema ankommen. Erst den Datenweg belegen, dann nach einer Detection suchen.

Für den Rückweg sind statische Adressen und DHCP-Reservationen getrennt zu behandeln:

• Statische gleiche IP: Neue VM ausschalten, erst danach die alte SVA mit ihrer erhaltenen statischen Konfiguration starten. Quellen behalten ihr bisheriges Ziel. Prüfe, dass die alte SVA diese IP tatsächlich verwendet und neue Syslog-Ereignisse empfängt und weiterleitet. Niemals beide VMs mit dieser Adresse einschalten.
• DHCP-Reservation auf gleiche IP: Zuerst die neue VM ausschalten. Danach die Reservation der alten IP wieder der dokumentierten alten SVA-MAC-Adresse zuordnen und den Lease-Zustand nach dem dokumentierten Verfahren der eigenen DHCP-Plattform behandeln. Es gibt dafür keinen hier vorausgesetzten universellen Lease-Löschbefehl. Erst anschliessend die alte SVA starten, ihren tatsächlichen Lease und ihre IP kontrollieren und mit einem neuen Syslog-Ereignis Aufnahme und Weiterleitung nachweisen. Die Quellen behalten ihr bisheriges Ziel; das blosse Starten der SVA beweist deshalb noch keinen funktionierenden Rückweg. Niemals beide VMs mit dieser Adresse einschalten.
• Andere IP oder DNS-Ziel: Die dokumentierten Quellziele und gegebenenfalls die dazugehörigen Netzregeln auf den alten Collector zurückstellen. Mit einem neuen Ereignis prüfen, dass die alte SVA wieder empfängt und weiterleitet. Den neuen Collector erst nach Prüfung aller Zuordnungen ausser Betrieb nehmen.

Der Rückweg ist erst abgenommen, wenn die alte SVA die vorgesehene Zieladresse nachweislich hält und frische Syslog-Ereignisse wieder aufgenommen und weitergeleitet werden.

Ein Rückweg funktioniert nur, solange die alte SVA noch verfügbar und ihre Konfiguration erhalten ist. Er führt nicht das vendorseitige Produktupgrade zurück und garantiert keine Wiederherstellung nicht zugestellter Ereignisse. Sophos kündigt ein späteres Supportende für SVA-Log-Collector an, nennt im hier geprüften Migrationsstand aber kein konkretes Datum. Neue Log-Collector-Instanzen sind nach der Migration als XDR Data Collectors anzulegen; die alte SVA ist deshalb ein begrenzter Bestandsrückweg, keine langfristige Neuinstallationsstrategie.

Bleibt die Ursache unklar, sammle Collector- und Tenant-Identität, Plattform, bereinigte Netzwerte, betroffene Quelle, exakte Zeitfenster, Status und Fehlermeldung. Für die Eskalation gilt Sophos Supportticket eröffnen. Secrets, Konfigurations-ISO und unbereinigte Logdaten gehören nicht in frei zugängliche Tickets oder Screenshots.