Migrer les collecteurs de logs SVA vers Sophos XDR Data Collectors

Lors du passage à la solution Sophos XDR étendue, Sophos provisionne une nouvelle configuration XDR Data Collector pour les collecteurs de logs Sophos Security Virtual Appliance (SVA) éligibles. Cela n’installe ni n’active automatiquement la VM dans votre environnement. Vous devez déployer le remplacement, basculer le chemin Syslog et vérifier la réception de nouveaux événements. Si l’adresse IP est identique, l’ancien collecteur ne doit pas être en fonctionnement lorsque le nouveau démarre.

Le XDR Data Collector est un récepteur Syslog virtuel installé sur site ou dans AWS, Azure ou GCP. Il transmet les logs reçus à Sophos XDR. Une intégration API directe n’a pas besoin de ce récepteur Syslog. Le runbook des intégrations explique Data Ingest, Response Actions et ces types de connexion.

Si Sophos Next-Gen SIEM est déjà utilisé, Sophos recommande de remplacer les anciens collecteurs Syslog SVA par des XDR Data Collectors afin de bénéficier de toute la rétention des données prise en charge par le produit SIEM. Les intégrations API existantes n’ont pas besoin d’être reconfigurées pour ce changement de collecteur Syslog. Cela n’implique ni une durée de rétention déterminée ni un droit à la rétention SIEM pour tous les tenants XDR ; les conditions de rétention applicables à votre propre produit SIEM restent déterminantes.

État vérifié au 11 octobre 2026 : le guide de migration du 1er octobre 2026 complète le déploiement de septembre. L’ancien chemin de documentation EAP indique la provenance de la version et ne garantit pas que chaque tenant dispose déjà de la fonctionnalité. Vérifiez d’abord l’état de mise à niveau du tenant et le collecteur effectivement proposé sous Security Operations > Integrations > Data Collectors. Ce runbook décrit la bascule Syslog et un déploiement concret sur site dans vSphere ; les adresses cloud sont expliquées, mais la création des ressources cloud correspondantes ne fait pas partie des étapes vSphere.

Recenser les charges de travail existantes et les paramètres non migrés

Pour chaque ancien collecteur SVA, relevez la plateforme, le nom, le nom d’hôte, les paramètres réseau statiques ou le bail DHCP, toutes les sources émettrices ainsi que leur destination Syslog, leur port et leur protocole. Notez également le format des données, la sélection des types d’événements, les exclusions de domaines et de protocoles, les paramètres de passthrough et les identifiants nécessaires. Documentez la dernière réception de données vérifiable pour chaque source ; après la bascule, cela permet de distinguer un flux silencieux d’une erreur.

Les éléments repris automatiquement sont le nom du collecteur, le nom d’hôte ou le nom qui en est dérivé, l’adresse IP statique, le masque de sous-réseau, la passerelle et le DNS ou le paramètre DHCP, ainsi que les correspondances de ports et de protocoles Syslog. Les ports d’origine des sources sont conservés et associés aux ports Syslog standard UDP/514 ou TCP/601. Le type de plateforme détermine le nouveau collecteur cloud ou sur site.

Les éléments suivants ne sont pas repris automatiquement :

• Intégrations NDR : NDR n’utilise pas de chemin de transfert Syslog. Pour une SVA mixte, seule la partie Syslog est migrée ; une SVA exclusivement NDR ne reçoit pas de XDR Data Collector à ce titre.
• Filtres de types d’événements et listes d’exclusion de domaines et de protocoles.
• Paramètres de format Syslog et de passthrough propres à la SVA.
• Identifiants des intégrations.
• Investigation Consoles, Nessus Scanner et autres types de VM en dehors des collecteurs de logs SVA.
• Appliances matérielles physiques : elles ne sont pas automatiquement migrées vers des collecteurs virtuels.

Vérifiez explicitement, pour la nouvelle intégration, quels filtres et formats restent nécessaires et quelles options de configuration le connecteur propose à cet effet. L’absence de filtres peut entraîner l’ingestion de davantage de données que prévu ; un format incorrect peut conduire à traiter les logs uniquement comme des événements génériques. Ne copiez pas les identifiants depuis des tickets ou d’anciennes captures d’écran : fournissez-les à nouveau via le système de gestion des secrets prévu à cet effet.

