e-Xpert Solutions Genève

Chemin du Pont-Du-Centenaire 109
CH-1228 Plan-les-Ouates / Genève
SUISSE

Tel. : +41 22 727 05 55 Fax : +41 22 727 05 50

e-Xpert Solutions Lausanne

Avenue de Gratta-Paille 20
CH-1018 Lausanne
SUISSE

Tel. : +41 21 802 26 78 Fax : +41 22 727 05 50
Contactez notre support : +41 22 727 05 56
Envoyez votre message



Accédez au menu
Contactez-nous

Prévenir la fuite des données

Retour aux articles

Comment prévenir la fuite des données ?

Les best practices selon nos experts !


Catégorie : Articles

Date de publication : 12 février 2018 - Dernière mise à jour : 23 avril 2018

Rédacteur : Damien Lassus, Daniel Willame et Bérangère Thévenet


Soyons d’accord, la solution miracle n’existe pas ! Il est impossible de vous garantir zéro fuite de données ! Notre challenge est de limiter le plus possible l’impact d’un comportement déviant d’un de vos utilisateurs et le cas échéant permettre d’identifier la source de la fuite.


Maîtriser l’origine de ses fuites de données

Nous distinguons 2 types de fuites de données : Malveillantes et accidentelles.

Contrairement à ce que l’on pourrait imaginer, les fuites accidentelles sont légion dans de nombreuses organisations. Bien souvent, ces fuites viennent d’une méconnaissance des processus d’échanges des données au sein de l’entreprise. Dans de tels cas, une sensibilisation des utilisateurs à la sécurité suffit bien souvent à corriger ces erreurs de traitement.

La prévention des fuites de données nécessite des actions à plusieurs niveaux. Encore aujourd’hui de nombreux projets ne se concentrent que sur un chemin de fuite (très souvent le mail), mais il est important de couvrir l’ensemble des chemins de fuites afin de disposer d’une vision complète des traitements de données sensibles.

Afin de disposer d’une bonne couverture des fuites de données, nous pouvons agir dans un premier temps sur les points d’échanges avec l’extérieur (principalement les mails et le web). Il s’agit là de contrôler les données transmises en dehors de l’entreprise. Sauf cas spécifique, il n’est pas nécessaire de contrôler les données entrantes.

Une fois les chemins d’échanges avec l’extérieur couverts, il convient de sécuriser les traitements localisés sur les postes de travail via l’installation d’un agent en local qui réalisera un contrôle des données utilisées par chaque utilisateur. Via cet agent, il sera alors possible d’inspecter les copies de données sur clé USB, copiées dans un espace non sécurisé, imprimées, …

Les étapes clés d’un projet DLP

La mise en application d’un projet DLP passe par plusieurs étapes qu’il est important d’identifier. Aucune des étapes n’est à négliger si l’on souhaite une implémentation dans les meilleures conditions.

1. Identification des acteurs
Selon les environnements, plusieurs acteurs peuvent être identifiés autour de la solution DLP :

- Les administrateurs systèmes de la solution,
- L’équipe gérant les incidents,
- L’équipe en contact avec les auditeurs,
- L’équipe responsable des contrôles internes,
- Les utilisateurs,
- Les consultants externes.
- L’identification de ces acteurs est une phase importante.

2. Ségrégation des rôles

Comme tout projet lié aux données sensibles, il est primordial de s’assurer de la séparation des droits d’accès à cette plateforme. Pour cela, plusieurs questions doivent être soulevées afin de définir les rôles et limites de chacun :

- Qui sera en charge de la création et de la « récolte » des données sensibles ?
- Qui sera en charge de la mise en place des règles DLP ?
- Qui est sera en charge de l’évaluation des incidents ?
- Qui modifiera les droits d’accès depuis la console de gestion ?

3. Identification des données
Avant de réfléchir aux règles DLP à mettre en place, il est important d’identifier le référentiel principal contenant les données sensibles que l’on va devoir protéger.

Lors de cette phase, il est également important de contrôler la consistance des données afin de s’affranchir d’une gestion trop complexe de faux positifs une fois la solution en production. Il s’agit la d’une démarche complexe mais primordiale afin de ne pas être noyé sous des incidents générés par de multiples faux positifs.

4. Définition des règles DLP

Une fois les données identifiées, il est possible de créer les règles DLP correspondantes.

Lors de cette étape, il peut être nécessaire de définir des combinaisons de données à identifier.

