DLP : éviter les fuites, sans colmater les brèches

La protection des données constitue, aujourd’hui plus que jamais, l’un des enjeux majeurs pour les entreprises. La pression sur le sujet est croissante : textes de lois (RGPD), demandes des régulateurs, menace cyber croissante, prise de conscience des utilisateurs, etc.

L’écosystème dans lequel évolue la donnée est, quant à lui, en constante complexification. En effet, les systèmes d’information, en pleine transformation, s’ouvrent sur l’extérieur et s’interconnectent avec différents services Cloud publics, constituant de nouvelles portes de sortie pour les données de l’entreprise.

 

Les événements menant à une fuite de données sont nombreux : négligence d’un employé, fraude interne, piratage par un tiers… Les moyens d’exfiltration eux aussi sont multiples : emails, Shadow IT, clés USB, imprimantes… En cas d’incident avéré, les conséquences peuvent être significatives. Les médias n’hésitent pas relayer avec insistance les cas de piratages menant à des fuites de données d’une grande entreprise, ce qui écornera durablement l’image de la marque. Les pertes financières liées sont également importantes, induites par les sanctions prévues des différents régulateurs et faisant suite à la perte de confiance des clients et partenaires.

 Le SI aujourd’hui, un écosystème complexe ouvrant de nombreuses voies à des fuites de données

 

Le DLP, un chantier rarement considéré mais à la portée de tous

Ce challenge de taille que constitue la lutte contre les fuites de données n’est cependant pas insurmontable. Certaines entreprises, et notamment les banques, ont pris de l’avance sur le sujet vis-à-vis d’autres secteurs d’activité, en déployant des outils prévenant la fuite des données appelés Data Leak Prevention (DLP, ou Data Loss Protection). Ces outils permettent notamment de suivre les données considérées comme sensibles et d’y appliquer des règles visant à contrôler les flux de données conformément aux politiques définies. Ces règles peuvent s’appliquer au niveau du terminal (poste de travail, serveur, etc.), de l’application (Office 365, etc.) ou du réseau (proxy, etc.).

La mise en œuvre de telles solutions nécessite cependant de mener un projet à part entière faisant intervenir à la fois le département de Sécurité de l’Information et les Directions métier. La complexité de cette réalisation sera modulée par trois facteurs principaux :

 

 

En effet, les problématiques à traiter et les solutions techniques à implémenter durant le projet dépendront des objectifs fixés par l’entreprise en termes de couverture du risque de fuites de données, ainsi que du niveau actuel des pratiques et méthodes de classification.

Il est par ailleurs impératif, lors de la mise en œuvre des solutions de DLP, de préserver l’expérience des utilisateurs, ces derniers ne devant pas voir leurs activités impactées par les mécanismes de protection. Les objectifs de sécurité devront ainsi nécessairement prendre en compte les besoins métiers, qui peuvent notamment impliquer l’échange d’informations sensibles avec l’extérieur.

 

Les bons tuyaux pour la réussite d’un projet DLP

Premièrement, la sélection de l’outil de DLP devra se baser sur les objectifs définis au lancement du projet concernant la structure des données à protéger et les canaux d’échange à analyser.

Certaines solutions du marché ont atteint un niveau de maturité avancé permettant de détecter si une donnée est sensible, quels que soient la structure de la donnée et le canal de transmission. La détection de données structurées est plus simple du fait que leur caractérisation est plus simple (par exemple : le nombre de chiffres est défini pour un numéro de sécurité sociale ou de carte de crédit). Concernant les données non structurées (80% des données selon le Gartner), la détection pourra se baser sur l’analyse des métadonnées introduites par la classification.

Par la suite, le cadrage du projet devra définir et formaliser les 4 grands chantiers caractéristiques d’un projet DLP, les clés du succès pour le déploiement de la solution :

 

La cartographie des données sensibles et la définition des règles de protection associées

Dans le cas où l’entreprise aurait déjà établi une cartographie répertoriant les données et traitements considérés comme sensibles, ainsi que les flux considérés comme légitimes, celle-ci constituera la base sur laquelle le projet DLP s’appuiera pour l’élaboration des politiques de DLP et des règles de protection fines.

Si cette cartographie n’existe pas, le projet DLP ne pourra aboutir sans l’implication forte des métiers sur le sujet. Il s’agira d’identifier avec eux, par Direction et par Activité, les données sensibles et les traitements associés. Cette première réflexion aboutira à la délimitation des traitements et des canaux de stockage et de transmission légitimes, à la fois à l’interne et l’externe de l’entreprise. Ce processus nécessite une collaboration rapprochée avec des contributeurs clés des différentes directions qui pourront lors d’entretiens fournir les informations nécessaires.

L’équipe projet peut alors à ce stade, créer les politiques de DLP associées aux scénarios assimilés à une fuite de données.