Si NDR fonctionne sur la même SVA, la bascule Syslog ne doit pas arrêter le capteur par inadvertance. La variante utilisant la même IP exige l’arrêt de l’ancienne SVA et interrompt donc aussi sa charge de travail NDR. Planifiez son exploitation séparément ou choisissez une autre IP pour le nouveau collecteur Syslog afin que la SVA puisse continuer à fonctionner pour NDR. Le runbook d’exploitation NDR traite cette charge de travail ; le provisionnement d’un remplacement Syslog n’est pas une migration NDR.

Choisir la variante d’adressage avant le téléchargement

L’adresse de destination détermine si les deux VM peuvent fonctionner simultanément et si les sources doivent être modifiées.

Avec une IP statique identique, prévoyez une courte phase de bascule : arrêtez l’ancienne SVA, puis démarrez la nouvelle VM. Les sources conservent leur destination. Cela ne garantit pas une transition sans perte ; la conservation des événements pendant l’interruption dépend aussi de la mise en mémoire tampon et du transport assurés par le système source.

Pour une migration progressive, définissez la nouvelle IP statique avant le téléchargement de l’ISO. Exemple : l’ancien collecteur utilise 192.0.2.10, le nouveau 192.0.2.20. Ces adresses de documentation ne doivent pas être utilisées en production. Choisissez plutôt une adresse libre dans le réseau approprié de votre environnement et vérifiez le sous-réseau, la passerelle, le DNS ainsi que l’accessibilité depuis les réseaux sources. Une nouvelle IP facilite le retour arrière et permet de basculer les sources une par une ; elle nécessite toutefois d’adapter les destinations et les règles de pare-feu.

Avec DHCP et réutilisation de l’ancienne IP, documentez avant la bascule les adresses MAC de l’ancienne et de la nouvelle VM, la réservation IP existante et l’état actuel du bail. Modifiez ou créez ensuite la réservation afin d’associer l’ancienne IP à l’adresse MAC de la nouvelle VM ; respectez la procédure documentée de gestion des réservations et des baux de la plateforme DHCP utilisée. Arrêtez ensuite l’ancienne SVA, puis seulement démarrez le nouveau collecteur. Vérifiez son bail effectif et l’IP attribuée avant de valider les données. Une réservation n’empêche pas une ancienne VM encore en fonctionnement d’utiliser la même adresse.

Pour les collecteurs cloud, l’adresse change toujours. Avec AWS et CloudFormation, la valeur CTPxCollectorDnsName est disponible dans la pile sous Outputs. Il s’agit du nom DNS du Network Load Balancer, à privilégier pour les sources Syslog plutôt qu’une IP configurée en dur. Pour Azure, vérifiez l’adresse de l’interface réseau de la VM dans le portail Azure ; pour GCP, vérifiez l’adresse interne sous Compute Engine > VM instances. Les adresses DHCP peuvent être identifiées dans la table des baux à partir de la nouvelle adresse MAC, ou via Data Collectors. Ne confondez pas cette adresse de destination des sources avec les adresses régionales de liaison montante Sophos.

Préparer le chemin réseau et les ressources du collecteur

L’envoi du collecteur vers Sophos XDR utilise mTLS avec TLS 1.3 et TCP/443 en sortie. Cela ne signifie pas qu’aucun port entrant n’est nécessaire : vos sources Syslog doivent pouvoir atteindre le collecteur sur le port et avec le protocole configurés. Les destinations standard sont UDP/514 et TCP/601 ; comparez également les correspondances de ports migrées à la configuration précédente. Ne créez pas d’autorisation d’accès Internet générale au récepteur Syslog.

Autoriser la liaison montante régionale, le DNS et la synchronisation horaire

Les destinations de liaison montante du collecteur ci-dessous constituent un instantané vérifié au 11 octobre 2026. L’affectation US1/US2/US3/EU1/EU2 provient de la configuration du collecteur XDR, et non d’une équivalence supposée avec une région AWS de Central. Utilisez uniquement la région réellement attribuée. L’ensemble d’adresses IP Sophos existant pour les appels API entrants chez le fournisseur tiers relève d’une autre liste d’autorisation.

Si votre pare-feu exige des autorisations fondées sur les IP, les adresses de destination suivantes font partie de cet instantané. Ne regroupez pas les régions :

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

