Examiner les données NDR locales dans l’Investigation Console

La NDR Investigation Console donne accès aux données locales des capteurs NDR qui lui sont attribués, et pas uniquement aux données transférées vers le Sophos Data Lake. Ce runbook vous guide depuis une hypothèse examinée dans Dashboard > Overview jusqu’à une requête ClickHouse ciblée sous Query. Toutes les requêtes décrites sont en lecture seule.

L’Investigation Console ne se substitue pas aux autres modes d’interrogation suivants :

Un résultat de l’Investigation Console ne constitue pas encore un incident confirmé. Transmettez les constatations suspectes conformément au processus SOC, XDR ou MDR en vigueur. Les mesures de réponse sont hors du périmètre de ce runbook.

Accès, rôles et mandat d’investigation

Utilisez un compte personnel disposant des droits nécessaires pour la mission. Le compte local de l’Investigation Console est distinct des rôles dans Sophos Fusion. Si Query, un schéma requis ou un bouton n’est pas disponible, demandez à l’administrateur responsable de vérifier le compte local et la console sélectionnée. Si le point d’accès depuis Sophos Fusion ou un pivot ultérieur vers le cloud n’est pas disponible, vérifiez séparément la licence, le rôle Fusion et, pour les Custom Roles, le périmètre des produits. N’étendez pas un rôle sur la base d’une simple supposition.

Les points suivants doivent être établis avant l’investigation :

• une hypothèse concrète, par exemple la communication d’une adresse IP de destination autorisée via des protocoles inattendus ;
• le capteur ou le segment réseau concerné, ainsi que les systèmes source ou de destination attendus ;
• le début, la fin et le fuseau horaire de l’événement ;
• un ticket ou une Case pour les notes, ainsi que la personne chargée de prendre en charge une constatation suspecte ;
• les règles applicables au traitement des adresses IP, des noms d’hôte et des résultats exportés.

La console doit être accessible et recevoir les données d’au moins une NDR Integration Appliance. Une connexion réussie ne prouve ni que les données des capteurs sont à jour, ni que la couverture du trafic mis en miroir est complète.

1. Restreindre la période et les capteurs concernés dans le tableau de bord

Après la connexion, la console ouvre Dashboard > Overview. Cette page affiche Total Indicators, Network Traffic, Total Indicators By Severity, Total Indicators By Type, Geolocation Map et Recent flow detections. Back permet de revenir à Sophos Fusion. This Appliance affiche les détails du système et n’est pas nécessaire pour cette investigation.

1. Sous Filters, ouvrez d’abord Time Range. La valeur par défaut est Last 1 hour.
2. Pour un incident connu, sélectionnez Absolute time range et saisissez les heures de début et de fin en incluant suffisamment de contexte avant et après l’événement. Pour une première vue d’ensemble, une quick range telle que Last 7 days peut suffire. Confirmez avec Apply time range.
3. Tenez compte de la limite des données : la console ne fournit que les 30 derniers jours. Une période plus longue ne donne accès à aucune donnée locale supplémentaire. L’absence d’un résultat plus ancien ne constitue donc pas une confirmation négative.
4. Sous Filters, sélectionnez une colonne de base de données proposée, l’opérateur approprié et une valeur. Sophos cite par exemple MasterProtocol, Equals et HTTP. Pour les colonnes numériques, des opérateurs tels que =, < ou >= sont disponibles.
5. Ajoutez uniquement les critères qui correspondent à l’hypothèse. Après avoir configuré chaque critère, cliquez d’abord sur Add pour l’ajouter au filtre, puis sur Apply. Vérifiez que les graphiques et le tableau reflètent désormais la période et les filtres sélectionnés.
6. Utilisez Save As uniquement pour un filtre stable doté d’un nom explicite. L’icône d’enregistrement remplace un filtre existant. Clear permet de supprimer les paramètres de filtre actuels.

Consignez les filtres, la période et le fuseau horaire. Comparez ensuite au moins deux représentations indépendantes :

• Total Indicators affiche les IoC de types DGA, IDS, EPA et SRA. Un clic sur un type permet de l’afficher ou de le masquer dans l’histogramme. Lorsque vous placez le pointeur sur une barre, l’heure et la valeur apparaissent.
• Network Traffic affiche le débit en Mbit/s, le nombre de paquets par seconde et le nombre de flux par seconde. Lorsque vous placez le pointeur sur le graphique, vous voyez le volume de données envoyées et reçues en gigaoctets.
• Total Indicators By Severity regroupe les indicateurs selon les niveaux Critical, High, Medium, Low et Info. Total Indicators By Type présente les mêmes types d’IoC sous forme de diagramme en anneau.
• Geolocation Map repose sur des regroupements d’adresses IP. Une région constitue un point de départ pour l’investigation, mais ne prouve ni l’emplacement réel ni le caractère malveillant d’un hôte.
• Recent flow detections affiche les flux réseau suspects. Examinez les détails de flux disponibles et confirmez les noms et la signification des champs à l’aide du schéma actuel, au lieu de vous fier uniquement à un pic du graphique.

