Le journal que personne ne lit

Éditorial

La plupart des systèmes journalisent ce qu'il est facile d'écrire, pas ce qu'il faudrait lire le jour d'un incident. Un journal ne se juge ni à son volume ni à sa conformité, mais à une seule capacité : répondre à la question « que s'est-il passé mardi ? ».

Mis à jour le 25 septembre 2026~27 min de lecture14 sections

papy cyber

→ Lire l’explication complète de la marmotte

Mardi, quatorze heures

Il existe une question qui départage toutes les politiques de journalisation, et elle n’est jamais posée pendant qu’on les rédige. Elle arrive plus tard, un jeudi en général, avec la simplicité désarmante des questions qui ruinent une soirée : « que s’est-il passé mardi ? »

Un compte a été utilisé depuis un pays où personne dans l’entreprise n’a jamais mis les pieds. Une facture est partie vers un IBAN d’une fraîcheur suspecte. Peu importe : quelqu’un veut savoir qui a fait quoi, sur quoi, avec quel résultat, et dans quel ordre. C’est à ce moment-là, et pas une minute avant, qu’on découvre ce que valent les journaux.

Le plus souvent, ils valent beaucoup de gigaoctets, collectés avec application et archivés avec dévotion. Ils contiennent la sonde de supervision toutes les trente secondes depuis trois ans, les avertissements de dépréciation d’une bibliothèque que plus personne n’ose mettre à jour, et les tentatives de connexion SSH d’une moitié de la planète, qui semble n’avoir rien de mieux à faire. Ils ne contiennent pas la réponse à la question.

Ce n’est pas un accident, c’est une œuvre : on a optimisé ce qui se mesure à la conception (le volume, la couverture, la case cochée) au détriment de ce qui ne se mesure qu’à l’usage. Un journal est un objet dont la valeur se révèle exclusivement le jour où l’on en a besoin, c’est-à-dire trop tard pour le corriger. En cela il ressemble à l’extincteur, au testament et au parapluie, avec cette différence que personne ne remplit un parapluie de confettis en espérant qu’il protège de la pluie.

Cet éditorial ne propose pas un outil : le marché en regorge, et chacun promet de « donner du sens à vos logs », aveu élégant qu’ils n’en avaient pas. Il propose un critère, qui suffit à disqualifier une bonne partie de ce qui s’écrit dans /var/log.

Deux journaux qui portent le même nom

Le mot « journalisation » désigne deux activités qui partagent les mêmes fichiers, les mêmes outils et parfois la même personne épuisée, mais pas le même but. On les confond comme on confond, au mariage, l’oncle qui fait un discours et celui qui a quelque chose à dire.

La journalisation réglementaire répond à une exigence venue d’ailleurs. Un référentiel, un contrat, un auditeur demandent que « les accès soient tracés ». Son critère de réussite est la preuve de son existence. L’auditeur demande un extrait, on le lui tend, il hoche la tête, le point est clos. Personne, dans cette liturgie, ne vérifie que l’extrait permettrait de comprendre quoi que ce soit. Ce n’est pas la question. La question était : existe-t-il ?

La journalisation utile répond à une exigence plus modeste et plus cruelle : pouvoir reconstituer. On pose une question précise sur une période précise, et les journaux répondent, ou avouent qu’ils ne savent pas, ce qui est déjà plus honnête que bien des témoins.

Les deux ne sont pas contradictoires. Elles sont indépendantes, et c’est pire. Un système peut être parfaitement conforme et parfaitement aveugle, comme un rapport d’activité peut être parfaitement relié et parfaitement vide. La raison n’a rien de mystérieux : la conformité a un calendrier (l’audit annuel), un visage (l’auditeur) et une sanction (l’écart), tandis que l’utilité n’a rien de tout cela, jusqu’au jour où elle a tout à la fois.