Avant toute modification en production, comparez la région et les destinations à la configuration actuelle du tenant et à la liste d’autorisation du collecteur tenue à jour par le responsable d’exploitation. Les écarts doivent faire l’objet d’un changement validé, et non d’une autorisation élargie par précaution. Le nom technique du point de terminaison secureworks.com reste inchangé.

Le collecteur a également besoin de UDP et TCP/53 vers les serveurs DNS renseignés lors du provisionnement. La synchronisation horaire nécessite UDP/123 vers les serveurs NTP choisis. Sans configuration NTP spécifique, les collecteurs hors AWS utilisent 0.pool.ntp.org à 3.pool.ntp.org ; pour AWS, la destination par défaut est 169.254.169.123. Avec un NTP local, le trafic entre le collecteur et le serveur de temps doit être autorisé dans les deux sens. Pour le collecteur sur site, ces paramètres NTP servent à l’amorçage ; une fois la connexion établie, le canal vers le backend XDR assure la synchronisation horaire. Selon le guide de la plateforme, les contrôleurs de domaine Windows ne conviennent pas comme destination NTP pour cet hôte non membre du domaine.

Un proxy Web de sortie peut être renseigné via Host Proxy. La présentation générale du collecteur exclut les proxys authentifiés configurés de manière fixe, tandis que le guide sur site montre également une syntaxe d’URL avec nom d’utilisateur et mot de passe. Ces indications ne concordent pas. Ne prévoyez donc pas de chemin via un proxy authentifié en production sans avoir obtenu une validation explicite de Sophos ; ne contournez pas cette contradiction en intégrant des identifiants dans l’ISO. En cas d’inspection TLS, la liaison montante mTLS concernée doit fonctionner sans interception MITM. Toute exception doit être limitée aux connexions nécessaires au collecteur.

Ne pas dimensionner la VM sur site selon les anciennes valeurs de la SVA

La nouvelle VM sur site nécessite 4 vCPUs à au moins 2 GHz, 8 GB de RAM, un disque système de 20 GB et un disque de données de 200 GB. Le guide de la plateforme indique comme environnements recommandés vSphere ESXi 6.7 ou ultérieur, Hyper-V 8.0 sous Windows Server 2016 ou ultérieur, ainsi que Nutanix 6.8.x ou ultérieur. Les fonctionnalités CPU x86-64-v2 doivent être visibles par la VM ; un masque de compatibilité CPU inadapté peut empêcher son démarrage.

La valeur jusqu’à 200'000 EPS est une limite supérieure pour des collecteurs cloud et sur site correctement configurés, et non une garantie de débit avec ces ressources minimales. Dimensionnez en fonction du nombre, de la taille et des pics de charge des événements, et contrôlez le flux de données réel. Aucun outil tiers ni aucune application supplémentaire ne doit être installé sur le collecteur. Les mises à jour sont automatiques, généralement toutes les 24 heures lorsque la connexion fonctionne correctement.

Déployer le collecteur sur site préprovisionné sur vSphere

Pour une migration existante, utilisez la configuration correspondante sous Security Operations > Integrations > Data Collectors. Comparez le nom, les paramètres réseau et les correspondances Syslog à ceux de l’ancienne SVA. Téléchargez l’ISO contenant la configuration du collecteur et l’OVA de la VM. Les deux vont de pair ; l’ISO d’un autre collecteur provisionnerait un état incorrect. Conservez les fichiers de configuration avec un accès restreint.

Si la configuration est absente, vérifiez d’abord les exclusions et les erreurs réseau dans la section suivante. Pour créer délibérément un remplacement manuel, l’interface propose Actions > Add Collector > On-Premises > Next. Renseignez le nom et le nom d’hôte, éventuellement la description, Host Proxy et NTP, ainsi que DHCP ou les paramètres réseau statiques complets, puis créez le collecteur avec Create Collector. Cela ne justifie pas de créer un collecteur en doublon non maîtrisé à côté d’une migration déjà existante.

Sur vSphere, procédez au déploiement comme suit :

