Analyser les rapports Sophos DNS Protection et Live Discover

Sous My Products > DNS Protection > Reports, les requêtes DNS peuvent être filtrées, présentées sous forme de rapport et exportées. Pour une analyse plus détaillée, utilisez Threat Analysis Center > Live Discover > DNS Protection : vous pouvez y examiner les enregistrements DNS du Data Lake à l’aide de requêtes SQL intégrées ou personnalisées.

Procédure rapide : dans Report Generator, sélectionnez un Report template et le Time frame, appliquez des filtres aussi précis que possible sous Query, puis cliquez sur Generate. Pour Live Discover, commencez par exécuter une requête DNS Protection intégrée sur une courte période. N’activez Designer Mode que lorsque la requête intégrée renvoie des données ; pour toute nouvelle requête DNS, Data Lake doit être sélectionné comme Source.

Prérequis, licences et attribution des données

DNS Protection doit déjà traiter des requêtes DNS. Pour analyser les rapports, il est donc utile de disposer d’une Location active connue ou d’un endpoint administré, ainsi que d’une courte période de test. Les données des rapports accusent un retard de 15 à 25 minutes sur le temps réel. Les changements de nom d’une Location ou d’une Policy peuvent mettre de 30 minutes à 4 heures avant d’apparaître dans les rapports.

Dans le cadre d’un déploiement autonome ou réseau, DNS Protection fait partie de la famille de licences Xstream. En revanche, lorsque DNS Protection est déployé sur des endpoints administrés, ce mode de déploiement relève de Workspace Protection. Workspace Protection et DNS Protection déployé sur l’endpoint sont également requis pour que les rapports puissent afficher les informations sur les utilisateurs et les appareils issues des données d’endpoint.

Live Discover répond à une condition distincte : cette fonctionnalité de requête requiert une licence Sophos EDR, XDR ou MDR. Cette licence ne remplace pas Workspace Protection pour le mode DNS sur endpoint administré. Les requêtes DNS Protection utilisent le Data Lake. Les Endpoint Queries ne correspondent pas au chemin de données approprié dans ce cas : elles interrogent l’état actuel d’appareils connectés sélectionnés, tandis que les requêtes Data Lake analysent les données qui y ont été chargées.

L’origine détermine la précision avec laquelle un rapport peut attribuer une requête :

DNS usage affiche les requêtes DNS de l’ensemble du réseau.
DNS usage by source associe les données réseau à une Location. Pour les données provenant de Sophos Endpoint, le rapport peut en plus indiquer les utilisateurs et les appareils.
Pour les données d’endpoint, User affiche le nom de l’utilisateur ou de l’appareil à l’origine de la requête. Device affiche l’ID de l’appareil. Ces colonnes sont uniquement disponibles pour Sophos Endpoint.
High risk devices affiche les appareils qui envoient des requêtes DNS vers des sites web à risque, suspects ou non sécurisés.

La limite est donc claire : un enregistrement DNS provenant du réseau ne fournit pas automatiquement l’identité de l’utilisateur ou de l’endpoint d’origine derrière un résolveur local. L’intégration des endpoints a ajouté les champs de rapport relatifs aux utilisateurs et aux appareils, ainsi que les templates DNS usage by source et High risk devices.

Configurer et filtrer un rapport DNS Protection

Ouvrez My Products > DNS Protection > Reports et sélectionnez le Report template approprié dans Report Generator.
Sous Time frame, choisissez une période prédéfinie ou définissez une heure de début et une heure de fin avec Custom. Pour le premier test, une courte période autour d’une requête DNS connue suffit.
Sous Query, sélectionnez ou saisissez le nom de la colonne, indiquez la valeur du filtre et, si nécessaire, modifiez l’opérateur à côté du signe égal.
N’ajoutez d’autres filtres que s’ils permettent de restreindre utilement les résultats. Plusieurs filtres sont reliés par AND ; une ligne doit donc satisfaire toutes les conditions.
Cliquez sur Generate. Vous devez également générer de nouveau le rapport après avoir cliqué sur une valeur du tableau pour ajouter un filtre.

Les opérateurs de comparaison ont des effets différents :

= et != sont sensibles à la casse et testent respectivement l’égalité et l’inégalité.
<, <=, > et >= s’appliquent uniquement aux valeurs numériques.
IN effectue une comparaison sensible à la casse avec une liste de valeurs séparées par des virgules.
~ et !~ effectuent une comparaison insensible à la casse avec une expression générique ; * est le caractère générique.

Pour tester un domaine, vous pouvez par exemple filtrer sur le domaine de test réellement interrogé. Le nom de domaine est une valeur propre à l’environnement et doit être remplacé par celui de votre propre test. Si le résultat reste vide, commencez par supprimer le filtre de domaine et vérifiez uniquement la période et la Location. Vous pourrez ainsi déterminer si l’orthographe ou la combinaison de plusieurs filtres exclut le résultat.

