Configurer les intégrations MDR et XDR dans Sophos Fusion

Les intégrations permettent à Sophos Fusion (anciennement Sophos Central) de regrouper dans le Sophos Data Lake la télémétrie issue de produits Sophos et tiers, ou de proposer des Response Actions ciblées. Il est essentiel de choisir le bon type d’intégration : Data Ingest fournit des données pour les requêtes, les détections et les investigations, tandis que Response Action exécute une action dans le produit connecté. Tous les produits ne prennent pas en charge les deux directions.

Le point d’entrée dépend de l’état de mise à niveau du produit dans le tenant. Pour la solution XDR/MDR étendue, utilisez Security Operations > Integrations > Marketplace ; les configurations Classic existantes se trouvent sous Threat Analysis Center > Integrations. Les instructions TAC conservées ci-dessous décrivent ce parcours Classic et ne correspondent pas à une séquence de clics identique dans la nouvelle interface. La vérification de la mise à niveau propre au tenant aide à déterminer le parcours applicable. La seule présence des noms Fusion à l’écran ne prouve pas que la mise à niveau du produit est terminée.

Dans le parcours d’onboarding Endpoint, cet article couvre la phase d’intégration interproduits entre la configuration de la protection et la validation opérationnelle.

La démarche pratique consiste à vérifier la licence et le système source, à sélectionner dans Marketplace la vignette produit et la configuration appropriées, à établir la connexion avec les droits les plus restreints possible, puis à la contrôler sous Configured et à la valider avec un événement de test attendu. L’intégration ne doit être considérée comme opérationnelle qu’après cette vérification.

Contrôler séparément la connexion et le flux réel de données

Dans l’interface actuelle, ouvrir Security Operations > Integrations > Configured Integrations. Sous Data Ingest, le statut indique la configuration et la connexion de l’intégration API, syslog ou Sophos. Le vert confirme la communication, pas encore des événements correctement normalisés. Un avertissement peut apparaître après 20 minutes sans communication ou lorsque certaines ressources ne remontent plus ; une erreur après 60 minutes ou un échec d’authentification. Le texte au survol précise la cause.

Pour une intégration API, ouvrir son nom puis API Query Logs. La période par défaut est le dernier jour ; jusqu’à sept jours peuvent être sélectionnés. Sous Details, comparer les paramètres au bon tenant source. Les intégrations hiérarchiques peuvent comporter un parent et plusieurs endpoints enfants ; un sous-chemin sain ne prouve pas le fonctionnement de tous les enfants.

Contrôler ensuite Security Operations > Integrations > Configured Data Sources. Cette vue distincte indique si les logs arrivent effectivement et à quels schémas ils sont associés. Healthy signifie une activité depuis moins d’une heure, Warning entre une et 24 heures et Unhealthy plus de 24 heures sans activité. Ce sont d’autres critères que les seuils de connexion ci-dessus. Une source peu bavarde s’évalue selon son activité attendue, pas au moyen d’un événement de test inventé qui la ferait déclarer saine.

Un clic sur la source affiche l’historique des messages par schéma sur 24 heures. Pour l’acceptation, générer un événement autorisé dans le système source et comparer heure, source, champs requis et schéma normalisé. Advanced Search dans les détails ouvre une recherche préparée sur l’ID du capteur pour les dernières 24 heures. Le guide de recherche explique les filtres supplémentaires. Si les données manquent, vérifier d’abord le chemin source → intégration/collector → schéma ; un événement d’audit ordinaire ne doit pas nécessairement produire une detection.

Export All as CSV ou Export Selected as CSV sauvegarde l’inventaire des sources via Data Exports. L’icône de corbeille ne retire en revanche que l’enregistrement de la source, pas la télémétrie déjà reçue. La suppression est irréversible ; une source qui continue d’émettre réapparaît et le retrait peut prendre jusqu’à cinq minutes. Supprimer n’est donc ni une confirmation d’effacement de télémétrie ni un test de réparation.

Visibilité, autorisations et allowlist API actuelle

Selon le produit, Marketplace affiche des cartes Ingest et Actions séparées. EDR sans XDR n’affiche pas de cartes d’ingestion non-endpoint ; les actions de réponse peuvent rester visibles. Admin et Super Admin peuvent gérer les intégrations. Help Desk et Read-only ne voient que configuration et statut. Pour les Custom Roles, attribuer Integration: read et seulement les droits nécessaires create, update, delete et download. Vérifier licence et rôle avant d’étendre les droits pour une fonction absente.

L’allowlist XDR actuelle se distingue de l’instantané IP Classic conservé plus bas et de l’uplink du collector. Déterminer la région géographique XDR réelle sous Profile icon > Support settings, sans la déduire du nom d’un produit. La liste du fabricant du 25 septembre 2026 indique les réseaux suivants pour les appels administratifs/API vers le tiers :

N’autoriser que le réseau de l’intégration réelle, après approbation du changement. La liste ne prouve pas que chaque produit est disponible dans chaque région et ne remplace pas la vérification des destinations API actuellement nécessaires. Le chemin mTLS sortant du collector utilise d’autres destinations.

Cibler les notifications de santé

Les règles expliquées plus bas pour 24 heures de panne continue, la remise à zéro du compteur et la répétition tous les 30 jours s’appliquent aussi à l’aide Fusion actuelle du 20 octobre 2026. L’e-mail n’est pas une alerte immédiate après les 20 ou 60 minutes mentionnées plus haut.

Ouvrir une règle de destinataires personnalisée sous General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Après rôle, administrateurs/listes de distribution et périmètre des appareils, choisir sous Alert Types les filtres Medium alert, produit Sophos Central et catégorie Central Integrations Alert. Définir ensuite nom/description et enregistrer. Prévoir la distribution des autres alertes avant l’enregistrement : la première règle personnalisée désactive l’envoi par défaut de tous les e-mails d’alerte à tous les administrateurs. Préserver les autres destinataires nécessaires avec des règles adaptées supplémentaires ; ne pas provoquer une panne sur un connecteur de production uniquement pour forcer un e-mail.

Étapes suivantes selon la source

