Data Collection et Live Discover de Sophos Endpoint

La Data Collection and Investigation Policy contrôle deux fonctions indépendantes : les connexions Live Response et l’envoi de la télémétrie Endpoint dans le Sophos Data Lake. Live Discover utilise ensuite soit les données actuelles d’un appareil connecté, soit les données historiques du Data Lake.

Ces fonctions nécessitent Sophos EDR, XDR ou MDR. Live Response dispose de droits propres et est également traité dans l’article distinct consacré à la réponse.

Procédure rapide pour Classic : sous Threat Analysis Center > Live Discover, sélectionnez d’abord la Data source appropriée, puis Query category et Query. Pour une requête Endpoint, limitez volontairement les appareils cibles sous Devices, puis sélectionnez Run Query. Le résultat n’est fiable que si les lignes de résultat et Telemetry correspondent à la source, à la période et aux appareils attendus.

Avant de lancer une requête, vérifier si le tenant utilise Threat Analysis Center ou Security Operations. Threat Analysis Center reste disponible sous la forme de Classic view. Security Operations sépare Data Lake Search, pour les données historiques, de Live Endpoint Search, pour les requêtes sur des appareils connectés. Les étapes Live Discover, exemples SQL, indications de planification et limites de l’interface ci-dessous décrivent Classic, sauf mention explicite d’une autre interface. Une mise à niveau du tenant ne les invalide pas automatiquement et ne les traduit pas en QL.

Security Operations: Data Lake Search

Sous Security Operations > Data Lake Search, trois méthodes permettent de rechercher les Detections et événements du tenant. Cette interface utilise Advanced Search query language, ou QL ; le SQL Data Lake de Classic ne doit pas y être copié tel quel.

• AI Search traduit une question en langage naturel en requête. Saisissez la question ou un prompt préparé, sélectionnez Search et vérifiez la requête générée avec les résultats. Browse Prompts ou View All ouvre les prompts ; Sophos Only, les filtres de catégorie et un terme de recherche réduisent la sélection. Au besoin, affinez le prompt et relancez la recherche.
• Query Builder construit visuellement la requête à partir de champs et d’opérateurs. Définissez la date et la période avant Search ou Shift + Enter. Pour une première vérification, utilisez une période courte contenant un événement connu et contrôlez que la source et les filtres le capturent bien.
• Query Editor permet de rédiger des requêtes QL. Basics présente les bases de la syntaxe et des exemples ; Cheat Sheet, les opérateurs et fonctions. Search Help fournit une aide contextuelle Build With Me pour les schémas et champs. Ici aussi, définissez la date et la période avant Search ou Shift + Enter. Les exemples SQL des sections Classic suivantes ne sont pas des modèles QL.

Le bouton d’épinglage à côté du nom de la méthode définit la méthode de recherche préférée. Chaque recherche exécutée est automatiquement ajoutée à l’historique de recherche du tenant ; elle n’est donc pas un simple brouillon local. Limitez les prompts et requêtes à la question d’investigation et ne saisissez aucun secret. Un tableau vide n’est significatif qu’après vérification de la période, de la source et des filtres ; il ne prouve pas l’absence d’un incident.

Pour enregistrer dans AI Search et Query Editor, sélectionnez Save Query ; dans Query Builder, sélectionnez d’abord Save Search. Saisissez un nom et une catégorie, ajoutez éventuellement une description et Bookmark this Query, puis terminez avec Save Query. Rouvrez et vérifiez la requête enregistrée sous Saved Queries. Un signet l’ajoute également à My Bookmarked Queries.

Full Screen agrandit la vue des résultats. Le menu de l’en-tête de colonne propose Pin, Autosize, Reset, Filter ainsi que l’affichage ou le masquage des colonnes ; faites glisser les en-têtes pour modifier leur ordre. Actions, au-dessus du tableau, permet d’exporter tous les résultats ou un sous-ensemble sélectionné. Vérifiez ensuite l’état de l’export et le téléchargement sur Data Exports. Ne documentez pas une vue filtrée ou un export partiel comme le périmètre complet de l’investigation.

