Nous allons au travers de deux articles explorer les capacités de l’IA, en particulier celles du Machine Learning, pour la cybersécurité. Dans ce premier article, nous allons parcourir pas à pas les étapes d’un projet de Machine Learning focalisé sur un cas d’usage cybersécurité : l’exfiltration de données depuis le SI, sur un cas très simplifié. Nous en avons choisi un, mais les concepts de cet article sont applicables à tous les projets de Machine Learning et peuvent être transposés à tout autre cas d’usage, notamment cyber. 

Avant toute chose, de quoi parle-t-on ? 

Le terme d’Intelligence Artificielle (IA) regroupe toutes les techniques permettant aux machines de simuler l’intelligence. Aujourd’hui toutefois, lorsqu’on parle d’IA on parle très souvent de Machine Learning, l’un de ses sous-domaines. Il s’agit des techniques permettant aux machines d’apprendre une tâche, sans avoir été explicitement programmées pour. 

Pour nous professionnels de la cybersécurité, cela tombe bien : nous avons bien souvent du mal à décrire explicitement ce que nous voulons détecter ! Le Machine Learning nous offre alors de nouvelles perspectives, avec déjà de nombreux cas d’application, dont les principaux sont illustrés ci-dessous:

L’exemple d’un cas d’usage pour la cybersécurité ML-augmenté : le DLP 

Pour illustrer l’apport du Machine Learning à la cybersécurité, nous avons choisi de nous intéresser à l’extraction frauduleuse de données depuis le système d’information d’une entreprise. Autrement dit, le cas du DLP (Data Leakage Prevention), problématique rencontrée par un grand nombre d’entreprises. Nous souhaitons détecter les communications suspectes vers l’extérieur afin de pouvoir les empêcher. 

« Très bien mais… comment caractériser une communication suspecte ? » 

Par des volumes échangés importants ? Par une destination étrange ? Par une heure de connexion inhabituelle ?  

En réalité, notre problème est complexe à expliciter et ce que nous devons évaluer a de fortes chances d’évoluer dans le temps. C’est pourquoi, en utilisant uniquement des règles de détection statiques, nos équipes sécurité ont du mal à être exhaustives. Elles peuvent jouer sur les seuils de ces règles pour affiner les éléments détectés, mais se retrouvent malheureusement encore avec un nombre important de faux positifs à traiter. 

On comprend que le Machine Learning tel que nous l’avons défini précédemment peut nous être utile ici. Et si on essayait ? 

Etape 1 : Clarifier le besoin 

C’est ce que nous venons de faire ! 

Etape 2 : Choisir les données 

Quand on entend les mots Machine Learning, il faut généralement comprendre « données » pour alimenter les algorithmes. Beaucoup de données, et de qualité ! 

En demandant où aller chercher des données utiles pour notre cas d’exfiltration des données à notre métier demandeur (qui pour une fois est la cybersécurité !), le proxy web ressort comme grand gagnant : il voit passer quasiment tout le trafic sortant du SI. Nous récupérons donc ses logs, ils ressemblent à ça. 

« Ca m’a l’air bien compliqué tout ça… » 

Les data scientists ont en effet de quoi être perdus : d’une part l’ensemble est peu digeste, de l’autre, après consultation du métier-cybersécurité, tous les champs ne sont pas vraiment utiles pour notre cas d’usage. Nous en sélectionnons donc quelques-uns avec lui avant de poursuivre. 

Le résultat est plus exploitable par les data scientists ! 

Etape 3 : préparer les données 

Les data scientists peuvent maintenant « explorer les données » afin de garantir un apprentissage optimal de l’algorithme. Ici, ils nous remontent un élément surprenant dans la répartition de nos requêtes suivant leur volume d’upload. Puisqu’on souhaite détecter des exfiltrations de données, cette variable nous intéresse en effet particulièrement. 

La valeur de notre variable n’est pas distribuée, nous avons même un très fort volume à 0. 

« Mais, elles sont quand même nombreuses ces requêtes avec un volume d’upload nul, est-ce que c’est vraiment pertinent de les garder dans notre cas ? ».  

Effectivement, après discussion avec le métier-cybersécurité, il ressort que ces données n’apportent pas grand-chose pour notre cas d’usage. Nous décidons donc de les retirer, notre jeu est alors distribué comme suit : 

