Vérifier Sophos XDR Data Lake Search et les exports

Data Lake Search, sous Security Operations > Data Lake Search, interroge les événements et detections ingérés dans le tenant. Avant la première requête, définir la question d’investigation, la source nécessaire et la fenêtre temporelle. Un résultat vide n’est significatif qu’après vérification de l’ingestion, du schéma et des filtres.

Ce guide décrit l’interface Security Operations actuelle. Live Discover et Live Endpoint Search distinguent les données historiques d’une interrogation directe des appareils et conservent les procédures Classic différentes. Les exemples QL sont des modèles de syntaxe fondés sur les sources, pas des tests réellement exécutés dans un tenant.

Choisir la source et la méthode de recherche

Avant la recherche, vérifier sous Integrations > Configured Data Sources que la source attendue fournit des données actuelles associées au schéma nécessaire. Une connexion verte ne suffit pas. L’acceptation des intégrations explique cette distinction.

Data Lake Search propose AI Search, Query Builder et Query Editor. AI Search génère une suggestion à partir d’une question en langage naturel. Contrôler son schéma, ses conditions et sa période avant l’analyse ; l’IA ne remplace pas l’acceptation de la source. Query Builder représente visuellement les conditions, tandis que Query Editor utilise Advanced Search Query Language. L’icône d’épingle permet de définir la méthode préférée par défaut.

Commencer par une petite source connue et une période courte. Dans Query Builder, choisir d’abord Detections ou Events, puis le type d’événement pour Events. Dans Query Editor, FROM détermine le schéma. Ne pas mélanger detections et événements dans la même requête.

Comprendre Schema Library et les champs logiques

Un schéma est une catégorie d’événements structurée, par exemple auth, process ou netflow. Schema Library affiche schémas, champs interrogeables et Logical Types. Tout champ renseigné par un parser n’est pas nécessairement disponible dans la recherche. Vérifier le mapping avec les champs réellement interrogeables, pas seulement avec un champ fabricant au nom similaire.

Les champs logiques préfixés par @, comme @ip ou @user, regroupent les champs adaptés de plusieurs schémas. Une recherche multischéma rassemble les résultats par schéma ; une condition n’agit que sur les schémas possédant le champ. Ce n’est pas une jointure relationnelle. Un filtre sur des champs événementiels dans une recherche de detections nécessite le préfixe du schéma correspondant, par exemple process.commandline.

Le modèle inoffensif suivant montre une recherche courte dans le schéma d’authentification. example-user est un exemple libre à remplacer par une identité autorisée pour l’investigation :

FROM auth WHERE @user CONTAINS 'example-user' earliest=-1h

CONTAINS recherche une sous-chaîne et ne garantit pas une correspondance exacte d’identité. Si une preuve de compte sans ambiguïté est nécessaire, vérifier le champ d’identité réel, l’opérateur et la source. Ne pas regrouper sans contrôle des comptes locaux et de domaine portant le même nom.

Distinguer période, conservation et accès Raw

Pour les Events normalisés, l’aide sur les schémas du 2 octobre 2026 autorise au maximum 31 jours par requête. La date de début peut se situer n’importe où parmi les données effectivement conservées. Pour une investigation plus longue, utiliser des fenêtres coordonnées aux limites documentées. Les detections peuvent être recherchées sur une période quelconque ; vérifier malgré tout leur historique disponible et les autorisations.

Ces 31 jours ne sont pas une durée de conservation. Next-Gen SIEM peut offrir une rétention plus longue sans permettre une requête unique illimitée.

Pour @raw et original_data, le guide SQL vers QL du 15 septembre 2026 décrit un accès distinct aux 20 derniers jours. Une requête Raw hors de ce périmètre est rejetée, pas silencieusement raccourcie. L’ancienne page Query Language mentionne aussi des incréments de 20 jours. Cela ne garantit pas que le découpage rende disponibles des données brutes plus anciennes. Avant de promettre une preuve Raw historique hors de ce périmètre, un chemin produit confirmé doit exister. Ce n’est ni une rétention générale de 20 jours ni une preuve de suppression physique.

Tenir compte des limites QL et des pièges de comparaison