Distinguer Live Endpoint Search des API de données historiques

Live Endpoint Search continue d’exécuter des requêtes SQL de type osquery sur des endpoints actuels et connectés. La migration de Live Discover de REST vers GraphQL concerne cette voie en direct, pas les requêtes historiques du Data Lake. Le fait que le catalogue LES puisse répertorier des requêtes enregistrées avec la source dataLake ne prouve pas que LES exécute des requêtes Data Lake. Une intégration existante d’API de données historiques ne doit donc pas être migrée sur la seule base de ce guide.

Depuis le 12 octobre 2026, la Search GraphQL API v1 est publiée pour les recherches QL historiques dans le Data Lake Fusion. Le processus comprend lancement, contrôle du statut et récupération paginée des résultats ; il est distinct de LES et de son SQL en direct de type osquery. Le runbook Search GraphQL explique requêtes, Search-URN, résultats partiels, curseurs, expiration et comparaison d’un client SQL existant. Data Lake Search reste la voie interactive et XDR Query API reste disponible. Ni cette publication ni le guide de migration LES ne traduisent automatiquement le SQL Classic en QL ni n’exigent une bascule API immédiate.

Clients REST existants et bascule facultative vers LES

Live Discover REST est explicitement exclu de la dépréciation des Classic Cases/Detections APIs. Un client existant n’a pas à être migré au seul motif de cette annonce. Pour un nouveau client Live Endpoint ou un changement volontairement planifié, LES est évalué séparément ; la XDR Query API historique et les requêtes SQL Classic conservées ci-dessus restent distinctes.

LES associe les appareils cibles à une session avant le lancement de la requête : exécutez d’abord createLiveDiscoverSession, conservez le nom de session renvoyé, puis affectez les appareils sélectionnés à la session avec endpointSessions. Lancez seulement ensuite runLiveDiscoverQuery avec ce nom comme sessionId et le paramètre toujours requis matchEndpoints: { all: false }. N’utilisez pas de filtres directs dans matchEndpoints comme raccourci, même si le schéma les autorise : le guide de migration ne mentionne que la procédure par session comme méthode d’intégration prise en charge. Commencez avec un seul appareil pilote approuvé et une requête SQL en lecture seule strictement délimitée ; rapprochez l’affectation des cibles, l’état de l’exécution, les lignes de résultat et Telemetry.

Avant la bascule, vérifiez la portabilité des ID de requêtes et de catégories enregistrées ; le guide ne confirme pas leur reprise à l’identique. Clarifiez également avec le responsable de l’API la conservation des résultats, la disponibilité ultérieure des exécutions terminées et le remplacement de la gestion actuelle des pivots d’enrichissement. LES n’accepte qu’un groupe de filtres par appel de sélection ; il ne faut pas deviner la signification de plusieurs anciens groupes de filtres REST. tamperProtectionEnabled devient tamperProtection sous forme de liste, et les filtres sous forme de chaînes/JSON non structurés nécessitent leur propre validation des valeurs.

La pagination des exécutions, du catalogue et des résultats est implémentée séparément pour chacun. Les résultats contiennent les colonnes de sortie SQL sous la forme d’une chaîne encodée en JSON dans additionalColumns ; metadata.columns décrit les noms et les types. Pour les pages suivantes, renvoyez le pages.nextKey fourni, sans modification, comme params.pageFromKey. HTTP 200 ne suffit pas : vérifiez aussi le tableau GraphQL errors et l’état réel de l’exécution et des endpoints. LES partage avec les requêtes planifiées la limite de 1'000 exécutions par jour et de 10 par minute ; l’API REST indique en revanche 500 exécutions par jour et 10 par minute. Ces valeurs propres aux API ne remplacent pas systématiquement les limites de l’interface Classic décrites plus bas. Le volume de données, le watchdog des appareils et les limites de résultats restent à prendre en compte pendant le pilote.

Live Endpoint ou Data Lake

