Que reste-t-il d’un incident de sécurité une fois le site nettoyé et le prestataire remplacé ? Trop souvent, la réponse est : rien de documenté. Le site fonctionne à nouveau, la faille semble corrigée, et la connaissance accumulée pendant la gestion de crise part avec l’équipe qui l’a acquise, laissant la suivante repartir de zéro en cas de récidive.
Ce qui disparaît en premier : le journal des événements
Les journaux d’accès du serveur, les journaux d’erreurs PHP et l’historique des fichiers modifiés pendant l’incident constituent la matière première de toute investigation. Une fois le nettoyage terminé, ces journaux sont souvent écrasés par la rotation automatique du serveur ou simplement ignorés, alors qu’ils permettent de reconstituer le point d’entrée initial, la durée réelle de la compromission et l’étendue des fichiers touchés.
Conserver une copie horodatée de ces journaux, extraite au moment de la détection et avant toute action de nettoyage, devrait faire partie du protocole de réponse à incident au même titre que le nettoyage lui-même.
Le dossier à constituer avant tout transfert
- Une chronologie des faits : date de détection, indicateurs observés, date estimée de compromission initiale si elle a pu être établie.
- La liste des fichiers modifiés ou ajoutés de façon malveillante, avec leur contenu ou une empreinte de hachage, conservée même après suppression du site en production.
- Le vecteur d’entrée identifié, avec le niveau de certitude associé : une extension vulnérable clairement identifiée n’a pas la même valeur qu’une hypothèse non confirmée.
- Chaque correctif appliqué, avec sa justification technique précise, distincte d’une simple mention « faille corrigée » sans détail exploitable par la suite.
- Les comptes utilisateurs créés ou modifiés pendant l’incident, y compris ceux qui ont été supprimés, avec leur date de création si elle a pu être retrouvée.
Pourquoi la raison du correctif compte autant que le correctif
Un correctif appliqué sans documentation de sa raison d’être devient, quelques mois plus tard, un mystère pour quiconque reprend le projet : une capacité retirée à un rôle, une route d’API désactivée, un fichier renommé sans explication risquent d’être remis en cause ou annulés par erreur, faute de savoir qu’ils répondaient à un incident précis. La documentation du pourquoi protège le correctif lui-même dans la durée, bien après le départ du prestataire qui l’a mis en place.
Un correctif sans trace de sa raison d’être a une durée de vie limitée à la mémoire de la personne qui l’a écrit.
Ce que ce dossier permet à l’équipe suivante
Une nouvelle équipe qui reprend un projet après un incident, avec ce dossier en main, peut vérifier directement si le vecteur d’entrée initial a bien été corrigé, plutôt que de devoir relancer un audit complet pour retrouver une information déjà établie. Elle peut aussi identifier plus vite une récidive éventuelle, en comparant les nouveaux symptômes à ceux déjà consignés, plutôt que de repartir d’une page blanche.
Le moment précis où ce dossier doit être constitué
Attendre la fin officielle de la mission pour rassembler ces éléments est presque toujours trop tard : les journaux ont déjà tourné, les fichiers malveillants ont été supprimés sans copie de sauvegarde, et la mémoire précise des étapes de diagnostic s’est déjà estompée. La constitution du dossier devrait démarrer dès la détection de l’incident, en parallèle du nettoyage lui-même, plutôt qu’après coup sous forme de reconstitution approximative destinée uniquement à justifier une facture.
Ce que ce dossier n’a pas besoin de contenir
Un dossier de transfert utile reste concis et factuel. Il n’a pas vocation à couvrir la communication tenue avec le client final pendant la crise, ni les échanges internes sur la répartition des responsabilités entre équipes. Ces éléments relèvent d’un autre registre, souvent contractuel, et leur mélange avec la documentation technique de l’incident nuit à la lisibilité de cette dernière pour l’équipe qui reprend le projet.
Notre verdict
Un incident de sécurité correctement traité produit deux résultats distincts : un site nettoyé, et un dossier de preuves et de correctifs exploitable par quiconque reprendra le projet ensuite. Le premier sans le second laisse la connaissance de l’incident disparaître avec la personne ou l’équipe qui l’a géré, ce qui expose le projet suivant au même risque, dans les mêmes conditions d’ignorance.