Le tableau affiche initialement les colonnes par défaut. Le sélecteur de colonnes en haut à droite permet d’afficher des champs supplémentaires ; les colonnes proposées dépendent du template et de l’origine des données. Cliquez sur l’en-tête d’une colonne pour trier les données par ordre croissant ou décroissant. Lorsqu’une colonne de date est visible, Sophos regroupe les lignes identiques en fonction de la période :

pour 1, 8 ou 24 heures, par date, heure et minute identiques ;
pour 7 jours ou une période Custom allant jusqu’à 7 jours, par heure de début identique ;
pour 30 jours ou une période Custom supérieure à 7 jours, par jour, avec 00:00 comme horodatage.

N’interprétez pas excessivement le statut : pour une URL incorrecte, non valide ou qui n’existe plus, Status affiche n/a pour les requêtes A, AAAA, CNAME ou HTTPS et Allowed pour les autres types de requêtes. Cette valeur seule ne prouve ni l’accessibilité ni la sécurité du site cible.

Les graphiques disponibles sont Bar, Horizontal bar, Pie, Line et Stack-area. Sélectionnez les axes à l’aide de l’icône en forme de clé. Le choix d’un autre type de graphique rétablit les valeurs par défaut de ses axes ; les graphiques en barres et en secteurs n’affichent que les dix catégories les plus fréquentes.

Enregistrer, planifier et exporter un rapport

Save Template enregistre les filtres de requête, le type et les axes du graphique, le tri du tableau ainsi que ses colonnes sous Saved Templates. Les données et la période ne sont pas enregistrées. Vous devez donc choisir à nouveau une période adaptée à l’analyse lors de l’utilisation suivante. Le nombre total de templates pour les rapports DNS Protection, ZTNA et Sophos Firewall est limité à 1 000.

Pour un envoi ponctuel, choisissez PDF, CSV ou HTML. Planifiez les analyses récurrentes avec Schedule selon une fréquence quotidienne, hebdomadaire ou mensuelle. Un Template Name ne peut pas dépasser 64 caractères et le nombre total de schedules est limité à 200. Les limites d’exportation sont les suivantes :

PDF : 10 000 lignes et 15 colonnes
HTML : 10 000 lignes et 23 colonnes
CSV : 100 000 lignes et 23 colonnes

Les exportations générées manuellement et planifiées apparaissent sous Scheduled Exports et sont supprimées au bout de 90 jours. Si un rapport contient des données à caractère personnel, il est préférable d’envoyer un lien par e-mail plutôt qu’une pièce jointe : des identifiants Sophos Fusion sont requis pour ouvrir ce lien. Les fichiers téléchargés et leurs destinataires doivent néanmoins respecter votre propre politique de protection et de suppression des données.

Analyser les données DNS avec Live Discover

Ouvrez Threat Analysis Center > Live Discover > DNS Protection.
Sélectionnez une requête DNS Protection intégrée. Designer Mode n’est pas requis pour cette étape.
Sous Select a Time Period, choisissez d’abord une courte période d’activité connue, puis cliquez sur Run Query. Une requête peut couvrir au maximum 30 jours. Pour les analyses plus longues, utilisez plusieurs fenêtres temporelles distinctes qui ne se chevauchent pas.
Une fois que la requête intégrée renvoie des données, activez Designer Mode et examinez la requête avec Edit, ou sélectionnez Create new query. Pour une nouvelle requête DNS Protection, définissez Data Lake comme Source.
Dans la boîte de dialogue SQL, ouvrez Schema. Dans le Schema Viewer, sélectionnez la section Firewall, puis la table xgfw_data sous Data Lake.

Ce test de base permet de distinguer une absence de données ou d’autorisations d’une erreur dans une requête personnalisée. Ne reprenez pas de modèle SQL général ni de champs non documentés. Basez plutôt vos requêtes personnalisées sur l’association documentée avec xgfw_data et sur les champs réellement disponibles dans le Schema Viewer de votre tenant. La sélection, l’exécution et la planification des requêtes Data Lake générales sont décrites dans Collecte de données Sophos Endpoint et Live Discover.

Champs DNS documentés dans `xgfw_data`

Sophos documente les champs suivants pour DNS Protection :

action, bytes, dns_qid, dns_qname, dns_qtype, dns_duration, domain, domain_category, domain_risk, hits, log_type, log_component, object_name, protocol, policy_name, query_class, query_flags, query_size, reason, response_code, response_records_num, response_ip_num, resolved_ip, response_type, response_name, response_class, response_ttl_list, response_size, response, riskscore, security_status, src_ip, src_port, src_location, timestamp.

