Comprendre Sophos Next-Gen SIEM et planifier la rétention

Sophos Next-Gen SIEM est une option pour Sophos XDR Powered by Secureworks et Sophos MDR. Le compte doit avoir été mis à niveau vers Sophos Fusion avant toute utilisation. L’aide technique d’administration décrit 13 mois de conservation des données en standard et une possibilité d’extension jusqu’à 10 ans. S’y ajoutent la télémétrie des menaces et de conformité, ainsi que des intégrations personnalisées en complément des intégrations XDR/MDR préconfigurées. Cette présentation correspond à l’état des vérifications au 28 octobre 2026 ; l’indication différente d’un an sur la page produit est expliquée plus bas pour l’achat.

Pour décider, il convient d’abord de recenser les sources de données et les durées de conservation nécessaires. On fait ensuite confirmer le périmètre précis de l’option pour son tenant, puis on vérifie avec une petite source pilote que les événements prévus sont réellement ingérés et peuvent être retrouvés. Une licence XDR ou MDR existante ne prouve pas, à elle seule, que l’option est activée.

Quand Next-Gen SIEM répond au besoin

SIEM signifie Security Information and Event Management : les données d’événements sont centralisées et rendues exploitables pour l’analyse. Next-Gen SIEM complète l’architecture de données commune à XDR/MDR pour prolonger la conservation et permettre des analyses de conformité. Il mérite surtout d’être évalué lorsque l’on a besoin d’événements historiques sur de longues périodes ou que l’on souhaite intégrer une source au moyen d’une intégration personnalisée.

Si le besoin immédiat est de configurer une intégration de produit existante, on commence par les intégrations MDR et XDR dans Sophos Fusion. Cet article explique leur flux de données et les contrôles en exploitation. Le raccordement de Sophos Firewall à syslog traite du transport des journaux du firewall vers un destinataire. Il ne détermine pas quel périmètre Next-Gen SIEM a été acheté ou activé pour une source.

Sophos XDR reste la plateforme principale pour la détection, l’investigation, la réponse et l’automatisation. Next-Gen SIEM complète ces processus par la collecte de données orientée conformité, les preuves historiques et une conservation prolongée. L’option SIEM n’est donc pas un prérequis général aux fonctions de détection ou de réponse XDR déjà couvertes par une licence ; inversement, XDR seul n’active pas les prestations SIEM supplémentaires.

Avanet recommande de ne pas choisir l’option uniquement pour obtenir la rétention la plus longue possible. La rétention désigne ici la conservation des données. L’essentiel est de savoir quels événements seront nécessaires, pour répondre à quelles questions, qui les analysera et combien de temps ils devront rester disponibles. Un stockage plus long est peu utile si la catégorie d’événements nécessaire n’est pas transmise ou si des champs importants manquent.

Sophos décrit également des tableaux de bord de conformité préconfigurés. Ces analyses facilitent la constitution de preuves, mais ne remplacent ni la vérification de la couverture des données, ni une évaluation juridique, ni une certification. L’option ne permet pas de conclure à une conformité automatiquement acquise.

Clarifier le tenant et l’offre avant la mise en œuvre

Avant l’achat, on documente le tenant concerné, le produit XDR/MDR utilisé et l’état réel de la mise à niveau vers Fusion. Une annonce ou une date de mise à niveau prévue ne suffit pas à autoriser l’utilisation en exploitation. On demande ensuite au partenaire Sophos de confirmer si Next-Gen SIEM est disponible pour ce compte et quelles prestations de conservation et d’intégration sont comprises dans l’offre précise.

Sophos décrit un modèle tarifaire fondé sur les utilisateurs et les serveurs, sans frais d’ingestion, c’est-à-dire sans facturation selon le volume de données ingérées. Il s’agit d’une description du modèle tarifaire, pas d’un devis ni d’une promesse de capacité technique illimitée. Avant toute commande, il faut clarifier le mode de comptage, la durée contractuelle, l’extension de rétention souhaitée, le périmètre des intégrations et les éventuels prérequis du produit tiers. En particulier, cette description ne permet de déduire ni la gratuité des licences tierces ni des limites garanties de débit ou de nombre d’événements.

