Data Loss Prevention (DLP) : comment se protéger contre la fuite de données dans le cloud ?

L’utilisation de services de cloud publics comme Microsoft 365 qui virtualise nos postes de travail est en constante augmentation en Suisse. De plus en plus de données sont stockées dans le cloud alors même que les exigences en matière de protection des données se renforcent.

Car bien que les données soient stockées dans le cloud, la responsabilité de leur protection et de leur sécurité reste du ressort des entreprises. Celles-ci doivent assurer que toutes les exigences réglementaires et légales sont remplies. Avec l’entrée en vigueur de la nouvelle loi sur la protection des données (nLPD) le 1^er septembre 2023, ces exigences vont encore augmenter. Des mesures techniques et organisationnelles en matière de protection des données personnelles vont être exigées.

Data Loss Prevention : qu’est-ce que c’est ?

Dans le cadre de la protection des données personnelles, on utilise souvent le concept marketing abstrait de « Data Loss Prevention » ou « Data Leak Prevention », « DLP » pour faire court. Le terme de DLP regroupe les stratégies ainsi que les solutions matérielles et logicielles qui permettent d’éviter des fuites involontaires de données.

C’est en particulier dans le cas de Microsoft 365 (M365) que règne la supposition que la solution de DLP intégrée – Purview – puisse couvrir sans faille les exigences en la matière. En pratique, on constate cependant que de nombreuses entreprises éprouvent des difficultés avec les produits standards de DLP des fournisseurs (Microsoft n’est pas le seul concerné).

Domaine d’application de la DLP et la conformité avec le standard ISO 27002

Trouver de la littérature de référence sur la DLP est une entreprise plutôt ardue, et, si en plus cette littérature doit être en français, il vaut peut-être mieux ne pas se lancer dans une recherche du tout. Les principaux fournisseurs de DLP, Forcepoint, Symantec (aujourd’hui Broadcom) ou Trellix (autrefois McAfee) utilisent chacun leur propre terminologie, plus ou moins bien définie sur leur site web.

Sur les sites web d’autres fournisseurs, qui ne proposent pas de suite de DLP indépendante, mais qui ont plutôt intégré des fonctionnalités complémentaires de DLP à leur infrastructure de systèmes existante. On peut citer l’exemple de Microsoft : on trouve sur leur site des descriptions de Purview, leur solution de DLP native, qui est avant tout capable de scanner la plateforme M365 pour identifier de potentielles infractions à la DLP.

Un système de DLP peut empêcher les fuites non intentionnelles de données grâce à trois différents canaux de DLP. Parmi eux, on compte les canaux de données suivants :

• Data at Rest (données au repos) : p. ex. lorsque des fichiers sont sauvegardés dans le cloud ou sur un serveur de fichiers ou lorsque des données sont stockées dans une base de données.
• Data in Motion (données en transit) : p. ex. lorsque des données sont partagées par e-mail ou sont téléchargées sur internet par le biais du navigateur.
• Data in Use (données en traitement) : p. ex. lorsque des données sont traitées sur un terminal, stockées sur un périphérique de stockage (USB) ou imprimées.

En tant que mesure technique, la DLP a aussi trouvé sa place dans le standard ISO 27002 :2022 (chapitre 8.11), actualisé et mondialement appliqué, qui concerne la sécurité de l’information. Avec l’utilisation croissante des services de cloud et des appareils mobiles, il convient de tenir compte de la DLP comme mesure de protection contre le risque d’une perte de données à différents niveaux, comme le web, le réseau ou les périphériques qui traitent des données sensibles.

Les solutions de DLP « Out of the Box » comme Purview de Microsoft ne sont qu’une aide partielle

Les fonctionnalités de base (reconnaissance des événements basée sur des Runbooks standards) des produits de DLP proposés sur le marché sont des solutions de masse pour pouvoir satisfaire un très large panel de clients avec une solution « de démarrage ». Deux aspects essentiels tels que la gestion des incidents et la gestion des stratégies ne sont cependant qu’insuffisamment couverts par les produits de DLP standards. Étant donné que ces deux exigences sont très variables d’un client à l’autre, les fonctionnalités de bases ne sont dans la plupart des cas pas suffisantes.

En ce qui concerne la majorité des solutions de DLP et d’ITSM, la gestion des incidents consiste avant tout en une liste de tâches. Les incidents de sécurité dans le cadre de la DLP sont gérés de la même manière que tous les autres incidents de sécurité. Les événements de DLP sont cependant nettement plus proches du monde de l’entreprise que de la technicité de l’informatique. De plus, la plupart des solutions reposent sur le modèle d’accès basé sur les rôles (RBAC), ce qui complique le traitement décentralisé des incidents de DLP.

Selon le type de l’événement de sécurité, cela entraine un travail manuel important, étant donné qu’un événement de DLP peut générer un nombre imprévisible d’incidents. Sans automatisation du côté de la gestion des incidents ou des cas, le temps de traitement par événement est beaucoup plus élevé.

Dans le domaine de la gestion des stratégies, la logistique de données est un aspect central tant lors de l’implémentation initiale que de l’exploitation opérative. En logistique des données, il s’agit d’exporter, d’agréger, de nettoyer (augmenter la qualité des données pour les indexes de recherche), de sélectionner et, après indexation, d’importer les données brutes des systèmes sources dans le système de gestion de DLP.