Si le tableau de bord et le tableau de données ne concordent pas pour une même période, réduisez la fenêtre temporelle et vérifiez les filtres actifs. Ne lancez qu’ensuite une requête libre.

2. Commencer par une requête préparée

Ouvrez Query et restez d’abord dans l’onglet Library. Dans le cadre de ce runbook, utilisez exclusivement des requêtes SELECT individuelles en lecture seule. La modification ou la création de requêtes nécessite des connaissances en SQL ClickHouse. Les commandes qui modifient des données, des tables, des schémas, des utilisateurs, des autorisations ou des paramètres de serveur sont exclues.

Commencez par une requête préconfigurée adaptée à votre hypothèse :

1. Dans Library, développez la catégorie appropriée et ouvrez la requête.
2. Lisez l’intégralité du texte. Vérifiez les tables, les champs, la condition temporelle, le regroupement, le tri et toute limite de résultats existante par rapport à votre hypothèse.
3. Passez à Schema. Développez le nom du schéma et confirmez les noms et les types de champs de chaque table utilisée. Ne reprenez pas les noms de champs provenant d’exemples du Data Lake ou d’Appliance Manager.
4. À partir du schéma actuel, limitez le SELECT à la période requise et, si possible, à un seul indicateur, hôte, une seule adresse IP source ou de destination, ou un seul protocole. Ne modifiez une condition temporelle préconfigurée que si le champ et la syntaxe ClickHouse sont sans ambiguïté.
5. Cliquez une seule fois sur Run. Les résultats apparaissent sous la requête. Des clics répétés n’accélèrent pas l’exécution et rendent son identification dans History plus difficile.
6. N’élargissez le périmètre de l’investigation que si la première exécution réussit et que le résultat est plausible et d’un volume gérable.

Utiliser les variables et les exemples en toute sécurité

Si une requête préparée contient une variable telle que @DestIp, un champ de saisie apparaît à sa gauche. Protocols For Destination IP est un exemple documenté. Utilisez ce champ et ne modifiez pas simultanément la substitution de variable, la table et la logique de filtrage.

Pour un simple contrôle de la syntaxe ou du déroulement, utilisez uniquement une adresse approuvée à cette fin. 192.0.2.10 appartient à un réseau réservé à la documentation et sert ici exclusivement d’exemple de format. Cette adresse ne renvoie pas nécessairement de résultats et ne constitue pas un indicateur de production. Les véritables adresses IP, domaines et noms d’hôte doivent provenir du ticket autorisé, et non d’exemples quelconques.

Lors de l’enregistrement, la console peut intégrer la valeur de la variable au texte de la requête. Par exemple, @DestIp est alors remplacé par l’adresse utilisée. Vérifiez donc le texte avant l’exécution suivante. Enregistrez une variante adaptée via Save As, sous un nom décrivant sa finalité et son périmètre, et ne remplacez pas la requête préconfigurée d’origine. Comme les requêtes enregistrées peuvent contenir des indicateurs confidentiels, la classification locale des données s’applique.

Pour créer une catégorie, cliquez sur l’icône plus en haut à droite de Library, saisissez un nom et une description, puis confirmez avec Create. Pour créer une requête, saisissez à droite le texte SELECT vérifié, testez-le avec Run, puis sélectionnez Save As. Sélectionnez la catégorie, saisissez un nom et confirmez avec Create. N’enregistrez que des requêtes vérifiées et réutilisables.

La console partage ses ressources avec le stockage et l’affichage des données locales. Filtrez donc le plus tôt possible selon la période et un champ sélectif. Limitez les résultats selon une méthode déjà utilisée dans Library et validée pour ClickHouse ; ne supprimez pas une limite existante lors du premier test. Avant d’utiliser un JOIN, des sous-requêtes, des regroupements étendus ou des tris, vérifiez le Schema actuel et effectuez un test sur une petite fenêtre temporelle. Ne copiez pas une requête SQL du Data Lake dans la console. Avant toute exécution, lisez intégralement les requêtes provenant de tickets, de discussions ou d’exemples publics, puis comparez-les au Schema.

3. Valider les résultats

Une requête exécutée avec succès n’est pas automatiquement correcte sur le fond. Vérifiez le résultat dans l’ordre suivant :

1. Périmètre de l’investigation : la fenêtre temporelle, le fuseau horaire, les capteurs concernés et les filtres correspondent-ils exactement à la mission ? L’événement se situe-t-il dans les 30 jours disponibles localement ?
2. Schéma : les types et la signification des champs concordent-ils avec Schema ? Vérifiez en particulier que les adresses IP, les valeurs temporelles et les nombres sont correctement interprétés.
3. Résultat de contrôle : recherchez un flux connu et attendu au cours de la même période restreinte. S’il est lui aussi absent, un résultat vide n’est pas probant.
4. Comparaison avec le tableau de bord : l’ordre de grandeur et l’évolution dans le temps concordent-ils avec Network Traffic, les IoC ou Recent flow detections ? Les agrégats du tableau de bord et les lignes individuelles ne doivent pas nécessairement être identiques, mais toute contradiction doit être expliquée.
5. Contre-vérification : supprimez exactement un filtre restrictif ou déplacez la fenêtre temporelle de manière contrôlée. Une différence plausible montre que la condition agit. Ne modifiez jamais plusieurs conditions simultanément.
6. Documentation : consignez dans le ticket le nom ou le texte de la requête, les variables, la période et son fuseau horaire, l’heure d’exécution, le nombre de résultats et les lignes pertinentes. Traitez les résultats comme des données réseau potentiellement sensibles.