Les journaux sont donc conçus pour l’auditeur, qui vient tous les ans et prévient, plutôt que pour l’enquêteur, qui vient une fois et ne prévient pas. On s’habille pour la visite qu’on attend. C’est humain, et c’est bien le problème.

Les référentiels ne sont pas coupables, je le dis avant qu’on m’accuse d’avoir le mépris facile (je l’ai, mais sélectif). Les bons textes, ceux de l’ANSSI en particulier, parlent de finalité, de corrélation, d’horodatage, d’intégrité. C’est leur traduction en grille de contrôle qui les aplatit, comme on traduirait un poème en notice de montage. « Les journaux d’authentification sont-ils collectés ? » se coche en une minute. « Pourriez-vous établir, pour une session donnée, d’où elle venait et ce qu’elle a fait ensuite ? » ne se coche pas, n’apparaît donc pas dans la grille, et, n’y apparaissant pas, cesse d’exister.

On journalise ce qui est facile

Si l’on examine d’où viennent réellement les lignes d’un journal, on découvre une loi qui n’est écrite nulle part et s’applique partout, à la manière des lois de la gravitation et de la bureaucratie : on journalise ce que le logiciel journalise par défaut, plus ce que le développeur a eu besoin de voir pendant le débogage, moins ce qu’il a trouvé trop bavard.

Chacun de ces trois termes a sa logique. Aucune n’est celle de l’enquête. Le défaut de l’éditeur est calibré pour le support technique de l’éditeur. Il enregistre ce qui aide à diagnostiquer une panne du produit : démarrages, erreurs de configuration, exceptions, temps de réponse. Il enregistre beaucoup moins bien ce qui intéresse votre sécurité à vous, parce que ce n’est pas le problème que l’éditeur cherche à résoudre quand vous ouvrez un ticket. L’éditeur veut savoir si son logiciel va bien. Il est assez rare qu’il se demande si vous allez bien.

Le message de débogage est limpide pour son auteur pendant la semaine où il l’a écrit, et hermétique pour l’humanité entière ensuite. « Entering handler », « token OK », « retry 3 » : des cartes postales dont on aurait perdu la photo, et qui ne disent plus que « il fait beau ».

La suppression du bavardage est l’opération la plus lourde de conséquences, et elle est presque toujours faite pour de mauvaises raisons. Le volume coûte (en stockage, en licence, en temps d’indexation), donc on coupe ce qui pèse. Or ce qui pèse est souvent ce qui est fin, et ce qui est fin est souvent ce qui manquera. On garde les erreurs, qui sont rares et bruyantes, on jette les succès, qui sont nombreux et discrets. Mais un attaquant qui dispose d’identifiants valides ne produit aucune erreur. C’est même à cela qu’on le reconnaît, si l’on peut dire, puisqu’on ne le reconnaît pas. Il produit des succès.

C’est le point central de ce chapitre et il faut l’énoncer sans précautions oratoires : une journalisation calibrée sur les erreurs est aveugle aux usages légitimes détournés, qui sont précisément la forme la plus courante des compromissions sérieuses. Une connexion réussie avec le bon mot de passe, un export réussi avec les bons droits, une modification réussie de la règle de transfert du courrier du directeur financier : rien de tout cela n’est une erreur. Tout cela est un incident.

Le résultat ressemble au compte rendu d’une réunion rédigé par quelqu’un qui n’aurait noté que les pannes du vidéoprojecteur. Précis, horodaté, fidèle, et sans le moindre rapport avec les décisions prises.

Quatre questions, et seulement quatre

Pour sortir de là, on cesse de demander au système « qu’as-tu envie de raconter ? », question à laquelle il répond avec l’intarissable générosité d’un invité qui a trop bu. On se demande « que voudrai-je savoir le jour où tout aura mal tourné ? ». Pour la sécurité, cela tient presque toujours en quatre questions, ce qui est rassurant pour la mémoire et inquiétant pour l’existant.