1. Dans la vSphere Web Console, ouvrez Virtual Machines > Create / Register VM et sélectionnez Deploy a virtual machine from an OVF or OVA file.
2. Attribuez un nom de VM unique, par exemple sophos-xdr-collector, et sélectionnez l’OVA téléchargée. Le nom est libre ; il doit permettre de distinguer la VM de l’ancienne SVA dans l’hyperviseur.
3. Choisissez un datastore disposant d’au moins 220 GB d’espace libre pour les deux disques. Contrôlez l’affectation réseau et la configuration des disques, vérifiez le récapitulatif et terminez avec Finish. Laissez la VM éteinte pour le moment.
4. Sous Storage > Datastore Browser, téléversez l’ISO de configuration correspondante.
5. Ouvrez Edit Settings pour la VM. Faites passer le CD-ROM de Client Device à Datastore ISO File, sélectionnez l’ISO téléversée et enregistrez. Avant le premier démarrage, vérifiez que l’ISO est effectivement montée et que la VM peut atteindre le réseau source approprié.
6. Si l’IP est identique, arrêtez maintenant l’ancienne SVA. Démarrez la nouvelle VM seulement ensuite. Avec une nouvelle IP, l’ancienne SVA peut continuer à fonctionner ; les sources seront ensuite basculées une par une.
7. Sous Security Operations > Integrations > Data Collectors, attendez que le nouveau collecteur affiche Ready. L’ISO ne peut être démontée qu’à ce moment-là. Ready ne confirme pas encore que chaque source est correctement ingérée.

Pour Hyper-V, Sophos fournit un package VHD à la place de l’OVA ; pour Nutanix, des fichiers QCOW2. Le second disque de données et l’ISO montée au premier démarrage restent nécessaires. La séquence de clics vSphere ne doit pas être transposée à ces plateformes. De même, les collecteurs cloud doivent être déployés avec les ressources de leur plateforme respective, et non sous forme d’OVA dans vSphere.

Basculer les sources et valider le flux de données

Si l’adresse de destination change, reconfigurez tous les équipements et applications concernés vers la nouvelle IP du collecteur ou le nouveau nom DNS. Modifiez uniquement la destination, et non le port, le protocole ou le format des logs sans vérification : ces correspondances doivent être reprises de la SVA. Si une source envoyait jusque-là ses données en UDP/514, elle reste en UDP/514 pour cette migration. Le passage du transport à TCP constitue un changement distinct, avec vérification du système source.

Avec des IP différentes, commencez par basculer une source de périmètre limité. Générez-y un événement inoffensif pris en charge par le connecteur et notez la source, le type d’événement et l’heure avec le fuseau horaire. Recherchez-le dans XDR par le moyen d’accès aux données ou de requête proposé pour cette intégration. La preuve doit montrer le bon tenant, la source, l’horodatage et le format d’événement approprié. Tenez compte des délais attendus du connecteur ; un événement de test ne génère pas nécessairement un Case ou une Detection.

Ne basculez les autres sources qu’après cette vérification. Pour chaque source, comparez les derniers événements avant la bascule et les premiers après. Il ne faut pas attendre une durée ou un taux d’événements identique pour toutes les sources ; leur activité réelle et l’absence de périodes inexpliquées sans données sont déterminantes. Évitez l’envoi simultané non planifié du même flux de données aux deux collecteurs, car cela peut générer des doublons.

La SVA existante peut continuer à fonctionner pendant la planification. Les données historiques de la SVA déjà ingérées restent consultables dans XDR ; le remplacement n’a pas à les envoyer à nouveau. Cela ne constitue pas un nouvel engagement de rétention illimitée. Le spool de 200 GB du nouveau collecteur met les logs en tampon lorsque la liaison montante est lente ou temporairement interrompue. Il ne dispense pas de vérifier la source et ne garantit pas la prise en charge de pannes d’une durée quelconque.

La validation opérationnelle n’est acquise que lorsque toutes les sources attendues fournissent des données actuelles et correctement attribuées, que les filtres et exclusions ont été vérifiés délibérément, que le DNS, la synchronisation horaire et la liaison montante fonctionnent et, le cas échéant, que NDR continue à fonctionner séparément. Documentez l’instant de la bascule et la période d’observation. Conservez jusque-là l’ancienne SVA et sa configuration pour un éventuel retour arrière ; décidez seulement ensuite du devenir de ses charges de travail restantes et de sa mise hors service sécurisée.

Isoler les erreurs et revenir en arrière sans conflit IP