Pour les sources personnalisées, HTTP Ingest, S3 et Azure expliquent les transports distincts. L’exploitation du collector et le déploiement cloud complètent le runbook de migration existant. Cloud Flow Logs, la télémétrie réseau et Windows Event Logs traitent les formats sources et les limites de licence par schéma. Toute télémétrie d’un fabricant n’est pas automatiquement une source réservée à SIEM.

Après la mise à niveau : rendre les Response Actions de nouveau opérationnelles

État vérifié le 11 octobre 2026 : la solution étendue utilise un autre modèle d’exécution et d’autorisations pour les Actions. Les connexions TAC existantes et leurs identifiants ne sont pas simplement repris à cette fin. Avant toute modification, documentez les tenants Microsoft concernés, les connexions, les actions activées et les responsables. L’ingestion réussie de données par un connecteur d’audit ou Graph distinct ne constitue pas un test de réponse.

Reconnecter Microsoft 365 ou réautoriser les identifiants

Ces étapes nécessitent le rôle Admin ou Super Admin dans Sophos Fusion et un Microsoft 365 administrator côté Microsoft. Dans chaque boîte de dialogue de consentement, vérifiez les droits effectivement demandés et le tenant Microsoft sélectionné ; ne reprenez pas sans vérification les autorisations d’une ancienne application TAC.

Si l’ancienne connexion TAC n’est pas encore configurée dans la nouvelle interface, créez-la comme suit :

1. Ouvrez Security Operations > Integrations > Marketplace, puis la vignette Actions Microsoft Graph API.
2. Sélectionnez Add new connection. Dans la section Add a Connection, sélectionnez de nouveau Add new connection, renseignez Name et, si nécessaire, Description ainsi que Tags, puis poursuivez avec Done.
3. Lancez l’autorisation Microsoft guidée avec Proceed. Un nom tel que M365-Response-Produktiv n’est qu’un libellé libre ; les éléments déterminants sont le bon tenant source et les droits approuvés.
4. Dans Pick an account, sélectionnez le compte administrateur prévu. La première demande Permissions requested autorise l’application principale Sophos. Après le retour à Sophos, une deuxième étape Microsoft concerne la connexion de réponse proprement dite. Après vérification des droits, terminez les deux boîtes de dialogue avec Accept. Si l’une d’elles est annulée, aucune connexion n’est créée.
5. Après le retour, vérifiez les actions proposées et n’enregistrez avec Save que le périmètre approuvé. La nouvelle connexion doit apparaître dans Configured Integrations.
6. Dans Microsoft Entra, sous Manage > All applications, utilisez Refresh pour vérifier que l’application de réponse nouvellement créée apparaît comme activée.

Si une connexion existe déjà sous Microsoft Graph API > Configured Integrations, ouvrez le menu à trois points à côté du nom de la connexion, puis Edit Connection. Sélectionnez Re-Authorize Credentials et suivez la procédure d’autorisation Microsoft. Ce bouton n’apparaît que lorsqu’une réautorisation est nécessaire et disparaît une fois celle-ci terminée. Répétez cette opération pour chaque connexion concernée ; la réparation d’une seule connexion ne suffit pas pour tous les tenants ou toutes les configurations.

Les instructions mises à jour le 7 octobre 2026 distinguent explicitement la protection qui continue de fonctionner des actions de réponse Microsoft susceptibles d’échouer jusqu’à la réautorisation. Elles indiquent le 1er octobre 2027 comme date limite de validité des anciens identifiants. Si vous avez besoin des Actions, n’attendez pas cette échéance : la preuve de fonctionnement requise doit être apportée dès maintenant.

La validation comprend la bonne application Entra, les connexions attendues et les actions activées, ainsi qu’un test approuvé avec un compte dédié. Utilisez uniquement une modification réversible documentée pour l’action concernée. La paire Classic Block user sign-in / Allow user sign-in décrite ci-dessous ne prouve pas que chaque nouvelle Action porte le même nom ou dispose de la même procédure de retour arrière. Les sessions ne peuvent pas être restaurées après révocation. Dans les détails de l’Action, View Executions > History fournit l’historique ; vérifiez également l’état réel dans Microsoft. Un consentement ou une entrée d’exécution réussie ne remplace pas à lui seul cette contre-vérification.

Ajouter Sophos Firewall (Actions) uniquement si la connexion est absente

Après la mise à niveau du produit, ouvrez d’abord un Case et vérifiez si les actions Sophos Firewall sont disponibles. Si oui, aucune nouvelle connexion n’est nécessaire. Si elles sont absentes :

1. Ouvrez Security Operations > Integrations > Marketplace.
2. Recherchez et ouvrez Sophos Firewall (Actions).
3. Sélectionnez Add new connection, puis enregistrez avec Save.

Aucun identifiant n’est demandé pour cette connexion. Les actions de réponse Firewall sont ensuite disponibles depuis les Cases, par exemple pour bloquer des adresses IP, domaines ou URL malveillants. Les analystes MDR peuvent exécuter ces actions dans le cadre du paramètre de réponse approuvé ; les utilisateurs XDR peuvent les lancer eux-mêmes depuis le Case. Vérifiez leur disponibilité sans bloquer de cibles en production. Un test de leurs effets constitue un changement distinct et approuvé, avec une procédure de retour arrière propre au produit définie au préalable.

Désactiver les nouvelles Actions de manière ciblée plutôt que supprimer aveuglément les connexions

Un commutateur est documenté pour les Actions de la solution étendue : sous Security Operations > Integrations > Marketplace, Configured > Actions, ouvrez l’Action concernée et désactivez-la dans la section Enable/disable integration. Ce n’est pas un commutateur universel pour tous les connecteurs Data Ingest. Une désactivation n’annule pas les modifications déjà effectuées dans le système source.

Delete Integration supprime les connexions et conditions associées et rétablit la configuration de l’Action à son état initial. La suppression de l’unique connexion supprime également les conditions qui lui sont associées. Sauvegardez ou documentez donc les connexions et conditions au préalable. Pour annuler les actions de test, utilisez toujours la procédure de retour arrière Microsoft ou Firewall correspondante, et non la suppression du connecteur.

Automatisations XDR : distinguer Classic REST et GraphQL

