SVA-logcollectors migreren naar Sophos XDR Data Collectors

Bij de overstap naar de uitgebreide Sophos XDR-oplossing maakt Sophos voor geschikte Sophos Security Virtual Appliance (SVA)-logcollectors een nieuwe XDR Data Collector-configuratie aan. Daarmee wordt de VM niet automatisch in de eigen omgeving geïnstalleerd of geactiveerd. Je moet de vervanger uitrollen, de syslogroute omschakelen en aantonen dat nieuwe gebeurtenissen binnenkomen. Bij hetzelfde IP-adres mag de oude collector niet draaien wanneer de nieuwe start.

De XDR Data Collector is een virtuele syslogontvanger op locatie of in AWS, Azure of GCP. Hij stuurt de ontvangen logs door naar Sophos XDR. Een directe API-integratie heeft deze syslogontvanger niet nodig. Het integratierunbook legt Data Ingest, Response Actions en deze verbindingstypen uit.

Als Sophos Next-Gen SIEM al wordt gebruikt, adviseert Sophos de bestaande SVA-syslogcollectors te vervangen door XDR Data Collectors om de volledige, door het SIEM-product ondersteunde bewaartermijn te kunnen benutten. Bestaande API-integraties hoeven voor deze vervanging van syslogcollectors niet opnieuw te worden geconfigureerd. Dit impliceert geen specifieke bewaartermijn of recht op SIEM-retentie voor alle XDR-tenants; de retentievoorwaarden van het eigen SIEM-product blijven bepalend.

Gecontroleerd op 11 oktober 2026: de migratiehandleiding van 1 oktober 2026 vult de uitrol van september aan. Het eerdere EAP-documentatiepad geeft de herkomst van de versie aan en is geen toezegging dat elke tenant de functie al heeft. Controleer eerst de upgradestatus van de tenant en de daadwerkelijk aangeboden collector onder Security Operations > Integrations > Data Collectors. Dit runbook beschrijft de syslogomschakeling en een concrete on-premisesdeployment op vSphere. Cloudadressen worden toegelicht, maar het aanmaken van de bijbehorende cloudresources valt buiten de vSphere-stappen.

Bestaande workloads en niet-gemigreerde instellingen inventariseren

Leg voor elke oude SVA-collector het platform, de naam, de hostname, de statische netwerkwaarden of DHCP-lease en alle verzendende bronnen met hun syslogdoel, poort en protocol vast. Noteer ook het gegevensformaat, de selectie van eventtypen, uitsluitingen van domeinen en protocollen, passthrough-instellingen en benodigde credentials. Documenteer per bron de laatste aantoonbare gegevensontvangst. Zo kun je na de omschakeling een inactieve gegevensstroom van een fout onderscheiden.

Automatisch overgenomen worden de collectornaam, de hostname of de daarvan afgeleide naam, het statische IP-adres, subnetmasker, gateway en DNS of de DHCP-instelling, en de syslogpoort-/protocoltoewijzingen. De oorspronkelijke bronpoorten blijven behouden en worden gekoppeld aan de standaardsyslogpoorten UDP/514 of TCP/601. Het platformtype bepaalt de nieuwe cloud- of on-premisescollector.

Niet automatisch overgenomen worden:

• NDR-integraties: NDR gebruikt geen syslogforwarding. Bij een gemengde SVA wordt alleen het sysloggedeelte gemigreerd; een SVA die uitsluitend NDR draait, krijgt hiervoor geen XDR Data Collector.
• Filters voor eventtypen en uitsluitingslijsten voor domeinen en protocollen.
• SVA-specifieke instellingen voor syslogformaat en passthrough.
• Integratiecredentials.
• Investigation Consoles, Nessus Scanner en andere VM-typen buiten de SVA-logcollectors.
• Fysieke hardwareappliances: deze worden niet automatisch naar virtuele collectors gemigreerd.

Controleer voor de nieuwe integratie expliciet welke filters en formaten nodig blijven en welke configuratie de connector daarvoor biedt. Ontbrekende filters kunnen meer gegevens binnenhalen dan bedoeld; bij een verkeerd formaat worden logs mogelijk alleen als generieke gebeurtenissen verwerkt. Kopieer credentials niet uit tickets of oude screenshots, maar stel ze opnieuw beschikbaar via het daarvoor bedoelde secretmanagement.

