Lorsque survient l’incident, les équipes de réponse sont régulièrement confrontées au même obstacle : le manque de journaux exploitables. Entre absence totale de logs et mauvaise configuration, les entreprises sont souvent bien plus aveugles qu’elles ne le croient… jusqu’à l’incident !
Durant un incident de cybersécurité, les journaux d’événements sont l’une des principales sources d’information des analystes chargés de déterminer la nature et l’impact de l’incident.
Et pourtant, cette matière première est bien souvent défaillante, voire inexistante !
La majorité des incident responders n’en fait d’ailleurs pas un secret : leur intervention pourrait généralement être raccourcie de plusieurs jours si les bons journaux, les bonnes informations, leur étaient d’emblée disponibles.
Le plus étonnant est que, bien souvent, les administrateurs système de l’entreprise victime découvrent eux aussi qu’ils manquent cruellement de journaux !
Résultat : les analyses forensiques durent beaucoup plus longtemps qu’elles ne le devraient (ce qui se traduit par un surcout évident de l’intervention, que l’équipe soit interne ou externe), et parfois même ne peuvent aboutir, par manque de données exploitables (parce que les bonnes informations ne sont pas conservées, ou parce que les journaux ne sont pas archivés sur une durée suffisante et ont été écrasés)
La faute aux configurations par défaut
Comment en arrive-t-on là ? Essentiellement parce que peu d’entreprises mettent en œuvre une véritable stratégie de journalisation. Elles se contentent bien souvent des configurations par défaut, pour chaque produit, qui génère une certaine quantité de journaux en ne conservant que les informations les plus communément utiles au « client type » de l’éditeur. Il s’agit alors du plus petit dénominateur commun, qui ne correspondra pas toujours aux besoins particuliers de l’entreprise.
Et puis surtout, chaque produit génère ses journaux dans son coin, sans centralisation (et il n’est même pas ici question de parler de corrélation, mais bien uniquement de centralisation !).
Ainsi lorsque survient l’incident, les équipes de la DSI sont rarement préparées à répondre aux requêtes de l’équipe de réponse à incident : « À quelle machine et quel utilisateur correspondait l’IP interne xx.xx.xx.xx le 15 mars 2020 à 19 h 12 ? », ou « Quelles machines internes ont contactées telle IP publique durant les 90 derniers jours ». Ou encore « À quelles ressources (machines, fichiers, services…) s’est connecté tel compte administrateur ce mois-ci ? ». Et la meilleure : « Quelle est la liste de toutes les ressources où est utilisé tel compte de service ? ».
Le cas particulier des utilisateurs privilégiés
L’absence « naturelle » de journaux est déjà suffisamment handicapante en soi. Mais lorsque s’y agrège l’autre grand classique des intrusions – la compromission de comptes d’administrateurs système ou de domaines -, cela devient beaucoup plus sérieux.
Car sans stratégie de journalisation digne de ce nom, il y a fort à parier que les comptes en question seront en mesure d’effacer ou de manipuler les journaux disponibles ! Alors à la pauvreté des journaux disponibles s’ajoute le risque de leur modification par l’attaquant, qui pourra y avoir retiré les informations les plus utiles à l’investigation ou, pire, modifié certaines pour faire perdre du temps aux investigateurs !
Une bonne stratégie de journalisation
Pour éviter de tels écueils, il est essentiel de pouvoir s’appuyer sur une stratégie de journalisation efficace. Celle-ci pourra varier en fonction de l’entreprise concernée et de la sensibilité de son Système d’Information, mais elle comprendra à minima un audit préalable des systèmes Windows afin de configurer les journaux d’événements (ne pas tout conserver, activer les événements les plus utiles à l’analyse forensique tels que l’ouverture de sessions distantes).
Cet audit sera suivi dans l’idéal d’une réflexion sur l’agrégation des logs (Windows, Linux et différents systèmes de routage) au sein d’un « puits de logs » déporté (une étape importante pour éviter leur modification par l’attaquant).
De l’avis des professionnels de la réponse à incidents, disposer d’emblée d’une interface unique permettant de lancer des requêtes sur l’ensemble des logs (systèmes, équipements de filtrage, etc.) permet de multiplier l’efficacité de leurs actions et de raccourcir le temps d’intervention de plusieurs jours.
Il restera ensuite à se préoccuper des comptes à privilèges.
Pour ces derniers une surveillance particulière est nécessaire. Dans un premier temps il est important de s’assurer que l’on journalise bien un maximum d’événements concernant les actions prises par les administrateurs, au-delà de ce qui est collecté pour les utilisateurs classiques. Des centaines d’événements critiques peuvent ainsi passer à la trappe sans une configuration minutieuse.
L’objectif ici est de disposer de suffisamment d’événements pour pouvoir retracer une session complète et déterminer aisément les actions prises par un compte administrateur à travers différents services (pare-feu, proxy, IDS, serveur de fichiers…).
Et le tout sur une durée plus longue que celle communément retenue par chaque équipement individuellement. Une solution dédiée permettra par exemple de conserver à part les logs de pare-feu, de proxy, des différents systèmes, sur plus d’un an pour les administrateurs système, alors qu’ils sont écrasés tous les 90 jours sur les systèmes eux-mêmes.
Et la cerise sur le gâteau : mettre en œuvre une telle stratégie de journalisation permettra non seulement, en temps de crise, d’être en mesure de réagir plus vite et plus efficacement, mais aussi, au quotidien, de résoudre plus rapidement et plus facilement les problèmes d’exploitation !