Une bonne pratique dans cette configuration est de partir sur des seuils bas en les augmentant au fur et à mesure de l’avancement du projet.

Bien que la finalité d’un projet DLP soit de stopper les tentatives de fuites de données, il est primordial de commencer par une phase de surveillance sans implémenter de blocage. En effet, un tel projet va nous ouvrir les yeux sur certains traitements de données dont on n’avait pas forcément connaissance auparavant, ainsi il est difficile d’en anticiper les actions de prévention adéquates.

Voici un exemple de règle que nous pourrions mettre en application.

L’idée de cette règle est de mettre en surveillance les fuites de données d’une combinaison (Nom et Prénom) pour une population définie.

5. Découverte des données

La réalisation de cette étape nécessite une étude préalable car elle peut relever un nombre important d’incidents. En effet, l’idée est de lancer une analyse des différents systèmes (postes de travail, serveurs, …) pour cartographier la position et la quantité de données sensibles au sein du SI. Durant cette phase, nous nous apercevons très souvent que des données confidentielles sont stockées dans le Répertoire « Téléchargement » du poste de travail ou que certaines d’entre elles sont tout simplement mises à disposition sur un partage de fichiers publique. Les entreprises découvrent souvent avec horreur des rapports qui ressemblent à un sapin de noël laissant présager que des extraits de données confidentielles sont éparpillées partout dans le SI. Il est possible de réaliser cette étape dans un premier temps sur un volume de données/fichiers restreint.

6. Suppression des faux positifs

Selon les sources de données utilisées, un volume important de faux positifs peut être généré une fois la solution DLP activée en production, il est donc nécessaire d’anticiper cette phase et prévoir du temps pour ce traitement.

Il est possible par exemple de créer un groupe d’exceptions (vide dans un premier temps) que l’on assignera à chaque règle DLP afin de pouvoir la compléter selon les besoins d’exclusions de faux positifs.

7. Suivi des incidents
Une fois la configuration en place opérationnelle (volume de faux positifs acceptable et seuils stables), il est nécessaire de réaliser un suivi des incidents générés par la solution DLP installée. En effet, une fois la solution en place auditée, chaque incident devra faire l’objet d’une validation par l’équipe concernée.

Voici un incident généré selon la règle détaillée au point 4 (surveillance les fuites de données d’une combinaison (Nom et Prénom) pour une population définie).

Dans cet exemple, nous pouvons observer une fuite via un mail transmis de John Doe vers son mail personnel sur gmail.com. Ce mail contient une liste de huit données personnelles (couple Nom et Prénom). On peut voir dans cet exemple que l’aspect visuel de la solution en place est important, il faut pouvoir identifier l’ensemble des éléments de la fuite de données rapidement. Dans notre exemple, on peut visualiser le mail sur la partie de droite et ainsi prendre une décision sur le caractère volontaire ou non de la fuite de données.

8. Génération de rapports d’incidents

Les rapports que l’on génère doivent être simples, visuels et compréhensibles.

Voici un rapport indiquant le nombre d’incidents par sévérité, par action ainsi que par chemin de fuite.

Un autre type de rapport intéressant est de réaliser une corrélation des incidents en indiquant un indicateur de risque par rapport à une déviance de traitement normaux.

Voici un exemple de ce type de rapport. Dans notre cas, l’utilisateur John Doe a réalisé plusieurs transferts de données sensibles vers un site spécifique « MyStore » et a également transmis d’autres informations sur son mail personnel.

Ne pas oublier le DLP au niveau réseau (SMTP et HTTP)

La protection périmétrique est indispensable afin de garantir un niveau de sécurité des données adéquate. Néanmoins, il s’agit d’une phase assez délicate dans le sens où il est nécessaire de se « greffer » sur l’environnement informatique existant.

L’architecture qui en découle devra couvrir les besoins en surveillances sur plusieurs canaux : le trafic email et le trafic web.

- Surveillance du trafic email :
Concernant le trafic email, deux types d’architecture peuvent être mise en place :

1. Placer un équipement DLP dans le flux de messagerie,
2. Placer un équipement DLP en parallèle d’une passerelle email déjà en place.

La gestion du trafic email peut prendre en compte le chiffrement de celui-ci. Dans ce cas, il est primordial de placer judicieusement la plateforme de chiffrement afin de ne pas court-circuiter l’analyse DLP que l’on aurait placé dans notre réseau. Ainsi, il est préférable de réaliser l’analyse DLP au plus proche des serveurs de messagerie et dans tous les cas avant le processus de chiffrement.