Aucun nouveau collecteur présent : une appliance matérielle, une SVA exclusivement NDR ou une VM autre qu’une SVA n’est pas migrée automatiquement. Pour une SVA Syslog activement utilisée, vérifiez que le port et le protocole sont configurés et que les paramètres réseau statiques sont complets. L’absence de paramètres de passerelle ou de DNS peut empêcher la migration. Corrigez la configuration réseau invalide dans Fusion et convenez avec le support d’une nouvelle migration, ou créez un collecteur manuel explicitement planifié. N’utilisez pas d’adresses fictives uniquement pour faire accepter un formulaire.

La nouvelle VM ne démarre pas : vérifiez l’association de l’ISO, le second disque, la RAM, les vCPUs et les fonctionnalités x86-64-v2 visibles par la VM. N’installez aucun logiciel de réparation ou de supervision sur le collecteur.

Le collecteur reste hors ligne : vérifiez d’abord l’IP réellement attribuée ou le bail, la passerelle, le DNS et la synchronisation horaire d’amorçage. Contrôlez ensuite les logs du pare-feu et du proxy pour la liaison montante régionale en TCP/443. Un port sortant ouvert ne prouve pas à lui seul qu’un canal mTLS est établi. Dans le scénario avec IP identique, assurez-vous également que l’ancienne SVA est réellement éteinte.

Le collecteur est Ready, mais une source manque : vérifiez l’adresse de destination de la source, la route et le port Syslog entrant. Comparez la correspondance des ports et le format à l’ancienne intégration. Un relais de logs en amont doit préserver le format attendu par l’intégration ; sinon, les données peuvent arriver comme des événements génériques plutôt que dans le schéma attendu. Vérifiez d’abord le chemin des données, puis recherchez une Detection.

Pour le retour arrière, traitez séparément les adresses statiques et les réservations DHCP :

• Même IP statique : arrêtez la nouvelle VM, puis seulement démarrez l’ancienne SVA avec sa configuration statique conservée. Les sources gardent leur destination précédente. Vérifiez que l’ancienne SVA utilise effectivement cette IP et qu’elle reçoit et transmet de nouveaux événements Syslog. N’allumez jamais les deux VM avec cette adresse.
• Réservation DHCP sur la même IP : arrêtez d’abord la nouvelle VM. Réassociez ensuite la réservation de l’ancienne IP à l’ancienne adresse MAC de la SVA documentée et traitez l’état du bail selon la procédure documentée de votre plateforme DHCP. Aucune commande universelle de suppression de bail n’est présupposée ici. Démarrez seulement ensuite l’ancienne SVA, contrôlez son bail effectif et son IP, puis démontrez la réception et la transmission à l’aide d’un nouvel événement Syslog. Les sources conservent leur destination précédente ; le simple démarrage de la SVA ne prouve donc pas que le retour arrière fonctionne. N’allumez jamais les deux VM avec cette adresse.
• Autre IP ou destination DNS : rétablissez les destinations des sources documentées et, le cas échéant, les règles réseau associées vers l’ancien collecteur. Vérifiez avec un nouvel événement que l’ancienne SVA reçoit et transmet à nouveau les données. Ne mettez le nouveau collecteur hors service qu’après avoir vérifié toutes les correspondances.

Le retour arrière n’est validé que lorsque l’ancienne SVA détient de manière vérifiable l’adresse de destination prévue et que de nouveaux événements Syslog sont à nouveau reçus et transmis.

Un retour arrière ne fonctionne que tant que l’ancienne SVA reste disponible et que sa configuration est conservée. Il n’annule pas la mise à niveau du produit côté fournisseur et ne garantit pas la récupération des événements non livrés. Sophos annonce une fin de support ultérieure pour les collecteurs de logs SVA, mais ne précise aucune date dans l’état de migration vérifié ici. Après la migration, les nouvelles instances de collecteurs de logs doivent être créées en tant que XDR Data Collectors ; l’ancienne SVA constitue donc une possibilité limitée de retour à l’existant, et non une stratégie de nouvelle installation à long terme.

Si la cause reste indéterminée, rassemblez l’identité du collecteur et du tenant, la plateforme, les paramètres réseau expurgés des informations sensibles, la source concernée, les plages horaires exactes, l’état et le message d’erreur. Pour l’escalade, suivez Ouvrir un ticket de support Sophos. Les secrets, l’ISO de configuration et les logs non expurgés ne doivent pas figurer dans des tickets ou captures d’écran librement accessibles.