Edition 09

Relisez cette conclusion, car c'est tout l'enjeu : les failles étaient banales. Gestion non sécurisée des jeux de données, métadonnées exposées, accès trop larges, credentials à longue durée de vie. Pas un seul zero-day exotique dans les fondations, juste les constats exacts que liste votre dernier rapport de pentest et que votre dernier plan de traitement des risques a probablement reportés. L'IA n'avait pas besoin d'être brillante. Il lui suffisait que vous ayez laissé le loquet ouvert, puis elle a vérifié chaque loquet 17 600 fois sans jamais s'ennuyer, se fatiguer ou avoir peur.

C'est ce changement qui devrait modifier votre approche des tests. Votre pentest annuel simule un humain : quelques jours, une personne qui dort, un périmètre qui s'arrête. Ceci simule quelque chose qui ne s'arrête jamais, n'oublie jamais son objectif, et se reconstruit chaque fois que vous le mettez à terre. Si votre modèle de menace suppose un attaquant avec la patience et les horaires de bureau d'un humain, il teste désormais un monde qui n'existe plus.

L'enseignement atterrit donc là où il atterrit toujours, mais plus fort : à l'ère de l'IA, l'hygiène de base est primordiale. Faites tourner les credentials. Supprimez les jetons à longue durée de vie. Appliquez le moindre privilège pour de vrai, pas sur le papier. Et si vous menez des tests offensifs, commencez à vous demander à quoi ressemble le red-teaming agentique contre votre environnement, car l'autre camp le pratique déjà. C'est la conversation de gouvernance qu'ISO/IEC 42001 ne cesse de pointer, et cet incident vient de la rendre concrète.

C'est le sujet le plus proche de mon bureau, alors je serai direct sur ce que cela change. Si vous disposez d'un jeu de données que vous avez traité comme anonyme parce que vous avez supprimé les noms ou haché les identifiants, l'EDPB, dans la lignée de la Cour, vient de vous dire que ce n'est pas une propriété de la donnée, c'est un jugement de contexte. Anonyme entre vos mains peut être une donnée personnelle entre celles de quelqu'un d'autre. Cela remet en question chaque argument « c'est anonymisé, le GDPR ne s'applique pas » dans un pipeline d'entraînement d'IA ou un partage de données de recherche.

J'ai rédigé une étude complète sur la définition de la donnée personnelle à travers les affaires Breyer et SRB, qui sont à l'origine de cette approche relative, et elle est mise en ligne sur Cyberacademy cette semaine, restez connectés. Si vous traitez des données que vous avez qualifiées d'anonymes, lisez-la avant votre prochaine décision de partage de données. En résumé : le label n'est pas la protection. L'évaluation du risque de réidentification documentée derrière lui l'est.

Je le dis dans chaque formation que j'anime, et maintenant la norme le dit en onze pages : l'Annexe A n'est pas un catalogue dans lequel vous faites vos courses. Vous partez de vos risques, vous décidez des mesures que ces risques exigent, et seulement ensuite vous vérifiez l'Annexe A pour vous assurer de n'avoir rien oublié. Les organisations qui ratent ISO/IEC 27001 procèdent à l'envers : elles ouvrent l'Annexe A en premier et la traitent comme une liste de courses, pour se retrouver avec un empilement de mesures qui ne répondent à aucun risque réel. La version allégée de ISO 27000 existe en partie pour tuer cette habitude.

Point pratique : si vos supports de formation, vos modèles ou votre wiki interne citent des définitions ISO 27000, ils pointent désormais vers une édition retirée, et le vocabulaire réside maintenant sur la plateforme en ligne de l'ISO. Et si vous gérez quoi que ce soit dans le cloud, ISO/IEC 27017 est enfin aligné sur les mesures de 2022, ce qui signifie que votre cartographie des mesures cloud et votre prochain audit cloud nécessitent tous deux la nouvelle version.

Observez la cohérence avec les deux points précédents. L'EDPB dit qu'un label d'anonymat n'est pas une protection. L'ISO dit qu'une case cochée dans l'Annexe A n'est pas une mesure. CISA dit maintenant qu'un SBOM généré n'est pas une sécurité de la chaîne d'approvisionnement. Même leçon, trois régulateurs, une semaine : l'artefact n'est pas le résultat. Un SBOM produit une fois et classé ne prouve rien le jour où un nouveau CVE tombe sur un composant enfoui à l'intérieur.

Même si vous êtes hors du périmètre américain, c'est la direction prise, et NIS2, DORA et le Cyber Resilience Act s'appuient tous précisément sur ce type de transparence de la chaîne d'approvisionnement. Traitez le SBOM comme un inventaire vivant que vous croisez avec les flux de vulnérabilités, pas comme un PDF pour le classeur d'audit.

Et voici ce qu'il faut anticiper : le SBOM n'est que le premier inventaire. L'AI Bill of Materials arrive, la même comptabilité appliquée aux modèles, aux jeux de données, aux poids et à la provenance de l'entraînement, et CISA a déjà publié un ensemble complémentaire d'éléments minimaux pour l'IA. C'est plus difficile, car un modèle ou un jeu de données peut changer sans qu'aucun build ne soit jamais exécuté, ce qui rend une capture annuelle inutile. Regardez le début de ce numéro : un composant IA non inventorié, exploité à grande échelle, est exactement le risque qu'un AI-BoM existe pour rendre visible. Commencez à le demander à vos fournisseurs avant que votre régulateur ne le fasse.

Je l'ai construite parce que les outils que je recommandais sans cesse étaient soit lourds, soit coûteux, soit traitaient le GRC comme un exercice de remplissage de formulaires, ce qui est l'opposé de tout ce que j'enseigne dans cette newsletter. Il y a un niveau gratuit pour commencer. Et si vous voulez le tester sérieusement, répondez à cet e-mail et je vous offrirai un an complet du niveau premium, gratuitement, pour le mettre à l'épreuve. Si ce n'est pas fait pour vous, pas de pression : la newsletter reste exactement ce qu'elle est.