Qui ? Quelle identité a agi. Pas « l’utilisateur », pas « le service », mais une identité précise, stable dans le temps, rattachable à une personne ou à un composant nommé. Cela suppose que l’identité soit portée jusqu’au journal, ce qui est moins évident qu’il n’y paraît. Une application qui se connecte à sa base avec un compte de service unique produit, côté base, un journal où tout le monde s’appelle app. Le « qui » a été perdu une couche plus haut, et aucune configuration de la base ne le ressuscitera. On ne retrouve pas un nom dans une foule qui porte un uniforme.

Quoi ? Quelle action, décrite dans le vocabulaire de l’enquête et non dans celui du code. « Création d’une règle de transfert », « changement du facteur d’authentification », « export de la table clients », « élévation de privilège ». Un journal qui dit POST /api/v2/rules 201 contient l’information, mais il faut la traduire, et un jeudi à dix-neuf heures l’érudition n’est pas la ressource la plus abondante.

Sur quoi ? Quel objet a été touché. C’est la question qu’on sacrifie le plus volontiers. Un journal qui dit « modification de configuration » sans dire laquelle atteste qu’il s’est passé quelque chose. On s’en doutait. C’est même pour cela qu’on était venu.

Avec quel résultat ? Succès, échec, refus, et la raison du refus. Et, pour les succès, ce qui a changé : l’ancienne valeur et la nouvelle, quand elles ne sont pas sensibles. Un changement de configuration qui tait l’état antérieur oblige à le retrouver ailleurs, en général dans une sauvegarde dont personne ne sait plus très bien de quand elle date, ni si elle date.

S’y ajoutent deux attributs qui ne sont pas des questions mais sans lesquels aucune question n’a de réponse : quand, avec une horloge fiable, et d’où, c’est-à-dire l’adresse, la machine ou la session d’origine.

Ces quatre questions ne sont pas de moi, rassurez-vous : on les trouve dans tous les guides sérieux, ce qui n’a jamais empêché personne de les ignorer. Leur intérêt est d’être un test. Prenez une ligne de vos journaux au hasard et interrogez-la. Si elle ne répond pas à trois des quatre questions, elle ne sert pas à l’enquête. Elle sert peut-être au diagnostic de performance, et c’est son droit, mais elle n’a pas à consommer le budget de la sécurité.

Le test appliqué à ses propres journaux

On peut se livrer à l’exercice sur une machine Linux ordinaire, en quelques minutes, sans rien casser. Les commandes suivantes sont en lecture seule ; elles montrent ce que le système est capable de dire d’une journée donnée.

# Nombre de lignes du journal système pour une journée précise
journalctl --since "2026-09-22 00:00" --until "2026-09-23 00:00" --no-pager | wc -l

# Les programmes les plus bavards ce jour-là
journalctl --since "2026-09-22" --until "2026-09-23" -o verbose --no-pager \
  | grep -o 'SYSLOG_IDENTIFIER=.*' | sort | uniq -c | sort -rn | head -15

# Les ouvertures de session réussies, qui sont en général ce qu'on cherche
journalctl --since "2026-09-22" --until "2026-09-23" --no-pager \
  | grep -iE 'accepted (password|publickey)|session opened'

Le premier chiffre est flatteur. Le podium est occupé par des composants dont personne n’a jamais relu une ligne. Le troisième résultat est court, et c’est le seul qui aurait servi. Le rapport entre les deux mesure ce que le système écrit pour lui-même et ce qu’il écrit pour vous. Il est rarement à votre avantage.

(Les noms de champs et la formulation des messages varient selon les distributions, les versions et la configuration de l’init et de son journal ; l’exercice est à adapter, pas à recopier.)

L’heure, cette donnée qu’on croit gratuite

Aucune enquête ne survit à des horloges fausses. C’est une banalité, et les banalités ont ceci de commun avec les impôts qu’on les connaît toutes et qu’on les découvre chaque année.