Pour les intégrations personnalisées, la possibilité de créer ses propres intégrations de données est confirmée. Cela n’établit pas pour autant une procédure de configuration vérifiée pour chaque source. Avant le pilote, il faut donc disposer d’une description adaptée à la source précise : transport, authentification, format des événements, correspondance des champs et analyses prises en charge. Les menus ou requêtes de connecteurs existants ne doivent pas être transposés sans vérification à une intégration personnalisée. Le point d’accès au dashboard est décrit ci-dessous ; il ne permet pas de déduire une procédure de configuration universelle pour chaque source personnalisée.

Confirmer explicitement le nombre de licences et le parcours Collector

Next-Gen SIEM ne peut pas être acheté comme produit autonome. Le nombre de ses abonnements doit correspondre au nombre total d’utilisateurs et de serveurs disposant de licences XDR et MDR ; les serveurs ne doivent pas être omis du comptage. Rapprochez l’inventaire réel et l’offre avec le partenaire, plutôt que de retenir uniquement un groupe pilote ou le volume de données comme quantité de licences. En complément des 13 mois standard, les extensions de rétention à trois, cinq, sept ou 10 ans sont des options payantes, et non une activation automatique par une licence XDR/MDR existante. Elles ne restaurent pas a posteriori l’historique arrivé à expiration et ne prouvent aucune conformité juridique.

Les directives de licence applicables au 16 octobre 2026 indiquent aussi une limite d’utilisation de 1 Go de données brutes ingérées par jour, agrégées sur toutes les sources. Le tableau définit la licence par utilisateurs et serveurs, mais la phrase sur le volume ne précise pas expressément si cette quantité s’applique par subscription ou au tenant. Il ne faut donc ni calculer 1 Go × utilisateurs et serveurs, ni supposer une limite fixe de 1 Go pour le tenant. Avant dimensionnement ou commande, obtenir une confirmation contractuelle de l’unité de référence, de l’agrégation et du comportement en cas de dépassement. Un prix sans frais d’ingestion liés au volume ne signifie pas une utilisation illimitée.

Le nombre de subscriptions Retention Add-on doit également correspondre au nombre total de subscriptions NG-SIEM. Cela ne permet pas de déduire une conservation prolongée pour un sous-ensemble choisi librement ou une seule source.

Pour les intégrations Syslog, les anciens Sophos Log Collectors ne prennent pas en charge toute l’étendue de rétention de Next-Gen SIEM. Sophos recommande à cette fin de passer aux XDR Data Collectors ; le runbook de migration des Collectors existant explique le provisionnement, le déploiement, la bascule des sources et la validation. Les intégrations API existantes ne nécessitent aucune reconfiguration au seul motif de ce changement de Collector. Sur une SVA partagée, NDR reste une charge de travail distincte et ne doit pas être arrêté involontairement lors de la bascule Syslog. Le nouveau Collector ne remplace pas la vérification des droits à l’option, du format source et de la conservation effective.

Le hub SIEM organise les guides existants par planification, collecte des sources, transport et contrôle des parsers. L’exemple HTTP/parser de bout en bout relie ces étapes à une source de laboratoire synthétique ; sa validation pratique dans un tenant reste à effectuer.

Données personnalisées : distinguer transport, normalisation et détection

Une Custom Integration transporte vers XDR les données d’une source qui n’est pas optimisée par Sophos. Cela ne confirme pas encore la normalisation, la recherche ou la détection pour cette source. Les Custom Parsers associent les champs des journaux aux schémas d’événements XDR standardisés pris en charge. On peut ensuite vérifier si les champs nécessaires à la recherche souhaitée, à un détecteur ou à une Custom Detection Rule sont présents.

Les Custom Parsers nécessitent un abonnement Next-Gen SIEM. Les rôles Admin et Super Admin peuvent les gérer ; les autres rôles peuvent uniquement consulter la liste des parseurs configurés. Les messages auxquels aucun parseur ne correspond utilisent le schéma generic. Ils peuvent fournir du contexte aux cases et aux règles personnalisées, mais n’apparaissent dans les résultats qu’avec des paramètres de recherche avancés. L’absence de résultat dans une recherche simple ne prouve donc pas qu’aucune donnée n’a été ingérée.

