Edition 18

Je prends ça pour moi, parce que j'ai utilisé ce vocabulaire. J'ai écrit sur les essaims en juillet, en août, puis le mois dernier, et le mot portait un récit qui permettait à tout le monde de regarder la machine plutôt que le périmètre qui l'entoure. Les faits ne changent pas. Le cadrage, si. Un agent avec un accès internet qu'il n'aurait pas dû avoir, un registre de paquets que personne ne surveillait, des identifiants sans expiration : chacun de ces éléments a été configuré par une personne. Je supprime le mot.

La partie utile, c'est l'architecture. Jacob Krell de Suzu Labs l'exprime bien : les contrôles traditionnels sont atomiques, ils inspectent une requête ou une permission à la fois, tandis qu'un agent enchaîne plusieurs défaillances individuellement tolérables pour construire un chemin d'exploitation. Construisez donc de façon à ce que l'intention soit sans importance. Isolation forte, réseau en refus par défaut, listes d'accès immuables, identifiants à portée étroite, vérification indépendante à chaque appel d'outil, et un coupe-circuit qui fonctionne hors du contrôle de l'agent. Un agent n'a pas besoin d'intention malveillante. Il lui faut suffisamment d'accès et une mauvaise décision.

Il y a un humain dans la boucle ici, et cet humain n'est pas un contrôle de sécurité. C'est un évaluateur de qualité sans mandat pour escalader quoi que ce soit, ce qui signifie que les contenus les plus graves passent devant une personne à qui on a dit que son travail est de juger si les pixels sont corrects. Tout le monde suppose l'inverse. C'est le même schéma que l'élément précédent : le contrôle existe, il fonctionne exactement comme prévu, et il n'a jamais été orienté vers ce que vous pensiez qu'il visait.

Deux points pour votre organisation. La question de protection des données est évidente dès qu'on la voit : les personnes dont les visages apparaissent ne sont souvent pas l'utilisateur, n'ont été informées de rien, et le floutage serait trivial. Vous pouvez vous opposer à l'entraînement, pas à ce qu'un inconnu regarde. Et le point pratique : quand des collaborateurs insèrent un document ou une photo dans un outil d'IA grand public, la question n'est plus seulement de savoir si cela entraîne un modèle. C'est de savoir si un sous-traitant dans un pays que vous n'avez jamais évalué va le lire.

Le contrôle était réel et il fonctionnait. Il validait qu'un message était bien formé et ne demandait jamais d'où venait ce message, ce qui est le même schéma de défaillance que celui que j'ai décrit la semaine dernière dans un processus de signature de paiement et un jeton MFA. Et regardez le reste : validation RSA artisanale, dans le composant dont l'unique raison d'être est de dialoguer avec des jetons de sécurité matériels, en banque d'entreprise. Nous avons protégé la clé dans le matériel, puis nous l'avons exposée via une extension de navigateur.

Deux remarques pratiques. Les extensions de navigateur restent l'angle mort de presque tous les registres d'actifs, et voici la pire version de ce problème : l'extension est précisément celle qui applique l'authentification forte. Au titre de DORA, SConnect est un composant tiers critique intégré dans votre chaîne d'authentification, et il ne figure dans le registre de personne. Allez vérifier quelles extensions de signature ou de jeton votre équipe financière utilise, et sur quelle version.

Tout ce qui relève de la conformité porte une date. La violation, la sanction, les échéances des injonctions, la décision d'appel à venir. Le côté de l'abonné n'en porte aucune. Après une violation de mot de passe, on change le mot de passe et l'exposition s'effondre en quelques minutes. Ici, le fichier contient des noms, des dates et lieux de naissance, des adresses et des IBANs. Un nom ne change pas. Un IBAN peut techniquement changer, sur demande auprès de la banque, mais il faut alors re-signer tous les prélèvements automatiques, donc presque personne ne le fait. La demi-vie de ce fichier se mesure en années. C'est la temporalité à présenter à votre conseil d'administration, pas l'amende.

Et remarquez quelle défaillance est revenue en premier plan. Le régulateur a sanctionné Free Mobile pour avoir conservé des données d'anciens abonnés qu'elle ne pouvait pas justifier, et des juristes lisant la décision ont trouvé près de trois millions de contrats résiliés depuis plus de dix ans qui dormaient encore dans la base. La presse spécialisée a rangé cela comme une note de bas de page administrative à côté du vrai sujet, la sécurité. C'est pourtant le sujet de sécurité. Des données supprimées ne peuvent pas être exfiltrées, revendues, ou utilisées pour crédibiliser une fausse facture. J'ai rédigé l'analyse complète, lien ci-dessus.

Les fondamentaux sont justes. Je les ai écrits toute l'année et je les réécrirai. Mais regardez ce que ce numéro vient de vous montrer : la question a bougé. Ce n'est plus « avez-vous l'authentification multifacteur ». Le mois dernier, elle était activée et non appliquée. La semaine dernière, elle était satisfaite sans jamais avoir été exécutée. Disposer d'un contrôle est désormais la moitié facile. Savoir qu'il fonctionne encore quand quelqu'un le teste, c'est la moitié que personne ne finance.

Voici donc ce que je ferais avec l'attention que vous obtenez ce mois-ci. Au lieu d'une affiche, testez un contrôle. Déposez un honeytoken dans un partage de fichiers et vérifiez si une alerte parvient à un humain. Activez une politique de sécurité du contenu en mode rapport uniquement pendant une semaine et lisez ce qui s'exécute réellement dans les navigateurs de vos clients. Répétez une éviction et vérifiez que l'attaquant est bien parti. Et donnez à Recover un vrai test, car c'est le R que presque personne ne peut démontrer, et sous NIS2 et DORA, il a cessé d'être optionnel.