Reconstituer un incident, c’est mettre en ordre des événements venus de sources différentes. Si elles ne partagent pas la même heure, l’ordre est faux, et un ordre faux est pire qu’un ordre absent, parce qu’il produit une histoire cohérente et erronée. Une connexion qui semble postérieure à l’export qu’elle a permis ne ressemble plus à une cause. Elle ressemble à une coïncidence, et les coïncidences, on les classe.

Trois défauts reviennent, avec la ponctualité qui fait défaut aux horloges.

Les horloges non synchronisées. Une machine privée de synchronisation du temps dérive, doucement, sans méchanceté, comme un invité qui s’endort. L’écart est invisible au quotidien et ruineux le jour où l’on corrèle. Il n’est pas même constant : il grandit depuis la dernière correction, ce qui interdit de le compenser proprement après coup.

Les fuseaux mélangés. Une source écrit en UTC, une autre en heure locale, une troisième en heure locale sans le dire, et le changement d’heure saisonnier passe au milieu comme un chat sur un clavier. On obtient une heure qui se produit deux fois et une heure qui n’existe pas. La seule convention défendable pour un journal est l’UTC, écrite explicitement avec son décalage ; l’affichage en heure locale relève de l’interface, pas du stockage.

La précision insuffisante. Une horodatation à la seconde situe un événement dans la journée ; elle n’ordonne pas dix événements survenus dans la même seconde sur trois machines. Inutile de viser la microseconde. Il faut savoir quelle précision on a, et ne pas lui faire dire plus qu’elle ne sait.

# État de la synchronisation (lecture seule)
timedatectl status
# Sur les machines qui utilisent chrony
chronyc tracking

Ces vérifications prennent dix secondes. On ne les fait jamais avant l’incident et toujours pendant, c’est-à-dire au moment précis où elles ne servent plus qu’à mesurer l’ampleur de ce qu’on ne pourra pas prouver.

Intégrité : un journal que l’attaquant peut réécrire

Un journal qui reste sur la machine qu’il décrit souffre d’un défaut que les juristes appelleraient un conflit d’intérêts : il est sous le contrôle de celui qu’il est censé surveiller. Qui obtient les droits d’administration sur un serveur obtient, sans supplément, les droits d’écriture sur ses journaux. S’il efface tout, l’absence se voit. S’il retouche, on a confié la rédaction du procès-verbal au prévenu.

Deux réponses, complémentaires et imparfaites, ce qui définit assez bien une bonne réponse en sécurité.

Éloigner

La première consiste à faire sortir le journal de la machine le plus vite possible, vers un point de collecte que l’administrateur de la source ne contrôle pas. C’est la vraie raison d’être de la centralisation, bien avant le confort de la recherche : ce qui a été envoyé ailleurs avant la compromission ne peut plus être réécrit, quels que soient les droits acquis sur la source.

Encore faut-il que l’envoi soit rapide (un journal expédié une fois par nuit laisse à l’intrus une journée de liberté éditoriale), fiable (c’est sous charge ou sous attaque que les files débordent, donc les messages perdus en silence seront ceux de l’incident) et à sens unique (les sources écrivent, elles ne reviennent pas sur ce qu’elles ont dit).

Et encore faut-il que le point de collecte soit mieux protégé que les sources. Un SIEM administré avec le même compte que tout le reste n’est pas un tiers de confiance. C’est une copie supplémentaire, rangée dans le même tiroir que la clé du tiroir.

Sceller

La seconde réponse consiste à rendre la modification détectable, faute de pouvoir la rendre impossible. Le principe est ancien et élégant : chaque bloc de journal porte un condensat qui dépend du bloc précédent, de sorte que la retouche d’une ligne ancienne casse toute la chaîne à partir de ce point. Ce sont exactement les propriétés qu’on attend des constructions à base de hachage : on ne sait pas empêcher la réécriture, on sait la rendre visible. C’est la différence entre une porte blindée et un scellé de cire. Le scellé n’arrête personne ; il dénonce tout le monde.

