Podcast – Les logs, c’est quoi exactement — et pourquoi ça peut tout changer en cas d’incident ?

On en parle souvent comme d'une contrainte technique, d'une case à cocher dans un audit de conformité. Pourtant, les logs sont probablement l'un des outils les plus sous-estimés de la cybersécurité. Pour creuser le sujet, j'ai reçu Sophie Baudin, ingénieure chez Access Ingénierie Informatique et Jules Bozouklian, responsable technique cybersécurité OT chez Eiffage Énergie Systèmes — deux entités du groupe Eiffage avec des approches complémentaires : l'une ancrée dans le monde IT, l'autre dans les systèmes industriels.

Un log, c’est d’abord une histoire. Sophie le résume bien : un log, c’est une ligne de texte qui raconte ce qui s’est passé dans un système. Connexion réussie, tentative d’accès refusée, élévation de droits, erreur critique. Pour être utile, un log doit répondre à cinq questions — qui, quoi, quand, où et comment. Sans ça, ce n’est pas une preuve, c’est du bruit.

Ou directement sur votre plateforme d’écoute préférée : https://smartlink.ausha.co/incyber-voices/logs-dans-it-ot-ce-que-vos-systemes-savent-de-vous

Et c’est là que ça se complique. En IT, le problème n’est pas le manque de logs, c’est l’excès. Des milliers de lignes générées chaque jour, dans lesquelles il faut repérer les trois signaux qui comptent vraiment. Les outils SIEM sont là pour corréler tout ça — détecter, par exemple, qu’un échec de connexion à 2h du matin suivi d’une élévation de privilèges sur l’Active Directory n’est probablement pas anodin.

Du côté de l’OT, on part de plus loin

Jules le dit clairement : sur des systèmes industriels vieux de quinze ou vingt ans, la journalisation n’a tout simplement pas été pensée. Les automates, capteurs et actionneurs de cette génération ne produisent parfois aucune trace. Sur les systèmes plus récents, c’est différent — la journalisation est devenue un standard — mais un autre problème apparaît : les formats propriétaires. Chaque constructeur a son dialecte, ce qui rend l’interconnexion avec un SIEM complexe.

L’attaque de la station de traitement d’eau en Floride, citée dans l’épisode, illustre bien ce qui peut arriver sans stratégie de détection : un attaquant s’est connecté via un accès distant non sécurisé et a modifié des paramètres chimiques du process. C’est un opérateur sur site qui a remarqué l’anomalie à temps, pas un système d’alerte, pas des logs mais bien le hasard.

Collecter ne suffit pas

C’est peut-être le point le plus important de l’échange. Avoir un puits de logs, c’est bien. Ne pas les exploiter, c’est construire une bibliothèque sans jamais l’ouvrir. Les logs doivent être archivés, centralisés sur un segment sécurisé, et surtout analysés en continu. Avant un incident pour détecter, pendant pour contenir, après pour prouver et progresser.

Pour une organisation qui part de zéro, Sophie conseille d’appliquer la règle des 80/20 : se concentrer d’abord sur trois sources critiques — l’Active Directory, le pare-feu et le VPN. Pas besoin de tout surveiller d’un coup. L’important, c’est de commencer, et de commencer bien.

Jules ajoute une étape souvent oubliée côté OT : avant même de centraliser quoi que ce soit, vérifier que la journalisation est bien activée. Beaucoup d’équipements industriels en sont capables mais ne le font pas par défaut.

Ce qu’on retient

Des logs bien exploités ne vous disent pas seulement d’où vous venez. Ils vous indiquent aussi les dangers qui se présentent maintenant. Ce n’est pas une contrainte réglementaire. C’est un outil de visibilité — en temps réel, et a posteriori. La question n’est pas de savoir si vous allez un jour en avoir besoin, mais si vous serez prêts quand ce moment arrivera.