Utiliser Sophos AI Assistant et AI Search dans XDR
Sophos AI Search ainsi que les assistants Security Analyst et Threat Hunter sont des outils d’investigation XDR dans Sophos Fusion (anciennement Sophos Central). Ce ne sont pas des fonctions générales de l’agent Endpoint et ils n’effectuent aucune remédiation autonome. AI Search transforme une recherche en langage naturel en requête Data Lake ; les assistants d’investigation accompagnent les analystes dans un chat. Un troisième assistant, Firewall Assistant, est disponible pour les règles et les politiques de pare-feu. Il utilise les données d’un pare-feu Sophos Firewall sélectionné et géré de manière centralisée ; son fonctionnement est présenté séparément ci-dessous.
L’accès à AI Assistant complet dans le processus d’investigation XDR nécessite Sophos XDR, Sophos MDR, Sophos MDR Plus ou Sophos Network Detection and Response. Sophos EDR inclut AI Case Summary, AI Command Analysis et AI Search, mais pas XDR AI Assistant. Ces indications de licence XDR ne précisent pas les conditions de licence de Firewall Assistant. Selon Sophos, l’accès complet aux fonctions AI nécessite le rôle Super Admin ou Admin. Seules les saisies et les réponses en anglais sont actuellement prises en charge.
Choisir le bon outil
- AI Search : recherche des données dans le Sophos Data Lake. Dans la vue Classic du Threat Analysis Center, sélectionnez Detections ou Endpoint Data ; les recherches Endpoint Data y sont limitées à Windows. Sous Security Operations > Data Lake Search, AI Search génère en revanche des requêtes Advanced Search en QL. La restriction à Windows documentée pour le processus Classic ne doit pas être étendue sans preuve à cette nouvelle interface de recherche.
- Security Analyst : étudie un Sophos-managed ou Self-managed Case précis et reprend son contexte de Case et de Detection.
- Threat Hunter : recherche des acteurs ou Indicators of Compromise dans le Data Lake et ne fonctionne qu’avec les Self-managed Cases.
- Firewall Assistant : aide à configurer les règles de pare-feu et à analyser les politiques d’un pare-feu géré dans Sophos Central à partir de SFOS 23.0. Le chat commence par la sélection du pare-feu, et non par un ID de Case.
- AI Case Summary : résume les Detections, appareils, utilisateurs, tactiques MITRE ATT&CK et prochaines étapes possibles d’un Case.
- AI Command Analysis : explique et désobfusque les lignes de commande issues des Detections.
Les assistants d’investigation XDR Security Analyst et Threat Hunter peuvent actuellement récupérer et analyser les données intégrées à XDR de Sophos Endpoint et Sophos Server sous Windows. Ils ne peuvent ni remédier à une menace ni exécuter une Response Action. Isolation, Live Response, Block, Allow et clôture d’un Case restent des décisions humaines délibérées. Ces sources de données Windows et ces limites en matière de Response décrivent le processus d’investigation, et non la configuration du pare-feu avec Firewall Assistant.
Utiliser AI Search en sécurité
Vérifiez d’abord quelle interface votre tenant utilise. Threat Analysis Center est la Classic view de Security Operations, qui reste disponible. Le processus SQL ci-dessous correspond à cette vue Classic ; la nouvelle Data Lake Search est décrite séparément ensuite. Une nouvelle entrée de menu ne justifie pas de réécrire sans vérification des requêtes Classic qui fonctionnent.
Classic : AI Search dans le Threat Analysis Center
- Ouvrir Threat Analysis Center > AI Search.
- Sélectionner Detections ou Endpoint Data à gauche. Endpoint Data exige un appareil Windows.
- Choisir une recherche suggérée ou saisir une question en anglais. Préciser autant que possible l’appareil, l’utilisateur, l’indicateur et la période.
- Sélectionner Search et examiner le tableau des résultats.
- Développer Generated Query et contrôler le SQL généré. Source de données, champs, filtres et période doivent correspondre à la question d’investigation.
Sans période explicite, AI Search utilise 24 heures. Sophos recommande de commencer par quelques heures ou au maximum une journée, puis d’élargir progressivement. Selon le volume, une requête couvrant des jours ou semaines peut être lente ou expirer.
Le tableau affiche au maximum 1 000 résultats. Sophos indique une conservation Data Lake de 90 jours, ou d’un an avec la licence complémentaire Central Data 1-Year Storage Pack. Mille lignes ne prouvent donc pas qu’il existe exactement mille événements ; un tableau vide ne prouve pas non plus l’absence d’activité sur toute la période de l’incident.
Save Query enregistre une requête utile dans la nouvelle catégorie Live Discover AI Search. Export télécharge son SQL et ses résultats en CSV. Sophos Live Discover et les requêtes Data Lake explique la différence entre Live Endpoint et Data Lake ainsi que les limites opérationnelles.
Security Operations: AI Search dans Data Lake Search
Sous Security Operations > Data Lake Search > AI Search, saisissez une question d’investigation en langage naturel ou sélectionnez un prompt préparé, puis Search. Browse Prompts ou View All ouvre les prompts préparés ; Sophos Only, les filtres de catégorie et la recherche permettent de réduire la sélection. Une fois chargé, le prompt peut être adapté à l’appareil, à l’indicateur et à la période de votre investigation.
Sous les résultats, la requête générée apparaît en Advanced Search query language, appelé ici QL, et non sous la forme de la requête SQL Classic de Generated Query. Vérifiez la source de données, les champs, les filtres et la période par rapport à la question d’investigation. Si le résultat ne convient pas, affinez le prompt et sélectionnez à nouveau Search. La limite de lignes et la restriction à Windows de Classic ne sont pas des limites établies pour cette interface.
Save Query exige un nom et une catégorie ; la description et Bookmark this Query sont facultatifs. Enregistrez avec Save Query, puis vérifiez sous Saved Queries que la requête peut être retrouvée. La section Data Lake Search du runbook de requêtes décrit le processus complet avec Query Builder, Query Editor, l’historique de recherche et l’export.
Lancer AI Assistant depuis un Case
L’accès au Case décrit ci-dessous correspond à la vue Classic. Security Operations dispose aussi de Cases ; cela ne prouve pas que le même bouton, les mêmes onglets ou le même transfert vers le chat y sont disponibles. Cet article traite de l’assistant d’investigation XDR, et non d’un assistant Endpoint général ou des fonctions de Sophos AI Defense.
Le point de départ le plus sûr est un Case déjà contrôlé plutôt qu’un chat sans contexte :
- Ouvrir Threat Analysis Center > Cases et sélectionner l’ID du Case.
- Vérifier la Detection, les appareils concernés et la période pertinente.
- Sélectionner Ask Sophos AI en haut à droite. Central ouvre Security Analyst avec le contexte du Case.
- Modifier un Prompt prédéfini ou poser sa propre question en anglais.
/ouvre les Prompts préparés et enregistrés. - Poser les questions suivantes dans le même chat. L’assistant tient compte de la conversation en cours ; un nouveau chat ne possède pas ce contexte.
On peut aussi ouvrir AI > Assistant, sélectionner New, puis Security Analyst ou Threat Hunter. Security Analyst demande ensuite un ID de Case. Ask AI peut également transmettre des lignes sélectionnées dans un tableau de résultats comme contexte. Avant l’envoi, vérifier quelle sélection sera réellement transmise.
Firewall Assistant : sélectionner le pare-feu et poursuivre le travail
Firewall Assistant dans Sophos Fusion prend en charge SFOS 23.0 ou une version ultérieure et nécessite un pare-feu géré de manière centralisée. La version minimale ne garantit pas à elle seule une disponibilité générale dans chaque tenant ou build ; la disponibilité effective et l’approbation du build cible doivent correspondre à votre environnement. Ce chat de configuration n’est pas le Sophos Assistant local dans WebAdmin destiné à la recherche documentaire et aux procédures guidées.
Sous AI > Assistant > New > Firewall Assistant, la liste des pare-feu gérés dans Sophos Fusion s’affiche. Les appareils utilisant une version antérieure de SFOS sont grisés et ne peuvent pas être sélectionnés pour ce processus. Un chat est associé à un seul pare-feu. Pour un autre appareil, démarrer un chat distinct ; plusieurs chats concernant différents pare-feu peuvent coexister. L’accès aux données reste limité aux autorisations de l’administrateur connecté pour le pare-feu concerné.
- Vérifier le nom et la version du firmware du pare-feu prévu, puis sélectionner son entrée. Le chat commence ainsi avec le bon appareil plutôt qu’avec un Threat Case.
- Choisir un Prompt prédéfini ou saisir sa propre question en anglais.
/permet d’afficher d’autres Prompts préparés ; Send envoie la question. - Vérifier la réponse par rapport aux règles et aux politiques du pare-feu sélectionné. Les questions suivantes posées dans le même chat conservent le contexte de la conversation. Après la fermeture de la page ou la sélection de New, le chat précédent reste disponible dans la liste de gauche et peut y être rouvert.
Si un appareil est grisé, vérifier d’abord sa version de SFOS. S’il manque dans la liste, vérifier sa gestion centralisée et s’assurer que le tenant est le bon. Une mise à niveau du firmware ne doit pas être effectuée uniquement pour débloquer l’assistant ; le build cible et l’autorisation de mise à niveau doivent être adaptés à l’environnement.
Pour la transition opérationnelle vers la gestion des règles, la présentation de Sophos Firewall v23 explique l’assistant AI et l’importance de la position des règles. Une réponse dans le chat ne constitue pas une autorisation d’activer une règle en production. Le pare-feu cible, les objets, la position des règles et les contrôles de sécurité doivent être vérifiés délibérément avant chaque modification ; la sélection de l’assistant ou la réussite d’un Prompt n’implique aucune activation autonome.
Vérifier le brouillon de règle, l’appliquer de manière contrôlée et auditer l’action
Dans le périmètre documenté de la phase 1, les actions se concentrent sur les règles de pare-feu et sont en lecture seule, à une exception près : un prompt peut créer une nouvelle règle de pare-feu. L’Assistant présente d’abord un brouillon avec un récapitulatif JSON et des vues des objets utilisés. Ce n’est qu’après confirmation que la règle est créée sur le pare-feu, par défaut désactivée en bas de la table des règles. Il s’agit déjà d’une modification de configuration, mais pas encore d’une autorisation effective du trafic.
⚠️ N’utiliser un prompt de création que pour une modification planifiée et autorisée. Avant de confirmer, consigner l’appareil cible, les règles et objets existants ainsi que l’état actuel de la configuration. L’activation ultérieure peut autoriser ou bloquer du trafic ; le flux de paquets souhaité, l’inspection de sécurité, la fenêtre de maintenance et la procédure de retour doivent donc être définis au préalable.
- Dans le chat du bon pare-feu, préciser la version IP requise, les noms des objets existants et le flux de paquets souhaité. Répondre aux demandes de précision plutôt que d’autoriser sans distinction des réseaux entiers ou n’importe quel service.
- Dans l’aperçu, comparer le récapitulatif JSON et les vues des objets à la règle prévue : source, destination, services, action et options de sécurité doivent correspondre. En cas d’écart, faire corriger le brouillon ou ne pas le confirmer.
- Ne confirmer la création qu’après vérification du brouillon. Ensuite, indépendamment du chat, ouvrir Rules and policies dans WebAdmin sur le même pare-feu et vérifier la liste de règles IPv4 ou IPv6 correspondante. La nouvelle règle doit être désactivée en bas de la table. Si elle manque ou si son état diffère, ne pas la recréer à l’aveugle ni l’activer ; rapprocher l’appareil, la liste et la confirmation de création.
- Vérifier les paramètres réellement enregistrés et les objets nécessaires. Seulement après approbation, déterminer la position techniquement appropriée et activer la règle manuellement. Une règle adaptée en bas de table peut rester sans effet à cause d’une règle précédente ; une règle placée trop haut peut au contraire contourner la restriction voulue. Vérifier les flux de paquets autorisés et ceux qui restent bloqués à l’aide du test de règle avec Log Viewer, Policy Test et Packet Capture.
- Pour obtenir la preuve de l’action de l’Assistant, ouvrir Log Viewer via Logs and policy test et filtrer sur le composant AI Assistant. Rapprocher les événements d’audit du pare-feu cible, de l’heure de modification et de la règle réellement enregistrée. L’entrée d’audit prouve l’action de l’Assistant, pas l’effet correct sur le flux de paquets. Si l’entrée attendue manque, vérifier la période et les filtres, puis analyser l’écart au lieu de supposer qu’aucune modification n’a eu lieu.
En cas d’effet inattendu, désactiver à nouveau la règle venant d’être activée et vérifier l’état consigné auparavant. Désactiver la règle ne supprime ni le brouillon ni les objets éventuellement créés et ne constitue pas un retour complet à la configuration précédente. Un brouillon non approuvé reste désactivé ; vérifier ses dépendances d’objets avant tout nettoyage ultérieur.
Rédiger un Prompt vérifiable
Un bon Prompt précise l’objectif, le périmètre et le format attendu. Exemple :
Compare the detections for endpoint WS-023 during 10 September 2026, 08:00-12:00 UTC. List process names, command lines and hashes, and mark every conclusion that still needs validation.
WS-023 est un exemple neutre à remplacer par l’appareil étudié. Date, heure et fuseau doivent correspondre au Case. N’ajouter processus, IP, utilisateur ou Hash que si l’hypothèse l’exige. Un Prompt enregistré reçoit un Alias clair ; l’Alias et le Prompt complet doivent être uniques. Un responsable, un objectif et une date de révision évitent qu’un Prompt obsolète ne devienne un Runbook non contrôlé.
Valider et documenter les résultats
Les réponses AI peuvent être fausses ou trompeuses. Une affirmation comme « aucun autre appareil concerné » doit être comparée à la chronologie du Case, aux détails de Detection, aux données de l’appareil et aux résultats des requêtes. Vérifier notamment :
- La période évaluée et son fuseau correspondent-ils au Case ?
- L’appareil envoyait-il de la télémétrie pendant cette période ?
- Les filtres, la prise en charge de la plateforme ou, dans le processus Classic d’AI Search, la limite de 1 000 lignes restreignent-ils la conclusion ?
- Les événements bruts étayent-ils la conclusion et la Response proposées ?
Les réponses, lignes individuelles, tableaux complets et requêtes peuvent être épinglés. Ces Pinned Items restent dans le Workbench pendant le chat et peuvent recevoir une note de justification. C’est une aide personnelle, pas une documentation du Case. Les boutons de Feedback évaluent la réponse précise ; aucun détail confidentiel ne doit figurer dans le commentaire facultatif.
Un ou plusieurs résultats vérifiés de Security Analyst ou Threat Hunter peuvent être ajoutés à l’onglet Notebook du Case. Ce processus d’ajout au Notebook d’un Case n’est pas documenté comme méthode de transfert pour Firewall Assistant. Pour une réponse, utiliser le symbole plus sous la réponse, puis confirmer l’ajout. Pour plusieurs réponses, utiliser menu à trois points > Select responses > Add to case. Avec Threat Hunter, il faut sélectionner le Case cible ; avec Security Analyst, il s’agit du Case étudié.
Un chat privé n’est visible que par la personne qui l’a lancé. Les autres administrateurs ayant accès au Case ne voient que les réponses ajoutées au Notebook. Pour supprimer tout le Thread, ouvrir le menu à trois points à côté du titre et sélectionner Delete. Il faut donc valider les preuves avec les données brutes et les consigner dans le Case ou le système d’incident ; le chat n’est pas une archive d’audit.
Confidentialité et limites d’utilisation
Mots de passe, clés privées, codes de récupération et données personnelles inutiles n’ont pas leur place dans les Prompts ou le Feedback. Limiter le contexte à la question et appliquer les règles internes de classification, conservation et export.
Les fonctions AI de XDR utilisent Azure OpenAI et Amazon Bedrock. Les entrées et résultats ne servent ni à entraîner les modèles ni à améliorer les services tiers, et toutes les données transférées aux services LLM tiers sont chiffrées pendant leur transit. Les autorisations Central existantes, basées sur les rôles, continuent de limiter les données auxquelles un utilisateur peut accéder. Avant l’activation, les responsables devraient consulter les informations actuelles sur le traitement des données et les sous-traitants dans la fiche de confidentialité XDR.
Les limites publiées pour les fonctions AI de XDR décrites ici s’appliquent sur 24 heures glissantes ; elles ne permettent pas de déduire des limites distinctes pour Firewall Assistant :
- AI Command Analysis : 50 par utilisateur, 250 par tenant
- AI Search : 20 par utilisateur, 100 par tenant
- AI Case Summary : 10 par utilisateur, 50 par tenant
- Threads AI Assistant : 20 par utilisateur, 100 par tenant
- messages Assistant individuels : 200 par utilisateur, 1 000 par tenant
Lorsqu’une limite est atteinte, la fonction concernée est suspendue avec HTTP 429. Sophos pouvant modifier ces valeurs, la page actuelle des limites fait foi. Une investigation critique doit toujours conserver une voie manuelle via Cases, Detections, Live Discover et la télémétrie sous-jacente.