Les retours des grands comptes montrent toutefois qu’un facteur clé de la réussite du projet est de savoir choisir ses combats ; il est en effet illusoire de vouloir implémenter – à minima dans un premier temps – l’ensemble des potentielles politiques de DLP. La bonne couverture des données les plus critiques de l’entreprise sera déjà preuve d’un niveau de maturité satisfaisant vis-à-vis de l’état de l’art.

 

L’identification des contraintes réglementaires et légales s’appliquant aux traitements analysés

Les réglementations concernant les données sensibles, telles que les données à caractère personnel (Loi informatique et liberté, RGPD, etc.) imposent des restrictions particulières sur les traitements autorisés sur ces données. De plus, pour les entreprises évoluant dans un contexte international, des particularités réglementaires locales existent et créent une hétérogénéité quant aux règles à respecter concernant les traitements sur les données.

Pour les aspects de conformité légale, il est important de s’appuyer sur les compétences des départements Légal et Conformité de l’entreprise et des différentes entités internationales, qui pourront valider les analyses et règles de protection appliquées sur les données.

Les principaux points à adresser lors de cette Due diligence réglementaire sont le traitement des données à caractère personnel, la notification des utilisateurs sur les traitements effectués, le lieu de stockage des données analysées et les canaux de transfert utilisés.

 

La définition du processus de gestion des incidents de fuite de données

La déclinaison opérationnelle des scénarios de DLP précédemment théorisés requiert ensuite de définir les moyens et processus à mettre en œuvre lors de la détection d’une fuite de donnée. Ceux-ci devront bien sûr s’adapter aux processus de gestion des incidents au sein de l’entreprise :

  • Qui recevra les alertes liées aux potentielles fuites de données (le SOC dans le cas où il existe, une équipe dédiée liée à une Direction métier, etc.) ?
  • Quels moyens mettre en place lors de l’investigation sur le périmètre impacté (ex : dans le cas d’un périmètre sensible, l’enquête doit respecter une certaine confidentialité) ?
  • Selon le niveau de criticité, quels niveaux hiérarchique et opérationnel contacter ?

À la différence d’incidents de sécurité techniques, il pourra être pertinent d’intégrer dans le processus des équipes métier ou le responsable sécurité de l’entité concernée afin de définir la criticité d‘une fuite de données et le périmètre impacté. En effet, dans le cas d’une donnée structurée, la criticité peut être évaluée simplement via des grilles de correspondance, mais cette réflexion est d’un tout autre ordre dans le cas de donnée non structurées (ex : email d’un responsable hiérarchique ou document lié à un projet confidentiel).

Un fort sponsorship sera également requis afin que les objectifs et moyens mis en œuvre dans le cadre du DLP soient approuvés par les différentes Directions Métier, le département Ressources Humaines ainsi que les représentants du personnel.

 

L’implémentation d’un outil adapté aux scénarios définis

En parallèle de la définition de processus de gestion d’incidents, vient la concrétisation du modèle de supervision avec le choix d’un outillage. Outre l’adéquation avec les scénarios de détection définis, l’outil choisi devra respecter un certain nombre de prérequis liés à l’écosystème de l’entreprise et à la Due diligence réglementaire réalisée. Parmi les critères de choix, la solution technique devra notamment :

  • S’intégrer avec les outils du SOC (SIEM, etc.) et idéalement avec les autres solutions de sécurité de l’entreprise (proxy, outils de chiffrement / DRM, etc.) ;
  • Être adapté à l’environnement métier (plateformes collaboratives, serveurs de fichiers, etc.) ;
  • Prendre en compte la diversité du parc informatique et du système d’information dans le cas de déploiement d’agents sur les terminaux.

Par ailleurs, une implémentation efficace d’une stratégie de DLP devra impérativement couvrir l’ensemble des canaux d’échanges et des cas d’usages métiers, afin de ne pas laisser de vannes ouvertes (ex : installer un outil DLP au niveau des serveurs mail et de fichiers tout en laissant les ports USB sans surveillance aucune).

Les 4 piliers du DLP

 

L’implémentation de la solution ne marque pas la fin du sujet DLP : le processus de Data Leak Prevention devra entrer dans une démarche d’amélioration continue. L’étude des faux positifs et les remontées d’alertes devront aboutir à une revue régulière (à minima tous les 6 mois) afin d’améliorer les scénarios de détection implémentés. Pour cela, il sera intéressant de prévoir dès la genèse du projet cette charge dans les équipes de Run et de commencer avec des scénarios basiques.

 

 

Il sera également intéressant d’inscrire les objectifs du projet de Data Leakage Prevention dans un programme plus large traitant de la protection de la donnée, incluant la revue des droits et des habilitations liés aux serveurs de fichiers, l’authentification avec accès conditionnel, l’intégration de la supervision avec le SOC et le chiffrement des fichiers et applicatifs.

Back to top