Certains journaux système le proposent nativement. journald, par exemple, dispose d’un mécanisme de scellement à clé évolutive, qu’il faut activer explicitement et dont la clé de vérification doit être conservée ailleurs que sur la machine, faute de quoi le sceau protège contre tout le monde, sauf contre celui qui a pris la machine, ce qui en limite l’intérêt.

# Vérification de la cohérence des fichiers de journal (lecture seule).
# Sans scellement configuré, elle détecte la corruption, pas la falsification.
journalctl --verify

Ce mécanisme garantit que les entrées scellées n’ont pas été modifiées depuis. Il ne garantit pas qu’une entrée a été écrite : un attaquant qui tient la machine peut empêcher les entrées futures d’être produites, ou en produire de fausses qui seront scellées de très bonne foi. Le scellement protège le passé, pas le présent, et c’est pourquoi il ne remplace pas l’éloignement.

Centraliser sans noyer

La centralisation est indispensable à l’intégrité et précieuse pour la corrélation. Elle a aussi un effet secondaire que les plaquettes commerciales taisent, sans doute par modestie : elle transforme un problème de lecture en problème de facturation. Les outils se paient au volume, en licence, en stockage ou en indexation ; le volume devient la grandeur qu’on surveille et qu’on réduit, avec l’acharnement qu’on réserve d’habitude aux notes de frais. Et l’on retombe dans le travers décrit plus haut : on coupe ce qui pèse, pas ce qui sert.

La réponse n’est pas de tout envoyer (le trimestre suivant s’en souviendra), ni d’envoyer au hasard (l’enquête s’en souviendra). C’est de classer les sources par valeur probante plutôt que par volume, et d’accepter des régimes différents, comme on accepte que le coffre-fort et la poubelle n’aient pas la même serrure.

Ce qui ne se reconstitue nulle part ailleurs (authentifications, changements de droits, modifications de configuration de sécurité, actions d’administration, accès aux données sensibles) part au point central, en entier, sans échantillonnage. C’est souvent une petite fraction du volume, et l’essentiel de la valeur.

Ce qui sert à la corrélation fine (journaux réseau, requêtes applicatives, résolutions DNS) peut rester plus près de la source, sur une durée plus courte, et n’être transféré qu’à la demande ou sous forme agrégée. On perd du confort, on garde la possibilité.

Ce qui ne répond à aucune des quatre questions (bavardage de démarrage, sondes de supervision, messages de débogage orphelins) n’a pas vocation à être centralisé du tout. Il peut rester local, tourner vite, et disparaître sans cérémonie ni oraison funèbre.

Rien de tout cela n’est révolutionnaire. C’est la logique de tri qu’on applique, ou qu’on devrait appliquer, à tout corpus qui s’accumule sans décision. Le journal n’est qu’un cas particulier d’une tendance générale des systèmes, et des greniers, à conserver ce qui ne coûte rien à entasser et beaucoup à retrouver.

Combien de temps, et pourquoi pas plus

La rétention est le seul sujet sur lequel la journalisation réglementaire et la journalisation utile se rencontrent enfin. C’est pour se disputer.

L’enquête a besoin de temps. Les compromissions sérieuses ne se découvrent pas le jour où elles ont lieu ; elles se découvrent souvent bien après, par un signalement extérieur ou ce hasard que les rapports d’incident rebaptisent pudiquement « vigilance des équipes ». Un journal conservé quinze jours ne sert qu’aux incidents bruyants, c’est-à-dire à ceux qu’on aurait vus sans lui. La durée de rétention fixe la profondeur maximale de toute enquête future, et elle la fixe à l’aveugle, puisqu’on ignore le délai de découverte de l’incident qu’on n’a pas encore eu.