Même des données correctement normalisées ne déclenchent pas automatiquement tous les détecteurs correspondant au schéma. Sophos précise certains parcours de détection pris en charge et les champs nécessaires ; les autres détecteurs ne sont pas garantis. La détection souhaitée doit donc être validée séparément avec des événements de test adaptés. L’assistance IA annoncée ne remplace pas ce contrôle.

Un Custom Parser nouvellement créé est désactivé par défaut. On le teste plusieurs fois avec différents exemples de messages, on l’enregistre, puis on l’active séparément. En revanche, les modifications d’un parseur déjà actif prennent effet immédiatement lors de l’enregistrement ; il faut donc les tester soigneusement avant d’enregistrer. Des Confirm Strings qui se chevauchent peuvent attribuer des messages au mauvais parseur ; le chemin d’extraction (extractor path) réellement utilisé doit donc aussi être vérifié.

Sophos n’assure ni la maintenance ni la mise à jour des Custom Parsers. Un exploitant responsable doit revérifier la correspondance des champs, les horodatages et les résultats de recherche ou de détection après toute modification du format source ou du parseur. Pour le pilote, l’ingestion, la normalisation et l’analyse souhaitée sont documentées comme trois résultats distincts ; un état de transport vert ne suffit pas.

La configuration pratique est décrite dans Custom HTTP Ingest, les variantes S3, Azure Event Hubs et Storage et le runbook Custom Parser. Pour chaque variante, transport, schéma et analyse souhaitée restent des résultats d’acceptation distincts.

Ouvrir le dashboard NG-SIEM pour vérifier les preuves

Lorsque l’option est activée, on ajoute la vue fournie à sa liste personnelle de dashboards comme suit :

Ouvrir Dashboards > Manage dashboards.
Sélectionner Find dashboards et ajouter NG-SIEM à la liste.
Ouvrir le dashboard depuis la liste et comparer les données affichées à l’inventaire des sources, à la période et aux événements attendus.

Le dashboard NG-SIEM contient des widgets sur le contrôle d’accès, la sécurité réseau et les événements d’audit. Sophos décrit également un exemple de dashboard ISO 27001 réunissant l’authentification, les modifications, les événements réseau/firewall, l’activité e-mail/fichiers ainsi que les processus de détection et de gestion des cases. Les informations réellement disponibles pour constituer ses preuves dépendent des sources connectées et de la qualité de leurs données ; cette vue ne constitue ni une certification ISO ni une confirmation automatique de conformité.

Le guide général des dashboards explique les listes personnelles, les vues disponibles et l’export PDF. Si NG-SIEM est absent, on vérifie d’abord le tenant, l’option et les autorisations ; pour une vue vide, on examine la provenance des données et la période. Ni l’absence de widgets ni leur état vert ne remplacent le contrôle des événements sous-jacents.

L’aide NG-SIEM spécifique au produit du 1er octobre 2026 décrit cet accès. L’ancienne aide commune aux dashboards du 17 septembre ne mentionne encore que le dashboard TAC. C’est une différence de documentation, pas une garantie concernant une vue de tenant non vérifiée. Si l’entrée manque malgré une offre correspondante, clarifier le provisionnement effectif ; ne pas créer une deuxième intégration sur une supposition.

Distinguer conservation, fenêtres de recherche et données brutes

13 mois dans l’aide d’administration, un an sur la page produit

La présentation technique du 1er octobre 2026 indique 13 mois de conservation standard. La page produit publique, vérifiée le 28 octobre, indique en revanche un an. Les deux citent des extensions à trois, cinq, sept ou dix ans. Cette différence n’est interprétée ni comme une modification produit confirmée ni comme un simple arrondi : Sophos n’en fournit pas d’explication univoque.

Pour la présentation technique de cet article, les 13 mois de l’aide d’administration propre au produit servent de référence. Avant une commande ou un engagement ferme de conservation, il faut néanmoins faire confirmer la durée applicable au tenant, aux types de données et à l’offre concernés. Cette confirmation doit figurer dans l’inventaire des sources. Si l’exploitation nécessite, par exemple, plus de douze mois d’historique, la période supplémentaire ne doit pas être présumée sur la seule base de la communication produit générale. L’inventaire de rétention et la validation décrits plus bas vérifient le périmètre convenu ; ils ne résolvent pas la contradiction entre les sources en supposant une durée.

Fenêtre de recherche et accès aux données brutes

Une longue conservation ne permet pas une requête de taille arbitraire en une seule fois. L’aide actuelle sur les schémas autorise au maximum 31 jours par requête pour les Events normalisés, avec n’importe quelle date de départ parmi les données réellement conservées. Répartir les investigations plus longues en fenêtres adaptées. La recherche de detections est distincte.

Pour @raw et original_data, le guide de migration SQL vers QL plus récent du 15 septembre 2026 indique une limite d’accès séparée de 20 jours. Une requête hors de ce périmètre est rejetée, pas silencieusement raccourcie à la plage autorisée. L’ancienne aide Query Language mentionne aussi des incréments de 20 jours ; cela ne garantit pas la disponibilité de données brutes plus anciennes. Découper les requêtes ne rend pas automatiquement ces données accessibles. Cette limite de recherche ne prouve ni une suppression physique après 20 jours ni une réduction générale de la conservation normalisée.

Data Lake Search et export explique le choix du schéma, les limites de requête, les fenêtres historiques et la preuve d’export complet. Le guide d’exploitation des règles distingue une recherche réussie d’une règle de detection ou de suppression évaluée en continu.

Créer un inventaire de rétention par source

L’inventaire fait partie de la documentation d’exploitation, pas seulement de l’offre. Pour chaque source, on consigne les informations suivantes ; différentes catégories d’événements d’une même application peuvent nécessiter des entrées distinctes :

Système source, tenant source, catégories d’événements et personne responsable.
Objectif de l’ingestion et question précise à laquelle une recherche ou une preuve devra répondre ultérieurement.
Champs nécessaires, par exemple l’horodatage avec fuseau horaire, l’action, le résultat et une identité adaptée à l’investigation.
Classification des données, contenu autorisé et approbation de la transmission et de l’accès.
Conservation souhaitée avec sa justification, ainsi que le périmètre confirmé réellement applicable.
Méthode d’intégration, autorisations nécessaires et responsable des identifiants, sans copier de secrets dans l’inventaire.
Début de l’ingestion, délai de traitement attendu et événement de test reproductible.
Méthode de recherche vérifiée, enregistrement le plus ancien trouvé, dernier contrôle réussi et prochaine date de révision.
Procédure en cas de panne, de changement de source, de modification de la conservation et de retrait de l’intégration.

L’indication du produit 13 mois, extensibles jusqu’à 10 ans ne doit pas être inscrite automatiquement comme durée effective pour chaque enregistrement existant. Pour sa propre source, il faut clarifier le périmètre, le début de la conservation et l’accès aux données historiques. Il ne faut pas non plus présumer une reprise rétroactive des anciennes données ou la récupération de données déjà arrivées à expiration.

Exemple de source pilote

L’exemple suivant est une fiche de planification, pas une configuration Sophos ni un connecteur vérifié. Les valeurs sont des exigences librement choisies pour une organisation fictive :

Source : application métier interne, environnement de test
Événements : connexion réussie et modification administrative d’un rôle
Objectif : retrouver qui a modifié une autorisation
Champs obligatoires : horodatage avec fuseau horaire, compte de test, action, résultat
Conservation souhaitée : 24 mois
Justification : période d’investigation approuvée en interne
Périmètre confirmé : à clarifier avant la commande et le pilote
Connexion et méthode de recherche : à confirmer pour cette source personnalisée
Test : modification approuvée d’un rôle sur un compte dédié aux tests
Retour arrière : rétablir le rôle initial et vérifier la modification
Équipes responsables : équipe de l’application avec l’équipe des opérations de sécurité

Les 24 mois constituent ici une exigence interne, pas une durée légale générale ni une valeur standard du produit. Ils dépassent la rétention standard décrite ; une extension adaptée doit donc être confirmée avant l’approbation. On remplace les comptes et événements par ses propres données de test approuvées. Les autorisations de production ne sont pas modifiées pour ce test.