En raison des activités répétitives dans le domaine de la logistique des données, une automatisation est la seule alternative viable. De plus, dans le cas d’une solution manuelle, les données nécessaires à l’indexation comme les noms des clients, les adresses ou des IBAN devraient être transmises aux prestataires externes. Mais la confidentialité rend cela impossible pour la plupart des entreprises.

Une meilleure détection grâce aux « Fingerprinted Policies » plutôt qu’aux « Regular Expressions »

Il existe différents types de règles de DLP qui aident à identifier les données critiques et qui exécutent une action selon une règle prédéfinie, comme « bloquer ». Parmi les règles les plus connues, on peut citer les règles de modèles de recherche descriptifs qui sont basés sur les « expressions régulières », des chaînes de caractères types donc.

Un bon exemple d’une chaîne avec ces propriétés est les numéros d’IBAN. Les IBAN sont, en suisse, des chaînes de 21 caractères qui sont présentés par blocs de quatre caractères. Même si ce n’est pas forcément flagrant, ces 21 caractères suivent un modèle bien particulier. Ainsi un numéro d’IBAN suisse (p. ex. CH99 0099 0999 0123 4567 9) doit toujours être représenté avec des espaces et sans caractères spéciaux (p. ex. séparateurs), car sinon, on peut se retrouver avec de nombreux faux positifs. Aussi, des contraintes doivent être définies dans les modèles de recherche, afin d’éviter que les numéros d’IBAN des employé.e.s ne soient  analysés et bloqués.

Les « Fingerprint Policies », aussi appelées « List Policies » (stratégies de liste), permettent une détection beaucoup plus précise. La constitution de l’index nécessite ici les données brutes, p. ex. issues des systèmes de GRC (CRM). Ensuite, les données brutes définies telles que le nom du client, l’adresse ou le numéro de compte sont complétées dans des « blacklists » avec une valeur de hachage (hash value) afin de permettre une identification unique. C’est ensuite un examen des contenus qui permet la reconnaissance de ces données p. ex. dans un e-mail ou un document Office. Lors du balayage des données ou des documents, une valeur de hachage est constituée et comparée avec les valeurs de hachage créées lors de l’indexation. Si une correspondance est trouvée, un résultat positif est renvoyé et l’action correspondante prédéfinie est exécutée.

Gestion des incidents de DLP selon les stratégies « fan in » ou « fan out »

Étant donné que les incidents DLP générés représentent le plus grand bloc d’effort de l’exploitation opérationnelle, il est important d’avoir une stratégie de traitement économique. En principe, on fait la différence entre un traitement par escalade (fan in) et un traitement délégué (fan out) des incidents. Selon la taille de l’entreprise, ces deux stratégies peuvent être appliquées à la fois.

En général, une solution décentralisée est préférable, étant donné que la plupart des incidents de DLP surviennent dans le cadre de processus commerciaux « cassés » et que ce sont les supérieurs hiérarchiques qui sont les plus aptes à juger si l’incident est un faux positif ou s’il doit être analysé plus en détail. De plus, une intégration de la gestion des incidents de DLP dans un service d’assistance informatique ne serait pas raisonnable en raison d’un manque de ressources récurrent. En effet, ce service a déjà suffisamment de demandes et de perturbations informatiques à canaliser.

Une gestion des règles et des incidents de DLP à la carte ?

On peut maintenant se poser la question s’il existe vraiment sur le marché une suite de DLP qui reconnait les incidents de DLP techniques avec différents types de règles (p. ex. Exact Data Match, Waiver Mapping, …) tout en proposant en même temps des processus automatisés autour de la gestion des incidents et de la gestion des règles et qui rend ainsi le tout digeste et réalisable dans l’exploitation opérationnelle. Malheureusement, la réponse des fournisseurs actuels est NON.

Comme décrit plus haut, les produits de base des grands fournisseurs atteignent leurs limites. Heureusement, il existe sur le marché suisse des intégrateurs de DLP comme p. ex. l’entreprise e3 (à ne pas confondre avec la licence E3 de Microsoft !), qui étend ces fonctionnalités de base avec des fonctions matures, automatisées et flexibles, en particulier dans le domaine de la gestion des règles et des incidents. Une sélection à la carte d’un ensemble de règles “Exact Data Matching” et de processus automatisés de gestion des incidents est possible, au lieu de devoir les reproduire entièrement avec les outils de la solution du fournisseur. Même dans ce cas, le défi posé par une stratégie multicloud ou par la couverture de solutions SaaS externes ne serait pas résolu. Mais grâce à une solution combinée constituée d’un produit DLP de base et d’une extension avec la solution e3, tout niveau de protection souhaité peut être atteint.

Conclusion

L’importance de la protection et de la sécurité des données augmente encore nettement lorsqu’il s’agit du cloud. Les mesures défensives de base comme l’IAM (gestion des accès) ou un IDS (Système de détection des intrusions) ne suffisent plus pour reconnaitre, et si nécessaire empêcher préventivement, des flux de données intentionnels ou non. Une solution de DLP mature avec des processus automatisés dans le domaine de la gestion des incidents et des règles peut s’avérer une aide considérable. Bien entendu, en plus de la DLP, d’autres mesures supplémentaires telles que la classification des données, la gestion des droits ou un CASB (Cloud Access Security Broker) sont nécessaires afin d’assurer une protection complète de l’information.