La minimisation, elle, réclame des limites. Un journal d’authentification est un fichier de données personnelles assez intime : il dit, par recoupement, à quelle heure une personne commence sa journée, quand elle part en congé et depuis quel domicile elle télétravaille. C’est un traitement, et il lui faut une durée justifiée. La CNIL a publié des recommandations sur la journalisation et sur sa durée de conservation ; leur contenu exact est à vérifier à la source, parce qu’il évolue et que je préfère renvoyer au texte que le paraphraser de mémoire, la mémoire étant, à mon âge, un journal dont la rétention n’est plus garantie.

Entre les deux, il n’y a pas de durée magique. Il y a une méthode : fixer la durée par catégorie et par finalité, l’écrire, et pouvoir la défendre devant quelqu’un qui n’est pas d’accord. Les journaux de sécurité à forte valeur probante justifient une conservation longue, sur un stockage protégé. Les journaux de diagnostic justifient une conservation courte. Et « on garde tout, on ne sait jamais » ne justifie rien, puisque c’est l’aveu, en quatre mots, qu’aucune finalité n’a été définie.

Reste la rétention que personne n’a décidée, la plus répandue : celle qui dépend de la taille du disque, pas du besoin. Un serveur bavard conservera trois jours d’histoire, un serveur taciturne en conservera six mois, et personne n’aura choisi ni l’un ni l’autre. C’est la démocratie appliquée aux octets : chacun a droit à la même place, et ceux qui parlent le plus effacent les autres.

# Ce que le journal système occupe réellement
journalctl --disk-usage
# La plus ancienne entrée encore disponible : la profondeur réelle de l'historique
journalctl --no-pager -o short-iso | head -n 2

Cette date est la seule réponse honnête à la question « jusqu’où pourrions-nous remonter ? », et elle est souvent plus proche qu’on ne le croyait.

Le meilleur argument contre

Il serait malhonnête de conclure sans exposer la thèse inverse, défendue par des gens qui ne sont pas des imbéciles, ce qui complique toujours un débat.

L’argument est le suivant : on ne sait pas à l’avance quelles questions on posera. Toute la démarche de cet éditorial consiste à partir des questions pour concevoir les journaux. Mais les incidents les plus instructifs sont justement ceux qu’on n’avait pas imaginés. Une journalisation bâtie autour de quatre questions attendues sera excellente pour les incidents attendus, et aveugle pour les autres. Le bruit d’aujourd’hui est la pièce à conviction de demain : un message de débogage anodin, une requête de supervision à une heure bizarre, un avertissement de dépréciation qui révèle qu’une vieille bibliothèque a été rechargée. Dans cette perspective, trier, c’est parier, et le pari est perdu d’avance sur les cas qui comptent.

L’argument a pour lui une réalité technique : le stockage brut coûte beaucoup moins cher qu’autrefois, et la recherche sur de gros volumes s’est nettement améliorée. Tout garder n’est plus absurde pour une infrastructure modeste.

Je le crois pourtant insuffisant, pour trois raisons.

La première est que l’argument défend le volume, pas la qualité. Garder toutes les lignes ne répare pas une ligne mal écrite. Si l’application journalise sous un compte de service unique, tout garder ne fera pas réapparaître l’utilisateur. Si l’horloge est fausse, tout garder conservera pieusement des heures fausses. Le tri et la conception sont deux problèmes distincts, et l’argument ne répond qu’au premier.

La deuxième est que le coût de la conservation n’est pas le stockage : c’est la relecture. Un volume que personne ne parcourt n’est pas une mémoire, c’est une décharge, et chaque gigaoctet de bruit est une heure volée à l’enquêteur.

La troisième est l’exposition. Tout garder, c’est aussi garder tout ce qui ne devait pas l’être : les mots de passe tapés dans le champ de l’identifiant par des utilisateurs pressés, les jetons passés en paramètre d’URL, les en-têtes d’authentification recopiés par un mode de débogage oublié en production depuis la dernière glaciation. Un journal exhaustif est aussi l’index exhaustif de ce qu’il ne fallait pas écrire.