L’aide Query Language indique 100 Query Units exécutées simultanément par tenant et une limite de scan de 10 To par requête. Une recherche peut utiliser plusieurs Query Units ; cent utilisateurs ne disposent pas chacun de cent recherches parallèles. Réduire en conséquence les recherches logiques larges et les grandes périodes. Une recherche en échec ou limitée ne doit pas être interprétée comme zéro événement.

Les expressions régulières des événements utilisent un moteur compatible Java ; les recherches de detections utilisent un moteur basé sur Lucene. Ne pas copier aveuglément un même motif entre ces chemins. La résolution du hostname est aussi un cas particulier, avec comparaison littérale sensible à la casse et opérateurs limités.

Dans les tableaux, des conditions peuvent correspondre à des entrées différentes du même événement. Une correspondance sur nom et valeur d’en-tête ne prouve par exemple pas qu’ils appartiennent à la même entrée. Si cette association est décisive pour le constat, examiner individuellement les données sous-jacentes.

Vérifier les résultats et enregistrer la recherche

Après sélection de la période, lancer avec Search ou Shift + Enter. Full Screen agrandit les résultats. Le menu d’un en-tête de colonne permet de filtrer, afficher/masquer, épingler ou redimensionner les champs ; les colonnes se réorganisent par glisser-déposer.

Pour un constat fiable, contrôler sur des lignes représentatives le bon tenant, la source, l’heure avec fuseau, l’identité et l’action. Le nombre de lignes visibles ou une detection positive ne remplace pas cette vérification des champs. Pour un test de source, comparer l’événement à la preuve d’origine.

Dans AI Search et Query Editor, Save Query ouvre l’enregistrement. Dans Query Builder, choisir d’abord Save Search. Renseigner ensuite nom, catégorie et description facultative, puis enregistrer avec Save Query ; Bookmark this Query ajoute la recherche aux favoris personnels. Un nom utile indique but et source sans secret ni donnée brute personnelle. Les recherches sont consignées dans l’historique du tenant. Un texte de requête enregistré n’est pas une archive permanente des résultats.

Sauvegarder des exports complets avant leur expiration

Dans le menu Actions au-dessus des résultats, exporter l’ensemble ou un sous-ensemble délibérément sélectionné. Ouvrir ensuite Security Operations > Data Exports. Vérifier le statut séparément de la bonne exécution de la recherche :

• Processing : l’export est encore en cours.
• Completed : le fichier peut être téléchargé.
• Errored : analyser l’erreur et utiliser Retry dans le menu à trois points lorsque la cause le justifie.
• Cancelled : export annulé, sans preuve complète.

Les exports sont limités à 100 000 lignes par fichier. Pour des volumes supérieurs, répartir utilement périodes, filtres ou paramètres et documenter plusieurs demandes. Le nombre et la couverture des fichiers partiels doivent correspondre ensemble au périmètre voulu. Un fichier téléchargé ne prouve pas l’exhaustivité d’une recherche plus grande.

File Expiration indique l’expiration du fichier. Le sauvegarder par Download dans l’emplacement autorisé avant cette date. Ne pas inventer de TTL fixe universel à partir d’un exemple. Cancel interrompt un export en cours ; Delete supprime irréversiblement l’export. Aucune de ces actions ne confirme l’effacement de la télémétrie d’origine du Data Lake.

La preuve d’export comprend requête, limites temporelles explicites et fuseau, sources/schémas sélectionnés, périmètre, statut, nombre de lignes et conservation dans le système cible. Régler à l’avance l’accès et le partage des données sensibles. Pour un client propre entièrement paginé, le runbook Search GraphQL explique Search-URN, échecs partiels, curseurs et expiration.

Analyser des résultats inattendus

Si les correspondances manquent, vérifier d’abord tenant, source, schéma, période et conditions. Après une erreur Raw, ne pas déduire une disponibilité plus ancienne en multipliant les fenêtres. En cas de limite de scan ou de parallélisme, réduire la requête et documenter la répartition, sans lancer des répétitions incontrôlées.

Si la prévisualisation est correcte mais qu’une règle de detection ou de suppression se comporte autrement, vérifier l’exploitation actuelle des règles. Les moteurs de streaming et de suppression traitent les données à des moments et avec des contraintes différents d’une recherche historique.