Cet état des API constitue un complément du 9 octobre 2026, et non un engagement rétroactif concernant le lancement de septembre. Les nouvelles intégrations XDR et les workflows XDR effectuant des écritures sur Fusion doivent utiliser les nouvelles GraphQL APIs. Il faut les distinguer d’une connexion API du Marketplace : les appels REST de cette dernière peuvent toujours être adressés au fournisseur tiers.

Les anciennes Cases REST API et Detections REST API portent désormais le nom Classic XDR APIs et sont dépréciées. La Detections REST API est déjà read-only. La Cases REST API reste disponible pour les intégrations existantes ; elle doit elle aussi passer ultérieurement en lecture seule. Les deux API doivent ensuite fournir des données historiques jusqu’à leur suppression. Aucune date précise d’arrêt n’est indiquée dans cet état des lieux. Ne supprimez donc pas systématiquement les intégrations existantes et ne modifiez pas leurs hôtes en raison du nom Fusion.

Pour chaque automatisation, consignez l’API, les opérations de lecture et d’écriture, la période des données, le tenant, les droits et la gestion des erreurs. Pour les clients existants, vérifiez séparément si des données actuelles ou historiques sont attendues et si un workflow d’écriture tente encore d’accéder à Classic Detections. Pour passer à GraphQL, le mappage des champs, la pagination, l’authentification, les autorisations et la gestion des erreurs doivent être implémentés à partir du nouveau schéma concret et comparés dans un test isolé. Cet article ne fournit volontairement aucun endpoint, nom de mutation ou payload inventé. L’inventaire est terminé lorsque chaque client dispose d’un responsable et d’une décision traçable de maintien en service ou de migration ; il ne constitue pas encore un test réussi de migration d’API.

Quelle GraphQL API convient au client ?

La publication du 18 septembre 2026 comprenait cinq API GraphQL aux fonctions différentes :

• Detections v2: rechercher et modifier les Detections provenant d’endpoints, de capteurs réseau et d’autres sources.
• Cases v2: gérer les Cases ainsi que les Evidence, commentaires, fichiers et liens.
• Threat Timeline v2: rechercher les relations entre processus pour un maximum de 100 processus en un appel.
• Events v1: récupérer les détails des événements à partir d’ID d’événements connus.
• Live Endpoint Search v1 (LES): exécuter des requêtes de type osquery sur des endpoints connectés et récupérer les résultats ainsi que Telemetry.

Live Discover REST n’est pas concerné par la dépréciation des Classic Cases/Detections APIs. Les intégrations Live Discover REST existantes peuvent continuer de fonctionner ; leur passage à LES est facultatif. La voie en direct et la XDR Query API historique répondent à des besoins différents. La délimitation des API Live Discover explique également la sélection des cibles LES par session. De même, l’Endpoint API sous /endpoint/v1 et sa fonction Device Migration ne sont pas migrées vers GraphQL en raison de cette dépréciation XDR.

Depuis le 12 octobre 2026, la Search GraphQL API v1 est également publiée pour les recherches QL historiques. Elle propose createSearch, getOrCreateSearch, search et searchResults ; Interroger le Data Lake Sophos Fusion avec la Search GraphQL API décrit le contrat de requête, le statut d’exécution, les pages de résultats et les vérifications de migration SQL. Data Lake Search reste la voie interactive ; XDR Query API reste disponible. La nouvelle API n’impose pas de transition immédiate et n’est pas un processus LES sur des endpoints en direct. Pour Assets et Entity Graph, les vérifications séparées des références et du tenant restent ouvertes : leur mention dans le guide Cases n’est pas une autorisation complète d’implémentation.

Vérifier le contrat de migration concret

Le changement ne consiste pas à remplacer l’URL en conservant le client à l’identique. Pour Cases, Detections et, éventuellement, LES, on compare chaque workflow propre, plutôt que d’appliquer une recette commune de REST vers GraphQL :

• GraphQL ne fournit que les champs sélectionnés. Le client vérifie à la fois l’état HTTP, le tableau errors et les champs d’état propres à l’opération ; HTTP 200 peut contenir une erreur de requête. Les champs imbriqués nécessaires et les indications temporelles avec seconds/nanos sont sélectionnés et traités délibérément.
• Pour Detections, detectionSearch remplace la procédure REST de lancement de la requête, de consultation de l’état et de récupération des résultats. Les petits ensembles de recherche utilisent offset/limit, les grands ensembles le search_id renvoyé avec detectionPoll. Rapprochez toutes les parties et le nombre total. Les filtres sont vérifiés individuellement comme prédicats QL ; une recherche d’hôte attend un ID, pas simplement le nom de l’appareil. Aucun remplacement identique n’est garanti pour un type REST ou une réputation Intelix.
• La sévérité des Detections dans REST et GraphQL évalue des jeux de données distincts selon des modèles distincts. REST utilise une échelle d’entiers allant jusqu’à 10, tandis que metadata.severity dans GraphQL utilise une échelle de 0 à 1. Ne convertissez pas par division. Réévaluez les seuils sur le plan fonctionnel à partir des données respectives. Case.severity, avec 2/4/6/8/10, constitue encore une autre échelle.
• Pour Cases, le client API utilise l’UUID id, et non la valeur lisible shortId au format CSE#####. Les anciens ID de Cases REST ne sont pas convertis et les anciens Cases ne deviennent pas disponibles via la nouvelle API. Les preuves requises pour les anciens dossiers sont sauvegardées avant la bascule par la méthode de récupération existante confirmée ; cela n’implique ni un bouton d’export universel ni une reprise de l’historique.
• Les types de Cases, états et Verdicts sont résolus comme données de référence dynamiques du tenant, dépendantes de la licence, et actualisés régulièrement. assigneeId attend une Subject ID ou une @mention prise en charge, pas une adresse e-mail. Un assigneeSubject impossible à résoudre peut être null ; l’affichage doit prévoir explicitement une valeur de remplacement.
• caseEvidence fournit des ID de liaison, pas des payloads Evidence prêts à l’emploi. Les Detections sont récupérées ensuite via detectionRetrieveById avec l’argument écrit exactement iDs, les Events via leurs Resource Names inchangés. Les dépendances Assets et Entity Graph restent à clarifier jusqu’à la vérification des références appropriées et du tenant. Les ID de Detection, Event, Asset et Entity Graph ne sont pas interchangeables ; un point d’entrée Entity Graph pour un Case utilise son UUID comme INVESTIGATION, et non sa shortId.
• La pagination des Cases utilise un offset ou un curseur, pas les deux dans une même requête. Pour une liste qui évolue, privilégiez le curseur et renvoyez-le sans modification. keyFindings est un document typé fourni lors de la récupération individuelle, et non dans la liste des Cases. Les anciens filtres overviewContains et escalated n’ont pas de remplacement direct ; décidez explicitement des fonctions requises avant la bascule.
• Il n’existe pas de deleteCase pour remplacer le DELETE REST. La clôture, le cas échéant avec le Verdict exigé par le type de Case, puis l’archivage facultatif sont des étapes distinctes. Pour les Cases MDR gérés par le prestataire, les champs effectivement autorisés en écriture sont plus restreints et doivent être vérifiés au préalable.