Als NDR op dezelfde SVA draait, mag een syslogomschakeling niet ongemerkt de sensor uitschakelen. Bij de variant met hetzelfde IP-adres moet de oude SVA uit en wordt dus ook de NDR-workload onderbroken. Plan de werking van NDR afzonderlijk of kies voor de nieuwe syslogcollector een ander IP-adres, zodat de SVA voor NDR kan blijven draaien. Het NDR-beheerrunbook behandelt deze workload; het provisionen van een syslogvervanger is geen NDR-migratie.

Adresvariant vóór de download kiezen

Het doeladres bepaalt of beide VM’s tegelijkertijd mogen draaien en of de bronnen moeten worden aangepast.

Bij hetzelfde statische IP-adres moet je een korte omschakelperiode plannen: schakel de oude SVA uit en start daarna de nieuwe VM. De bronnen behouden hun doel. Dit garandeert geen verliesvrije overdracht; of gebeurtenissen tijdens de onderbreking behouden blijven, hangt ook af van de buffering en het transport van het bronsysteem.

Leg voor een stapsgewijze overstap het nieuwe statische IP-adres vóór het downloaden van de ISO vast. Voorbeeld: de oude collector gebruikt 192.0.2.10, de nieuwe 192.0.2.20. Neem deze documentatieadressen niet over in productie. Kies een vrij adres in het juiste eigen netwerk en controleer subnet, gateway, DNS en bereikbaarheid vanuit de bronnetwerken. Een nieuw IP-adres maakt terugschakelen eenvoudiger en laat je bronnen afzonderlijk omschakelen, maar vereist aangepaste doel- en firewallregels.

Bij DHCP met hergebruik van het oude IP-adres documenteer je vóór de omschakeling de oude en nieuwe VM-MAC-adressen, de bestaande IP-reservering en de huidige leasestatus. Koppel daarna de reservering voor het oude IP-adres aan het nieuwe VM-MAC-adres of maak deze aan. Volg daarbij de gedocumenteerde reserverings- en leaseprocedure van het gebruikte DHCP-platform. Schakel vervolgens de oude SVA uit en boot pas daarna de nieuwe collector. Controleer de daadwerkelijke lease en het toegewezen IP-adres voordat je de gegevensstroom valideert. Een reservering voorkomt niet dat een nog draaiende oude VM hetzelfde adres gebruikt.

Voor cloudcollectors verandert het adres altijd. Bij AWS met CloudFormation staat onder Outputs in de stack de waarde CTPxCollectorDnsName. Dit is de DNS-naam van de Network Load Balancer; gebruik deze voor syslogbronnen bij voorkeur in plaats van een vast IP-adres. Controleer bij Azure het adres van de VM-netwerkinterface in het Azure-portaal, en bij GCP het interne adres onder Compute Engine > VM instances. DHCP-adressen kun je via de leasetabel op basis van het nieuwe MAC-adres of via Data Collectors achterhalen. Verwar dit doeladres voor bronnen niet met de regionale Sophos-uplinkadressen.

Netwerkroute en collectorresources voorbereiden

De upload van de collector naar Sophos XDR gebruikt mTLS met TLS 1.3 en uitgaand TCP/443. Dat betekent niet dat er geen inkomende poorten nodig zijn: de eigen syslogbronnen moeten de collector via hun geconfigureerde poort en protocol kunnen bereiken. De standaarddoelen zijn UDP/514 en TCP/601; vergelijk ook de gemigreerde poorttoewijzingen met de bestaande configuratie. Stel de syslogontvanger niet onbeperkt open voor internet.

Regionale uplink, DNS en tijdsynchronisatie toestaan

De volgende collectoruplinkdoelen zijn een momentopname, gecontroleerd op 11 oktober 2026. De toewijzing US1/US2/US3/EU1/EU2 komt uit de XDR-collectorconfiguratie, niet uit een veronderstelde overeenkomst met een AWS-Central-regio. Gebruik alleen de daadwerkelijk toegewezen regio. De bestaande Sophos-IP-adressen voor inkomende API-aanroepen bij de externe leverancier horen bij een andere allowlist.

Als de eigen firewall IP-gebaseerde toegangsregels vereist, horen de volgende doeladressen bij deze momentopname. Voeg regio’s niet samen:

• 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.