Ma position est donc un compromis, que j’assume avec la mauvaise grâce qui sied aux compromis : concevoir autour des quatre questions pour les sources à forte valeur, et conserver le reste brut, localement, sur une durée courte, pour les questions qu’on n’a pas su prévoir. On paie le pari par une fenêtre limitée plutôt que par un aveuglement total. Ce n’est pas élégant. C’est ce que je sais faire de mieux, et je n’ai pas honte de dire que ce n’est pas beaucoup.

Le test ultime

Tout ce qui précède se ramène à un exercice qui ne demande ni outil, ni budget, ni consultant, et que pour cette raison presque personne ne pratique : ce qui est gratuit inspire toujours une certaine méfiance.

Choisissez un mardi. Un vrai, récent, sans incident particulier, un de ces mardis dont personne ne se souviendra. Posez-vous, pour ce mardi, une série de questions précises, en vous interdisant d’y répondre autrement qu’en lisant les journaux. Pas de coup de téléphone au collègue, pas de « je crois que c’était Bernard ».

Qui s’est connecté aux machines d’administration, depuis où ? Quelles configurations ont changé, par qui, et que valaient-elles avant ? Quels comptes ont changé de droits ? Quelles données ont été exportées, sous quelle identité ?

Chronométrez. Notez ce qui se résout en minutes, en heures, ou pas du tout. Ces dernières forment la liste des travaux, et cette liste vaut mieux que n’importe quel rapport d’audit, parce qu’elle a été écrite par la réalité et non par une grille.

L’exercice mesure la capacité réelle plutôt que la couverture supposée, et il se fait à froid, quand on a le loisir de combler une lacune, plutôt qu’un jeudi soir sous le regard d’une direction qui a soudain beaucoup de questions et très peu de patience.

On peut le durcir en le confiant à quelqu’un qui ne connaît pas l’infrastructure : des journaux lisibles par leur seul auteur se taisent le jour où il est absent, et une loi que nul n’a démontrée mais que chacun a vérifiée veut que ce soit ce jour-là. On peut aussi y glisser une action de test délibérée, et vérifier qu’elle apparaît, avec les bons attributs, au bon endroit. C’est pour les journaux l’équivalent de la restauration de test pour les sauvegardes : la seule preuve qu’un dispositif fonctionne est de l’avoir vu fonctionner. Le reste relève de la foi, qui est respectable, mais qui n’a jamais reconstitué un incident.

Ce que je ne sais pas

Je ne sais pas fixer une bonne durée de rétention en général. J’ai dit pourquoi elle se décide par catégorie et par finalité ; je n’ai pas de chiffre universel à proposer, et je me méfie de ceux qui en ont un. Le délai de découverte des incidents varie énormément selon l’attaque et la maturité de la victime, et je ne dispose d’aucune source que je juge assez solide pour en tirer une règle.

Je ne sais pas si les quatre questions suffisent pour les architectures très distribuées. Dans un système fait de dizaines de services qui s’appellent les uns les autres, le « qui » se dilue à chaque saut, et le reconstituer exige des identifiants de corrélation propagés de bout en bout, ce que la littérature sur l’observabilité traite mieux que cet éditorial. Le critère reste valable ; sa mise en œuvre change d’ordre de grandeur.

Je ne sais pas ce que valent les journaux résumés par des modèles de langage. C’est peut-être un progrès pour la lecture ; c’est certainement un intermédiaire de plus entre l’événement et l’enquêteur, avec ses propres omissions, et je manque de recul pour trancher.

Je ne sais pas mesurer ce qu’on rate. L’exercice du mardi révèle une partie des lacunes. Il ne révèle pas les questions qu’on n’a pas pensé à poser, et ce sont, par définition, celles qu’on posera.

Ce qui reste

Un journal n’est pas une obligation qu’on remplit. C’est une réponse qu’on prépare à une question dont on ignore encore le détail mais dont on connaît parfaitement la forme.

