L’essentiel en 30 secondes
- Un utilisateur interne n’a rien à contourner pour accéder à la donnée : tout se joue au moment de la sortie.
- Négligence et malveillance appellent deux tests distincts ; commencez par la négligence, la plus fréquente.
- On teste les contrôles, jamais les personnes : comptes dédiés, données factices, cadre validé et rejeu régulier.
La menace interne désigne le risque qu’un utilisateur disposant d’accès légitimes (salarié, prestataire, alternant, administrateur) fasse sortir des données de l’entreprise, par erreur ou volontairement. Tester l’exfiltration par la menace interne consiste à rejouer, avec des données factices et un cadre validé, les gestes qu’un utilisateur de confiance pourrait faire, afin de vérifier que vos contrôles les bloquent ou au moins les détectent.
Le point clé : un utilisateur interne n’a rien à contourner pour accéder à la donnée. Il l’a déjà. Tout se joue donc au moment de la sortie.
Pourquoi la menace interne échappe aux contrôles classiques
La plupart des dispositifs de sécurité sont pensés contre un intrus : authentification forte, détection de comportements anormaux sur un compte compromis, segmentation. Face à un collaborateur qui ouvre un fichier qu’il consulte tous les jours, ces barrières ne se déclenchent pas. L’accès est légitime, l’horaire est normal, le poste est connu.
Il reste un seul endroit où l’on peut agir : le canal de sortie. Pièce jointe vers une adresse personnelle, synchronisation vers un cloud personnel, clé USB, impression, copier-coller dans un outil d’IA générative, partage externe depuis un espace collaboratif. C’est précisément le terrain de la DLP, et c’est aussi là que les règles mal calibrées laissent passer des flux sans le moindre signal. Nous détaillons ce phénomène dans l’article sur les faux négatifs DLP.
Schéma · le seul point d’action
Négligence ou malveillance : deux profils, deux tests
Confondre les deux conduit à de mauvais tests. Le collaborateur négligent ne cherche pas à se cacher. Le collaborateur malveillant, lui, fait un effort, souvent modeste, pour éviter les alertes.
| Critère | Négligence | Malveillance |
|---|---|---|
| Intention | Travailler plus vite, « emporter du travail à la maison » | Conserver ou monnayer de l’information |
| Canaux typiques | Messagerie personnelle, cloud personnel, outils d’IA, partage de lien public | Mêmes canaux, plus fractionnement, renommage, archivage, supports amovibles |
| Ce que le test doit prouver | Les règles de base bloquent ou avertissent l’utilisateur | Les variations simples ne font pas tomber la détection |
| Réponse attendue | Blocage avec message pédagogique | Blocage et alerte exploitable par le SOC |
Pour la malveillance, restez sur des variations que n’importe quel utilisateur trouverait seul : changer l’extension, compresser, découper en plusieurs envois, passer par un autre service. L’objectif n’est pas de construire une technique d’attaque, mais de vérifier que la règle ne repose pas sur un seul attribut fragile.
Le départ d’un collaborateur : le scénario à tester en priorité
La période de préavis concentre le risque. La personne a encore tous ses accès, connaît la valeur des documents et a une raison concrète d’en garder une copie : fichier clients, offres commerciales, documentation technique, modèles de contrats.
Un scénario concret
Un ingénieur commercial démissionne et part chez un concurrent dans trois mois. Durant les dernières semaines, il exporte son portefeuille depuis le CRM, l’envoie sur sa messagerie personnelle « pour garder ses contacts », puis synchronise un dossier d’offres vers un stockage personnel. Aucune alerte, car chaque action, prise isolément, ressemble à son travail habituel.
Ce scénario se rejoue facilement avec des données factices : un export CRM leurre, des offres fictives marquées comme confidentielles, un compte de test placé dans le groupe des collaborateurs en départ. On observe alors trois choses : ce qui est bloqué, ce qui est seulement journalisé, et ce qui passe sans trace.
Ce qu’il faut vérifier côté organisation
- Le signal RH (démission, rupture conventionnelle, fin de mission) remonte-t-il réellement vers la sécurité, et dans quel délai ?
- Existe-t-il une politique renforcée pour les comptes en départ, et s’applique-t-elle bien à tous les canaux ?
- Les prestataires et intérimaires sont-ils couverts, alors qu’ils passent souvent hors du circuit RH ? Le sujet rejoint celui des fuites chez les tiers et sous-traitants.
- Les alertes générées sont-elles traitées par quelqu’un, ou tombent-elles dans une file que personne ne lit ?
Et chez vous ?
Vos contrôles verraient-ils un départ préparé ?
Une démo guidée de 30 minutes, sur des jeux de résultats préétablis, pour voir comment une campagne restitue ce qui sort par chaque chemin de sortie.
Tester de façon éthique et encadrée
Tester la menace interne touche aux salariés. Un test mal cadré peut ressembler à de la surveillance individuelle, ce qui pose des questions juridiques et abîme la confiance. Le principe à tenir : on teste les contrôles, jamais les personnes.
Les règles du cadre
- Comptes de test dédiés. Les scénarios sont joués depuis des comptes et des postes créés pour l’exercice, pas en usurpant l’identité d’un collaborateur réel.
- Données factices uniquement. Les fichiers sortis sont des leurres qui imitent la forme de vos données sensibles sans en contenir. Si le test réussit à faire sortir quelque chose, aucune donnée réelle n’est exposée. Voir notre article sur les données factices en production.
- Validation écrite. Le périmètre, les canaux testés et les dates sont validés par la direction, le DPO et, selon votre organisation, les juristes et les instances représentatives du personnel.
- Information du SOC selon l’objectif. Si vous mesurez la détection, une personne référente est prévenue pour éviter une escalade disproportionnée. Si vous testez seulement le blocage, l’équipe peut être informée en amont.
- Destinations maîtrisées. Les comptes personnels, stockages externes et adresses de réception utilisés appartiennent à l’équipe de test et sont détruits ensuite.
- Restitution sur les contrôles. Le livrable parle de règles, de canaux et de configurations. Il ne désigne personne.
Les canaux à couvrir
- Messagerie sortante vers des domaines personnels (méthode détaillée dans DLP e-mail : tester vos règles)
- Téléversement vers un cloud personnel via le navigateur ou un client de synchronisation
- Partage externe depuis les outils collaboratifs (lien public, invité externe)
- Copier-coller dans un assistant d’IA générative
- Supports amovibles et impression
- Export massif depuis une application métier (CRM, ERP, GED)
- Postes en télétravail, hors VPN, où les contrôles réseau ne s’appliquent plus
Pour chaque canal, notez le résultat attendu (bloqué, averti, journalisé) et le résultat observé. L’écart entre les deux constitue votre liste de travail. Le cadre général de cette démarche est décrit dans notre guide du test d’exfiltration de données.
Rejouer dans le temps, pas une seule fois
Un test ponctuel donne une photographie. Or les règles DLP bougent : mise à jour d’un agent, nouvelle application SaaS adoptée par une équipe, exception ajoutée pour débloquer un projet et jamais retirée. Un canal fermé en janvier peut être rouvert en mars sans que personne ne le remarque. Le rejeu régulier des mêmes scénarios permet de mesurer la posture dans la durée et de repérer les régressions dès qu’elles apparaissent.
FAQ
Faut-il prévenir les salariés qu’un test de menace interne a lieu ?
Le test porte sur des comptes dédiés et des données factices, il ne surveille aucun salarié. Une information générale sur l’existence de contrôles de sécurité et de tests réguliers est néanmoins une bonne pratique. Faites valider le dispositif par votre DPO et vos juristes.
Un outil d’analyse comportementale suffit-il contre la menace interne ?
Non. Il aide à repérer des comportements atypiques, mais un départ préparé discrètement ressemble souvent à une activité normale. Il faut aussi des contrôles qui agissent sur les canaux de sortie, et la preuve qu’ils fonctionnent.
Par quel scénario commencer ?
Par l’envoi d’un fichier sensible factice vers une messagerie personnelle et un cloud personnel, depuis un compte placé dans le groupe des collaborateurs en départ. C’est simple, rapide et très révélateur.
Les administrateurs doivent-ils être inclus ?
Oui. Ils disposent souvent d’exceptions aux règles DLP. Vérifiez que ces exceptions sont justifiées, documentées et limitées.