DLP messagerie : comment tester vos règles d’e-mail sortant

Vendredi, 18 h 40. Un commercial qui part fin octobre s’envoie le fichier clients de son secteur sur son Gmail personnel, zippé « pour que ça passe ». Lundi matin, votre SOC n’a rien vu. La règle DLP sur les données clients était pourtant marquée active.

Tester une règle de DLP messagerie, c’est rejouer ce geste avec des données synthétiques : depuis un vrai poste et une vraie boîte, vous envoyez de faux IBAN ou de faux fichiers clients, puis vous regardez ce que la passerelle en a fait. Blocage, quarantaine, chiffrement, alerte, ou rien du tout. En pratique, la messagerie est souvent le canal où les exceptions s’empilent le plus vite.

Nous ne parlons ici que de messagerie sortante, que vous soyez sur Microsoft 365, Google Workspace ou derrière une passerelle dédiée. Pour la démarche tous canaux confondus, voyez notre page sur le test d’exfiltration de données.

Pourquoi les règles e-mail se dégradent sans bruit

Le jour où vous la créez, votre stratégie DLP de messagerie est rarement fausse. Elle le devient. Un domaine partenaire en liste blanche en mars, un connecteur de relais pour l’ERP en juin, une règle de transport Exchange créée un jeudi soir pour débloquer un dirigeant : chacun de ces changements se défend, et chacun ouvre une porte.

Côté messagerie, voici ce que nous constatons le plus souvent :

• Ordre d’évaluation des règles : une règle de transport traitée avant la DLP peut court-circuiter l’inspection.
• Exceptions par expéditeur ou par groupe : votre direction, vos comptes de service, vos boîtes partagées.
• Chemins de sortie parallèles : relais SMTP applicatif, client mobile iOS ou Android, webmail hors périmètre.
• Limites d’analyse du contenu : taille maximale, profondeur des archives, formats non pris en charge.

Les quatre familles de tests à couvrir

1. Le corps du message et les pièces jointes

Tout le monde fait ce test, et presque tout le monde s’arrête trop tôt. Un faux IBAN dans un document Word ne valide que la détection la plus simple. Ensuite, nous faisons varier le contenant, une variable à la fois :

• le même faux IBAN dans le corps, puis dans un fichier .docx, puis dans un PDF ou un PowerPoint ;
• PDF issu d’un scan (image sans couche texte), pour voir si votre reconnaissance de caractères est activée ;
• ZIP, puis ZIP glissé dans une archive 7z, sur 2 ou 3 niveaux (technique T1560 de MITRE ATT&CK) ;
• fichier volumineux, juste sous puis juste au-dessus de la limite d’analyse de votre solution ;
• classeur Excel dont les données sensibles sont dans un onglet masqué.

Chaque variante pose la même question à votre solution : sait-elle ouvrir ce format, et sinon, que fait-elle ? Laisser passer en silence un fichier illisible peut se défendre, à condition que quelqu’un l’ait décidé et l’ait écrit.

2. Le chiffrement

Derrière ce mot, nous voyons deux situations sans rapport.

D’abord, le chiffrement comme action de la DLP : la règle repère une donnée sensible et chiffre le message au lieu de le bloquer (dans Microsoft 365, avec Purview Message Encryption par exemple). Vérifiez depuis une boîte externe que le destinataire reçoit bien un message protégé, et non le texte en clair sous une bannière.

Ensuite, le chiffrement qui empêche l’inspection. Un classeur protégé par mot de passe, un ZIP chiffré en AES, un message S/MIME : votre passerelle ne les lit pas. Que fait alors votre politique ? Bloquer, mettre en quarantaine ou laisser sortir avec une alerte au SOC se défendent selon le contexte. Ne rien décider ne se défend pas.

3. Le transfert vers des adresses personnelles

C’est notre commercial du vendredi soir, le scénario de menace interne le plus banal. Testez séparément quatre chemins, qui ne dépendent pas des mêmes réglages :

• envoi manuel d’une pièce jointe vers Gmail, Yahoo Mail, Outlook.com ou Proton Mail ;
• transfert d’un message reçu, avec sa pièce jointe d’origine ;
• règle de transfert automatique créée par l’utilisateur dans sa boîte (T1114.003 dans MITRE ATT&CK) ;
• redirection configurée côté serveur pour une boîte partagée.

4. Les chemins de sortie oubliés

Une partie de vos e-mails sortants ne passe jamais par Outlook : l’ERP qui envoie ses exports par relais SMTP, l’imprimante multifonction qui « scanne vers e-mail », le CRM qui écrit aux clients en votre nom. Qu’un de ces flux contourne la DLP peut se justifier. Encore faut-il l’avoir écrit quelque part, et l’avoir compensé par un autre contrôle.

Une grille de validation pour la DLP messagerie

Pour chaque scénario, nous notons le résultat attendu et le résultat observé. L’écart entre les deux, c’est votre liste de travail.

Faites défiler le tableau →

Vérifiez aussi la chaîne d’alerte, souvent oubliée. Si le message est bloqué mais que le SOC n’en sait rien, vous avez fait la moitié du chemin. Un test n’est clos que lorsqu’un analyste a vu l’événement arriver dans votre SIEM. Sur les canaux web et réseau qu’il teste, Enforcis classe d’ailleurs chaque scénario dans l’un des 3 états (Bloqué, Détecté sans blocage, Non détecté), ce qui vous dit où la chaîne a cassé.

Scénario concret : un départ de collaborateur

Imaginez un groupe de distribution qui sort d’un audit et vient de durcir sa DLP. Premier envoi : un tableur de 200 faux IBAN vers un domaine externe. Bloqué, rien à redire. Deuxième envoi : le même tableur zippé, depuis le compte d’une assistante de direction membre du groupe exempté pour l’expert-comptable. Le message sort. Aucune alerte.

Techniquement, rien n’est cassé : l’exception a été validée en janvier 2024. Seulement, elle couvre aujourd’hui 14 personnes au lieu de 3, et personne ne l’avait reliée au transfert vers l’extérieur. Cela n’apparaît qu’en rejouant l’envoi avec le compte réellement exempté.

Les règles du jeu pour tester sans utiliser de donnée métier réelle

• N’envoyez que des leurres qui respectent formats et sommes de contrôle : faux IBAN à clé modulo 97 valide, faux NIR de 15 caractères, clé comprise. Notre article sur les données synthétiques en production détaille la démarche.
• Prévenez le SOC ou convenez d’un marqueur pour qualifier les incidents de test, sans pour autant les exclure de la chaîne d’alerte.
• Envoyez depuis de vrais postes de votre parc, comme le font nos agents Windows et Linux.
• Recevez vos envois sur des boîtes externes à vous, pour voir ce qui est vraiment arrivé.
• Testez avec vos différents profils : utilisateur standard, compte en exception, boîte partagée.
• Relancez les scénarios après chaque mise à jour de stratégie, nouveau connecteur ou migration.

Si votre messagerie repose sur Microsoft 365, la méthode s’applique directement aux stratégies décrites dans notre guide pour valider Microsoft Purview^™ DLP.

FAQ