Prévention des e-mails envoyés par erreur : une protection là où la DLP échoue

La plupart des équipes de sécurité mettent en place un programme de prévention des pertes de données (DLP), et la majorité de ces programmes fonctionnent comme prévu. Pourtant, des données sensibles continuent d’atteindre de mauvaises personnes par e-mail, car les règles de détection analysent le contenu du message, sans tenir compte du destinataire. La prévention des e-mails mal adressés vient combler cette faille.

Imaginez une liste de clients envoyée avec quarante noms visibles dans le champ « À », un contrat transféré sur une adresse Gmail personnelle la semaine précédant une démission, ou un domaine mal saisi d’une lettre. L’expéditeur est autorisé, le fichier peut sortir, aucune règle ne s’active. Les données sont correctes. Le destinataire ne l’est pas.

Cet article explique où s’arrête la DLP basée sur des règles, comment Kiteworks Agent et Human Error Prevention (AHEP) vérifient le destinataire pendant la rédaction du message, et comment tester cette solution sur vos propres incidents avant de vous engager.

Résumé Exécutif

La DLP basée sur des règles et la vérification du destinataire répondent à des questions différentes. La DLP s’interroge sur la présence de données qui ne devraient pas être envoyées. AHEP, une fonction du moteur de règles de données Kiteworks, vérifie si le destinataire est cohérent avec le message, et ce, tant que l’expéditeur peut encore corriger l’erreur. Pour les responsables de la sécurité, cela représente un contrôle sur une catégorie de risques que les outils existants ne détectent pas, intégré à la plateforme qui gère déjà les données sensibles en mouvement. Le mode « Report Only » permet de mesurer l’exposition avant qu’un seul expéditeur ne voie une alerte.

Résumé des Points Clés

1. La DLP analyse les données, pas le destinataire. Des données autorisées envoyées à la mauvaise personne passent toutes les règles de détection, il faut donc un contrôle spécifique pour les erreurs de destinataire. Affiner les règles DLP ne résoudra pas ce problème.
2. L’e-mail mal adressé est un incident courant et bien documenté. Selon Osterman Research, ce type d’incident arrive en tête des signalements auprès des autorités de protection des données (21 %), et 96 % des plus de 300 responsables interrogés par Abnormal ont déclaré avoir subi des pertes à cause de ce phénomène.
3. Chaque règle AHEP s’active uniquement dans des conditions précises. Le type de destinataire, le volume externe, la correspondance d’identité et la présence de pièces jointes alimentent trois règles prédéfinies, pour que les alertes restent rares et prises au sérieux par les expéditeurs.
4. Le mode « Report Only » mesure le risque avant toute alerte visible. Chaque message est évalué et consigné en toute discrétion, ce qui vous donne une base de détections par règle à comparer avec votre journal d’incidents et vos résultats DLP.
5. Toutes les alertes et décisions sont consignées dans le journal d’audit. Règle, directive, destinataires, réponse et horodatage sont enregistrés, ce qui facilite les audits si l’on vous demande comment le contrôle a fonctionné.

Pourquoi la DLP Basée sur des Règles Ne Détecte Pas un Mauvais Destinataire

La DLP joue un rôle essentiel, et il ne faut surtout pas la désactiver. Elle inspecte les messages et pièces jointes pour détecter les données qui ne doivent pas sortir, comme les numéros de carte, les identifiants ou les documents marqués. Le problème survient quand les données peuvent sortir mais que le destinataire n’est pas le bon. Aucune règle ne correspond, donc rien ne s’active, et l’incident n’est découvert que si le vrai destinataire répond ou si un client se plaint.

Ce Que les Règles Analysent

Les règles analysent le message lui-même : son texte, ses pièces jointes, ses étiquettes. Elles répondent efficacement à une question claire : ce message contient-il un type de données soumis à restriction ? Cela fonctionne pour l’exfiltration ou les fuites accidentelles de données qui ne devraient jamais circuler par e-mail. Mais cela ne sert à rien lorsqu’un document légitime est envoyé à un tiers non prévu.

Ce Qu’elles Ne Peuvent Pas Analyser

Les outils voisins ne comblent pas non plus cette faille. Le DSPM localise et classe les données sensibles au repos. L’IAM décide qui peut se connecter. Le Zero trust détermine qui peut accéder à quoi. Ces trois outils sont utiles, mais aucun ne vérifie si la personne dans le champ « À » est bien celle que l’expéditeur voulait. Cette question se pose au moment de la rédaction, d’où l’importance de placer la vérification du destinataire dans la fenêtre de composition.

Comment Kiteworks AHEP Vérifie le Destinataire Avant l’Envoi

AHEP fait partie du moteur de règles de données Kiteworks et nécessite la version 9.5. Il évalue un message pendant sa rédaction, puis à chaque ajout ou suppression de destinataire ou de pièce jointe. L’e-mail transite toujours directement du client vers le serveur de messagerie. Le service de validation AHEP se contente d’évaluer le message, sans jamais envoyer de mail lui-même.

Trois Règles Prêtes à l’Emploi pour les Erreurs de Destinataire Courantes

Trois règles sont livrées prêtes à l’emploi. L’une recommande le champ CCI lorsque le nombre de destinataires externes dépasse un seuil défini par l’administrateur. Une autre empêche l’envoi vers des adresses e-mail personnelles lorsqu’un domaine personnel connu, une correspondance d’identité avec l’expéditeur et une pièce jointe non intégrée sont réunis. La troisième détecte les erreurs de domaine, en signalant les domaines à une lettre d’un domaine grand public connu et ceux sans enregistrement MX valide. Les administrateurs définissent le statut de chaque règle (désactivée, activée ou « Report Only ») et choisissent la directive (Suggestion ou Alerte). Aucun développement spécifique n’est requis.

Pourquoi les Alertes Restent Rares et Pertinentes

La règle sur les adresses personnelles exige que ses trois conditions soient réunies, donc une adresse personnelle sans pièce jointe ne l’active pas. Cette retenue est volontaire. Les utilisateurs cessent de lire les alertes trop fréquentes, alors qu’une alerte qui apparaît uniquement dans les bonnes conditions incite à l’action. Si une alerte s’affiche, la correction se fait dans la fenêtre de composition : déplacer les destinataires externes en CCI, corriger le domaine ou retirer le destinataire signalé. En mode Suggestion, l’expéditeur peut poursuivre. En mode Alerte, il doit résoudre ou ignorer l’alerte avant d’envoyer. Rien n’est bloqué en silence.

Tester AHEP sur Vos Propres Incidents

Vous n’avez pas à vous fier aux chiffres d’un fournisseur. Exécutez chaque règle en mode « Report Only » pendant quelques semaines. AHEP évalue et consigne chaque message sans rien afficher aux utilisateurs. Comparez ensuite les détections avec votre journal d’incidents et les alertes DLP sur la même période. La différence entre les deux vous donne votre chiffre, et c’est l’argument le plus solide à présenter à un décideur budgétaire.

Points à Vérifier Avant de Lancer un Pilote

Anticipez les limites. Les alertes fonctionnent dans l’application Web Kiteworks et Outlook Classic. AHEP nécessite la couche de services conteneurisés Kiteworks (RKE2) et le service de validation, activé par le support technique Kiteworks. La détection est plus précise si les noms d’utilisateurs suivent un format standard et si les adresses professionnelles ressemblent à prenom.nom@entreprise ; toutes les adresses personnelles ne sont pas détectées, notamment celles sur un domaine personnalisé. Validez ces points avec votre équipe messagerie avant de lancer le pilote pour obtenir des résultats pertinents.

Combler la Faille Destinataire sur le Data Control Plane de Kiteworks

Les outils de posture vous indiquent où résident les données sensibles et qui peut y accéder. La DLP inspecte ce qui sort. L’étape suivante consiste à protéger activement les données en mouvement, au moment où une personne ou une IA choisit un destinataire. C’est là qu’intervient le Data Control Plane de Kiteworks. AHEP est intégré au moteur de règles qui gère déjà la messagerie, le partage de fichiers, SFTP, MFT et les formulaires, pour que les vérifications de destinataire s’ajoutent aux règles orientées données que vous appliquez sur d’autres canaux. La validation s’effectue dans votre propre environnement, et chaque alerte, rejet ou décision est consignée dans un journal d’audit inviolable, compatible avec vos outils SIEM.

Cette solution complète vos investissements en DLP, DSPM et IAM, sans les remplacer. Si vous souhaitez voir ces trois règles à l’œuvre dans l’application Web Kiteworks et Outlook Classic, réservez une démo personnalisée avec notre équipe et présentez vos propres exemples d’incidents.