Après plusieurs allers-retours entre les data scientists challengeant les données avec un point de vue statistique et les équipes cybersécurité répondant avec leur œil métier, les données sont simplifiées au maximum. Elles sont ensuite : 

• Enrichies en créant de nouvelles variables plus denses en information utile. Nous avons introduit un volume d’upload relatif vers chaque site, mesurant l’écart entre le volume d’upload d’une requête et sa valeur moyenne observée sur les 90 derniers jours. Nous pourrions également ajouter la durée de connexion par exemple. 
• Normalisées en réduisant l’amplitude de chaque variable pour diminuer une sur ou sous-pondération de certaines variables.
• Numérisées, la plupart des algorithmes ne pouvant interpréter que des variables numériques.  

Nous pouvons maintenant séparer notre jeu de données en deux : un jeu allant servir à l’entraînement de notre modèle, un jeu qui nous permettra de tester sa performance. Plusieurs méthodes de séparation existent, permettant de conserver certaines caractéristiques des données (e.g. la saisonnalité), mais l’objectif reste le même : garantir une mesure d’évaluation au plus proche des performances réelles du modèle, en présentant au modèle des données qu’il n’a pas eu a disposition durant l’entraînement. 

Etape 4 : Choisir la méthode d’apprentissage et entrainer le modèle 

Certains algorithmes sont plus performants que d’autres pour une problématique donnée, il convient donc de faire un choix raisonné. 

Il existe deux principales catégories d’algorithmes de Machine Learning :  

• Supervisés, lorsque l’on a des données labelisées comme référence à donner en exemple à notre algorithme. Ces algorithmes sont par exemple utilisés en cybersécurité par les solutions anti-spam : ils peuvent apprendre via la classification des emails comme spam par les utilisateurs par exemple. 
• Non supervisés, lorsque l’on ne sait pas précisément ce qu’on souhaite détecter ou que l’on manque d’exemples à fournir à l’algorithme pour son apprentissage (i.e. nous manquons données labélisées). 

Comme expliqué plus haut, le contexte de notre cas d’usage nous oriente plutôt vers la deuxième option. C’est d’ailleurs pour les mêmes raisons que nous avions initialement pensé au Machine Learning. Nous choisissons ensuite notre algorithme d’apprentissage non supervisé (Isolation Forest ici, mais nous aurions pu en choisir un autre) et entrainons notre modèle. 

Etape 5 : Analyser les résultats 

Nous utilisons notre jeu de données de test pour évaluer l’efficacité de notre modèle pour détecter les cas d’exfiltration.  

Le modèle conçu permet de détecter des patterns dans les données (requêtes), pour ensuite comparer les nouvelles données (requêtes) avec ces patterns et mettre en lumière celles qui s’éloignent de ce qu’il considère comme la norme de par son apprentissage (score d’anomalie).  

Voici nos résultats :  

« Ok, mais comment j’interprète tout ça ? » 

Le graphique à gauche représente les scores d’anomalie associés à chaque requête du jeu de test, triés par ordre chronologique. A droite se trouvent les logs présentant les scores d’anomalie les plus importants. 

Après investigation avec le métier-cybersécurité : 

• Le pic en jaune, correspond à un upload de volume beaucoup plus important que les autres, d’un utilisateur qui extrait un large volume de données. Cette anomalie est légitime. Toutefois, une alerte sur la base d’une règle statique sur le volume par requête aurait également permis de détecter cette communication suspecte. 

• Plus intéressant maintenant, les pics en rouge, correspondent à des requêtes de faibles volumes d’upload régulières vers des sites inconnus depuis le même utilisateur. Ces anomalies sont plus difficiles à détecter avec des moyens classiques, pourtant notre algorithme leur a attribué le même score d’anomalie que pour un large volume. Elles deviennent donc tout aussi prioritaires à qualifier pour nos équipes de gestion des alertes de cybersécurité. 

Maintenant, focalisons-nous sur le large paquet au centre du graphique (en orange). Le premier jour, on observe un score d’anomalie important, il s’agit d’un envoi soudain de données par de nombreux utilisateurs vers le site web de transport en commun de la ville. Après investigation on se rend compte qu’il ne s’agit pas d’un vrai incident de sécurité, mais de l’envoi annuel de justificatifs pour poursuite des abonnements de transport (nous sommes début septembre…). On observe par la suite que l’algorithme « comprend » que ces flux reviennent chez plusieurs utilisateurs et les intègre progressivement comme une habitude. Le score de risques décroit donc jour après jour. 