Valider séparément l’ingestion et la conservation

Pour le pilote, on consigne l’état initial et le début de l’ingestion. Les circuits de journalisation existants sont conservés jusqu’à la validation de la nouvelle source. On génère ensuite un événement inoffensif et approuvé appartenant à la catégorie prévue. Dans l’exemple, le rôle du compte de test est modifié, puis rétabli à sa valeur initiale documentée.

Après le délai de traitement attendu, on vérifie les points suivants avec la méthode de recherche ou d’analyse confirmée pour cette source :

L’événement de test exact est-il présent dans le bon tenant ?
Le système source, l’horodatage, l’action et le résultat correspondent-ils à la preuve issue de la source ?
Les champs nécessaires sont-ils associés de manière compréhensible, plutôt que disponibles uniquement sous forme de texte brut inexploitable ?
Peut-on retracer d’autres événements attendus sur la durée du pilote ?

Un enregistrement nouvellement trouvé prouve l’ingestion pour ce test, pas une conservation sur plusieurs années. Pour valider la rétention, on compare également le périmètre confirmé au réglage effectif ou à une confirmation propre au tenant. On contrôle les données historiques déjà présentes sur une plage temporelle ciblée et on consigne l’enregistrement le plus ancien trouvé ainsi que les lacunes connues. Pour une nouvelle source sans historique, on documente que la conservation à long terme n’a pas encore été démontrée par le temps écoulé et on prévoit des contrôles ultérieurs.

Le contrôle d’ingestion ne suppose pas une alerte de sécurité. Un événement d’audit ordinaire peut être nécessaire en tant qu’enregistrement sans donner lieu à un incident. Data Collection et Live Discover explique les requêtes XDR existantes ; cela ne fournit pas de requête universelle pour une nouvelle source personnalisée.

Isoler les erreurs et annuler les changements en sécurité

Si l’option ou une fonction manque, on vérifie d’abord le tenant, l’état réel de la mise à niveau vers Fusion et le périmètre confirmé de l’option. On ne crée pas une deuxième intégration au hasard et on ne modifie pas une stratégie de protection des endpoints pour corriger un manque supposé de licence.

Si des événements récents manquent, on compare d’abord la preuve issue de la source au début de l’ingestion, à la catégorie d’événements, à l’authentification, au format et au délai de traitement convenu. Si des enregistrements existent mais sont inexploitables, on vérifie la correspondance des champs et les références temporelles. Si seuls des événements anciens manquent, on examine séparément le début de l’ingestion, les lacunes de données, la rétention effective et la plage temporelle de recherche. Une extension ultérieure de la rétention n’est pas une solution garantie pour les données déjà manquantes.

Avant de raccourcir la conservation ou de retirer l’intégration, on détermine avec les responsables quelles données restent nécessaires et comment les préserver, lorsque cela est pris en charge et requis. Il ne faut pas supposer qu’un retour ultérieur à l’ancienne valeur restaurera l’historique perdu. De même, supprimer une intégration ne prouve pas la suppression des données déjà ingérées.

En cas d’échec du pilote, on annule uniquement la modification documentée de la source pilote en suivant sa procédure de retour arrière confirmée. Les identifiants partagés, les collecteurs et les autres sources restent intacts. On vérifie ensuite l’état restauré de la source et l’ancien circuit de journalisation encore nécessaire. La suppression des données et la résiliation de l’option sont clarifiées séparément avec le partenaire ou les responsables ; cet article ne promet aucun interrupteur universel pour ces opérations.

La transmission à l’exploitation nécessite l’inventaire des sources, le périmètre confirmé, les preuves du pilote, les lacunes historiques encore ouvertes, la responsabilité en cas de panne et la date de révision. Si le format des données, la méthode de recherche ou la rétention d’une source nécessaire restent indéterminés, cette source n’est pas encore validée. Pour une escalade, l’identification du tenant, la plage temporelle, la catégorie d’événements et des preuves d’erreur expurgées suffisent dans un premier temps ; les secrets et les données personnelles brutes inutiles n’ont pas leur place dans la demande.