Ouvrez ensuite History. La console y affiche le type d’utilisateur, la date et l’heure, le nombre de résultats, ainsi que successful ou failed. Identifiez l’entrée correspondant à votre exécution. History atteste l’exécution, mais ni l’exhaustivité ni l’exactitude de la requête.

Cerner les erreurs et revenir à un état sûr

Le tableau de bord est vide

Vérifiez Time Range, les Saved Filters actifs et Filters. Sélectionnez une courte période pendant laquelle du trafic réseau est attendu et supprimez les filtres avec Clear. Si Network Traffic reste également vide, le problème ne provient pas d’une requête libre. Vérifiez que la bonne console est ouverte et que le capteur attendu ou l’appliance responsable fournit des données. Un état vert de l’appliance ne prouve pas que la couverture du trafic mis en miroir est complète. Transmettez la période, le flux attendu, la console et le capteur concerné au processus d’exploitation ou de support, au lieu d’étendre la période au-delà de 30 jours.

La requête ne renvoie aucune ligne

Confirmez la période et le fuseau horaire. Dans Schema, vérifiez que la table, le nom du champ et le type sont à jour. Supprimez ensuite exactement le filtre fonctionnel le plus restrictif et exécutez une nouvelle fois la requête. Testez également une valeur connue et attendue dans la même fenêtre temporelle. Si une requête préconfigurée non modifiée ne renvoie pas non plus les données attendues, vérifiez le chemin des données et les capteurs concernés. Le résultat vide ne prouve pas que l’activité est absente.

La requête est failed

Recherchez l’entrée correspondante dans History et consignez l’état, le texte de la requête et l’heure d’exécution dans vos notes de travail. Vérifiez la syntaxe, les noms et les types de champs à l’aide de Schema. Ouvrez depuis Library la dernière requête non modifiée qui fonctionnait auparavant, limitez son SELECT à la période pertinente la plus courte et définissez une seule valeur de variable validée. Lancez exactement une nouvelle exécution. Si la requête préconfigurée reste failed, documentez l’erreur et faites-la remonter. Ne la contournez pas au moyen de commandes d’écriture, de modifications de schéma ou de paramètres de serveur.

La requête s’exécute anormalement longtemps ou sollicite fortement la console

Ne cliquez pas de nouveau sur Run. Notez l’heure de début, l’utilisateur et le nom de la requête. Ne lancez aucune autre requête étendue. Une fois l’exécution terminée, vérifiez dans History si elle était successful ou failed, ainsi que le nombre de résultats obtenus. Si l’interface reste lente, cessez les requêtes et transmettez l’observation à l’équipe chargée de l’exploitation de la console. Le redémarrage ou l’arrêt de la console est hors du périmètre de ce runbook.

Revenir à une requête fonctionnelle

1. Arrêtez toute nouvelle exécution de la même variante. Ne lancez ni répétitions précipitées ni autre requête de contrôle étendue.
2. Si l’interface répond, copiez le texte de la requête et consignez l’heure de début, les filtres, les variables et l’entrée History correspondante. N’enregistrez pas la variante défectueuse comme nouvelle requête standard.
3. Ouvrez de nouveau la requête préconfigurée d’origine depuis Library. Vérifiez qu’aucune valeur de variable insérée ni aucune modification non enregistrée n’a été reprise.
4. À partir du schéma confirmé, limitez le SELECT à une courte période, une valeur validée et un faible volume de résultats. Vérifiez de nouveau les tables et les champs sous Schema.
5. Exécutez un seul test de lecture ayant déjà réussi. Vérifiez le résultat et History.
6. Si ce test échoue également ou si la console reste affectée, mettez fin à l’investigation et faites remonter le problème avec les informations recueillies. N’utilisez aucune commande de réparation de base de données, de suppression ou de démantèlement.

Clôture et transmission

Pour terminer, consignez l’hypothèse, la console utilisée, les capteurs concernés, la fenêtre temporelle et son fuseau horaire, les filtres du tableau de bord, la requête exécutée, les variables, l’état dans History et le nombre de résultats. Transmettez les constatations positives via le processus SOC, XDR ou MDR existant. Un résultat négatif signifie uniquement que rien n’a été trouvé dans le périmètre local documenté de l’investigation. Il ne prouve pas que l’activité est absente de l’ensemble du réseau.

Supprimez les valeurs d’exemple sensibles d’une définition de requête qui n’est nécessaire que temporairement, ou clarifiez la durée de conservation autorisée avec la personne responsable de Library.

Questions fréquentes