Le DLP n’est pas, comme certains peuvent l’imaginer, le blocage de la sortie de toutes données confidentielles. Dans beaucoup d’entreprise les informations les plus sensibles doivent pouvoir être transférées vers des tierces parties pour des raisons légitimes (régulateur, partenaire commerciale, client,….). Cela peut se traduire, entre autres, par :
- le besoin d’envoyer un email vers un cabinet d’audit,
- de poster des documents sur des data room externe à l’entreprise,
- de copier un document sur une clé USB pour aller le présenter en dehors de l’entreprise,
- d’imprimer un document pour le faire signer par un partenaire.
Dans un monde parfait, tous ces processus seraient connus, identifiés et maitrisés et on pourrait connaitre par anticipation ces destinations potentielles ou les personnes pouvant effectuer ces actions. Cela permettrait, dès la définition des politiques, de mettre en place des exceptions liées à l’activité de l’entreprise. J’ai rarement rencontré ce monde parfait…..
Pour pallier à ce problème, il est nécessaire de prévoir la possibilité pour les collaborateurs de l’entreprise de demander des exceptions de sécurité (qui devront bien sûr être dument validées suivant les processus de l’entreprise).
Ces exceptions peuvent être anticipées par les métiers ou alors être demandées suite à la détection d’une sortie d’information et dans ce cas, je conseille de mettre en place un status spécifique dans le DLP qui permettra de reconnaitre ces événements spécifiques.
Ensuite le traitement de ces exceptions de sécurité au sein du DLP peut se faire de différentes façons :
- Ajout d’exception (de détection, de personne ou de destination) dans les politiques DLP
- Modification des règles de détection pour ajouter un critère spécifique
- Adaptation des niveaux de sévérité des règles pour déclencher des actions de remédiations différentes selon la sévérité de l’incident
- Implémentation de l’exception dans une « flexresponse »
- ….
Ces méthodes fonctionnent bien et permettent de réduire le nombre d’événement devant être qualifié par les personnes en charge du processus de traitement des incidents DLP. Elles ont tout de même un inconvénient majeur, du point de vue de la sécurité, car on perd toute traçabilité de la sortie de ces informations confidentielles. C’est pour cela que l’on peut envisager une troisième méthode, qui consiste à mettre en œuvre un custom lookup plugin analysant l’incident pour vérifier s’il correspond ou non à une exception de sécurité, cela présente plusieurs avantages :
- On conserve la traçabilité de ses sorties d’informations confidentielles (nombre de sortie, contenu,…)
- On peut baser les exceptions sur plus de critères car le plugin a accès à l’ensemble des « custom attribute » (par exemple le département de l’utilisateur, son type de contrat,….)
Il comporte aussi un certains inconvénients qu’il ne faut pas négliger selon le déploiement DLP mis en œuvre dans votre entreprise :
- Ce plugin n’est pas fourni, il faudra donc le réaliser
- Ces exceptions ne peuvent pas être prises en compte pour décider de déclencher ou non des actions de remédiations (blocage, chiffrement, mise en quarantaine,…) car elles seront analysées au niveau de l’enforce donc après l’exécution effective de l’action par l’utilisateur.
Il n’y a pas de bonnes ou de mauvaises méthodes pour mettre en place la gestion de ces exceptions par contre ne pas les prendre en compte entrainera le traitement d’événement qui pourrait être évité et l’impression pour les équipes métiers que (« comme d’habitude » J ) la sécurité ne prend pas en compte leurs contraintes de travail.