Un pilote doit répondre à la même question fonctionnelle dans le bon tenant, avec des ID traçables, une pagination complète et des erreurs analysées. Les fonctions GraphQL supplémentaires telles que les commentaires, fichiers, liens, règles, Templates et Split/Merge sont des extensions distinctes, pas une condition préalable à chaque bascule. L’absence de correspondance entre champs ou un historique non clarifié restent des décisions ouvertes pour le client ; ces points ne sont pas ignorés en supposant une équivalence.

Périmètre : XDR, MDR et licences

Une intégration ne remplace ni une licence XDR ni une licence MDR. XDR fournit les fonctions d’analyse qui permettent à votre propre équipe de sécurité d’examiner les données dans Threat Analysis Center et le Data Lake. MDR y ajoute le service managé de Sophos. Les intégrations disponibles dans un tenant dépendent du contrat Sophos, du produit, du type d’intégration et, le cas échéant, de la licence du produit tiers.

Pour une conservation plus longue ou des sources de données personnalisées, Sophos Next-Gen SIEM explique comment vérifier l’add-on optionnel et inventorier la durée de conservation par source.

L’affirmation selon laquelle certaines intégrations sont gratuites ne signifie pas que tout le Marketplace l’est. Pour MSP Flex, des Integration License Packs distincts s’appliquent aux catégories Endpoint, Network, Email ou Firewall. La règle MSP Flex antérieure indiquait qu’avec une licence XDR, Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security et Microsoft 365 audit appliance ne nécessitaient aucun Integration License Pack supplémentaire. Cette règle concerne expressément les clients MSP Flex uniquement. Cloud Optix n’y figure aujourd’hui qu’à titre historique : sa fin de vie le 30 septembre 2026 ne permet plus de planifier de nouveaux déploiements en production avec ce service. Vérifiez les droits du tenant et le contrat au lieu de supposer une gratuité générale.

Le système tiers peut lui aussi exiger des licences. Les pages Sophos se contredisent au sujet de Microsoft 365 : la page de présentation indique que les journaux d’audit Management Activity sont accessibles à tous les clients Microsoft 365, tandis que la page de configuration exige Purview Audit (Standard ou Premium), l’une des licences utilisateur qu’elle répertorie et l’activation de l’audit. Ce sont ces conditions précises qui s’appliquent à la configuration. Les Detections fournies par Graph Security V2 dépendent en outre des licences Microsoft et des fonctions Defender XDR disponibles. Pour Microsoft 365 Response Actions dans le parcours Classic/TAC, Sophos ne mentionne aucune exigence de licence Microsoft ; un administrateur Microsoft 365 et les autorisations Graph explicitement indiquées ci-dessous comme propres à Classic sont toutefois nécessaires. Pour les Actions de la solution étendue, ce sont les prérequis décrits plus haut et les droits effectivement demandés lors de l’autorisation en deux étapes qui s’appliquent ; la liste Classic ne définit pas le nouveau consentement.

Cloud Optix après sa fin de vie : traiter séparément la télémétrie et le CSPM

Sophos Cloud Optix a atteint sa fin de vie le 30 septembre 2026. Depuis cette date, le service ne collecte plus de nouvelles données, ne génère plus de résultats et ne transmet plus de télémétrie à MDR ou XDR. À la date de vérification du 11 octobre 2026, l’ancienne recommandation d’exporter avant l’EOL et de basculer en parallèle n’est plus une étape réalisable à l’avenir.

Vérifiez maintenant quels environnements AWS, Azure, GCP ou OCI étaient auparavant connectés exclusivement via Cloud Optix et lesquels disposent déjà d’une connexion directe à la solution XDR/MDR étendue. Ces intégrations cloud directes doivent être configurées pour chaque plateforme ; la mise à niveau du produit ne s’en charge pas automatiquement. Sans nouvelle connexion vérifiée, aucune couverture télémétrique sans interruption ne peut être affirmée pour la période postérieure au 30 septembre. Pour un tenant qui n’a pas encore basculé ou une vignette produit manquante, clarifiez la situation avec l’équipe Sophos chargée du compte ou des partenaires.

Une intégration directe par API cloud n’est pas la même chose qu’un Syslog Data Collector exécuté dans AWS, Azure ou GCP. Dans le Marketplace, sélectionnez l’intégration correspondant au flux de données cloud requis, vérifiez les autorisations précises côté source, puis apportez la preuve de la présence des données et des Detections attendues. Cette preuve doit permettre d’identifier le compte cloud, la source de données et la fenêtre temporelle ; une connexion affichée en vert ne suffit pas à elle seule.

Le Cloud Security Posture Management (CSPM) n’est pas repris : l’évaluation de l’état des configurations cloud, les rapports de conformité aux référentiels et les résultats relatifs aux dérives de configuration ne font pas partie des prestations promises par les nouvelles intégrations de télémétrie. Documentez ce besoin séparément et clarifiez avec l’équipe chargée du compte les solutions de remplacement et les droits contractuels restants. Les rapports Cloud Optix, l’historique des résultats, les justificatifs de conformité et les données d’inventaire ne sont pas non plus migrés vers le nouveau système. Sauvegardez les exports déjà disponibles et vérifiez leur exhaustivité ; aucune possibilité d’export a posteriori ni de restauration n’est confirmée ici.

Types d’intégration et identifiants requis

REST API

Une intégration API récupère des données dans le service cloud du fournisseur ou y envoie une action de réponse. Selon le produit, l’assistant demande notamment l’identifiant du tenant ou de l’organisation, l’URL de l’API, un Client ID, un Client Secret, un token ou un certificat. Les intégrations API ne nécessitent pas de Sophos appliance.

Certaines intégrations recueillent les identifiants directement dans l’assistant. D’autres demandent une Integration Credential réutilisable. L’option permettant de sélectionner un identifiant existant ou d’en créer un dans l’assistant indique si le connecteur prend cette fonction en charge. L’Integration Credential Manager n’est disponible que pour une partie limitée des intégrations API ; tous les secrets ne sont donc pas réutilisables de manière centralisée.

Log collector

La description de l’appliance ci-dessous s’applique au parcours Classic SVA. Dans la solution XDR étendue, les XDR Data Collectors collectent les données Syslog ; ils ont leurs propres exigences en matière de ressources et de réseau. Les anciennes valeurs minimales SVA ne doivent pas être appliquées à la nouvelle VM. La migration provisionne des configurations, mais ne démarre pas un remplacement prêt à l’emploi. Le guide Bascule Syslog SVA et exploitation du XDR Data Collector explique les variantes d’adressage, les paramètres exclus et la bascule sécurisée. NDR n’est pas automatiquement migré dans ce cadre.

Dans une intégration Log Collector, le système source exporte ses événements par Syslog vers une Sophos appliance. Son Log Collector traite les données et les charge dans le Sophos Data Lake. L’appliance fonctionne sur ESXi, Hyper-V, AWS ou Nutanix, ou sur du matériel Dell, NUC ou OnLogic adapté. Pour ESXi ou Hyper-V, prévoyez au minimum 4 CPU, 16 Go de RAM et 160 Go de stockage ; sont pris en charge ESXi 6.7 Update 3 avec le matériel VM version 11 ou ultérieure et Hyper-V sous Windows Server 2016 ou ultérieur. Sophos gère les mises à jour du système et de sécurité ; n’installez aucun autre agent Sophos ou antimalware. Augmentez les ressources pour un volume élevé ou plusieurs intégrations et validez DNS, proxy ainsi que les exclusions de ports et domaines avant approbation. Configurez le produit tiers pour envoyer à cette appliance, pas à un serveur Syslog quelconque.

Plusieurs intégrations peuvent utiliser la même appliance. Vous devez néanmoins configurer le protocole, le port, le format et la source de chaque produit conformément à son guide d’intégration. Une appliance affichée en vert ne prouve pas à elle seule que le bon type d’événement arrive.

Produits Sophos

Des produits tels que Sophos Firewall ou Sophos NDR possèdent leurs propres parcours de configuration. Sophos NDR et les intégrations Log Collector nécessitent une Integration Appliance, mais pas forcément une VM classique. Une intégration REST API seule ne nécessite aucune appliance. Utilisez le Marketplace du tenant concerné pour vérifier la disponibilité : chaque fiche indique les méthodes proposées et ouvre l’assistant approprié.

Délimiter en toute sécurité la charge de travail NDR sur une appliance partagée

La topologie d’appliance partagée ci-dessous s’applique à Classic SVA/TAC, et non au nouveau XDR Data Collector. Celui-ci remplace la partie Syslog ; NDR reste une charge de travail d’appliance exploitée séparément et n’est pas transféré sur le nouveau Collector.

Une appliance ne peut héberger qu’une seule intégration Sophos NDR. Elle peut parallèlement héberger plusieurs intégrations tierces basées sur une appliance sous forme de Log Collectors. Avant toute modification, développez donc l’entrée de l’appliance sous Configured > Integration Appliances et vérifiez toutes les intégrations qui lui sont attribuées. Ni la valeur Integrations ni un état vert de l’appliance ne remplace cette vérification.

Un redémarrage ciblé de NDR interrompt le capteur NDR, tandis que les Log Collectors continuent de fonctionner. En revanche, Restart ou Shutdown de l’ensemble de la VM interrompt NDR ainsi que tous les Log Collectors de cette appliance. Planifiez ces actions dans une fenêtre de maintenance, consignez au préalable l’état de chaque charge de travail, puis contrôlez-les séparément. La procédure est décrite dans Exploiter en toute sécurité l’appliance et le capteur Sophos NDR.

L’option Delete du menu de l’appliance ne supprime pas simplement une intégration donnée. Ne supprimez pas l’appliance tant qu’une intégration NDR ou un Log Collector lui est attribué. Cette option n’indique pas non plus que la VM déployée sera supprimée ni que les données déjà ingérées dans le Data Lake seront effacées. Avant la mise hors service, clarifiez les attributions, la conservation des données, le retrait des ressources de la plateforme, la procédure de restauration et le contrôle final. Jusque-là, conservez l’appliance.

Avant la configuration

1. Connectez-vous à Sophos Fusion en tant qu’Admin ou Super Admin. Sophos exige l’un de ces rôles pour la configuration générale.
2. Vérifiez dans le produit tiers la licence, le rôle d’administrateur, la fonction API ou la sortie Syslog nécessaires.
3. Déterminez si vous avez besoin de Data Ingest, de Response Action ou des deux. Une intégration de réponse ne fournit pas automatiquement la télémétrie sur laquelle repose une investigation.
4. Pour les accès API, créez si possible une application ou un compte de service dédié. N’accordez que les droits demandés par le guide du produit et consignez le propriétaire, la date d’expiration et la procédure de rotation du secret.
5. Si le produit tiers impose une liste d’adresses IP sources autorisées pour les appels API administratifs, identifiez d’abord la région Central sous My Environment > Installers : survolez un lien de téléchargement sous Endpoint Protection ou Server Protection et relevez la région dans l’URL affichée, par exemple eu-central-1. N’autorisez ensuite que les adresses de cette région dans le tableau ci-dessous. Elles sont les sources des appels API Sophos, pas les destinations sortantes de l’Integration Appliance.
6. Pour une Integration Appliance, vérifiez son propre chemin réseau sortant, DNS et, le cas échéant, son proxy conformément aux exigences de l’appliance.
7. Prévoyez un événement de test reproductible et sans danger. Un événement de connexion ou d’audit est préférable à une véritable tentative d’infection.

Adresses IP sources à autoriser pour les API

Ce tableau présente le jeu d’adresses IP Classic vérifié le 14 septembre 2026. Il se distingue de la liste d’autorisation XDR actuelle ci-dessus et ne constitue pas à lui seul un justificatif suffisant pour modifier une liste d’autorisation en production.

Avant un changement, vérifier la génération de l’intégration, la région du tenant et le jeu complet d’adresses IP nécessaires par rapport aux informations Sophos actuelles. En cas d’écart, ne pas reprendre d’anciennes valeurs ni combiner des régions. Faire contrôler l’association de la région et le changement selon votre propre processus d’approbation, n’autoriser que le périmètre nécessaire, puis valider l’intégration concernée au moyen d’une synchronisation d’API ou d’un événement de test sans danger. Consigner dans le changement l’état initial, l’approbation, les résultats et la procédure de retour.

Sophos étiquette actuellement les lignes São Paulo et Dubaï comme sa-east-1. Distinguez-les par l’emplacement du tenant et le jeu d’adresses IP ; ne combinez jamais des régions. Consignez la liste approuvée dans le changement.

Ajouter une intégration dans Marketplace

1. Ouvrez Threat Analysis Center > Integrations > Marketplace.
2. Recherchez le fournisseur ou le produit. Si plusieurs entrées se ressemblent, ouvrez la page du produit et vérifiez la catégorie, le nom du produit, le type d’intégration et l’objectif. Cisco Meraki et Fortinet FortiAnalyzer, par exemple, sont proposés à la fois sous forme d’intégration API et Log Collector.
3. Ouvrez l’intégration souhaitée.
4. Sélectionnez le type nécessaire, par exemple Data Ingest, puis cliquez sur Add Configuration.
5. Suivez les étapes Integration setup. Pour les intégrations API, saisissez les données du système source ou accordez un consentement OAuth. Pour les intégrations Log Collector, créez ou sélectionnez une appliance, puis dirigez vers celle-ci l’export Syslog du système source.
6. Si Sophos demande les domaines internes et les plages d’adresses IP lors de la première intégration, saisissez uniquement vos propres plages internes. Ces informations identifient les adresses détenues, regroupent les alertes associées et évitent les recherches auprès de tiers ; elles ne doivent pas être confondues avec la liste d’autorisation des adresses source Sophos.
7. Enregistrez la configuration et terminez complètement toute boîte de dialogue de consentement externe. Notez le nom de l’intégration, le tenant source, la personne responsable et la date de la prochaine rotation des identifiants.
8. Ouvrez Threat Analysis Center > Integrations > Configured. La nouvelle configuration doit y apparaître. C’est ici que vous pourrez ensuite la superviser ou la modifier ; la valeur Connection Method indique également s’il faut examiner le chemin API ou Log Collector lors d’un dépannage.

FortiAnalyzer : les Alerts de l’API ne couvrent pas tous les événements Syslog reçus

Pour Fortinet FortiAnalyzer, le connecteur API prend en charge Appliance et VM Subscription, mais pas FortiAnalyzer Cloud. Il lit exclusivement les Alerts générées par FortiAnalyzer depuis /eventmgmt/adom/<ADOM>/alerts ; <ADOM> désigne le domaine administratif approprié du système source. Un événement Syslog simplement reçu par FortiAnalyzer ne devient pas automatiquement une telle Alert. Si des événements Syslog doivent être ingérés, évaluez plutôt l’intégration FortiAnalyzer Log Collector ou l’intégration Fortinet Fortigate pour la source concernée. Cette décision doit être prise avant la configuration du connecteur, et non seulement lorsqu’une lacune de données est suspectée.

Le connecteur API supprime les données non conformes au format, puis rejette certains types d’Alerts : messages de tunnel VPN (vpntunnel), requêtes web bloquées vers des destinations non évaluées, messages de scan d’IP/ports, connexions exemptées de l’inspection SSL en raison d’une liste d’autorisation ou d’une adresse, messages Link Monitor sur les interfaces arrêtées ou démarrées, avertissements de saturation du Memory Log, ainsi que les Alerts/avertissements de quota disque et les connexions SSL non sécurisées bloquées. L’absence d’une telle Alert n’indique donc pas automatiquement une erreur d’authentification ou de transport. L’attribution du type utilise une comparaison de motifs lorsque message n’est pas vide ; sinon, elle utilise les champs FTNTFGTattack, ad.subtype et cat ; en l’absence de correspondance, le champ message est nettoyé. Un titre d’Alert reçu ne constitue pas automatiquement un mappage MITRE complet.

Pour la validation, choisissez un événement inoffensif et approuvé dont il est établi qu’il génère une Alert FortiAnalyzer, par exemple une modification de configuration prévue à cet effet dans votre propre gestionnaire d’événements. Documentez d’abord l’Alert, l’ADOM et l’heure dans FortiAnalyzer, et assurez-vous que le format et le type d’Alert ne sont pas rejetés. Retrouvez ensuite cette même Alert dans le bon tenant via la méthode de recherche Sophos confirmée pour ce connecteur. Une connexion de test quelconque ou une ligne Syslog envoyée sans Alert FortiAnalyzer ne constitue pas un test valide d’ingestion par API. Si l’Alert attendue manque, vérifiez d’abord sa génération, l’ADOM, le format et les filtres de types, puis les identifiants et la connexion ; une Sophos Detection ou un Case n’est pas garanti, même lorsque l’ingestion réussit.

Contrôler et tester le fonctionnement

Une configuration enregistrée ne prouve pas encore que l’intégration fonctionne. Vérifiez successivement la connexion, le flux de données et le contenu fonctionnel :

