L’essentiel en 30 secondes
- Un test d’exfiltration fait sortir des données synthétiques pour voir si vos contrôles les bloquent, les signalent ou les laissent passer.
- Cinq familles de canaux à couvrir : poste, réseau, messagerie, cloud et SaaS, IA générative. Enforcis 1.0 teste les canaux web, réseau et cloud : voir les 8 canaux.
- Chaque échec appelle une action corrective, puis un nouveau rejeu du scénario pour vérifier.
- Le scénario se rejoue, parce qu’une mise à jour d’agent suffit à rouvrir un chemin.
Depuis 2021, l’équipe fondatrice fait sortir des données synthétiques de vrais systèmes d’information : d’abord chez Holiseum avec le « Tir à blanc de rançongiciel », primé en 2022 au Cybernight et aux Cas d’Or, puis au fil de plus de 40 déploiements. La leçon : tant que personne n’a essayé de faire sortir un fichier, personne ne sait s’il peut sortir. Enforcis en est né en 2025. C’est ce que nous appelons un test d’exfiltration de données.
Un test d’exfiltration de données consiste à simuler, de façon contrôlée, la sortie d’informations sensibles hors de votre système d’information pour vérifier si vos contrôles la bloquent, la détectent ou la laissent passer. À la fin, vous avez une liste : pour chaque scénario, bloqué, seulement détecté, ou passé.
Ce qu’est un test d’exfiltration, et ce qu’il n’est pas
Ce que c’est
- Un test actif : nous faisons vraiment sortir un leurre, au lieu de relire des règles.
- Une seule question : une donnée sensible peut-elle sortir, par quel canal, et quelqu’un s’en aperçoit-il ?
- Reproductible : le même scénario se relance après une mise à jour ou une migration.
- Orienté remédiation : chaque échec mène à une action corrective identifiable.
Ce que ce n’est pas
- Un audit de configuration : il lit la règle sans jamais la voir tourner. Les faux négatifs DLP se logent dans cet écart.
- Un pentest généraliste : lui cherche à entrer ; ici, l’attaquant, ou l’initié, est déjà là.
- Une plateforme BAS complète : la spécialisation change la profondeur. Voir le comparatif ci-dessous et notre article BAS et test d’exfiltration.
- Une fuite réelle maîtrisée : les charges de test sont synthétiques ; aucune donnée métier réelle du client n’est utilisée comme payload de campagne.
En un coup d’œil
| Approche | Question posée | Ce qu’elle apporte | Sa limite face à l’exfiltration |
|---|---|---|---|
| Test d’exfiltration | Une donnée sensible peut-elle sortir, et le voit-on ? | Une preuve scénario par scénario, rejouable, en production, avec des données synthétiques | Suppose l’accès acquis : ne teste pas l’entrée |
| BAS | Les techniques simulées sont-elles arrêtées ? | Une simulation d’attaque automatisée, large spectre | Peu d’évasion, souvent en environnement simulé, moindre profondeur sur la sortie |
| Pentest | Peut-on entrer et progresser ? | Une preuve d’exploitabilité | Ponctuel et non exhaustif, centré sur l’entrée |
| Audit de configuration DLP | La règle est-elle paramétrée comme prévu ? | La conformité du paramétrage | Lit la règle sans la voir tourner ; vue par silo |
Pourquoi tester la sortie plutôt que l’entrée
Vos budgets défensifs vont souvent à l’entrée : messagerie, périmètre, terminaux. Le dommage, lui, arrive au moment où la donnée part. Dans un rançongiciel à double extorsion, c’est l’exfiltration qui fonde le chantage, avant même le chiffrement.
247 jours
en moyenne pour identifier et contenir une brèche dans le monde.
Source : IBM, Cost of a Data Breach Report 2026 (Ponemon Institute), juillet 2026.
6 167
notifications de violations de données reçues par la CNIL en 2025, un record (+9,5 % sur un an).
Source : CNIL, rapport annuel 2025, mai 2026.
42 %
des 460 événements caractérisés comme possibles fuites de données ont été associés à une fuite avérée.
Source : ANSSI, Panorama de la cybermenace 2025, mars 2026.
Schéma · le workflow rejoué
- 1DécouverteRepérer les données sensibles
- 2CollecteAgréger les fichiers cibles
- 3PréparationStructurer, archiver ou compresser
- 4AutomatisationOutiller l’opération
- 5ExfiltrationSortir par un canal autorisé
Les canaux à couvrir
| Famille | Exemples de canaux | Contrôles concernés |
|---|---|---|
| Endpoint | Périphériques amovibles, presse-papiers, impression, applications locales | Agent DLP endpoint, EDR |
| Réseau | HTTPS, DNS, protocoles de transfert, ports inhabituels | Proxy, pare-feu, filtrage sortant |
| Messagerie | Pièces jointes, corps de message, transferts automatiques vers une boîte Gmail | DLP e-mail, passerelle |
| Cloud et SaaS | Stockage personnel (Google Drive, Dropbox), outils collaboratifs (Teams, Slack), partage de liens | CASB, DLP SaaS, stratégies natives |
| Usages émergents | Prompts vers des IA génératives (ChatGPT, Copilot), extensions de navigateur | Contrôles navigateur, passerelle web |
Deux canaux sont rarement vérifiés : le DNS et le HTTPS face aux limites de l’inspection TLS. Et puis il y a les prompts : coller un contrat dans un assistant d’IA générative, c’est aussi faire sortir une donnée.
Un scénario type : toutes les tentatives d’exfiltration vers GitHub réussissent. L’explication est simple : GitHub est une destination légitime pour vos développeurs, souvent exclue de l’inspection TLS, et les git push échappent à la DLP. Il ne s’agit d’ailleurs pas de bloquer GitHub. Nous vous conseillons de distinguer l’espace GitHub de l’entreprise, autorisé avec une mesure compensatoire comme la MFA sur arbitrage du RSSI, d’un dépôt tiers quelconque, qui ne devrait jamais être joignable.
La méthode : cinq étapes, rejouées en continu
- Définir ce qui est sensible. Sans classification, la DLP ne sait pas quoi reconnaître. Nos leurres imitent vos vraies catégories de données : fichiers clients, plans, dossiers de santé, identifiants.
- Fabriquer des données synthétiques réalistes. Assez crédibles pour déclencher vos règles, sans aucune valeur : de quoi tester en production sans utiliser de donnée métier réelle.
- Rejouer les scénarios d’attaque. Un canal après l’autre, depuis vos postes et vos serveurs, avec au moins un agent Windows ou Linux par sous-réseau.
- Observer trois issues possibles. Bloqué, détecté sans blocage, non détecté. Une alerte que personne ne traite ne compte pas comme un succès.
- Hiérarchiser et recommencer. Classer les échecs par criticité et par effort, corriger, puis relancer le scénario. Les prochaines versions d’Enforcis apporteront des recommandations contextualisées et priorisées, validées par retest.
Ponctuel ou continu ?
Schéma · la boucle
Un scénario concret
Imaginons un industriel équipé d’une DLP Microsoft qui bloque les fichiers marqués « Confidentiel » envoyés par e-mail vers l’extérieur. Le test rejoue quatre variantes avec un faux plan technique : envoi direct, archive compressée, copie dans le corps du message, dépôt sur un stockage personnel depuis le navigateur.
Schéma · contrôle supposé, sortie réelle
Étape suivante
Combien de chemins vos règles couvrent-elles vraiment ?
Une démo de 30 minutes : une campagne complète sur les 8 canaux que nous testons, sur notre environnement de démonstration. Le POC montre in situ, sur un scénario simple en environnement synthétique, comment la solution se comporte chez vous. Ce qui sort réellement de vos canaux, c’est le pilote qui vous le montre.
Pour qui, et par où commencer
- RSSIUne mesure objective des contrôles, à présenter à la direction. Voir ce que NIS2 attend de la direction et les indicateurs DLP pour le COMEX.
- SOC ou SecOpsVérifier que les alertes d’exfiltration remontent au SIEM et sont exploitables.
- DPO et conformitéDocumenter, dates à l’appui, que les mesures de sécurité sont testées.
- DSI d’ETI sans RSSISavoir où porter l’effort sans équipe spécialisée.
Checklist avant un premier test
- Les catégories de données sensibles sont identifiées.
- Les contrôles en place sont inventoriés (endpoint, réseau, e-mail, cloud).
- Le SOC est prévenu, sauf si vous voulez mesurer sa détection à l’aveugle.
- Seuls des leurres serviront au test.
- Un responsable est désigné pour chaque famille de correction.
- La date du prochain passage est fixée.
Pour comparer les solutions, voir nos critères pour choisir un outil de test DLP ; pour le vocabulaire, le glossaire DLP et exfiltration.
Questions fréquentes
En quoi un test d’exfiltration diffère-t-il d’un audit de configuration DLP ?
Un audit relit vos règles et vérifie qu’elles sont paramétrées comme prévu. Il ne les voit jamais tourner. Nous, nous faisons sortir un leurre par un vrai canal (HTTPS, DNS, Google Drive, GitHub Gist), depuis un vrai poste Windows ou Linux, et nous notons ce qui se passe. Les faux négatifs se logent dans cet écart : une règle conforme sur le papier qui ne se déclenche pas sur le portable d’un commercial en télétravail.
Pourquoi tester la sortie des données plutôt que l’entrée ?
Parce que c’est au moment où la donnée part que le dommage arrive. Le rançongiciel à double extorsion l’illustre bien : le fichier exfiltré fonde le chantage, avant même le chiffrement. Or vos budgets défensifs vont souvent à l’entrée. Messagerie, périmètre, terminaux. Depuis 2021, nous partons du principe inverse : l’attaquant, ou l’initié, est déjà dans le réseau, et nous mesurons ce qu’il pourrait emporter.
Faut-il déjà avoir une DLP ?
Non. Sans DLP, le test montre les canaux ouverts (HTTPS, DNS, FTP, Google Drive ou GitHub Gist) et vous aide à décider où investir. Avec une DLP, il mesure ce qu’elle arrête réellement, sur les scénarios effectivement testés.
Faut-il bloquer GitHub après un test comme celui-ci ?
Rarement : vos développeurs en ont besoin. Ce qu’il faut fermer, ce sont les dépôts tiers quelconques. L’espace GitHub de l’entreprise peut rester ouvert, avec une mesure compensatoire comme la MFA, sur arbitrage du RSSI.