- Surveillance du trafic Web :
Concernant le trafic web, comme pour le trafic email, deux types d’architectures sont réalisables :

1. Soit nous plaçons le proxy proposé par l’éditeur DLP qui en général intègre les fonctions DLP
2. Soit nous nous basons sur le Protocol ICAP en installant des serveurs ICAP (qui ont la fonction DLP) en parallèle des proxys existants.

DLP et ses fonctions avancées

Comme on a pu le voir, un projet DLP agit à plusieurs niveaux et les fonctions autours de ces solutions sont nombreuses. Néanmoins, certaines fonctions supplémentaires peuvent être un plus dans certains environnements.

Selon les solutions DLP retenues, il est alors possible de réaliser une extraction de texte contenu dans les images afin d’en contrôler le contenu. Dans ce cas, une impression d’écran réalisée par un utilisateur sur un document sensible pourra être détecté lors de sa transmission vers l’extérieur de l’entreprise. Cette technologie s’appelle OCR (Optical Character Recognition).

Limites et défis des solutions DLP

Aucune solution DLP garantit le zéro fuite ! L’objectif de ces projets est de contrôler les fuites de données dans la mesure du possible.

Les technologies d’aujourd’hui ont forcément des limitations qu’il est important de connaitre et d’anticiper. L’exemple le plus fréquent est la prise d’une photo d’un document à l’écran à l’aide de son smartphone personnel.

Prenons un autre exemple pour les flux HTTPS. Dans ce cas de figure, la transmission de données sensibles dans un canal sécurisé et chiffré pourrait permettre de passer au travers des mesures mises en place afin de contrôler les données sortantes de l’organisation. Pour d’anticiper ce point, il est nécessaire de revoir sa stratégie de contrôle au niveau des proxys existants. En effet, la plupart des proxys permettent la réalisation d’une interception sur le protocole SSL afin de pouvoir réaliser une analyse de son contenu.

Défis techniques d’une solution de DLP

Comment rediriger un flux proxy vers un outil de DLP ? Comment minimiser l’impact sur les performances d’une analyse OCR (afin d’extraire les données d’une image) ?

Pour répondre à ces problématiques, la solution DLP doit s’articuler autour d’une batterie de serveurs en charge de ces analyses.

- Pour le premier cas (l’analyse des flux proxy), l’installation d’une ferme de serveurs ICAP ayant pour rôle d’analyser les requêtes provenant du ou des proxy(s) est la solution optimale.

- Pour le deuxième cas (impact de l’analyse OCR), l’installation d’un serveur OCR pour chaque serveur d’analyse DLP permet de garantir des performances adéquates dans le cadre d’une extraction de données dans les images. L’efficacité de cette architecture va tout de même dépendre du besoin d’analyse d’images en sortie de l’entreprise. En effet, plus nous allons solliciter ce serveur avec des images volumineuses, plus son temps de réponse sera élevé.

Conclusion

Comme vu, une solution DLP agit à plusieurs niveaux, que ce soit pour son aspect organisationnel ou opérationnel.

Lors du lancement d’un projet DLP, il est important de procéder à un avancement par phase, de ne pas se précipiter sur une fonction ou une autre sans anticiper l’impact que cela pourrait avoir sur le traitement des règles et des incidents. N’oublions pas, également que nous manipulons vos données sensibles dans ce type de projet et à ce titre, il est nécessaire de disposer des autorisations adéquates afin de visualiser certains incidents qui pourraient être générés par une telle solution.

De nouveaux besoins peuvent naitre d’un projet DLP existant. Il est en effet fréquent que d’un besoin de couverture règlementaire viennent d’autres demandes de protection de données. Un exemple que l’on rencontre fréquemment est un besoin de contrôle de la bonne application de classification des fichiers sensibles. Pour couvrir ce besoin, une simple tâche d’analyse du système de fichiers permet de se rendre compte de l’application correcte des processus de classification instaurés dans l’entreprise.

Pour conclure, comment parler DLP sans en faire l’association avec le règlement européen (GDPR) rentrant en application dans quelques mois. Un projet DLP prend en effet tout son sens dans ce cas, car l’identification de fuites de données personnelles ou sensibles passe forcement par l’application d’une solution de DLP que ce soit par ses capacités pour contrôler les chemins de fuite mais également via son module de découverte de données dormantes.

Abonnez-vous
à nos newsletters