Analyser et conserver les Audit Logs Sophos Central
Sophos Central consigne les activités administratives dans l’Audit Log. Après une fausse alerte, une modification de stratégie ou une connexion suspecte, il permet de déterminer quel compte a exécuté l’action, à quel moment et depuis quelle adresse IP.
L’Audit Log ne remplace pas un SIEM complet. Le portail permet de remonter au maximum 90 jours. Pour répondre à des obligations de conservation plus longues ou corréler rapidement les journaux Entra, firewall et endpoint, les données doivent être régulièrement exportées ou récupérées automatiquement.
Ne pas confondre Audit Log et Event Log
| Journal | Question typique |
|---|---|
| Audit Log | Qui a modifié un rôle, une stratégie, une exclusion ou un paramètre ? |
| Events | Qu’a signalé un appareil protégé ou un produit Sophos ? |
| Alerts | Quelle alerte évaluée doit être examinée ou traitée ? |
Un code malveillant bloqué apparaît comme événement ou alerte. La fermeture ultérieure de l’alerte, une exclusion globale ou la modification d’un rôle constituent en revanche une activité administrative dans l’Audit Log.
Une entrée d’audit peut par exemple indiquer que Users and Groups a été modifié, nommer comme objet concret un utilisateur nouvellement créé ou consigner l’authentification réussie d’un compte Central. L’association entre classe d’objet, objet modifié, description et compte exécutant est plus parlante que chacun de ces champs isolément.
Accès et rôles
Le chemin actuel est Reports > General logs > Audit Logs. Les données visibles dépendent du rôle d’administration. Pour un rôle personnalisé, Access sensitive logs & reports doit être autorisé.
L’accès à l’audit n’est pas accordé globalement à tous les comptes Help Desk. Les entrées contiennent des noms d’administrateurs, des adresses IP et des modifications sensibles. Au moins un rôle d’exploitation doit néanmoins y avoir accès afin de pouvoir examiner un incident sans dépendre du compte Super Admin.
Lire correctement les champs
Chaque entrée contient généralement :
- Date pour la date et l’heure ;
- Modified by pour le compte Central ayant exécuté l’action ;
- Item type pour la classe d’objet concernée ;
- Item modified pour l’objet concret ;
- Description pour des détails supplémentaires ;
- IP address pour l’adresse source de l’action.
Modified by fournit peu d’informations avec des comptes partagés. C’est précisément pourquoi chaque personne doit avoir son propre compte administrateur. Les actions API restent attribuables à l’identité technique concernée lorsque chaque intégration possède son propre identifiant.
Procéder dans le bon ordre
Lors d’une modification suspecte, on commence par délimiter la période. Central affiche par défaut les sept derniers jours et permet d’étendre la période jusqu’à 90 jours. Après toute modification de date ou de terme de recherche, il faut sélectionner Update.
La recherche est volontairement limitée. Elle convient surtout pour :
- l’adresse IP depuis laquelle une modification a été effectuée ;
- la valeur de Modified by ;
- l’association d’un terme de recherche et d’une période choisie.
Les modifications liées sont ensuite examinées comme une séquence. Une exclusion globale peut par exemple faire suite à une connexion, à une modification de rôle, à un changement de stratégie et à la fermeture d’une alerte. Une entrée isolée n’explique pas ce contexte.
Utiliser correctement l’export
Central propose CSV et PDF. Une distinction importante s’applique :
- current view reprend la vue et les filtres actuellement sélectionnés ;
- past 90 days exporte toute la période de 90 jours. Un filtre de recherche peut s’appliquer, mais pas la période choisie dans le portail.
L’export se lance à droite de la page Audit Logs via Export. Dans le menu déroulant, on choisit consciemment la vue actuelle ou l’export sur 90 jours ainsi que le format requis. Avant de cliquer, il faut relire le terme de recherche et la vue pour ne pas archiver par erreur un fichier filtré comme s’il s’agissait du journal complet.
Après l’export, le fichier reçoit immédiatement un nom explicite comprenant par exemple le tenant, la période et la date de création. Des noms génériques comme audit.csv ne doivent pas être conservés tels quels dans un dossier commun.
CSV convient au filtrage, à la corrélation et au traitement automatisé. PDF est utile pour joindre un instantané inchangé à un ticket ou à une validation. Pour une conservation probante, on documente en plus l’empreinte du fichier exporté et on protège l’original contre l’écriture.
Conservation opérationnelle
Un export mensuel représente la solution minimale lorsqu’aucun SIEM n’est connecté. La période exportée chevauche celle du cycle précédent afin qu’un job défaillant ou une clôture tardive ne crée aucune lacune. Les doublons peuvent être supprimés ultérieurement, les entrées manquantes ne peuvent pas être reconstruites.
Dans les environnements plus importants, on utilise l’API Sophos Central. L’identité technique reçoit uniquement le rôle nécessaire et fait l’objet d’une surveillance et d’une rotation.
Une politique de conservation pertinente définit :
- l’équipe responsable et le lieu de stockage ;
- la durée de conservation selon les exigences internes et légales ;
- la protection des accès et l’immutabilité ;
- la synchronisation horaire ;
- le test des recherches et de la restauration ;
- la procédure en cas d’échec de l’export.
Contrôles importants
L’Audit Log ne doit pas être consulté uniquement lors d’un incident. Des contrôles réguliers ciblent notamment :
- les administrateurs ajoutés ou supprimés ;
- l’attribution de Super Admin et de rôles personnalisés ;
- la création et la suppression d’API Credentials ;
- les modifications de la MFA, de la connexion fédérée et des sources d’annuaire ;
- les exclusions globales, Tamper Protection et les changements de stratégie ;
- les modifications automatiques de l’Account Health Check ;
- les migrations d’appareils ou de tenants ;
- l’activation de Remote Assistance.
Après Fix automatically dans l’Account Health Check, on contrôle les modifications dans l’Audit Log. Un score vert ne prouve pas à lui seul que la modification convient à l’environnement d’exploitation.
Problèmes fréquents
La modification attendue est absente
On vérifie d’abord la période, le fuseau horaire, le filtre de recherche et Update. Il faut ensuite déterminer si l’action a réellement été exécutée dans ce tenant ou depuis un contexte Enterprise, partenaire ou client différent.
L’export contient plus de données que la vue
Avec past 90 days, la période choisie dans le portail ne s’applique pas comme avec current view. Pour une conservation étroitement délimitée, on exporte la vue actuelle puis on vérifie son contenu.
Le nom de l’administrateur n’est pas univoque
Les comptes partagés doivent être supprimés. Chaque accès technique dispose de son propre API Credential. Avec une connexion fédérée, on corrèle aussi les journaux de connexion de l’IdP.
L’accès à l’audit est absent
Pour un rôle personnalisé, on vérifie si l’accès aux journaux et rapports sensibles est activé. Si l’option manque complètement, un Super Admin doit contrôler l’attribution du rôle.