Tester sa DLP : checklist par canal et plan de test pour savoir si elle bloque

« Notre DLP tourne depuis 2 ans. Qu’est-ce qu’elle a bloqué, au juste ? » Nous entendons souvent cette question chez les RSSI que nous rencontrons, et la console ne sait pas y répondre. Pour le savoir, il faut tester sa DLP. Voici la checklist que nous recommandons, avec un plan de test qui tient sur une page.

Tester sa DLP, c’est provoquer volontairement des sorties de données synthétiques, canal par canal, puis vérifier pour chacune si elle a été bloquée, seulement journalisée ou ignorée. Votre DLP peut avoir toutes ses règles actives et quand même laisser fuir. Pour le cadre général, voyez notre page sur le test d’exfiltration de données.

Pourquoi une console DLP « verte » ne prouve rien

La console vous montre des stratégies actives, des règles publiées, des agents déployés. Elle ne montre jamais ce qui n’a pas déclenché d’alerte. Une DLP qui rate ne prévient personne. L’écran reste vert. Or l’attaquant a du temps : 14 jours de présence en médiane selon le M-Trends 2026 de Mandiant.

Les causes sont connues, et souvent banales. Un agent endpoint désactivé sur une partie du parc. Une règle restée en mode audit depuis la phase pilote. Une exception ajoutée pour un projet urgent, jamais retirée. Un nouveau service SaaS que personne n’a ajouté au périmètre. Une archive protégée par mot de passe, que le moteur d’analyse ne sait pas ouvrir. Ou un seuil : un EDR qui laisse partir des fichiers vers Google Drive jusqu’à un certain volume, puis coupe, ce qu’un envoi fractionné contourne. Aucune ne produit d’erreur visible. Rien ne remonte. Nous les détaillons dans l’article sur les faux négatifs DLP.

Trois résultats possibles pour chaque test

Avant de lancer quoi que ce soit, fixez une grille de lecture commune avec votre SOC. Chaque scénario rejoué aboutit à l’un de ces 3 états :

Faites défiler le tableau →

Tester sa DLP : la checklist par canal

Voici ce que nous recommandons de vérifier au minimum sur chaque grand canal de sortie. Restez simple. Des gestes d’utilisateur ordinaires suffisent : si une clé USB passe, inutile de sortir des techniques d’attaquant pour trancher.

Poste de travail (endpoint)

• Copie d’un fichier synthétique d’apparence sensible vers une clé USB, puis vers un disque externe chiffré (T1052 dans MITRE ATT&CK).
• Impression d’un document marqué « Confidentiel ».
• Copier-coller d’un extrait sensible vers une application non autorisée, Notion par exemple.
• Même test sur un portable hors du réseau d’entreprise, en télétravail et sans VPN.
• Contrôle de l’agent sur 20 postes tirés au hasard : est-il présent, à jour, et sous la bonne stratégie ?

Messagerie

• Envoi vers une adresse Gmail ou Outlook.com personnelle, en corps de message puis en pièce jointe.
• Pièce jointe compressée en ZIP, puis en ZIP protégé par mot de passe.
• Envoi à un destinataire externe en copie cachée.
• Données sensibles placées dans une image ou un PDF scanné.

Web et réseau

• Dépôt d’un fichier synthétique sur WeTransfer ou Smash, depuis Chrome ou Edge.
• Collage de contenu sensible dans un formulaire web, Copilot ou Gemini.
• Transfert vers une destination non catégorisée par votre proxy.
• Vérification de la couverture de l’inspection TLS sur les flux sortants en HTTPS.

Cloud et applications SaaS

• Partage d’un document par lien public depuis Microsoft 365 ou Google Workspace.
• Synchronisation vers un compte Dropbox ou OneDrive personnel.
• Envoi d’un fichier dans un canal Teams ou Slack ouvert à des invités externes.
• Téléchargement massif depuis une application métier, Salesforce par exemple.

Le quotidien des outils collaboratifs mérite à lui seul un examen.

Un mini plan de test en trois décisions

1. Le périmètre

Ne commencez pas par tout. Choisissez 2 ou 3 catégories de données qui vous coûteraient cher en cas de fuite (fichiers clients, paie, plans ou code source) et les populations qui y ont accès. Incluez au moins un profil nomade et un compte à privilèges. Je préfère quelques scénarios joués cette semaine à un inventaire complet prévu pour le trimestre prochain.

2. Les scénarios

Pour chaque catégorie, croisez vos données avec les canaux de la checklist. Fabriquez des leurres réalistes : assez proches des vraies données pour déclencher vos règles (formats de numéros, mots-clés, marquages de classification), sans jamais en être. C’est à cette condition que vous pouvez tester en production sans utiliser de donnée métier réelle, comme expliqué dans l’article sur les données synthétiques en production.

Un scénario bien écrit se présente ainsi : « Un commercial en télétravail envoie un export client Excel synthétique de 500 lignes vers sa messagerie personnelle, en pièce jointe compressée. Résultat attendu : blocage et alerte SOC sous 15 minutes. » Écrire le résultat attendu à l’avance évite les débats après coup.

3. La cadence

• Socle : un passage complet au moins tous les 3 mois.
• Événements : un rejeu ciblé après une migration, un nouvel outil SaaS, une mise à jour majeure de l’agent ou une modification de stratégie.
• Canaux critiques : un contrôle automatisé, toutes les 12 h ou chaque jour, sur les 2 ou 3 canaux les plus exposés.

Pourquoi tant insister ? Parce qu’une règle qui bloquait en janvier peut ne plus rien voir en avril sans que personne n’y ait touché directement. Un test isolé vous dit où vous en étiez ce jour-là. Rejoué chaque mois, il montre si la situation s’améliore.

Lire les résultats et décider

Un test qui produit 50 constats sans ordre de traitement ne sert à rien. Classez chaque échec selon deux axes : la sensibilité de la donnée et la facilité du geste qui l’a fait sortir. Un export client qui part par un simple glisser-déposer dans un navigateur passe avant une fuite théorique qui demande des droits d’administrateur.

Gardez enfin un historique. Notez le taux de scénarios bloqués par canal, son évolution d’un passage à l’autre et le délai de correction. Les prochaines versions apporteront un reporting à plusieurs niveaux (direction, RSSI, opérations), avec des correspondances MITRE ATT&CK et, lorsque la correspondance est établie, MITRE D3FEND, ainsi que des intégrations SIEM. Face à un auditeur ISO 27001 ou à votre direction, cet historique pèse bien plus qu’une capture de console.

Questions fréquentes