Un éditeur de logiciels cloud pour le secteur de l’assurance disposait d’un programme de sécurité des données mature pour les bases de données de ses applications principales. La classification était appliquée, les contrôles d’accès étaient en place et l’audit SOC 2 confirmait des contrôles appropriés sur ses systèmes principaux. Ce que l’audit n’avait pas examiné, parce que cela sortait du périmètre des systèmes principaux, c’était le système de tickets de support client du fournisseur. En six ans d’exploitation, les clients avaient soumis des tickets de support accompagnés de fichiers comprenant des documents de police d’assurance avec des numéros de sécurité sociale, des formulaires de sinistre contenant des informations médicales, des pièces d’identité numérisées et des exports de tableurs contenant des PII de clients, téléversés lors du diagnostic d’incohérences de données. Le système de tickets contenait environ quatorze mille pièces jointes sensibles. Aucune n’avait été classifiée. Aucune n’était gouvernée par le programme de sécurité des données. Le système de tickets a été compromis par une vulnérabilité distincte. La notification de violation décrivait l’exposition du contenu des tickets de support. Le régulateur des assurances a demandé si le fournisseur avait mené une analyse de découverte des données sensibles sur ses systèmes de support. La réponse était non.
Qu’est-ce que le problème des lacunes de découverte des données sensibles, réellement ?
La découverte des données sensibles est le processus systématique d’analyse de l’environnement de données d’une organisation afin d’identifier où se trouvent des données sensibles (informations personnelles, données financières, informations de santé, identifiants et autres catégories de données réglementées ou à forte valeur) dans les systèmes de stockage, les documents, les plateformes collaboratives et l’infrastructure opérationnelle. La lacune naît de la tension inhérente entre la façon dont les programmes de gouvernance des données sont conçus, à partir des référentiels de données sensibles connus, et la façon dont les données sensibles se répartissent réellement, en s’accumulant au fil des activités opérationnelles de chaque personne et de chaque système qui interagit avec le paysage de données de l’organisation.
Les programmes de gouvernance des données sont généralement conçus autour des systèmes qui collectent et stockent intentionnellement des données sensibles : bases de données clients, systèmes RH, plateformes financières, systèmes de dossiers de santé. Ces systèmes sont inventoriés, classifiés, gouvernés et inclus dans les évaluations de sécurité parce que leur finalité en matière de données sensibles est explicite et connue. La lacune de découverte apparaît dans la catégorie bien plus vaste des systèmes qui collectent fortuitement des données sensibles dans le cours normal des processus métier : systèmes de support où les clients transmettent des fichiers contenant des informations personnelles, plateformes collaboratives où les employés partagent des documents contenant des données sensibles, archives de messagerie où des informations sensibles circulent en pièces jointes, et systèmes opérationnels où des données sensibles arrivent comme contexte de la tâche à accomplir.
L’ampleur de l’accumulation fortuite de données sensibles est souvent sous-estimée. Dans toute organisation qui interagit avec des clients, traite des transactions ou gère des relations de service suivies, les données sensibles arrivent par les canaux de support, les demandes opérationnelles et les communications d’affaires dans des volumes qui éclipsent le jeu de données formellement géré. Le système de tickets de support d’un fournisseur du secteur de l’assurance peut accumuler en un an plus de données sensibles par les pièces jointes des clients que la base de données principale n’en ajoute sur la même période, car chaque client qui soumet une demande de support est susceptible de joindre le document qu’il a sous la main, souvent une police d’assurance, un formulaire de sinistre ou un relevé contenant ses informations personnelles.
Les lacunes de découverte des données sensibles se concentrent autour de cinq schémas d’accumulation précis :
- Pièces jointes des systèmes de support et de tickets : fichiers transmis par les clients contenant des données sensibles, téléversés comme contexte de demandes de support et accumulés dans des systèmes de tickets hors du périmètre principal de gouvernance des données
- Documents des plateformes collaboratives : données sensibles partagées dans des canaux Teams, des fils Slack, des dossiers Google Drive et des bibliothèques SharePoint dans le cadre du travail opérationnel, jamais formellement classifiées ni gouvernées
- Données sensibles dans les archives de messagerie : informations personnelles, données financières et identifiants transmis dans les pièces jointes et le corps des courriels, qui s’accumulent dans des archives de messagerie pouvant se trouver hors du périmètre de découverte du programme de gouvernance des données
- Collecte fortuite par les systèmes opérationnels : systèmes de journalisation, plateformes de surveillance, outils de signalement d’erreurs et bases de données opérationnelles qui accumulent des données sensibles comme effet secondaire de leur fonction principale de surveillance
- Données sensibles dans les environnements de développement et de test : échantillons de données de production copiés dans les environnements de développement, jeux de données de test contenant de vraies informations clients et artefacts de débogage qui capturent des données sensibles issues des systèmes de production
Pourquoi c’est important
Les lacunes de découverte des données sensibles sont importantes pour le TPRM parce qu’elles représentent la catégorie d’exposition des données invisible aux évaluations standard de la sécurité des fournisseurs. Un fournisseur qui confirme des contrôles appropriés sur ses systèmes principaux, réussit un audit SOC 2 limité à ces systèmes et tient une documentation complète de gouvernance des données peut détenir en même temps d’importants volumes de données sensibles de clients dans des systèmes qui n’ont jamais fait partie du périmètre d’aucune évaluation, d’aucun audit ni d’aucun programme de gouvernance. Les contrôles confirmés lors de l’évaluation s’appliquent aux systèmes évalués. La violation, quand elle surviendra, trouvera le système qui n’a pas été évalué.
La conséquence sur la notification des violations est la dimension à l’impact le plus immédiat. Lorsqu’un fournisseur subit une violation et que l’équipe de réponse aux incidents commence à en déterminer l’étendue, elle analyse tous les systèmes à la recherche de données sensibles, y compris ceux qui n’ont jamais fait partie du périmètre du programme de gouvernance. Les données sensibles découvertes dans ces systèmes lors de la détermination de l’étendue doivent être incluses dans la notification de violation, que leur présence ait été connue ou non avant la violation. Un fournisseur qui affirme gouverner correctement les données sensibles de ses clients peut voir sa notification de violation décrire l’exposition de données qu’il ignorait détenir, dans des systèmes qu’il n’avait jamais évalués, par des processus qu’il n’avait jamais considérés comme des activités de traitement de données.
La dimension de conformité réglementaire ajoute à l’urgence. Le principe de responsabilité du GDPR exige que les responsables du traitement et les sous-traitants puissent démontrer qu’ils connaissent les données personnelles qu’ils détiennent et la base légale qui les autorise à les détenir. Un fournisseur qui détient d’importants volumes de données personnelles dans des systèmes non analysés ne peut pas démontrer sa responsabilité au titre du GDPR pour ces données, puisqu’il ignore leur existence. La lacune de découverte est à la fois un risque de sécurité et une lacune de conformité réglementaire.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à limiter l’évaluation de la sécurité des données aux systèmes connus pour détenir des données sensibles, au lieu de rechercher les systèmes où des données sensibles ont pu s’accumuler sans gouvernance. Les évaluations qui partent de l’inventaire connu des données sensibles confirmeront la gouvernance des systèmes connus et passeront entièrement à côté de la lacune de découverte, car la question « ce système est-il correctement gouverné ? » ne peut être posée que pour des systèmes figurant à l’inventaire, et la lacune de découverte est précisément la lacune de l’inventaire.
La deuxième défaillance consiste à traiter la découverte des données sensibles comme un exercice ponctuel plutôt que comme un processus continu. Même les organisations qui mènent des analyses initiales de découverte des données constatent souvent que de nouvelles données sensibles s’accumulent dans des systèmes déjà analysés entre deux cycles d’analyse, et que de nouveaux systèmes sont créés ou adoptés sans déclencher d’analyse de découverte. La lacune de découverte réapparaît en permanence à mesure que l’environnement de données évolue.
- Limiter l’évaluation aux systèmes connus : évaluation de la gouvernance des référentiels de données sensibles identifiés, sans analyse de découverte des accumulations non identifiées
- Données des systèmes de support non évaluées : systèmes de support et de tickets en contact avec les clients non inclus dans le périmètre de découverte des données sensibles
- Aucune périodicité de découverte : analyses de découverte ponctuelles, sans nouvelle analyse périodique pour identifier les nouvelles accumulations de données sensibles
- Plateformes collaboratives non analysées : Teams, Slack, SharePoint et messagerie exclus du périmètre de découverte des données sensibles
- Environnements de développement et de test non analysés : données sensibles des environnements hors production non incluses dans le périmètre du programme de découverte
À quoi ressemblent les bonnes pratiques
Les programmes de découverte des données sensibles matures analysent l’ensemble de l’environnement de données (non seulement les systèmes connus pour contenir des données sensibles, mais tous les systèmes de stockage où des données sensibles ont pu s’accumuler) selon un calendrier défini, et les constats alimentent le programme de classification et de gouvernance en vue de la remédiation. Le programme de découverte est continu, et non ponctuel.
- Analyse de découverte de l’ensemble de l’environnement : outils de découverte appliqués à tous les systèmes de stockage, y compris les plateformes de support, les outils collaboratifs, les archives de messagerie et les environnements de développement
- Analyse des données des systèmes de support : systèmes de tickets, plateformes d’assistance et stockage du support client expressément inclus dans le périmètre de découverte
- Nouvelle analyse continue ou périodique : analyses de découverte selon une périodicité définie pour identifier les nouvelles accumulations entre deux cycles
- Constats de découverte corrigés : données sensibles découvertes dans des systèmes non classifiés évaluées, classifiées et placées sous une gouvernance appropriée, ou supprimées
- Analyse des environnements de développement : environnements hors production inclus dans le périmètre de découverte, avec une attention particulière à la présence de données de production
Outils
La découverte des données sensibles exige des outils capables d’analyser des environnements de stockage hétérogènes à la recherche de motifs de données sensibles, dans les données structurées comme non structurées.
Découverte et classification des données : BigID, Varonis, Spirion, Microsoft Purview
Ces plateformes appliquent la reconnaissance de motifs, l’apprentissage automatique et l’analyse de contenu pour rechercher des données sensibles dans les environnements de stockage, en identifiant les informations personnelles, les données financières, les dossiers de santé et les identifiants dans les bases de données, les systèmes de fichiers, le stockage cloud et les plateformes collaboratives. BigID offre en particulier une analyse complète d’environnements de données variés, dont le stockage cloud, les applications SaaS et les référentiels non structurés. Pour les praticiens TPRM, demander si l’analyse de découverte du fournisseur couvre les systèmes de support et les plateformes collaboratives permet de savoir si la lacune de découverte décrite dans le scénario d’introduction serait détectée.
Sécurité des systèmes de support : fonctionnalités GDPR de Zendesk, Freshdesk Data Privacy, Salesforce Shield
Les plateformes modernes de support client offrent des fonctionnalités de confidentialité et de sécurité des données conçues spécifiquement pour gérer les données sensibles dans le contexte du support : détection automatisée des données sensibles dans le contenu et les pièces jointes des tickets, masquage des données sensibles détectées et politiques de conservation du contenu des tickets. Pour les praticiens TPRM, demander si le fournisseur a activé les fonctionnalités de gestion des données sensibles sur sa plateforme de support constitue une question précise sur ses capacités pour le canal d’accumulation fortuite de données le plus à risque.
DLP pour la collaboration : Microsoft Purview DLP, Nightfall, Polymer
Les outils DLP pour plateformes collaboratives détectent les données sensibles dans les messages Teams, les canaux Slack, les contenus Google Workspace et les documents SharePoint et y réagissent, empêchant les données sensibles de s’accumuler dans un stockage collaboratif non classifié. Pour les praticiens TPRM, demander si le fournisseur applique une DLP aux plateformes collaboratives contenant des contenus partagés par les clients permet de savoir si le deuxième canal le plus courant d’accumulation fortuite de données sensibles est couvert.
Enjeux de gouvernance
Le défi de gouvernance de la découverte des données sensibles tient à la complexité opérationnelle de l’analyse d’environnements hétérogènes à grande échelle. Les environnements de données des entreprises comprennent des dizaines de systèmes de stockage, d’applications et de plateformes : les analyser tous exige des outils couvrant des types de systèmes variés et un investissement opérationnel pour gérer les constats et piloter la remédiation. La plupart des organisations mettent en place des programmes de découverte qui couvrent les systèmes à risque élevé connus et présentent d’importantes lacunes sur les systèmes moins visibles où des données sensibles se sont accumulées fortuitement.
Pour les programmes TPRM, l’approche de gouvernance pratique consiste à interroger précisément les fournisseurs sur le périmètre de leur programme de découverte (s’étend-il au-delà des bases de données principales aux systèmes de support, aux plateformes collaboratives et aux environnements de développement ?) et à demander si les constats de découverte alimentent un processus de remédiation plutôt que de simplement produire un rapport. Le périmètre du programme de découverte détermine ce que le fournisseur sait de son paysage de données sensibles. Les lacunes de ce périmètre déterminent ce qu’il ignore.
- Interroger le fournisseur sur le périmètre du programme de découverte : quels systèmes sont inclus et, en particulier, si les environnements de support, collaboratifs et de développement sont couverts
- Interroger le fournisseur sur la périodicité de la découverte : fréquence des nouvelles analyses et déclenchement ou non d’une découverte avant la mise en service de nouveaux systèmes
- Interroger le fournisseur sur la gestion des données sensibles dans les systèmes de support : une DLP ou un équivalent est-il appliqué aux plateformes de support client ?
- Interroger le fournisseur sur l’analyse des environnements de développement : les environnements hors production contenant des données clients font-ils partie du périmètre de découverte ?
- Exiger l’extension du programme de découverte pour les fournisseurs présentant des lacunes connues sur les canaux à risque élevé
Si vous êtes une petite équipe
Ajoutez à votre évaluation des fournisseurs une question qui révèle immédiatement la lacune de périmètre de découverte : votre analyse de découverte des données sensibles couvre-t-elle votre système de tickets de support client et ses pièces jointes, et quand la dernière analyse de ce système a-t-elle été réalisée ? Cette question cible le canal d’accumulation fortuite de données sensibles le plus à risque et distingue immédiatement les fournisseurs dotés de programmes de découverte complets de ceux dont la couverture s’arrête aux bases de données des applications principales.
- Demander si les pièces jointes des systèmes de support sont incluses dans l’analyse de découverte des données sensibles
- Demander quand la dernière analyse de découverte a été effectuée et quel en a été le constat le plus important
- Demander si les plateformes collaboratives font partie du périmètre de découverte
- Demander ce qu’il advient des données sensibles découvertes dans des systèmes non classifiés : remédiation ou simple signalement
Ce qu’il faut exiger
Demandez directement :
« Votre programme de découverte des données sensibles analyse-t-il votre système de tickets de support client et les pièces jointes, quand ce système a-t-il été analysé pour la dernière fois, et quelles catégories de données sensibles ont été trouvées ? »
« Quel est le périmètre de votre programme de découverte des données sensibles ? En particulier, couvre-t-il les plateformes collaboratives, les archives de messagerie et les environnements de développement, en plus des bases de données des applications principales ? »
« Lorsque des données sensibles sont découvertes dans un système non classifié ou non gouverné, quel est votre processus de remédiation, et pouvez-vous décrire un exemple récent de données sensibles découvertes hors de votre périmètre principal de gouvernance ? »
Preuves attendues
- Documentation du périmètre du programme de découverte : tous les systèmes inclus, avec confirmation précise de la couverture des plateformes de support et collaboratives
- Synthèse des résultats de la dernière analyse de découverte des systèmes de support
- Documentation du processus de remédiation pour les données sensibles découvertes hors périmètre
- Confirmation de la périodicité de la découverte : fréquence des nouvelles analyses
Un fournisseur qui répond à la question sur le système de support par « nos systèmes principaux sont bien gouvernés » a confirmé la gouvernance des systèmes qu’il connaît. Demandez précisément si une analyse de découverte a déjà été effectuée sur son système de tickets de support et ce qu’elle a révélé. La réponse indique si le scénario des quatorze mille pièces jointes sensibles est un scénario qu’il aurait découvert, ou un scénario qui attend d’être découvert lors de l’enquête sur une violation.
Comment le prouver
Le principe de responsabilité du GDPR exige que les responsables du traitement et les sous-traitants puissent démontrer qu’ils connaissent les données personnelles qu’ils détiennent. La découverte des données sensibles est le mécanisme qui crée cette connaissance au-delà des référentiels de données connus. Démontrer la diligence requise exige de prouver que le périmètre du programme de découverte couvrait les systèmes où s’accumulent fortuitement des données sensibles.
- Traces d’évaluation des fournisseurs documentant le périmètre du programme de découverte, y compris les systèmes de support et collaboratifs
- Preuves d’analyse de découverte des systèmes de support et des plateformes collaboratives
- Preuves de remédiation pour les données sensibles découvertes hors du périmètre principal de gouvernance
- Documentation de la périodicité de la découverte
À retenir
Les données sensibles n’arrivent pas uniquement par la porte d’entrée de la collecte intentionnelle. Elles arrivent par tous les canaux où clients, employés et systèmes échangent des informations : tickets de support, plateformes collaboratives, pièces jointes de courriels, journaux d’erreurs et outils de développement. Le programme de gouvernance construit autour de la collecte intentionnelle couvre les systèmes conçus pour elle. Les données sensibles accumulées par des canaux fortuits sont invisibles pour un programme qui part de l’inventaire connu au lieu de rechercher les accumulations inconnues. La découverte est l’étape de gouvernance qui rend visible l’invisible. Ce que le fournisseur ne sait pas détenir, il ne peut pas le gouverner. Ce qu’il ne peut pas gouverner, il ne peut pas le protéger.