log_type avec la valeur DNS et log_component avec la valeur FE-DNS identifient un log DNS Protection. object_name contient le nom de la Domain List lorsque l’action de la Policy était Reject et la raison Custom Domain Block or Allow. timestamp correspond à l’heure de traitement de la requête DNS, hits au nombre de requêtes et bytes à la somme de la taille de la requête et de la réponse. Les champs response_* décrivent la réponse DNS ; security_status indique si DNSSEC a été validé pour la réponse.

Bien que la table s’appelle xgfw_data et se trouve sous Firewall, cela ne signifie pas que tous les autres champs de pare-feu sont renseignés dans les enregistrements DNS. En particulier, cette liste de champs DNS ne documente aucun champ pour User ou Device. Avant de créer une requête, vérifiez donc les champs disponibles dans le Schema Viewer de votre propre tenant.

Valider les résultats et cerner les problèmes

Pour effectuer un test fonctionnel reproductible, générez une requête connue depuis une Location clairement attribuée ou un endpoint pilote administré. Attendez ensuite 15 à 25 minutes et vérifiez les points suivants :

La requête apparaît-elle dans la période sélectionnée du rapport ?
Le domaine, l’action ou le statut, la Policy et la Location sont-ils corrects ?
Pour les données d’endpoint, les champs User et Device sont-ils renseignés de manière plausible ?
Une requête DNS Protection intégrée à Live Discover renvoie-t-elle des enregistrements correspondants pour la même période ?

Le rapport reste vide

Commencez par vérifier le Time frame, le fuseau horaire, les filtres et la casse pour =, != et IN. Supprimez ensuite les filtres un à un, car toutes les conditions doivent être satisfaites simultanément. Si le rapport élargi ne renvoie toujours rien, vérifiez que le test a effectivement généré des requêtes DNS et que la Location ou l’origine des données d’endpoint attendue a bien été utilisée. Une Location ou une Policy qui vient d’être renommée ne convient pas à un test immédiat en raison du délai possible de 30 minutes à 4 heures.

User ou Device est absent

Vérifiez si l’enregistrement provient réellement de Sophos Endpoint. Les requêtes réseau ne contiennent pas cette attribution à un endpoint. Utilisez ensuite DNS usage by source et affichez User et Device à l’aide du sélecteur de colonnes. Si les colonnes ou les valeurs restent absentes, ne déduisez pas l’identité d’un utilisateur à partir de l’adresse IP source ou de la Location.

Les rapports affichent des données, mais pas Live Discover

Commencez par vérifier la licence EDR, XDR ou MDR, la section DNS Protection, Data Lake comme Source, la période et Firewall > xgfw_data. Exécutez ensuite une requête DNS Protection intégrée sans la modifier à l’aide de Run Query. Si elle fonctionne, l’erreur se trouve dans votre requête personnalisée : reprenez les noms de champs directement depuis Schema et simplifiez progressivement la requête. Si la requête intégrée échoue elle aussi, l’étape suivante sûre consiste à vérifier le chemin des données vers le Data Lake ou à solliciter le support ; les champs ou jointures non documentés ne constituent pas une solution fiable.

Retour arrière sûr et cycle de vie

Les rapports ne modifient pas le traitement DNS. La suppression d’un filtre ou l’abandon d’une analyse non enregistrée ne nécessite donc aucun retour arrière technique. Avant de supprimer un artefact enregistré, vérifiez toutefois qu’aucun autre administrateur ou processus d’exploitation n’en a besoin :

Sous Scheduled Exports, sélectionnez une planification et supprimez-la avec Delete. Vérifiez ensuite qu’aucune autre exportation n’est générée par ce schedule.
Sous Saved Templates, sélectionnez un template et supprimez-le avec Delete. Vous pouvez supprimer au maximum 25 templates à la fois. Cette opération supprime la configuration de rapport enregistrée, mais pas les données DNS sources.
Ne continuez pas à utiliser une requête Live Discover personnalisée incorrecte à la place de la requête intégrée. Revenez à la requête DNS intégrée connue et à une courte période.

Dans le cadre de l’exploitation courante, vérifiez régulièrement le propriétaire, l’objectif, les destinataires, la période et les colonnes nécessaires des templates et schedules enregistrés. User, Device, le domaine et l’adresse IP source, notamment, peuvent constituer des données à caractère personnel ou pertinentes pour l’exploitation. Après toute modification de l’intégration des endpoints, vérifiez également que DNS usage by source continue d’indiquer les utilisateurs et les appareils. Avant toute modification opérationnelle, consultez l’aide actuelle ainsi que les champs effectivement disponibles dans le Schema Viewer. N’utilisez les Release Notes que si vous souhaitez retracer l’introduction d’une fonctionnalité de rapport.