Trois choses me semblent acquises. Que la conformité ne dit rien de l’utilité : un système peut produire tous les journaux exigés et n’en produire aucun qui serve. Que ce qu’on écrit se décide à partir de ce qu’on voudra lire : qui, quoi, sur quoi, avec quel résultat, à une heure fiable, depuis un endroit nommé, et non à partir de ce que le logiciel consent à raconter. Et que seul l’usage prouve la valeur : un journal jamais relu est un journal dont on ignore s’il fonctionne, exactement comme une sauvegarde jamais restaurée ou un vieux sage jamais consulté.

Le reste est de l’hygiène : éloigner, sceller, synchroniser, trier, borner. Rien de cela n’est difficile. Tout cela est ennuyeux, et c’est pour cette unique raison que ce n’est pas fait.

Il reste une question que cet éditorial a laissée de côté avec une lâcheté calculée. Un journal utile ne sert pas qu’à l’enquête après coup. Il peut alimenter une détection, c’est-à-dire des alertes qui préviennent pendant que l’incident a lieu. Là, le problème change de nature : on passe du journal que personne ne lit aux alertes que tout le monde reçoit et que plus personne ne regarde. C’est le sujet de La fatigue d’alerte.

🐝 Ce qui arrive si on s’en passe

Sans journaux capables de répondre au qui, au quoi et au sur quoi, un incident ne peut pas être borné. Faute de savoir quelles données ont été exportées et sous quelle identité, il faut traiter comme touchées toutes celles que le compte compromis pouvait atteindre, et réinitialiser tous les accès qu’il aurait pu créer. L’absence de trace ne prouve rien, dans un sens ni dans l’autre : elle interdit seulement d’affirmer que l’intrus est reparti. Les règles de transfert de courrier, clés ajoutées ou comptes créés pendant la fenêtre non journalisée restent en place, invisibles, et survivent au nettoyage que tout le monde croyait complet.

🦫 Explication de la marmotte 🍫

Les ordinateurs et les logiciels écrivent en continu des lignes dans des fichiers appelés journaux. Chaque ligne décrit un événement : un démarrage, une erreur, une connexion. En cas d’incident, par exemple un compte utilisé par un inconnu, on relit ces journaux pour reconstituer ce qui s’est passé. Souvent, cela échoue. Les logiciels écrivent surtout ce qui aide à réparer leurs propres pannes, et l’on supprime les messages trop nombreux, souvent les connexions réussies. Or un attaquant qui possède un vrai mot de passe ne provoque aucune erreur. Une ligne utile doit dire qui a agi, ce qui a été fait, sur quel objet, avec quel résultat, à quelle heure et depuis où. L’heure doit être la même sur toutes les machines, sinon les événements sont remis dans le mauvais ordre. Il faut aussi protéger les journaux : quelqu’un qui prend le contrôle d’une machine peut modifier ceux qui y sont stockés. On les envoie donc rapidement vers une autre machine, et on peut les sceller par un calcul qui rend visible toute modification. Ensuite, il faut trier : garder longtemps ce qui prouve des actions importantes, garder peu de temps le reste, et fixer une durée pour chaque catégorie. Enfin, le seul moyen de savoir si les journaux fonctionnent est de choisir une journée ordinaire et d’essayer d’en retracer les événements en ne lisant qu’eux.

Pages voisines

La citent

Le journal que personne ne lit

Elle cite

: les deux pages se citent l’une l’autre.

Le journal que personne ne lit

Mardi, quatorze heures

Deux journaux qui portent le même nom

On journalise ce qui est facile

Quatre questions, et seulement quatre

Le test appliqué à ses propres journaux

L’heure, cette donnée qu’on croit gratuite

Intégrité : un journal que l’attaquant peut réécrire

Éloigner

Sceller

Centraliser sans noyer

Combien de temps, et pourquoi pas plus

Le meilleur argument contre

Le test ultime

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines