Sophos Switch : interroger les données des appareils et clients avec Live Discover

Live Discover permet d’interroger la télémétrie des Sophos Switch administrés dans Sophos Fusion. Les données du Data Lake aident par exemple à examiner les appareils qui étaient connectés à un switch précis. Elles ne constituent toutefois pas une vue en direct de l’état actuel du switch.

Conditions requises

Vous avez besoin d’au moins un Sophos Switch administré dans Sophos Fusion ainsi que d’un accès au bon tenant et à Threat Analysis Center > Live Discover. Live Discover nécessite une licence Sophos EDR, XDR ou MDR. La documentation ne mentionne par ailleurs ni pack de licence Switch particulier, ni rôle d’administrateur précis. Si Live Discover, Switch ou une fonction de modification manque, faites donc vérifier l’attribution des licences, vos droits d’accès et l’activation de la fonction dans le tenant concerné.

Définissez au préalable l’objectif de l’examen. Le switch ID, le nom de l’appareil, le numéro de série, l’adresse MAC du client, le port, le VLAN et la période sont des repères appropriés. Designer Mode n’est nécessaire que pour modifier ou créer une requête.

Interroger les données du switch

Commencez par une requête de switch intégrée. Vous obtenez ainsi d’abord un résultat de comparaison et ne devez passer au concepteur que si la requête existante ne répond pas à votre question.

1. Dans Sophos Fusion, ouvrez Threat Analysis Center > Live Discover > Switch.
2. Sélectionnez une requête Data Lake intégrée pour Sophos Switch. Contrôlez son objectif, sa définition visible et les paramètres requis.
3. Si cette option est proposée, définissez la période d’examen sous Select a Time Period, puis exécutez la requête.
4. Interprétez les résultats à l’aide de l’identité du switch, de type_of_data et des champs temporels. Comparez un switch connu ou un client de test avec les données de l’administration des switchs.
5. Si la requête intégrée suffit, documentez la requête, les paramètres, la fenêtre temporelle et le résultat. Sinon, activez Designer Mode et choisissez l’une des méthodes suivantes :
   • Adapter une requête existante : sélectionnez la requête sous Query et cliquez sur Edit. Enregistrez la définition d’origine avant de la modifier.
   • Créer une requête : sous Query, cliquez sur Create new query et sélectionnez Data Lake comme Source.
6. Dans la boîte de dialogue SQL, ouvrez Schema en haut à droite. Le Schema Viewer s’ouvre dans un nouvel onglet. Sélectionnez NSG Cswitch > nsg_cswitch_data et contrôlez les colonnes et types de données disponibles.
7. Utilisez uniquement les tables, champs et valeurs qu’affiche le Schema Viewer actuel ou la requête intégrée. Ne modifiez à chaque fois qu’un élément cohérent, par exemple la sélection des champs ou le filtre d’un switch connu.
8. Exécutez d’abord la requête adaptée avec un switch ou client connu et étroitement délimité. Comparez le résultat à celui de la requête intégrée inchangée et aux données d’inventaire ou de connexion connues.

Pour rechercher les clients d’un switch précis, identifiez sans ambiguïté l’appareil cible avec device_id ou le numéro de série. Évaluez ensuite ensemble l’adresse MAC du client, device_port, client_vlan, l’état de la connexion et les champs temporels. Cette restriction évite les confusions, mais ne prouve pas encore que la liste des clients est complète ; la période et is_full_set doivent également correspondre.

Choisir une fenêtre temporelle

Select a Time Period est facultatif pour les requêtes Data Lake. Sans sélection, les 7 derniers jours s’appliquent. Une requête individuelle peut couvrir au maximum 30 jours.

Pour les examens plus longs, exécutez plusieurs requêtes avec des fenêtres temporelles distinctes. Pour 90 jours, Sophos cite par exemple 0–30, 31–60 et 61–90 jours. Documentez chaque fenêtre séparément et conservez le switch, le type de données et les autres filtres inchangés lors de la comparaison.

Champs du schéma de switch

Le schéma couvre l’identité du switch, les clients connectés et les journaux. type_of_data désigne le type de données envoyées, par exemple les données de client ou de journal. Chaque ligne ne contient donc pas simultanément tous les champs de client et de journal.

Les valeurs d’état, de sous-type et de gravité peuvent varier selon les données affichées. Reprenez leur orthographe exacte et leur signification dans le schéma actuel et le résultat de la requête.

Interpréter correctement les résultats

Une ligne brute du Data Lake est d’abord un résultat de requête. type_of_data et les champs renseignés indiquent si elle contient des données de client ou de journal. Si la requête SQL regroupe plusieurs enregistrements, la ligne de résultat est une synthèse calculée et non un événement réseau individuel. Ne transposez donc pas la signification de timestamp à un agrégat sans la contrôler.

Identité et tenant

device_id est l’ID unique du switch. Comparez aussi au moins un autre repère, comme device_serial_id, device_name, device_model ou device_ip, avec l’appareil cible. Les noms et adresses IP peuvent changer ou être réutilisés. customer_id associe les données au tenant ; ce n’est ni un ID de switch, ni un numéro de série, ni un ID de client.

Heure de l’événement et de l’ingestion

• timestamp désigne l’heure de génération de l’événement.
• client_event_timestamp désigne l’heure à laquelle l’appareil s’est connecté.
• ingestion_timestamp désigne l’heure d’ingestion en secondes epoch.
• ingest_date est la date d’ingestion.

Une ingestion ultérieure ne correspond pas automatiquement à un événement réseau ultérieur. Pour les séries temporelles, contrôlez aussi la conversion de l’epoch et le fuseau horaire de l’environnement de requête utilisé.

Données complètes et incrémentielles

is_full_set indique si une livraison est complète ou incrémentielle. Ne considérez pas un jeu de données incrémentiel comme un inventaire complet des clients. Même une livraison marquée comme complète ne garantit pas à elle seule que chaque client attendu apparaît pendant la période examinée.

Clients et journaux

device_port et client_vlan associent un client à un port et à un VLAN. Seule la valeur de direct_end_device indique s’il est directement connecté, et non la simple présence du champ. L’adresse IP et le nom d’hôte peuvent manquer ou changer ; utilisez également client_mac et les champs temporels pour l’attribution. Un enregistrement de télémétrie n’est en outre qu’une observation datée, et non une preuve de l’état actuel ou d’un historique de connexion sans lacune.

Pour les données de journal, log_id, log_subtype, log_component, log_message et log_severity fournissent le contexte. La gravité ne prouve à elle seule ni la cause ni l’incidence d’un problème réseau.

Vérifier le résultat

Avant d’utiliser le résultat, répondez aux questions suivantes :

• customer_id et l’identité du switch appartiennent-ils au bon tenant et à l’appareil cible ?
• type_of_data et les champs de client ou de journal effectivement renseignés correspondent-ils à la question examinée ?
• Les heures d’événement, de client et d’ingestion se situent-elles dans la fenêtre attendue et ont-elles été interprétées séparément ?
• is_full_set a-t-il été pris en compte si vous formulez une conclusion sur l’exhaustivité ?
• Pour un client de test connu, l’adresse MAC, le port, le VLAN et la valeur de direct_end_device correspondent-ils à la connexion attendue ?
• La requête intégrée fournit-elle un résultat de comparaison plausible pour la même cible et la même fenêtre temporelle ?

Un enregistrement manquant n’est qu’une absence de preuve dans les conditions choisies. Il ne prouve ni que le switch ou le client n’existe pas, ni à lui seul une erreur de télémétrie.

Cerner les problèmes

Requêtes de switch ou fonctions de modification absentes

Si la section Switch manque, contrôlez d’abord le bon tenant Fusion, la présence d’un switch administré par Fusion et l’attribution d’une licence Sophos EDR, XDR ou MDR. Faites ensuite contrôler vos droits d’accès et l’activation de la fonction dans le tenant. Designer Mode doit en outre être activé pour Edit et Create new query.

Schéma ou table absent

Le Schema Viewer s’ouvre depuis la boîte de dialogue SQL d’une requête modifiée ou nouvelle. Pour une nouvelle requête, Source: Data Lake doit être sélectionné. Pour la télémétrie des switchs, utilisez exclusivement le chemin NSG Cswitch > nsg_cswitch_data affiché dans le viewer et ses champs actuels.

La requête ne renvoie aucune ligne

Testez d’abord une requête de switch intégrée pour un switch connu. Notez le tenant, le filtre du switch, l’enregistrement de test attendu et la fenêtre temporelle. Retirez ensuite vos propres filtres un par un et comparez les noms de champs au schéma.

Sans sélection temporelle personnelle, tenez compte de la valeur par défaut de 7 jours. Les autres conditions restant inchangées, élargissez progressivement la fenêtre jusqu’à 30 jours au maximum. Pour les examens plus longs, utilisez des fenêtres distinctes et documentées. Comparez également les heures d’événement et d’ingestion, puis contrôlez type_of_data et is_full_set. Consignez le résultat sous la forme « aucune ligne dans les conditions de requête et pendant la période sélectionnées ».

Vous pouvez également contrôler l’état opérationnel et de synchronisation de l’appareil cible avec le runbook Administrer une flotte de Sophos Switch.

Des lignes sont présentes, mais les données de client manquent

Une ligne de journal ne doit pas nécessairement contenir des champs de client. Contrôlez donc d’abord type_of_data et is_full_set, puis examinez ensemble client_mac, client_ip, client_hostname, client_event_timestamp et client_conn_status. Ne complétez pas les valeurs manquantes à partir de l’inventaire ou de conventions de nommage.

La série temporelle semble incohérente

Comparez séparément les heures d’événement et d’ingestion, puis contrôlez la conversion de l’epoch et le fuseau horaire. Une ingestion retardée ne correspond pas automatiquement à un deuxième événement réseau. Vous pouvez utiliser message_identifier pour la déduplication, mais son unicité n’est documentée qu’au sein du pipeline d’ingestion.

Annuler les modifications et protéger les données

Une requête modifie sa définition ou sa sélection SQL, pas la configuration du switch. Si une requête adaptée n’est pas fiable, cessez de l’utiliser et revenez à la requête intégrée inchangée. Si nécessaire, restaurez la définition enregistrée précédemment ou supprimez la nouvelle variante avec la fonction proposée dans votre interface. Contrôlez ensuite avec la requête intégrée que le fonctionnement normal est toujours assuré.

Les résultats exportés peuvent contenir des ID de client, des numéros de série, des adresses IP et MAC, des noms d’hôte, des ports, des VLAN et des messages de journal. Protégez et supprimez les exports, captures d’écran et notes conformément à vos règles de conservation et de protection des données. L’annulation d’une requête ne supprime pas les copies déjà enregistrées ; celles-ci doivent être traitées à leurs emplacements de stockage respectifs.