Le modèle détecte donc ce qui sort de la norme, quelle que soit la norme et s’autocorrige avec l’expérience. C’est en cela que le Machine Learning tient une vraie valeur ajoutée par rapport aux méthodes classiques de détection. 

Si la performance du modèle sur ce premier cas d’usage simplifié permet d’attester de la valeur potentielle du Machine Learning, il peut être temps de passer à l’étape 6 – le déploiement à l’échelle !  

Dans un second article nous reviendrons sur ces étapes pour mettre en lumière les facteurs de réussite et pièges à éviter lorsqu’on souhaite étudier les possibilités du Machine Learning en cybersécurité. 

Cet article Booster sa cybersécurité grâce à du Machine Learning ?  Partie 1 – « Absolument, voici comment! » est apparu en premier sur RiskInsight.

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.

Cet article DLP : éviter les fuites, sans colmater les brèches est apparu en premier sur RiskInsight.

La question n’est donc plus de savoir si la donnée peut fuiter (intentionnellement ou non) et être exfiltrée, mais plutôt de savoir comment la sécuriser afin de limiter les impacts en cas de fuite.

Dans ce contexte, les modèles de sécurité doivent s’adapter. Celui du château-fort est largement dépassé, celui de l’aéroport est en passe de l’être. Il devient alors nécessaire d’avoir une protection centrée sur la donnée (ou data-centric). Cette protection doit de plus répondre aux exigences d’expérience utilisateurs des métiers qui rechignent à être impactés dans leurs utilisations quotidiennes.

2 typologies de données distinctes … qui nécessitent une approche différente

Les grands projets de protection de la donnée lancés au sein des grands comptes se sont tous confrontés au même problème : comment connaître le niveau de sensibilité d’une information ? La réponse à cette question est fondamentale car elle est nécessaire pour appliquer un niveau de protection pertinent et éviter les fuites de données.

Il existe aujourd’hui deux typologies de données :

• Les données structurées désignent l’ensemble des informations répondant à un type de format et aisément identifiable en tant que tel : un champ CRM, numéro de sécurité sociale, formulaire Cerfa, adresse mail, ainsi que tout autre donnée pouvant être exprimées sous forme d’expressions régulières (1). Il s’agit communément des informations que l’on retrouve dans les bases de données des applications.
• Les données non structurées, à l’opposé des données non structurées, peuvent prendre n’importe quel type de format (document Office, PDF, image, vidéo, musique, fichier d’une application métier, etc.). Il est à noter qu’une donnée qui au premier abord serait considérée comme structurée (ex : champ téléphone d’un CRM), pourrait ne pas l’être si le respect de la syntaxe n’est implémenté.

Alors qu’il est aisé d’identifier automatiquement une donnée structurée, et d’en décrire la sensibilité selon des grilles prédéfinies ; la problématique est d’un tout autre ordre dans le cas des données non structurées, ces dernières représentant pourtant la plus grande part des données produites quotidiennement par les collaborateurs. Cela se traduit concrètement par l’incapacité des outils de sécurité (ex : Data Loss Prevention ou DLP) à repérer toute fuite ou manipulation suspecte d’informations vitales.

La classification des données non structurées apparaît alors comme la pierre angulaire d’une stratégie de protection de la donnée, via une action manuelle de la part de l’utilisateur final.

Qu’est-ce que la classification ?

Le sujet de la « classification de la donnée » regroupe l’ensemble des processus techniques et organisationnels permettant de catégoriser l’information produite par les collaborateurs d’une organisation. Suivant la catégorisation établie – par niveau de sensibilité (ex : interne, confidentiel, secret, etc.) ou par métiers concernés (ex : RH, R&D, achat, etc.) – la classification permettra de faire rentrer la donnée dans un cadre réglementaire, législatif ou de sécurité.

Historiquement très basiques (case à cocher dans un en-tête ou sur la première page d’un document ou ajout manuel de métadonnées), les solutions de classification se consolident et responsabilisent l’utilisateur en le plaçant au cœur du processus ; lui proposant ainsi une expérience améliorée (interface simple et conseils).

En pratique, les outils de classification offrent des fonctionnalités diverses :