Les requêtes Live Endpoint reposent sur osquery et sont exécutées directement sur les appareils cibles. Les requêtes Data Lake portent sur la télémétrie envoyée par les appareils, peuvent être planifiées et accèdent, selon la licence, à un maximum de 30 ou 90 jours de données.

Dans Live Discover, la période Data Lake détermine l’intervalle historique interrogé. Elle ne constitue pas un calendrier d’exécution. Une requête unique peut couvrir au maximum 30 jours. Pour 90 jours, plusieurs requêtes délimitées sont utilisées.

Choisir et tester une requête

Des requêtes Endpoint et Data Lake prêtes à l’emploi sont disponibles sous Threat Analysis Center > Live Discover. La procédure sépare délibérément la source, la requête et la cible :

1. Sous Data source, sélectionnez Endpoint pour connaître l’état actuel des appareils connectés ou Data Lake pour interroger la télémétrie historique déjà envoyée.
2. Sous Query category, sélectionnez une catégorie, puis la requête souhaitée sous Query. Dans les détails de la requête, vérifiez les systèmes d’exploitation pris en charge et le System Impact indiqué par Sophos.
3. Pour une requête Endpoint, sélectionnez d’abord un seul appareil pilote sous Devices. Si nécessaire, utilisez Show filters, puis actualisez la liste des appareils sélectionnés. Pour une requête Data Lake, définissez plutôt une période courte et connue.
4. Sélectionnez Run Query et attendez le résultat.

Testez d’abord toute requête nouvelle ou modifiée sur un seul appareil pilote ou sur une courte période Data Lake. Les lignes obtenues doivent correspondre à l’appareil ou à la période choisis. Sous Telemetry, vérifiez également si la cible a répondu, le niveau de System Impact et le volume de données transféré. Si le résultat reste vide, vérifiez d’abord Data source, la période, le système d’exploitation pris en charge et, pour les requêtes Endpoint, l’état de connexion de l’appareil. Pour une requête Data Lake, vérifiez aussi que l’envoi est activé sous My Products > Endpoint > Policies > Data Collection and Investigation ou, pour les serveurs, sous My Products > Server.

Designer Mode permet de créer des requêtes osquery ou SQL personnalisées. Sophos Support aide pour les requêtes Sophos prédéfinies et le chemin des données, mais pas pour le développement fonctionnel de requêtes personnalisées quelconques. Community et Professional Services sont disponibles à cet effet.

Les résultats proposent des Pivots, Enrichments et Actions. Un SHA-256 suspect peut ainsi mener à une autre requête, un contrôle Intelix ou VirusTotal, un Threat Graph ou Live Response.

Pour interroger des données DNS Protection, consultez Analyser les rapports et Live Discover de Sophos DNS Protection afin de connaître la sélection DNS Protection, le schéma Data Lake correspondant et les contrôles propres au DNS.

Contrôler l’envoi vers le Data Lake

L’envoi est activé par défaut pour Endpoint Protection. Il peut être limité à certains groupes sous My Products > Endpoint > Policies > Data Collection and Investigation.

Sa désactivation réduit les Detections disponibles et les possibilités d’investigation historique. Une exception Event Collection n’est utilisée que sur instruction de Sophos Support, car elle réduit la télémétrie et donc les capacités de détection ou d’analyse.

Après l’activation, le trafic réseau peut augmenter temporairement. Dans les segments sensibles ou sur les liaisons à faible débit, observer donc la modification dans un groupe pilote.

Event Journals sur l’appareil

Sophos enregistre localement des Event Journals sur les appareils Windows, macOS et Linux. Ils fournissent les données pour les Endpoint Queries. Il n’existe pas de durée de conservation fixe : elle dépend de la plateforme, de l’activité et du stockage configuré.

Sous Global Settings > Products and Services > Endpoint and Server > Event Journals, la taille maximale peut être définie entre 300 et 30'000 Mo. La valeur par défaut est de 5'250 Mo. Il est aussi possible de limiter un pourcentage du disque. Lorsque les deux limites s’appliquent, Sophos utilise la plus petite.

La configuration centrale de ces limites n’est disponible qu’avec une licence XDR, MDR ou MDR Plus. Les Event Journals locaux existent toujours sur les appareils Windows, macOS et Linux protégés, mais leurs seuils ne peuvent pas être adaptés à l’échelle du tenant sans la licence appropriée.

Le paramètre vaut pour tous les appareils concernés et ne peut pas être personnalisé par Endpoint. Une réduction peut supprimer des données de journal existantes et raccourcir la période d’investigation.

Rétention et limites de stockage

XDR conserve les données du Data Lake jusqu’à 90 jours, EDR jusqu’à 30 jours. Le pack facultatif Central Data Storage – 1 yr étend la durée à un an. Il s’agit d’un maximum : lorsque le pool de stockage est épuisé, les anciennes données sont supprimées plus tôt.

Chaque appareil peut envoyer au maximum 2 Go par jour. Une fois la limite atteinte, l’envoi est suspendu jusqu’à la réinitialisation. Sous Windows, celle-ci a lieu à minuit, heure locale ; sous Linux, toutes les 24 heures après le démarrage de l’agent XDR. Les données non envoyées ne sont pas transmises ultérieurement, mais restent disponibles pour une requête Endpoint directe.

Le pool Endpoint comprend en moyenne 20 Mo par licence et par jour. En cas de dépassement permanent, la durée historique réellement disponible diminue. Un tenant annoncé pour 90 jours peut donc contenir moins de données interrogeables.

Trouver la cause d’une limite quotidienne d’Upload

L’événement Data Lake uploads stopped because the daily limit reached apparaît sur les Endpoints Windows et les serveurs Windows ou Linux. Les Hydration Queries planifiées de l’appareil produisent ces envois. XDR et MDR ont chacun une limite quotidienne de 2 Go par appareil. Une fois atteinte, aucune autre donnée de Hydration Query n’est envoyée avant le lendemain ; le quota est alors réinitialisé et les requêtes reprennent jusqu’à la fin du jour ou au prochain dépassement.

Pour trouver la Hydration Query qui génère le plus grand volume d’envoi, connectez-vous à Sophos Fusion (anciennement Sophos Central) et ouvrez Threat Analysis Center > Live Discover. Activez Designer Mode, choisissez Create a new query, nommez-la et sélectionnez Data Lake comme Source. Sous Show variable editor, attribuez des noms descriptifs et ajoutez les types Device Name et Date. Saisissez l’appareil concerné et la date YYYY-MM-DD, puis exécutez :

SELECT
  query_name,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date (from_unixtime($$date$$))
  AND meta_hostname = '$$hostname$$'
GROUP BY query_name, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Cette requête sans variables classe sinon tous les appareils et requêtes par jour ; remplacez la date d’exemple avant l’exécution :

SELECT
  query_name,
  meta_hostname,
  date_trunc('day', ingestion_timestamp) AS date,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) >= date '2021-09-17'
GROUP BY query_name, meta_hostname, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Le plus grand résultat désigne la Hydration Query à examiner, et non automatiquement un processus à bloquer. Consultez le Sophos Data Lake Schema Viewer actuel pour connaître ses colonnes, puis regroupez sur une colonne utile. Si running_processes_windows_sophos domine, ventilez par chemin :

SELECT
  path,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date '$$date$$'
  AND meta_hostname = '$$hostname$$'
  AND query_name = 'running_processes_windows_sophos'
GROUP BY path, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Dans l’exemple Sophos, cette requête a généré environ 72 Mo et le chemin d’un processus lancé représentait plus de 50 % de son envoi quotidien ; les noms réels étaient masqués car propres à l’environnement. Ajoutez ensuite des contraintes ou examinez Command Line, User Name ou Parent Process afin de trouver une correction réduisant le volume. Vérifiez cause, légitimité et configuration avant toute modification ou tout blocage.

Limites de protection

Sophos limite les requêtes afin de protéger les Endpoints et le tenant :

• UI : au maximum 15 requêtes par minute,
• requêtes planifiées et API réunies : 1'000 par jour et 10 par minute,
• watchdog Endpoint : interruption au-delà de 30 % de CPU pendant 12 secondes ou de 256 Mo de RAM,
• au maximum 10 Mo de données de réponse par appareil et requête,
• au maximum 1 Mo par ligne,
• au maximum 100'000 lignes pour l’ensemble des appareils répondants.

Un résultat vide peut donc aussi provenir d’une taille de ligne dépassée. La section Telemetry sous le résultat indique l’état, System Impact et le volume transmis par appareil.

Délimiter systématiquement Query cancelled

Query cancelled n’est pas une erreur propre à HAFNIUM. Sous Windows, le Memory Watchdog peut interrompre une Live Query. Dans SophosLiveQueryService.log, identifiez le Query Name et la Resource Error, réduisez la période, par exemple de 15 à 7 jours, puis retestez sur un appareil. Si l’erreur persiste, raccourcissez encore ou affinez la requête.

Après un Downgrade de Sophos Core Agent 2025.2 vers une ancienne version LTS ou FTS, SophosOsquery.exe peut ne pas démarrer en raison d’une modification de File Attestation. Le log contient alors Exception whilst running LiveQueryRunner. Dans ce cas précis, redémarrez l’appareil ; réécrire la Query ne résout pas la limite de version.

AI Search

Dans la vue Classic sous Threat Analysis Center > AI Search, AI Search génère des requêtes Data Lake à partir du langage naturel. Les Detections et données Endpoint Windows peuvent être recherchées sans écrire soi-même la syntaxe SQL. Le tableau de résultats affiche au maximum 1'000 entrées. Ces limites de plateforme et de résultats ne doivent pas être extrapolées à la nouvelle Data Lake Search décrite ci-dessus.

La recherche commence également par quelques heures ou une journée. Les grandes périodes peuvent ralentir ou échouer. La requête SQL générée est contrôlée avant de considérer le résultat comme complet.

Catégories personnalisées et requêtes planifiées

Les Queries réutilisables sont classées dans des catégories personnalisées clairement nommées. Description, systèmes pris en charge, source de données, Variables et sortie attendue font partie de la documentation de la Query. Une requête copiée n’est pas considérée fiable au seul motif que son SQL s’exécute correctement. Sophos déploie progressivement les catégories personnalisées ; cette fonction peut donc ne pas encore apparaître dans tous les tenants.

Les Scheduled Queries conviennent aux hypothèses et contrôles récurrents et ne sont disponibles que pour les Data Lake Queries. Fréquence, jour, date de fin et période interrogée sont définis consciemment. Chaque administrateur peut avoir au maximum 100 Queries ou rapports de ce format activement planifiés. Des Queries trop larges ou trop fréquentes peuvent aussi atteindre les limites générales et générer beaucoup de télémétrie personnelle.

Exploitation et protection des données

La télémétrie Data Lake et Live Discover peuvent contenir des noms de processus, lignes de commande, utilisateurs, hachages de fichiers, adresses IP et autres données d’exploitation. Les rôles, la finalité, la rétention et l’export sont donc documentés.

Les catégories de requêtes organisent les recherches courantes. La suppression d’une catégorie personnalisée ne supprime pas les requêtes qu’elle contient ; elles restent disponibles sous All Queries ou dans d’autres catégories.

Articles connexes

L’isolation et Live Response sont expliqués dans Isoler et examiner un Endpoint Sophos avec Live Response. Sophos Endpoint XDR : investigation et Threat Graph traite l’évaluation ultérieure des Detections et Threat Graphs.

Questions fréquentes

Pour l’interface Security Operations actuelle, Data Lake Search et export explique le choix du schéma, les fenêtres d’événements de 31 jours, la limite distincte des données brutes et les exports actuels. Les limites Classic conservées ci-dessus ne sont pas transposées à cette interface.