Edition 22

Les deux explications peuvent être vraies simultanément, et ce qui se cache derrière est plus intéressant que l'une ou l'autre. Un client particulier n'a aucun moyen d'accorder à un agent une autorité limitée, il lui remet donc l'intégralité de ses identifiants. C'est le problème de l'identité machine que j'évoquais en septembre : une identité par agent, avec des droits limités à une tâche. Sauf que le titulaire du compte ne dispose d'aucun de ces outils, et que la banque ne peut pas distinguer votre agent d'un fraudeur. L'accès en lecture seule ne résout qu'une moitié du problème. Un agent capable de lire vos relevés peut toujours les divulguer s'il est compromis ou manipulé. Bloquer un virement et protéger la confidentialité sont deux missions distinctes.

Je vous ai dit deux fois cette année de traiter le SBOM comme un inventaire vivant plutôt que comme un artefact d'audit. Voici le chiffre qui me manquait : 72 heures. Si le vôtre est généré à la compilation et que votre dernière mise en production date de septembre, il décrit un système que vous ne faites plus tourner. Et notez quelle moitié est absente presque partout. La nomenclature enregistre ce que vous avez livré. Personne ne surveille ce qui se charge. Lors d'un incident, les deux seules questions sont : qu'est-ce qui s'est exécuté et jusqu'où a-t-il atteint. Une liste de dépendances n'y répond ni à l'une ni à l'autre.

Vous en avez déjà vu la version concrète à deux reprises. En août, un kit de phishing qui avait enrôlé sa propre passkey sur le compte de la victime et avait survécu à la réinitialisation du mot de passe. Le mois dernier, un fournisseur MFA externe frauduleux qui satisfaisait la vérification alors que le second facteur ne s'était jamais produit. Aucun des deux n'a attaqué la cryptographie. Tous deux ont visé directement l'enrôlement et la récupération. Déployez donc les passkeys, c'est toujours le bon choix. Répondez ensuite aux deux questions qui déterminent s'ils tiennent : qui est autorisé à en enrôler une sur un compte, et quelle preuve votre service desk accepte-t-il lorsqu'une personne appelle pour signaler la perte de son appareil.

Ce que les cinq demandent à la place est identique : une durée liée à une finalité, consignée par écrit avec une justification. L'erreur habituelle est de fixer la rétention par outil, car « le SIEM conserve 90 jours » est une décision de licence habillée en badge sécurité. Fixez-la par finalité : détection, investigation, imputabilité des accès à privilèges, plancher légal, et laissez gagner la plus contraignante que vous pouvez réellement justifier. Utilisez ensuite les deux leviers que personne n'actionne : journalisez l'événement sans la donnée elle-même, et nivelez le stockage de façon que moins de personnes puissent accéder aux données les plus anciennes. Un schéma que je retrouve dans presque chaque audit que je conduis : le DPO n'a jamais été consulté. L'article 38 indique qu'il aurait dû l'être.

Lisez ceci en regard de l'article précédent et les deux forment l'enjeu complet. Vous pouvez calibrer votre rétention parfaitement, consulter votre DPO, documenter la finalité et la durée, et rester aveugle malgré tout : parce que quelqu'un a coupé l'enregistrement sous vos pieds, au niveau de l'hyperviseur. Regardez ensuite ce que votre propre processus en aurait fait. Un score de 2,7 se situe en dessous du seuil de la plupart des politiques de correctifs, il n'aurait donc jamais été mis en file d'attente. Broadcom a corrigé en juillet et rien n'a bougé jusqu'à ce qu'un rapport de threat intelligence nomme le groupe trois mois plus tard. Un dernier point à vérifier : les sources publiques ne s'accordent même pas sur le score, certaines l'indiquent à 7,6. Un écart de cinq points sur le même CVE décide si votre politique le verra jamais.