• Pour les nouveaux fichiers, classification à la main de l’utilisateur ou déterminée automatiquement selon des règles prédéfinies (ex : présence de X numéros de sécurité sociales) ;
• Pour les fichiers existants, scan manuel des fichiers présents sur les répertoires locaux ou on-premise selon des règles prédéfinies ;
• Ajout sur le fichier de métadonnées (ou tagging) : ces métadonnées, interprétables par des outils tiers, permettent de donner de visibilité aux outils de supervision, type Data Loss Prevention ;
• Ajout d’éléments de marquage visuels (en tête, pied de page, filigrane) pour sensibiliser les utilisateurs finaux.

Des résultats peu probants à ce jour pour les projets de classification

Bien que les filières RSSI soient sensibles au sujet de la classification et des données et que le sujet soit inscrit au cœur des politiques de la majorité des grandes entreprises – obligation renforcée par les récentes règlementations comme le GDPR ou la LPM qui requièrent de cartographier les données et les usages – peu d’organisations, en dehors des établissement bancaires, ont réussi à mettre en place une stratégie efficace de classification.

Plusieurs raisons peuvent expliquer cette lacune :

• Les utilisateurs finaux n’ont généralement pas la connaissance de la nature des données sensibles ou de leur impact : alors que le niveau de classification le plus élevé (« C4 », « Secret », « Confidentiel », etc.) correspond aux documents susceptibles de mettre en péril une entité voire le Groupe tout entier – ce qui correspond à habituellement 1% des informations –  cette proportion avoisine les 10% dans certaines entités. A l’inverse, il n’est pas rare qu’un utilisateur partage des fichiers contenant des données à caractères personnel sensibles ou des fichiers de mot de passe sans aucun niveau de classification ni aucune protection.
  Ainsi, tout projet de classification des données nécessite un fort accompagnement au changement des utilisateurs finaux avec des messages clairs et des exemples concrets, lui permettant de classifier aisément ses informations. Des rappels récurrents seront également nécessaires pour rappeler les bonnes pratiques. En effet, un utilisateur manipulant au quotidien des données sensibles, pourrait ne plus se rendre compte de l’impact de la divulgation de celles-ci.
• Faute de mettre à disposition de ses utilisateurs des moyens suffisamment ergonomiques, une entreprise ne peut s’attendre à des résultats probants. L’expérience montre en effet que les cases à cocher avec les niveaux de classification dans les pages de garde, les en-têtes ou les pieds de pages ne sont que très peu sélectionnées.
• La classification de l’ensemble des données de l’entreprises est un projet de transformation à part entière, et nécessite un fort engagement des équipes métiers et de la direction si on souhaite la généraliser. Cet engagement doit être d’autant plus important si la stratégie de classification définie impacte les utilisateurs (obligation de classifier les documents, de chiffrer, etc.).

Le retour de la classification sur le devant de la scène

Toutefois, la thématique revient en force au sein des grands comptes, poussée par les programmes de transformation digitale – qui nécessitent de repenser la protection des données – et par les acteurs du marché – qui consolident leurs offres autour du sujet. Certains analystes comme le Gartner, anticipent même le regroupement des solutions de protection de la donnée en une unique solution centrée sur la classification.

Afin d’être un succès, il sera opportun d’allier sensibilisation et ergonomie, afin d’embarquer les utilisateurs finaux dans cette démarche. L’un ne pourra pas aller sans l’autre.

Nous étudierons dans un prochain article comment le marché évolue autour d’acteurs de la sécurité historiques et comment la mise en place d’une stratégie efficace de classification apporte des bases solides pour (re)donner un nouveau souffle à la thématique de la protection des données.  

(1) Une expression régulière, est une chaîne de caractères, répondant à une syntaxe précise. Par exemple, un numéro de téléphone française peut prendre l’un des trois formats suivants : 0123456789, +33123456789 ou 0033123456789.

Cet article La classification, cet incontournable de la protection des données est apparu en premier sur RiskInsight.

Un apport des DLP complémentaire à la lutte contre l’intrusion et au contrôle d’accès

Une fuite d’information peut provenir de trois sources différentes. L’attaquant externe est souvent celui qui vient à l’esprit en premier. Cependant, l’expérience montre que ce sont les utilisateurs internes, autorisés ou non, qui font fuir le plus d’information.

Suivant la position de celui qui fait fuir l’information, trois grandes étapes peuvent être enchaînées : intrusion, accès à l’information, diffusion de l’information – dont la nécessité dépend des accès initiaux de l’acteur à l’origine de la fuite d’information. À chacune de ces étapes, des solutions de sécurité permettant de réduire le risque existent.

