Les attaquants qui s’appuient sur l’IA n’attendent plus une faille célèbre pour agir. Leurs outils scannent en continu les applications exposées, testent des identifiants volés, repassent sur les mêmes cibles quelques jours plus tard pour vérifier qu’un mot de passe fonctionne encore. Le spécialiste en sécurité Daniel Miessler en tire une recommandation simple : avant d’acheter un nouvel outil, chaque organisation doit poser une base solide, en trois chantiers que n’importe quelle équipe peut lancer dès ce mois-ci.
Ce tuto reprend ces chantiers et les traduit pour une structure française soumise au RGPD, et parfois à NIS2. Il s’adresse au DPO comme au référent RGPD qui doit dialoguer avec la DSI sans être lui-même technicien.
L’attaque est en cours ? Commencez par là
- isoler les postes et serveurs touchés du réseau, sans les éteindre, pour garder les traces en mémoire ;
- couper les accès distants et les comptes à privilèges suspects, puis changer les mots de passe d’administration depuis un poste sain ;
- prévenir le DPO immédiatement et ouvrir un journal daté de chaque action ;
- qualifier la violation de données : si un risque existe pour les personnes, la notification à la CNIL doit partir dans les 72 heures (article 33 du RGPD) ;
- contacter Cybermalveillance.gouv.fr ou, pour les entités concernées, le CERT-FR de l’ANSSI, et déposer plainte.
Étape 1 : recenser chaque application, chaque API, chaque serveur
On ne protège pas un serveur dont personne ne connaît l’existence. Dans la plupart des audits, l’inventaire tenu par la DSI couvre les gros logiciels métier et oublie le reste : l’outil de prise de rendez-vous branché sur l’agenda, l’API ouverte pour un prestataire il y a trois ans, le serveur de test resté en ligne, le compte d’IA générative créé avec une adresse professionnelle sans passer par l’informatique.
Pour un attaquant, ces oubliés sont la porte d’entrée idéale. Ils ne reçoivent pas les mises à jour, personne ne surveille leurs journaux, et ils partagent souvent des identifiants avec des systèmes plus sensibles.
- Partez du registre des traitements (article 30 du RGPD) : chaque traitement cite des logiciels, chaque logiciel tourne quelque part.
- Croisez avec les factures : un abonnement payé chaque mois correspond à un outil utilisé, qu’il figure ou non dans l’inventaire.
- Demandez à la DSI la liste des domaines et sous-domaines publiés, des adresses IP exposées et des clés d’API actives.
- Interrogez chaque service sur les outils qu’il utilise « en dehors » de l’informatique, sans chercher de coupable.
- Pour chaque élément, notez le responsable, l’hébergeur, le pays d’hébergement, le mode d’accès et les données traitées.
Le résultat attendu tient dans un tableau unique, mis à jour au fil de l’eau. Un inventaire refait une fois par an et rangé dans un dossier partagé vieillit en quelques semaines.
Étape 2 : basculer un maximum de ressources en accès privé
Une fois la liste établie, regardez pour chaque ligne qui peut l’atteindre depuis internet. Une application de gestion interne accessible par une simple page de connexion publique se fait tester des milliers de fois par jour par des robots. La même application placée derrière un outil d’accès privé disparaît purement et simplement de leur champ de vision.
Les solutions d’accès privé, souvent regroupées sous le sigle ZTNA, vérifient l’identité de l’utilisateur et l’état de son poste avant de lui ouvrir une seule application, et pas tout le réseau comme le fait un VPN classique. Un identifiant volé ne suffit plus : il faut aussi le bon appareil, le bon second facteur, parfois le bon pays.
- Les interfaces d’administration (pare-feu, serveurs, hébergement, messagerie) : elles n’ont rien à faire sur internet.
- Les applications qui contiennent des données de santé ou des données sensibles au sens de l’article 9 du RGPD.
- Les accès distants des prestataires, souvent ouverts en permanence alors qu’ils servent deux heures par mois.
- Les API : limitez-les aux adresses connues, donnez à chaque clé une durée de vie courte et des droits minimaux.
Tout ne peut pas passer en accès privé. Un site public, un formulaire de contact, un portail destiné aux usagers restent exposés par nature. Pour ceux-là, l’authentification multifacteur, les mises à jour et la surveillance des connexions deviennent non négociables.
Étape 3 : réévaluer le risque porté par vos fournisseurs
Le point le plus dérangeant de l’analyse de Daniel Miessler concerne les petits fournisseurs de sécurité. Votre infogérant, l’éditeur de votre gestionnaire de mots de passe, le prestataire qui gère vos sauvegardes ou votre supervision détiennent souvent les clés de dizaines de clients à la fois. Pour un attaquant organisé, compromettre une petite structure de dix personnes rapporte bien plus que d’attaquer ses clients un par un.
Le RGPD impose déjà de ne choisir que des sous-traitants présentant des garanties suffisantes (article 28). NIS2 ajoute, pour les entités concernées, une obligation explicite de gérer la sécurité de la chaîne d’approvisionnement. Dans les deux cas, un contrat signé et une attestation ISO rangée dans un tiroir ne répondent pas à la vraie question.
- Quels identifiants ou accès à privilèges ce fournisseur détient-il chez nous ?
- Ses propres accès sont-ils protégés par une authentification forte et journalisés ?
- S’est-il engagé par écrit à nous prévenir d’un incident, et dans quel délai ?
- Peut-on couper ses accès en moins d’une heure sans bloquer notre activité ?
- Nos sauvegardes restent-elles disponibles s’il disparaît, ou dépendent-elles entièrement de lui ?
- Sous-traite-t-il lui-même une partie du service, et à qui ?
Classez ensuite vos fournisseurs par niveau d’exposition. Les plus critiques méritent un questionnaire d’audit annuel, une clause de notification d’incident chiffrée en heures et un plan de repli testé. Pour les autres, une revue tous les deux ou trois ans suffit souvent.
Le rôle du DPO dans ce chantier
Le DPO ne pilote pas la sécurité informatique, mais il tient plusieurs pièces du puzzle : le registre des traitements, la liste des sous-traitants, les contrats de l’article 28, la procédure de gestion des violations de données. Il peut donc vérifier que l’inventaire de la DSI couvre bien tous les logiciels cités dans le registre, et inversement. Il peut aussi exiger que chaque nouveau fournisseur passe par une évaluation avant signature.
Ce travail tourne vite au casse-tête quand les informations vivent dans des tableurs dispersés. DPO SUITE réunit dans un même espace le registre, les logiciels, les serveurs, les sous-traitants avec leurs questionnaires d’audit, et la gestion des incidents avec le calcul automatique des délais de notification. Le lien entre un traitement, le logiciel qui le supporte et le fournisseur qui l’héberge devient visible en un clic, ce qui permet de répondre en quelques minutes à la question « que perdons-nous si ce prestataire tombe ? ».