Faux négatifs DLP : 7 erreurs de configuration qui laissent fuir

Prenons un scénario type. Google Drive est considéré comme bloqué. Un test envoie des fichiers leurres vers Drive : l’EDR laisse passer les premiers, puis coupe le transfert une fois un certain volume atteint. Le même envoi, découpé en lots plus petits, chacun sous le seuil, passe. Personne n’a mal fait son travail : la politique surveille un volume par transfert, et le test lui présente autre chose.

C’est un faux négatif DLP typique. Un faux négatif DLP, c’est une donnée sensible qui sort de l’entreprise sans que l’outil de prévention des fuites ne la bloque, ne lève d’alerte ou ne la journalise. Le faux négatif ne laisse aucune trace, il n’apparaît qu’à l’occasion d’un test actif ou, trop tard, d’un incident. Selon IBM, Cost of a Data Breach Report 2026 (Ponemon, 602 organisations), il faut en moyenne 247 jours pour identifier et contenir une brèche.

Pourquoi le faux négatif est le vrai risque d’une DLP

En pratique, beaucoup d’équipes passent leur temps DLP à réduire le bruit. C’est compréhensible. Un faux positif se voit : il génère une plainte, il bloque un commercial un lundi matin, devant un client. Alors vous remontez un seuil, vous ajoutez une exception, vous assouplissez une règle. Chaque ajustement se défend. Additionnés sur 2 ou 3 ans, ils déplacent votre frontière de détection, et plus personne ne mesure ce qui passe.

Une DLP ne vous dit que ce qu’elle a vu. Ce qu’elle n’a pas inspecté ou pas reconnu n’existe pas pour elle. Une console silencieuse ne vous dit pas que tout va bien. Elle ne vous apprend donc rien.

Les sept erreurs de configuration qui produisent des faux négatifs

Ces 7 causes se retrouvent quel que soit l’éditeur. Rien d’exotique, et vous en avez sans doute plusieurs chez vous.

1. Une règle qui reconnaît un format et rate la donnée. Un numéro de sécurité sociale compte 13 chiffres et une clé de 2. Si votre expression régulière attend la forme avec espaces, elle ratera peut-être le même numéro collé, séparé par des points ou découpé sur 2 cellules Excel. Pareil pour un IBAN français de 27 caractères, écrit en blocs de 4 ou d’une traite. Un contrat scanné ou un PDF image, sans OCR activé, ne contient aucun texte pour le moteur. Nous testons donc une même donnée sous plusieurs formes.
2. Des seuils calibrés contre le bruit. Déclencher à partir de 10 occurrences vous évite des alertes sur une signature d’e-mail. Cette règle laisse aussi passer 9 enregistrements clients par envoi, sans limite de répétition. Notre cas Google Drive suit la même logique côté volume ; MITRE ATT&CK décrit d’ailleurs ce découpage sous T1030 (Data Transfer Size Limits). Un seuil est une décision de risque : documentez-la, datez-la, revoyez-la.
3. Des exceptions qui ne meurent jamais. Un groupe exclu pour un projet de 3 mois, un domaine partenaire en liste blanche, un poste de direction exempté « temporairement ». Elles survivent aux projets qui les justifiaient et deviennent des couloirs que personne ne surveille. Demandez pour chacune qui l’a créée et quand. Si personne ne sait, vous tenez votre premier chantier.
4. Une classification incomplète ou contournable. Beaucoup de vos règles reposent sur des étiquettes de sensibilité. Si l’étiquette manque, si elle est posée à la main ou si un copier-coller vers un nouveau fichier Word la fait tomber, la règle ne s’applique plus. Un export CSV généré à la volée par votre CRM n’en porte donc, en général, aucune.
5. Des canaux hors périmètre. Votre politique couvre la messagerie et le partage de fichiers. Elle oublie le navigateur vers un SaaS non référencé ou vers Gmail, l’impression, le presse-papiers vers un outil d’IA générative ou certains protocoles réseau. Les chemins liés au shadow IT et au navigateur sont parmi les plus souvent oubliés.
6. Un mode audit jamais basculé en blocage. La stratégie est déployée en simulation, puis y reste, faute de volontaire pour assumer le blocage. Elle produit quand même des journaux. Personne ne les lit. Dans la console, la règle existe. Sur le réseau, elle ne protège rien.
7. Des agents absents, obsolètes ou dégradés. Un agent jamais installé sur les postes livrés en septembre, une version ancienne qui ignore un nouveau navigateur, un service arrêté après une mise à jour de Windows ou de Linux. Votre console affiche la politique comme appliquée parce qu’elle l’a poussée, sans savoir si elle s’exécute.

Un scénario concret : la fuite que tout le monde a ratée

Voici un scénario type, que votre équipe peut rejouer avec des leurres. Dans un cabinet de conseil, la DLP couvre la messagerie sortante et bloque les pièces jointes étiquetées « Confidentiel ». Un vendredi à 19 h, un collaborateur sur le départ exporte la base clients du CRM en CSV, donc sans étiquette. Il le compresse et le dépose sur son Dropbox personnel depuis Chrome. Aucune règle ne se déclenche. Le fichier n’a pas d’étiquette, le canal web n’est pas couvert, l’archive n’est pas ouverte. Côté MITRE ATT&CK, c’est la technique T1567.002, exfiltration vers un stockage cloud. 6 mois plus tard, un concurrent appelle vos clients un par un.

Comment détecter les faux négatifs avant un incident

Regarder vos alertes ne vous montrera jamais un faux négatif. Vous devez provoquer volontairement une sortie de données, avec des leurres, et vérifier ce qui se passe. Un premier passage reste modeste : 5 types de données (numéro de sécurité sociale, IBAN, carte bancaire, fiche client, contrat), 4 formats pour chacun et 6 canaux. Soit 120 essais. Vous avez 3 approches, de la plus légère à la plus complète :

Faites défiler le tableau →

Checklist de départ pour un RSSI

• Listez vos exceptions actives avec leur date de création et leur propriétaire. Supprimez celles qui n’ont plus de justification.
• Repérez vos règles encore en mode audit et fixez une date de décision pour chacune, à 30 jours par exemple.
• Comparez le nombre d’agents actifs au nombre de postes de votre annuaire, version par version.
• Pour ces essais, utilisez des fichiers leurres au format réaliste, jamais de vraies données.
• Testez aussi le fractionnement : 1 gros envoi, puis 10 petits vers la même destination.

Faux négatifs DLP : un problème de dérive

Une DLP bien réglée en janvier ne se comporte plus de la même façon en juin. Les exceptions s’empilent, une migration cloud déplace les données hors du périmètre initial. Un test par an, sur un SI qui change chaque semaine, vous décrit une situation déjà disparue. Les prochaines versions permettront de programmer des rejeux périodiques ou déclenchés par un changement, selon la criticité du périmètre et la fraîcheur attendue de la preuve. Vous verrez alors si l’écart se réduit ou s’élargit, et à quelle date il est apparu.

FAQ