Vergelijk vóór een productiewijziging de regio en doelwaarden met de actuele tenantconfiguratie en de collectorsafelist die de operationeel verantwoordelijke bijhoudt. Afwijkingen vereisen een gecontroleerde change, geen preventief ruimere toegang. De technische eindpuntschrijfwijze secureworks.com blijft ongewijzigd.

De collector heeft daarnaast UDP en TCP/53 nodig naar de DNS-servers die bij de provisioning zijn ingesteld. Voor tijdsynchronisatie is UDP/123 naar de gekozen NTP-servers nodig. Zonder eigen NTP-instelling gebruiken niet-AWS-collectors 0.pool.ntp.org tot en met 3.pool.ntp.org; voor AWS is het standaarddoel 169.254.169.123. Bij lokale NTP moet verkeer tussen de collector en de tijdserver in beide richtingen toegestaan zijn. Voor de on-premisescollector dienen deze NTP-waarden voor de bootstrap; na het verbinden neemt het XDR-backendkanaal de tijdsynchronisatie over. Volgens de platformhandleiding zijn Windows-domaincontrollers geen NTP-doel voor deze host, die geen lid van het domein is.

Een forward-webproxy kan via Host Proxy worden ingesteld. Het collectoroverzicht sluit vast geconfigureerde geauthenticeerde proxy’s uit, terwijl de on-premiseshandleiding ook een URL-syntaxis met gebruikersnaam en wachtwoord toont. Deze gegevens komen niet overeen. Plan daarom geen geauthenticeerd proxypad voor productie zonder expliciete goedkeuring van Sophos; omzeil het conflict niet door inloggegevens in de ISO op te nemen. Bij TLS-inspectie moet de betreffende mTLS-uplink zonder MITM-ingreep werken. Beperk een uitzondering tot de vereiste collectorverbindingen.

On-premises-VM niet dimensioneren op basis van oude SVA-waarden

De nieuwe on-premises-VM vereist 4 vCPU’s met minimaal 2 GHz, 8 GB RAM, een 20-GB-systeemschijf en een 200-GB-dataschijf. De platformhandleiding noemt vSphere ESXi 6.7 of nieuwer, Hyper-V 8.0 onder Windows Server 2016 of nieuwer en Nutanix 6.8.x of nieuwer als aanbevolen omgevingen. De VM moet x86-64-v2-CPU-functies kunnen zien; een ongeschikt CPU-compatibiliteitsmasker kan het opstarten verhinderen.

De vermelding tot 200'000 EPS is een bovengrens voor passend geconfigureerde cloud- en on-premisescollectors, geen doorvoergarantie voor deze minimumresources. Dimensioneer op basis van aantal, grootte en piekbelasting van gebeurtenissen en controleer de werkelijke gegevensstroom. Installeer geen tools van derden of extra toepassingen op de collector. Updates verlopen automatisch, doorgaans om de 24 uur wanneer de verbinding gezond is.

Vooraf geprovisioneerde on-premisescollector uitrollen op vSphere

Gebruik voor een bestaande migratie de bijbehorende configuratie onder Security Operations > Integrations > Data Collectors. Vergelijk naam, netwerkwaarden en syslogtoewijzingen met de oude SVA. Download de ISO met de collectorconfiguratie en de OVA voor de VM. Beide horen bij elkaar; een ISO van een andere collector zou de verkeerde configuratie toepassen. Bewaar configuratiebestanden met beperkte toegangsrechten.

Ontbreekt de configuratie, controleer dan eerst de uitsluitingen en netwerkfouten in het volgende gedeelte. Voor een bewust handmatig aangemaakte vervanger biedt de interface Actions > Add Collector > On-Premises > Next. Vul daar naam en hostname, eventueel een beschrijving, Host Proxy en NTP, en DHCP of de volledige statische netwerkwaarden in en maak de configuratie aan met Create Collector. Dit is geen reden om naast een bestaande migratie ongecontroleerd een tweede collector aan te maken.

De deployment op vSphere verloopt als volgt:

1. Open in de vSphere Web Console Virtual Machines > Create / Register VM en kies Deploy a virtual machine from an OVF or OVA file.
2. Geef de VM een unieke naam, bijvoorbeeld sophos-xdr-collector, en selecteer de gedownloade OVA. De naam is vrij te kiezen en moet de VM in de hypervisor onderscheiden van de oude SVA.
3. Kies een datastore met minimaal 220 GB vrije ruimte voor de twee schijven. Controleer de netwerktoewijzing en schijfconfiguratie, bekijk de samenvatting en voltooi met Finish. Laat de VM voorlopig uitgeschakeld.
4. Upload onder Storage > Datastore Browser de juiste configuratie-ISO.
5. Open Edit Settings van de VM. Wijzig de CD-ROM van Client Device naar Datastore ISO File, selecteer de geüploade ISO en sla op. Controleer vóór de eerste start of de ISO daadwerkelijk is gekoppeld en de VM het juiste bronnetwerk bereikt.
6. Schakel bij hetzelfde IP-adres nu de oude SVA uit. Start pas daarna de nieuwe VM. Bij een nieuw IP-adres mag de oude SVA blijven draaien; de bronnen worden daarna afzonderlijk omgeschakeld.
7. Wacht onder Security Operations > Integrations > Data Collectors totdat de nieuwe collector Ready toont. Pas dan mag de ISO worden ontkoppeld. Ready bevestigt nog niet dat elke bron correct wordt ontvangen.

Voor Hyper-V biedt Sophos een VHD-pakket in plaats van een OVA, en voor Nutanix QCOW2-bestanden. De tweede dataschijf en de bij de eerste boot gekoppelde ISO blijven vereist. Neem de vSphere-klikroute niet over voor deze platforms. Cloudcollectors moeten eveneens met de bijbehorende platformresources worden uitgerold, niet als OVA in vSphere.

Bronnen omschakelen en de gegevensstroom valideren

Stel bij een gewijzigd doeladres alle betrokken apparaten en toepassingen in op het nieuwe collector-IP-adres of de nieuwe DNS-naam. Wijzig daarbij alleen het doel, niet ongecontroleerd de poort, het protocol of het logformaat: deze toewijzingen moeten uit de SVA worden overgenomen. Als een bron voorheen via UDP/514 verzond, blijft dat voor deze migratie UDP/514. Een transportwijziging naar TCP is een afzonderlijke change met controle van het bronsysteem.

Schakel bij verschillende IP-adressen eerst een overzichtelijke bron om. Genereer daar een ongevaarlijke gebeurtenis die de connector verwerkt en noteer bron, gebeurtenistype en tijdstip met tijdzone. Zoek deze gebeurtenis in XDR via de voor deze integratie aangeboden gegevens- of queryroute. De controle moet de juiste tenant, bron, tijdstempel en het passende gebeurtenisformaat tonen. Houd rekening met verwachte connectorvertragingen; een testevent hoeft niet noodzakelijk een case of detection op te leveren.

Schakel pas na deze controle de overige bronnen om. Vergelijk per bron de laatste gebeurtenissen vóór en de eerste na de omschakeling. Niet elke bron heeft dezelfde duur of gebeurtenisfrequentie; bepalend zijn de werkelijke activiteit en het ontbreken van onverklaarde tijdvakken. Vermijd ongepland gelijktijdig verzenden van dezelfde gegevensstroom naar beide collectors, omdat dit duplicaten kan veroorzaken.

De bestaande SVA kan tijdens de planning blijven werken. Historische SVA-gegevens die al zijn ontvangen, blijven in XDR opvraagbaar; de vervanger hoeft ze niet opnieuw te versturen. Dit geeft geen nieuwe toezegging van onbeperkte retentie. De 200-GB-spool van de nieuwe collector buffert logs bij een trage of tijdelijk onderbroken uplink. Hij vervangt noch de controle van de bron, noch een garantie voor onbeperkt lange storingen.

De operationele validatie is pas voltooid wanneer alle verwachte bronnen actuele, correct toegewezen gegevens leveren, filters en uitsluitingen bewust zijn gecontroleerd, DNS, tijdsynchronisatie en uplink werken en NDR, indien aanwezig, afzonderlijk blijft werken. Documenteer het omschakeltijdstip en de observatieperiode. Bewaar tot dan de oude SVA en de configuratie voor een mogelijke terugkeer. Beslis pas daarna over resterende workloads en veilige buitengebruikstelling.

Fouten onderzoeken en zonder IP-conflict terugschakelen