1. État de la connexion : ouvrez l’entrée sous Configured ou, pour une appliance, son état. Pour les Log Collectors, le rouge signifie que l’intégration ne fonctionne pas, le jaune qu’elle fonctionne avec des erreurs, et le vert que les événements sont reçus et traités sans problème visible.
2. Événement de test défini : générez dans le système source un événement sans danger dont vous savez qu’il est recueilli par l’API ou la catégorie Syslog concernée, par exemple une modification administrative ou une connexion de test. Notez l’heure, l’utilisateur et la source.
3. Vérification dans le Data Lake : après le délai propre au produit, recherchez l’événement sous Threat Analysis Center > Live Discover. Utilisez la catégorie ou la requête Live Discover indiquée dans le guide propre au produit ; si Sophos n’en documente aucune pour ce connecteur, ce processus général ne doit pas promettre une validation universelle par requête. Le runbook Live Discover explique les requêtes, les limites du Data Lake et la vérification des résultats. Contrôlez l’horodatage, le tenant, l’utilisateur et le type d’événement. Un seul enregistrement prouve que la connexion fonctionne ; plusieurs enregistrements récents sur une période appropriée démontrent que le flux se poursuit.
4. Limite des détections : chaque événement ingéré ne produit pas nécessairement une Detection ou un Case. Data Ingest rend les données analysables ; une Detection n’est créée que si une logique de détection appropriée s’applique. Testez donc d’abord l’ingestion dans le Data Lake sans attendre systématiquement une Alert.
5. Response Action : utilisez un compte de test approuvé et consignez son état initial. Pour Microsoft 365, Block user sign-in, suivi de Allow user sign-in, constitue un test réversible ; Revoke all current sessions ne l’est pas. Tenez également compte du fait qu’Entra Connect Sync peut réactiver ultérieurement un compte hybride bloqué, que le mode de réponse MDR limite les actions que les analystes Sophos peuvent exécuter et que le nom des Inbox Rules est sensible à la casse dans les Response Actions.

Les Health Alerts ne constituent pas un test immédiat. La période de 24 heures commence au premier message d’erreur et ne produit une Alert de sévérité moyenne que si l’erreur persiste sans interruption. Le retour à un état vert ou l’acquittement de l’Alert réinitialise le compte à rebours. Si le problème persiste, l’Alert réapparaît ensuite une fois tous les 30 jours.

Microsoft 365 : trois intégrations distinctes

« Connecter Microsoft 365 » ne correspond pas à un seul bouton. Le tableau suivant décrit les tâches distinctes dans le Marketplace Classic/TAC, y compris la limite des Response Actions propre à ce parcours. Pour la solution étendue, la procédure Microsoft Graph API Actions décrite plus haut s’applique, avec ses propres connexions et un nouveau consentement ; la restriction Classic à un seul environnement ne s’applique pas à cette nouvelle procédure.

Pour les Response Actions dans le parcours Classic/TAC, Sophos indique les autorisations Microsoft Graph User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite et User.Read. Avec MDR, l’option de réponse MDR sélectionnée détermine toujours si les analystes peuvent intervenir sans autorisation. Dans un environnement Entra ID hybride, Microsoft Entra Connect Sync peut réactiver ultérieurement une connexion bloquée dans Central.

Exemple : connecter Management Activity en toute sécurité

1. Vérifiez que l’audit est activé dans Microsoft 365. Un administrateur Microsoft 365 doit autoriser la connexion.
2. Ouvrez Threat Analysis Center > Integrations > Marketplace, puis sélectionnez Microsoft - Office 365 Management Activity API.
3. Sous Data Ingest (Security Alerts), cliquez sur Add Configuration.
4. Lisez l’avertissement relatif à l’audit, cliquez sur Save and continue, puis sur Proceed dans Connect to Microsoft 365.
5. Connectez-vous avec le compte administrateur Microsoft prévu, vérifiez les autorisations demandées, puis confirmez avec Accept. Terminez la confirmation avec Close.
6. Contrôlez l’entrée dans Sophos Fusion. La catégorie Microsoft 365 audit data doit apparaître sous Live Discover > Query. Générez ensuite un événement d’audit identifiable et recherchez-le avec l’une des requêtes fournies.

Microsoft ne garantit aucun délai fixe pour l’apparition d’un événement donné dans le journal d’audit. Une ligne retardée ne signifie donc pas automatiquement que l’intégration est défaillante. Après la première activation de l’audit, l’affichage des données peut prendre jusqu’à 12 heures.

Pour Graph Security V2, la première synchronisation intervient environ cinq minutes après la disponibilité des données dans Microsoft Defender Security Center. Si le service Alerts and Incidents doit d’abord être provisionné, cette seule étape Microsoft peut prendre environ une heure.

Désactiver ou retirer une intégration

Il n’existe pas de bouton Disable commun à tous les types d’intégration. Les actions disponibles varient selon le produit et la Connection Method. Ne partez donc pas du principe qu’il existe un bouton universel :

1. Ouvrez Threat Analysis Center > Integrations > Configured, sélectionnez la configuration et consignez son état, son nom, le tenant source, l’appliance et les identifiants.
2. Pour une intégration API, commencez par arrêter l’ingestion de manière contrôlée ou utilisez l’action Disable ou Delete proposée, si la page du produit concerné en prévoit une. Révoquez ensuite le consentement OAuth dans le système source, ou désactivez l’application dédiée ou le token. Pour les Response Actions, cette étape empêche de nouvelles actions depuis Central.
3. Pour une intégration Log Collector, supprimez la destination Syslog dans le système source. Ne supprimez pas une Sophos appliance partagée tant que d’autres intégrations l’utilisent.
4. Ne supprimez la configuration dans Central que lorsque les exigences de conservation, d’audit et de gestion des changements sont respectées. La suppression d’une configuration ne garantit pas l’effacement des données déjà ingérées dans le Data Lake ; clarifiez donc au préalable leur conservation et leur suppression selon les règles du Data Lake et les exigences de conformité applicables au tenant.
5. Vérifiez qu’aucun nouvel événement n’arrive et qu’aucune Response Action inattendue ne reste possible. Supprimez ensuite les secrets, certificats, comptes de service et entrées de liste d’autorisation devenus inutiles.

Pour une courte interruption de maintenance d’une intégration Log Collector, arrêtez l’export Syslog sans supprimer une appliance partagée. Pour les intégrations API et Response, ne verrouillez un identifiant afin de suspendre la connexion que si la réactivation de cette même configuration a été vérifiée au préalable ; sinon, utilisez exclusivement la procédure Disable, Delete ou Reconnect propre au connecteur. Un identifiant verrouillé ou expiré ne constitue pas un mécanisme universel de retour arrière et provoque des erreurs de synchronisation.

Cerner méthodiquement les erreurs courantes

L’intégration API ne se synchronise pas

