Lorsqu’une cyberattaque touche le serveur d’une entreprise, la première question n’est presque jamais de savoir si quelque chose a mal tourné. Les équipes doivent déterminer ce qui s’est passé, quand l’attaque a commencé, quels comptes et systèmes ont été impliqués, quelles données ont été consultées et si un attaquant y a encore accès.
Ces réponses dépendent des journaux de sécurité. Un journal ne constitue pas automatiquement une preuve utile simplement parce qu’il existe. Un enregistrement incomplet, un horodatage incorrect ou un journal pouvant être modifié par le même administrateur à l’origine de l’événement peut laisser les enquêteurs avec une liste de soupçons plutôt qu’une chronologie défendable.
Une journalisation efficace facilite la réponse aux incidents, les examens juridiques et réglementaires, le retour d’expérience opérationnel et les décisions de récupération. Elle aide également l’entreprise à distinguer un système de production compromis d’un point de récupération digne de confiance.
Commencez par les événements qui révèlent le parcours de l’attaquant
Le jeu d’événements pertinent varie selon le système d’exploitation, l’application et l’infrastructure, mais l’objectif reste le même : consigner les actions qui révèlent l’accès initial, l’élévation de privilèges, les mouvements latéraux, la persistance, l’accès aux données et les tentatives de dissimulation ou de destruction des preuves.
Événements d’authentification et d’identité
Consignez les connexions réussies et échouées sur les serveurs, les services d’annuaire, les VPN, les consoles cloud, les outils d’administration à distance et les applications importantes. Les informations utiles comprennent le compte utilisé, la méthode d’authentification, l’adresse source, le système cible, le résultat et, lorsqu’elle est disponible, la raison de l’échec.
Ne limitez pas cette collecte aux utilisateurs humains. Les comptes de service, identités de tâches planifiées, clés d’API, certificats machine et identités d’application peuvent être détournés aussi efficacement que les comptes nominatifs. Les changements de mot de passe, événements d’authentification multifacteur, émissions de jetons, créations de session, fins de session et verrouillages de compte doivent également être conservés.
Modifications des privilèges et des comptes
Les changements de privilèges marquent souvent le moment où une intrusion devient nettement plus dangereuse. Consignez les ajouts aux rôles d’administrateur, root, administrateur de domaine, propriétaire de base de données et administrateur cloud. Enregistrez les modifications des fichiers sudoers, des appartenances aux groupes, des autorisations déléguées, des politiques d’accès et des droits des comptes de service.
La création, la suppression, la désactivation et la réactivation des comptes doivent être visibles, tout comme l’identité ayant effectué l’action. Il en va de même pour les modifications des identifiants d’API, clés SSH, jetons d’accès, certificats et paramètres de réinitialisation des mots de passe. Un attaquant peut créer un nouveau compte plutôt que de continuer à utiliser celui qui a servi à l’accès initial.
Exécution des processus et persistance
Les journaux d’exécution des processus peuvent montrer comment un attaquant est passé d’une connexion légitime à une activité malveillante. Lorsque cela est possible, capturez le nom de l’exécutable, la ligne de commande complète, le processus parent, l’utilisateur ou l’identité du service, l’identifiant du processus, l’heure de démarrage et l’hôte. La création de fichiers, l’utilisation d’interpréteurs de scripts, les tâches planifiées, les tâches cron, les services, les éléments de démarrage, les clés d’exécution du registre et les commandes d’administration à distance peuvent révéler des mécanismes de persistance.
Le détail de la ligne de commande est important. Un enregistrement indiquant que powershell.exe a été exécuté est moins utile qu’un enregistrement montrant le script, les paramètres, le processus parent et la destination contactée. La journalisation doit être conciliée avec la confidentialité et la gestion des secrets : les lignes de commande peuvent contenir des mots de passe, des jetons ou des données personnelles. Leur accès nécessite donc des contrôles appropriés.
Activité de configuration, de pare-feu, de VPN et de DNS
Les modifications de configuration peuvent expliquer à la fois comment un attaquant est entré et pourquoi les contrôles habituels ont cessé de fonctionner. Consignez les changements des paramètres de sécurité du système d’exploitation, de la protection des terminaux, des règles de pare-feu, des paramètres d’accès distant, des politiques d’annuaire, du routage, des paramètres de proxy et des groupes de sécurité réseau.
Les journaux de pare-feu doivent afficher les connexions autorisées et refusées, les adresses source et destination, les ports, les protocoles, l’interface ou la zone, ainsi que la règle ayant traité le trafic. Les journaux VPN doivent inclure les heures de connexion et de déconnexion, l’adresse attribuée, le compte, les informations sur l’appareil, le résultat de l’authentification et la passerelle. Ces enregistrements peuvent relier une source externe à une activité apparaissant ensuite sur un serveur interne.
Les requêtes DNS sont souvent négligées. Elles peuvent révéler une infrastructure de commande et contrôle, des emplacements de préparation, des domaines récemment enregistrés et des tentatives d’accès à du stockage cloud ou à des services de transfert de données. Conservez l’hôte demandeur, le nom interrogé, le type d’enregistrement, la réponse, le résolveur et l’horodatage. Le DNS seul ne prouve pas une compromission, mais il peut compléter une séquence que d’autres journaux ne montrent que partiellement.
Activité Web, bases de données et administrateurs cloud
Les journaux d’accès Web doivent capturer l’heure de la requête, l’adresse source, l’hôte, la méthode, le chemin, le code d’état, la taille de la réponse, ainsi que l’identifiant utilisateur ou de session lorsque cela est pertinent. Les proxies inverses et les pare-feu applicatifs peuvent apporter un contexte supplémentaire sur les requêtes bloquées, les règles déclenchées et les adresses client transmises. Préservez soigneusement les informations originales sur la source ; les en-têtes de proxy ne doivent pas être considérés comme fiables sauf si la chaîne de proxies est maîtrisée.
Pour les bases de données, consignez les connexions, les échecs de connexion, les changements de privilèges, les modifications de schéma, les commandes administratives, les requêtes impliquant des tables sensibles, les exportations, les sauvegardes, les restaurations et les changements des paramètres d’audit. La journalisation complète des requêtes peut être coûteuse ou contenir des données sensibles. Les organisations doivent donc définir quelles bases de données, actions et catégories de données nécessitent une capture détaillée.
Les plans de contrôle cloud ont besoin de leur propre piste d’audit. Consignez les actions des administrateurs concernant la gestion des identités et des accès, le stockage, les machines virtuelles, les groupes de sécurité, les clés, les paramètres de journalisation, les instantanés, les routes réseau ainsi que les politiques de suppression ou de conservation. Le journal d’une charge de travail cloud peut montrer ce qui s’est passé à l’intérieur d’un serveur, tandis que le journal d’administration du fournisseur indique qui a modifié l’environnement autour de celui-ci.
Les opérations de sauvegarde sont des événements de sécurité
Les sauvegardes ne doivent pas être considérées comme une préoccupation distincte de la journalisation des incidents. Consignez le début et la fin des tâches de sauvegarde, les systèmes sources, les données sélectionnées, le résultat, l’identité de l’opérateur ou du service, la destination, les changements de conservation, les demandes de suppression, les erreurs de chiffrement ou de clé, les demandes de restauration et leurs résultats.
Un attaquant qui ne peut pas immédiatement chiffrer ou voler les données de production peut tenter de supprimer les points de récupération, de raccourcir la durée de conservation, de désactiver les tâches ou de compromettre les identifiants utilisés pour gérer les sauvegardes. Ces actions doivent apparaître dans une piste d’audit qui n’est pas contrôlée uniquement par l’administrateur de production.
Les champs qui transforment une entrée de journal en preuve
Le volume d’événements n’est pas synonyme de valeur investigative. Chaque événement important doit répondre à quelques questions : quand s’est-il produit, d’où provenait-il, quelle était sa cible, qui ou quoi l’a exécuté, quelle action a eu lieu et a-t-elle réussi ?
- Horodatage synchronisé : utilisez une source temporelle cohérente et indiquez le fuseau horaire ou le décalage UTC. Incluez une heure précise de l’événement lorsque la plateforme le permet, ainsi que l’heure de collecte lorsque ces deux valeurs diffèrent.
- Source et destination : capturez les adresses IP source et destination, les ports, les noms d’hôte, les interfaces, les zones, les URL, les objets de base de données ou les ressources cloud, selon le cas. Enregistrez le contexte NAT ou proxy lorsqu’il influence l’attribution.
- Identité : identifiez l’utilisateur humain, le compte de service, le processus, l’appareil, le certificat, le jeton ou le client API. Un simple nom d’affichage ne suffit pas s’il ne peut pas être associé à une identité unique.
- Action : indiquez ce qui a été tenté : connexion, attribution de rôle, lancement de processus, accès à un fichier, modification de règle, exportation, suppression ou restauration.
- Résultat : distinguez la réussite, l’échec, le refus, l’exécution partielle et l’erreur. Les événements en échec peuvent révéler des reconnaissances et des tentatives répétées ; les événements réussis montrent l’accès obtenu.
- Identifiants de corrélation : préservez les identifiants de requête, de session, de trace, de transaction, de processus et de tâche. Ils permettent aux enquêteurs de relier une requête de proxy à un événement applicatif, une requête de base de données et une action ultérieure.
- Détails de l’objet et des changements : pour les modifications de configuration ou d’accès, consignez la ressource affectée et, lorsque cela est possible, les anciennes et nouvelles valeurs.
Les identifiants de corrélation sont particulièrement précieux dans les environnements distribués. Un utilisateur peut s’authentifier via un fournisseur d’identité, accéder à un VPN, se connecter à un service Web, déclencher un processus applicatif et provoquer une requête de base de données. Sans identifiants communs ou correspondance fiable entre les systèmes, la chronologie devient un exercice manuel fondé sur des suppositions.
Les organisations doivent documenter les sources horaires, la dérive attendue et les formats d’horodatage. Une différence de cinq minutes entre un pare-feu et un serveur peut suffire à inverser l’ordre des événements lors d’une attaque courte. Les collecteurs de journaux doivent préserver l’horodatage original plutôt que le remplacer silencieusement par l’heure d’arrivée de l’événement.
Définissez un jeu minimal d’événements et une liste de contrôle d’enquête
Chaque entreprise devrait tenir à jour une base de référence écrite pour la journalisation de ses serveurs et systèmes critiques. Au minimum, elle devrait couvrir l’authentification, les changements de privilèges et de comptes, l’exécution des processus, les modifications de configuration, les accès réseau, le DNS, l’activité Web et celle des bases de données, l’administration cloud et les opérations de sauvegarde. Cette base doit identifier le propriétaire du système, la source de journal attendue, la méthode de collecte, la durée de conservation et la personne chargée d’examiner les événements graves. Une référence pratique pour créer une liste de contrôle des journaux de sécurité et des événements de réponse aux incidents peut aider les équipes à identifier les lacunes avant qu’un incident ne survienne.
La base de référence n’est pas une tâche de configuration ponctuelle. Examinez-la après une mise à jour logicielle majeure, une migration, l’adoption d’un nouveau service cloud, une acquisition ou un incident. Vérifiez que les événements prévus sur le papier sont effectivement générés, collectés, consultables et conservés pendant la durée requise.
Centralisez la collecte sans créer de point de défaillance unique
La collecte centralisée accélère les investigations, car les analystes peuvent effectuer des recherches dans les serveurs, les systèmes d’identité, les réseaux et les applications à partir d’une seule chronologie. Elle réduit également le risque qu’un attaquant compromettant un serveur puisse effacer toutes les traces de son activité.
Envoyez les journaux vers un niveau de collecte dédié ou une plateforme de gestion des informations et des événements de sécurité. Utilisez un transport sécurisé, limitez les personnes autorisées à soumettre ou modifier les enregistrements, surveillez l’état des collecteurs et déclenchez une alerte lorsqu’une source importante cesse d’envoyer des données. Une défaillance silencieuse de la journalisation peut être aussi grave qu’une alerte qui n’a jamais été configurée.
La centralisation ne doit pas signifier que chaque système dispose d’un accès illimité à tous les journaux. Séparez les privilèges d’ingestion, de recherche, d’administration et de suppression. Conservez une trace des accès aux journaux et des activités d’exportation, en particulier lorsque les preuves peuvent être partagées avec un prestataire d’analyse forensique, un assureur, un régulateur ou les autorités judiciaires.
Conservation et résistance à la falsification
La durée de conservation doit tenir compte du temps pendant lequel un attaquant peut rester indétecté, des obligations légales, des exigences contractuelles et de la vitesse des investigations internes. Une conservation trop courte peut supprimer les preuves nécessaires pour comprendre l’accès initial. Une conservation excessive sans contrôle d’accès peut accroître les risques liés à la confidentialité et à la sécurité.
Utilisez, lorsque cela est approprié, un stockage en ajout uniquement ou immuable, protégez le service de journalisation avec des identifiants distincts et empêchez les administrateurs de production de modifier ou supprimer les enregistrements historiques. Le hachage, les enregistrements signés, le stockage à écriture unique et les copies indépendantes peuvent renforcer la détection des falsifications. Le contrôle exact doit correspondre à la sensibilité de l’environnement, mais le principe est simple : la personne capable de compromettre la production ne doit pas pouvoir réécrire les preuves qui la concernent.
Séparez la production des preuves
Les journaux ne doivent pas dépendre entièrement de l’état des systèmes qu’ils surveillent. Si un attaquant obtient un accès administrateur à un serveur, les journaux locaux peuvent être supprimés, modifiés ou chiffrés. Envoyez des copies hors de l’hôte et, pour les systèmes critiques, maintenez une frontière administrative distincte pour l’infrastructure de collecte et de conservation.
Protégez également la plateforme de journalisation avec une authentification multifacteur, une administration limitée, une segmentation réseau et une surveillance indépendante. Sauvegardez sa configuration et, lorsque cela est approprié, ses données. Si la plateforme de journalisation est indisponible pendant un incident, l’organisation peut perdre à la fois sa visibilité et sa capacité à prouver ce qui a été collecté.
Comment les agences peuvent isoler les preuves entre leurs clients
Les fournisseurs de services managés, agences informatiques et équipes de sécurité qui accompagnent plusieurs entreprises ont besoin d’un niveau de discipline supplémentaire. Les preuves doivent être séparées par client, et pas seulement identifiées par un champ qu’un analyste pourrait filtrer incorrectement par accident.
Utilisez des environnements, zones de stockage ou domaines d’accès distincts pour chaque client, avec des rôles séparés et des autorisations fondées sur le moindre privilège. Les identifiants client doivent être inclus dans les métadonnées des événements, mais ils ne doivent pas constituer l’unique contrôle empêchant les accès entre clients. La recherche, les tableaux de bord, les exportations, les alertes et les politiques de conservation doivent être testés afin de vérifier l’isolation des environnements.
Conservez une piste d’audit indiquant quel membre du personnel a accédé aux preuves de quel client et à quel moment. Définissez la manière dont les preuves sont préservées pendant une enquête, transférées, puis supprimées. Si un collecteur partagé est utilisé, documentez les contrôles techniques et procéduraux empêchant les journaux d’un client d’apparaître dans l’enquête d’un autre.
Les agences doivent également convenir à l’avance de la personne autorisée à valider la collecte, le confinement, la suspension de comptes, la restauration et la divulgation. Lors d’une attaque, une autorité mal définie peut retarder l’action tandis que les preuves continuent de disparaître.
Utilisez les journaux pour reconstituer le cycle de vie de l’attaque
Une investigation utile est une chronologie, pas une collection d’événements alarmants. Commencez par le premier signal crédible et vérifiez chaque étape à partir de plusieurs sources.
- Accès initial : recherchez les réussites d’authentification inhabituelles, les échecs répétés suivis d’une réussite, les services exposés, les sessions VPN suspectes, les requêtes Web exploitant des chemins vulnérables, les nouveaux outils distants et les connexions cloud inattendues. Comparez la source, l’appareil, la zone géographique, l’heure et la méthode d’authentification avec l’activité normale.
- Exécution et élévation de privilèges : identifiez le premier processus, script, commande ou action applicative suspect. Tracez ensuite les changements de privilèges locaux, d’annuaire ou cloud. Demandez-vous si le compte disposait déjà de droits excessifs ou si l’attaquant a créé une nouvelle voie vers l’administration.
- Mouvement latéral : suivez les enregistrements d’authentification et de réseau depuis le premier hôte vers les autres serveurs, partages de fichiers, bases de données, hyperviseurs et systèmes de gestion. Recherchez le même compte, la même adresse source, le même outil ou processus sur plusieurs systèmes.
- Persistance : recherchez les nouveaux comptes, tâches planifiées, services, entrées de démarrage, clés SSH, jetons d’API, politiques d’accès modifiées et paramètres d’administration à distance altérés. La persistance peut être créée plusieurs jours avant le vol ou le chiffrement des données.
- Accès aux données et impact : corrélez les requêtes Web, les accès aux bases de données, les lectures de fichiers, la création d’archives, les exportations, l’activité du stockage cloud et les connexions sortantes inhabituelles. Déterminez ce qui a été consulté, et pas seulement ce qui était potentiellement disponible.
- Évasion des défenses : vérifiez l’arrêt des agents, l’effacement des journaux d’événements, la désactivation des politiques d’audit, la modification des règles de pare-feu, la suppression des instantanés, l’altération des calendriers de sauvegarde et les échecs de collecte des journaux. Ces événements peuvent indiquer à la fois l’intention de l’attaquant et les limites des preuves disponibles.
La chronologie doit distinguer les faits observés des suppositions. Indiquez la source de chaque conclusion, préservez les journaux bruts pertinents et signalez les lacunes. Si un serveur était hors ligne ou si la journalisation était désactivée, dites-le clairement. Un rapport d’incident défendable est plus utile lorsqu’il reconnaît l’incertitude que lorsqu’il présente une heure exacte non étayée.
Questions à poser lors de l’examen des journaux après un incident
Utilisez des questions pratiques pour maintenir l’examen ciblé :
- Quel est le premier événement qui ne peut pas être expliqué par l’activité normale de l’entreprise ?
- Quel compte, service, appareil ou application exposée était impliqué en premier ?
- Le premier accès a-t-il réussi, ou les échecs répétés ont-ils révélé une préparation avant la compromission ?
- Quels privilèges ont changé après l’accès initial ?
- Quels processus, scripts, outils ou tâches planifiées sont apparus sur les systèmes touchés ?
- Quels hôtes internes le compte ou la source ont-ils ensuite contactés ?
- Des fichiers sensibles, tables de bases de données, boîtes mail ou objets de stockage cloud ont-ils été lus ou exportés ?
- L’attaquant a-t-il modifié les règles de pare-feu, les paramètres DNS, la journalisation, les politiques d’identité ou les opérations de sauvegarde ?
- Les horodatages de tous les systèmes pertinents sont-ils suffisamment synchronisés pour établir la séquence ?
- Quels journaux sont manquants, retardés, stockés localement ou potentiellement falsifiés ?
- Quels comptes, clés, jetons et sessions doivent être révoqués avant la récupération ?
- Quels systèmes ont été suffisamment examinés pour décider qu’une restauration est sûre ?
Le confinement et la préservation des preuves doivent être équilibrés. Déconnecter un serveur compromis peut empêcher d’autres dommages, mais l’arrêter ou l’effacer peut supprimer des preuves volatiles. Suivez une procédure d’incident approuvée et faites appel à un spécialiste de l’analyse forensique lorsque les faits peuvent avoir des conséquences juridiques, réglementaires ou assurantielles.
La récupération dépend d’un historique fiable
Les journaux peuvent montrer quand les systèmes ont été compromis, mais ils ne peuvent pas les réparer. La récupération nécessite une copie connue comme saine des données et de l’état du système, ainsi que la certitude que l’attaquant n’a pas modifié le processus de récupération.
Avant de restaurer, identifiez la première compromission présumée et considérez avec prudence les points de récupération créés par la suite. Examinez les journaux des tâches de sauvegarde, l’activité des administrateurs, les changements de conservation et les tests de restauration. Confirmez que les identifiants de sauvegarde n’ont pas été exposés, que les données de récupération sont complètes et que les systèmes restaurés ne se reconnecteront pas immédiatement à l’infrastructure de l’attaquant.
Les points de récupération propres doivent être conservés assez longtemps pour couvrir la durée probable de présence de l’attaquant et la période d’investigation. L’immuabilité pendant la fenêtre de conservation contribue à empêcher un attaquant de réécrire ou supprimer ces points après avoir obtenu un accès à la production. Le chiffrement protège les données en cas d’accès au stockage, tandis que la séparation des clés garantit que le fournisseur de stockage ne peut pas déchiffrer seul les données du client.
Pour les entreprises qui protègent les serveurs dont elles ont le contrôle, Safenix propose une sauvegarde externalisée chiffrée avec une clé que Safenix ne détient jamais, stockée en Allemagne et immuable pendant toute la durée de conservation. Le service est conçu pour les serveurs professionnels contrôlés par l’entreprise, et non pour les sites hébergés sur une plateforme mutualisée.
Après un incident, la restauration doit être testée dans un environnement isolé avant le basculement en production. Validez les applications, les comptes, les chemins réseau, les tâches planifiées, la surveillance et les contrôles de sécurité, puis renouvelez les identifiants et confirmez que la voie d’entrée d’origine est fermée. Les entreprises qui évaluent les moyens de conserver des points de récupération propres et de tester la restauration peuvent consulter les options de sauvegarde externalisée de serveurs Safenix.
Intégrez la journalisation à la planification de la résilience
Les journaux de sécurité sont les plus utiles lorsqu’ils sont conçus avant l’urgence. Documentez la base de référence des événements, synchronisez les horloges, centralisez la collecte, limitez les accès, séparez les preuves de la production et testez les procédures de conservation et de restauration.
La surveillance des serveurs peut identifier rapidement les comportements anormaux, tandis que les journaux d’audit fournissent les détails nécessaires pour reconstituer les décisions et les actions. Avec des points de récupération propres et protégés, ils offrent à l’entreprise les deux éléments dont une équipe de réponse aux incidents a le plus besoin : un récit fiable de ce qui s’est passé et un moyen plus sûr de reprendre son activité.