Geen nieuwe collector beschikbaar: een hardwareappliance, SVA met uitsluitend NDR of niet-SVA-VM wordt niet automatisch gemigreerd. Controleer bij een actief gebruikte syslog-SVA of poort en protocol zijn geconfigureerd en de statische netwerkwaarden volledig zijn. Ontbrekende gateway- of DNS-waarden kunnen migratie verhinderen. Corrigeer een ongeldige netwerkconfiguratie in Fusion en bespreek met Support een nieuwe migratiepoging, of maak een expliciet geplande handmatige collector aan. Gebruik geen placeholderadressen alleen om een formulier geaccepteerd te krijgen.

Nieuwe VM start niet: controleer ISO-koppeling, tweede schijf, RAM, vCPU’s en de x86-64-v2-functies die de VM kan zien. Installeer geen reparatie- of monitoringsoftware op de collector.

Collector blijft offline: controleer eerst het daadwerkelijk toegewezen IP-adres of de lease, gateway, DNS en tijdsynchronisatie voor de bootstrap. Controleer daarna de firewall-/proxylogs voor de regionale TCP/443-uplink. Een open uitgaande poort bewijst op zichzelf geen geslaagd mTLS-kanaal. Controleer bij hetzelfde IP-adres ook of de oude SVA echt uit staat.

Collector is Ready, maar een bron ontbreekt: controleer doeladres van de bron, route en inkomende syslogpoort. Vergelijk poorttoewijzing en formaat met de oude integratie. Een logforwarder vóór de collector moet het verwachte integratieformaat behouden; anders komen gegevens mogelijk als generieke gebeurtenissen binnen in plaats van in het verwachte schema. Toon eerst de gegevensroute aan en zoek daarna naar een detection.

Behandel statische adressen en DHCP-reserveringen afzonderlijk bij het terugschakelen:

• Hetzelfde statische IP-adres: schakel de nieuwe VM uit en start pas daarna de oude SVA met haar bewaarde statische configuratie. Bronnen behouden hun bestaande doel. Controleer of de oude SVA dit IP-adres daadwerkelijk gebruikt en nieuwe sysloggebeurtenissen ontvangt en doorstuurt. Schakel nooit beide VM’s met dit adres in.
• DHCP-reservering op hetzelfde IP-adres: schakel eerst de nieuwe VM uit. Koppel daarna de reservering van het oude IP-adres weer aan het gedocumenteerde oude SVA-MAC-adres en behandel de leasestatus volgens de gedocumenteerde procedure van het eigen DHCP-platform. Er wordt hier geen universeel commando voor het verwijderen van leases verondersteld. Start pas daarna de oude SVA, controleer de werkelijke lease en het IP-adres en bewijs met een nieuwe sysloggebeurtenis dat ontvangst en doorsturen werken. Bronnen behouden hun bestaande doel; alleen de SVA starten bewijst dus nog geen werkend herstelpad. Schakel nooit beide VM’s met dit adres in.
• Ander IP-adres of DNS-doel: zet de gedocumenteerde brondoelen en eventueel bijbehorende netwerkregels terug naar de oude collector. Controleer met een nieuwe gebeurtenis of de oude SVA weer ontvangt en doorstuurt. Stel de nieuwe collector pas buiten gebruik nadat alle toewijzingen zijn gecontroleerd.

Het herstelpad is pas gevalideerd wanneer de oude SVA aantoonbaar het bedoelde doeladres gebruikt en nieuwe sysloggebeurtenissen weer worden ontvangen en doorgestuurd.

Terugschakelen werkt alleen zolang de oude SVA beschikbaar is en de configuratie behouden is. Het draait de productupgrade van de leverancier niet terug en garandeert geen herstel van niet-afgeleverde gebeurtenissen. Sophos kondigt een later einde van de ondersteuning voor SVA-logcollectors aan, maar noemt in de hier gecontroleerde migratieversie geen concrete datum. Nieuwe logcollectorinstanties moeten na de migratie als XDR Data Collectors worden aangemaakt. De oude SVA is daarom een beperkt herstelpad voor de bestaande situatie, geen langetermijnstrategie voor nieuwe installaties.

Als de oorzaak onduidelijk blijft, verzamel dan de collector- en tenantidentiteit, het platform, opgeschoonde netwerkwaarden, de betrokken bron, exacte tijdvakken, status en foutmelding. Escaleer via Een Sophos-supportticket openen. Secrets, configuratie-ISO’s en niet-opgeschoonde loggegevens horen niet in openbaar toegankelijke tickets of screenshots.