Ouvrez Configured, vérifiez la Connection Method et lisez l’erreur précise. Corrigez d’abord Invalid credentials, insufficient permission et expired credentials dans le produit tiers : contrôlez les ID, secrets, durées des tokens, certificats et droits API. Network not reachable et invalid domain imposent aussi de contrôler DNS, proxy, pare-feu et état du service. En cas de request throttling, le fournisseur limite l’API ; des enregistrements immédiats répétés peuvent aggraver le problème. Pour Microsoft, HTTP 401 signale une authentification incorrecte ; 429 et 509 une limitation.

Log Collector reste rouge ou jaune

Le rouge indique un arrêt, le jaune un fonctionnement avec des erreurs. Vérifiez les ressources de la VM, le réseau et DNS, l’accès sortant, ainsi que le chemin Syslog entre le système source et l’appliance. Le message no events received since last container restart indique qu’aucun événement Syslog n’a été reçu depuis le redémarrage du conteneur ; no received events in last 10 mins peut signaler un export interrompu ou simplement une source qui émet rarement. En cas d’échec du chargement, l’appliance met les données en mémoire tampon sur le disque. Si le chargement reste bloqué et que le stockage se remplit, les données les plus anciennes peuvent être supprimées.

Microsoft 365 ne fournit aucune donnée

Pour Management Activity, l’audit Microsoft 365 doit être actif et la propriété Enabled for users to sign-in? = Yes doit l’être sous Office 365 Management APIs. Tenez compte du délai de démarrage, qui peut atteindre 12 heures après l’activation de l’audit. Pour Graph Security V2, vérifiez l’accès à Defender XDR, le consentement, le provisionnement du service Alerts et les licences Microsoft disponibles. L’ancienne Graph Security API ne constitue plus une solution de secours.

Aucune Health Alert malgré une panne

Vérifiez d’abord qu’il s’agit d’une intégration Data Ingest et que l’erreur persiste sans interruption depuis 24 heures à compter de son premier signalement. Un état vert intermédiaire ou l’acquittement de l’Alert réinitialise le compte à rebours. Par défaut, tous les administrateurs Central reçoivent l’e-mail ; des Notification Rules personnalisées peuvent modifier cette distribution.

Règles de sécurité et d’exploitation

• Utilisez des applications et secrets dédiés plutôt que des accès administrateur personnels.
• N’accordez que les droits API exigés par l’intégration concernée. Les intégrations de réponse nécessitent par nature des droits d’écriture et doivent être approuvées plus strictement que l’ingestion seule.
• Ne stockez pas les secrets dans des tickets, des captures d’écran ou des articles de la KB. Consignez leur propriétaire et leur date d’expiration dans votre solution de gestion des mots de passe ou des secrets.
• Planifiez la rotation des identifiants avant leur expiration. Sophos signale les identifiants expirés comme des erreurs de synchronisation.
• N’autorisez les adresses IP Sophos que si le fournisseur exige une liste d’adresses sources autorisées, et utilisez la liste correspondant à votre région Central effective.
• Activez les notifications d’intégrité pour l’équipe responsable. Lors de la création d’une Custom Notification Rule, sachez qu’elle désactive l’envoi standard de toutes les Alerts par e-mail à tous les administrateurs ; les règles nécessaires doivent alors être recréées séparément.
• Pour chaque intégration, documentez la source des données, l’objectif, la classification des données, la conservation, les droits, le test, le responsable et la procédure de retrait.

Critères de validation

L’intégration n’est finalisée que lorsqu’elle apparaît sous Configured avec la méthode attendue, qu’un événement de test défini est visible dans la destination prévue, que l’horodatage et le tenant source sont corrects, et qu’un responsable prend en charge la rotation des identifiants et les Health Alerts. Pour les Response Actions, la validation comprend également un test approuvé et documenté ; seules les actions réversibles sont alors ramenées à leur état initial, et les actions irréversibles telles que la révocation des sessions ne doivent pas servir de test de retour arrière. Consignez dans le journal d’exploitation les délais incompressibles, notamment pour l’audit Microsoft 365.

Questions fréquentes

Chaque intégration envoie-t-elle des données au Sophos Data Lake ?

Non. Data Ingest envoie les données au Data Lake. Response Action permet d’exécuter une action dans le produit tiers. Certains produits ne proposent qu’un seul type, tandis que d’autres utilisent des configurations distinctes pour les deux directions.

Les intégrations tierces sont-elles gratuites avec XDR ?

Pas toutes. Pour MSP Flex, Sophos répertorie dans la catégorie Sophos XDR certaines intégrations utilisables avec XDR sans Integration License Pack supplémentaire. Les autres catégories exigent les packs Flex correspondants. Des licences du fournisseur tiers peuvent également être nécessaires.

Pourquoi les données sont-elles visibles, mais sans Detection ?

L’ingestion et la détection sont deux étapes distinctes. Un connecteur Data Ingest peut écrire correctement des événements dans le Data Lake sans que chaque événement déclenche une Sophos Detection ou un Case. Vérifiez d’abord le flux de données brutes avec la requête Live Discover prévue.

Puis-je utiliser la même appliance pour plusieurs intégrations Syslog ?

Oui, dans le parcours Classic SVA, Sophos autorise plusieurs intégrations tierces ainsi qu’une intégration Sophos NDR sur une même appliance. Chaque source doit malgré tout être configurée avec les paramètres de connexion et de format appropriés. Le nouveau XDR Data Collector, en revanche, remplace la partie Syslog et ne reprend ni n’héberge cette charge de travail NDR. Pour la bascule, suivez la procédure de migration du Collector liée plus haut ; NDR est exploité séparément selon le runbook d’exploitation NDR.

Pourquoi l’intégration Microsoft 365 Response ne suffit-elle pas ?

Elle fournit des actions, mais n’ingère pas automatiquement les Alerts d’audit ou de Defender. Ajoutez Microsoft 365 Management Activity et Microsoft Graph Security API V2 afin de disposer des Detections et du contexte nécessaire aux investigations.

La suppression d’une intégration efface-t-elle les données historiques du Data Lake ?

Le retrait ne garantit pas la suppression immédiate des données déjà ingérées. Considérez donc le retrait comme l’arrêt des futurs flux de données et clarifiez séparément les obligations de conservation ou de suppression avant d’annoncer un délai contraignant.