Il convient d’agir à toutes les étapes d’une fuite d’information en s’appuyant sur des mesures allant de la sécurité physique aux solutions de Digital Right Management (DRM), en passant par le chiffrement de flux, le cloisonnement, ou encore la gestion des accès et des habilitations…

Si de telles mesures sont déjà mises en œuvre, les outils de DLP permettent alors essentiellement de se prémunir contre des erreurs ou malveillances d’utilisateurs ayant un accès légitime à l’information. En ce sens, ils permettent d’apporter une protection au plus proche de la donnée.

Des solutions fonctionnellement matures

Les mécanismes de contrôle des DLP sont mis en œuvre à travers des règles ou politiques centralisées permettant d’analyser les traitements faits sur la donnée quelle que soit sa nature ou son support.

Grâce à des agents déployés sur le réseau et/ou sur les postes de travail, le DLP va pouvoir empêcher la copie d’un fichier sur un périphérique externe, l’envoi d’un document sensible par email, l’impression d’un document ou encore la publication d’une information confidentielle sur les réseaux sociaux.

Après analyse et filtrage des données par la solution DLP, différentes mesures de prévention peuvent être prises, avec un impact plus ou moins élevé pour l’utilisateur : alertes, demande de justification, blocage…

Enfin, il convient de noter que les acteurs du marché mettent de plus en plus l’accent sur le contexte d’utilisation de la donnée. Certains éditeurs proposent ainsi des fonctionnalités de gouvernance au sein de leur solution de DLP permettant par exemple de savoir exactement où se trouvent les données sensibles et qui y a accès.

Le marché des DLP est donc de plus en plus mature : la couverture fonctionnelle proposée est élevée et évolutive, la gestion de l’impact sur les collaborateurs de plus en plus souple. Néanmoins, les retours d’expérience restent limités par rapport à ce que l’on pourrait attendre.

La raison de ce paradoxe vient du fait que les métiers sont trop souvent insuffisamment impliqués dans les projets de DLP, alors même que ces projets n’ont que peu de chance d’aboutir sans eux, en particulier vu le volet RH nécessairement associé.

Adopter une approche par les résultats pour mobiliser les métiers

Il est illusoire de vouloir protéger toutes ses données dans tous les cas d’usage imaginables. Une approche purement technique visant un périmètre exhaustif n’a que peu de chance de convaincre, particulièrement dans la conjoncture économique actuelle.

Une approche par les résultats mêlant ciblage précis, démarche outillée, accompagnement et visibilité est donc à favoriser dès la sélection de la solution. Une fois les objectifs atteints sur un périmètre prioritaire, on peut envisager de l’élargir.

La première étape, primordiale, est donc la définition du périmètre prioritaire de données à protéger et des cas d’usage fonctionnels à traiter. Identifier les dix données les plus critiques, s’appuyer sur des situations fonctionnelles avérées, commencer par un nombre limités de supports pour réduire les aléas techniques sont autant de facteurs clés de succès.

La définition des processus de surveillance (politiques d’interaction avec les utilisateurs, processus en cas d’alerte…) ne doit également pas être négligée. Sur ce volet, et dès le début du projet, il est important de mobiliser les fonctions RH de l’entreprise pour valider le mode de mise en œuvre de la démarche DLP (alerte, blocage, journalisation…), construire les processus de gouvernance associés et au final envisager un passage devant les instances représentatives du personnel.

Lorsque le cadrage global du périmètre fonctionnel est effectivement achevé, la phase de sélection de la solution peut être entamée. Une démarche outillée impliquant la réalisation d’une maquette est indispensable pour s’assurer de l’adéquation de la solution aux cas d’usages fonctionnels identifiés et évaluer les résultats envisageables.

En cas de résultats satisfaisants, un déploiement progressif est à envisager avec un leitmotiv : la sensibilisation des utilisateurs.

Enfin, en mode récurrent, l’intégration à un SOC (Security Operation Center) peut permettre de bénéficier de la maturité de la gestion opérationnelle de la sécurité pour optimiser la surveillance d’une part et l’accompagnement et la visibilité fournis aux métiers d’autre part.

Cet article Le paradoxe des projets de Data Leak Prevention (DLP) : une problématique clé, des solutions matures… mais une mise en œuvre qui fait encore peur est apparu en premier sur RiskInsight.