Menaces internes et shadow IT : les risques qu'aucun document de stratégie data n'évoque

Le risque data qui inquiète votre équipe sécurité vient des attaquants externes. Le risque data qui devrait inquiéter votre CDO se trouve deux étages plus bas, au marketing, en train de faire tourner ses propres classeurs Tableau sur un export de tableur issu d'un système qui n'a pas été mis à jour depuis six mois.

Le shadow IT et les menaces internes sont les risques data sans prestige, ceux qui n'ouvrent jamais les conférences de sécurité, et qui sont responsables d'une part significative des incidents data réels.

Shadow IT : le risque data que vous n'avez pas approuvé

Le shadow IT en data, c'est tout traitement de données qui se déroule en dehors de votre infrastructure gouvernée. Cela ressemble à ceci :

• Un analyste qui maintient une copie « personnelle » des données clients dans un Google Sheet « parce que le système officiel est trop lent »
• Une équipe régionale qui construit son propre data warehousedata warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète → dans Microsoft Access « parce que l'IT ne leur donnera pas ce dont ils ont besoin à temps »
• Un product manager qui télécharge un export client de 500 000 lignes « juste pour faire une analyse rapide »
• Un directeur de département qui utilise un outil d'IA tiers pour analyser les retours clients, en collant des données clients dans ChatGPT

Chacun de ces scénarios crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée un risque data : non-conformité au RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →, incohérence de la qualité des données (la « version tableur » diverge de la source de référence), exposition sécurité (des données dans des systèmes non autorisés), et rupture de gouvernance (le CDO ne sait pas quelles données sont utilisées, par qui, à quelle fin).

Le shadow IT en data est presque toujours le symptôme d'une frustration légitime. Les gens construisent leurs propres solutions parce que l'infrastructure officielle ne répond pas à leurs besoins. Le CDO qui répond « arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez ça » sans traiter le besoin sous-jacent échouera. Le CDO qui rend l'infrastructure officielle rapide, accessible et en self-service éliminera naturellement l'essentiel du shadow IT.

Menaces internes : malveillance ou négligence

Les insiders malveillants sont des salariés ou des prestataires qui détournent intentionnellement leur accès aux données. Ils peuvent voler des données clients pour un gain financier, emporter des informations confidentielles chez un concurrent, ou saboter des systèmes de données. Ces cas sont relativement rares mais à fort impact.

Les insiders négligents, beaucoup plus fréquents, sont des salariés qui provoquent des incidents data par inattention plutôt que par intention. L'analyste qui envoie une liste de clients vers une adresse e-mail personnelle pour travailler de chez lui. L'ingénieur qui commite des identifiants de base de données dans un dépôt GitHub public. Le conseiller client qui consulte le compte d'une célébrité par curiosité.

La plupart des programmes de data loss prevention (DLP) se concentrent sur les insiders malveillants. La plupart des incidents sont causés par les négligents. Le programme du CDO doit traiter les deux, avec des approches différentes : des contrôles techniques pour les acteurs négligents (impossible d'envoyer des fichiers sensibles vers des adresses externes), une surveillance comportementale pour les malveillants.

Le cas Uber 2022

En septembre 2022, Uber a révélé une brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →èche de sécurité majeure. L'attaquant était un jeune de 18 ans qui n'a utilisé aucun exploit technique sophistiqué. Il a utilisé l'ingénierie sociale.

L'attaquant a contacté un salarié d'Uber via WhatsApp, en se présentant comme la sécurité informatique d'Uber. Il a demandé au salarié d'approuver une demande d'authentification multifacteur (MFA). Le salarié, lassé des notifications répétées (une attaque par « MFA fatigue »), a finalement approuvé. L'attaquant disposait d'un accès réseau complet.

Une fois à l'intérieur, l'attaquant a trouvé un script PowerShell sur un partage réseau. Le script contenait des identifiants codés en dur pour le système de privileged access management (PAM) d'Uber. Avec ces identifiants, il avait accès à pratiquement tout : AWS, Google Cloud, Slack, HubSpot, les outils internes, et une base de vulnérabilités de sécurité.

Le risque data : l'attaquant a trouvé des fichiers confidentiels, des informations de sécurité internes, et potentiellement des données personnelles de salariés et de chauffeurs.

Les leçons pour le CDO :

1. Gestion des identifiants : les secrets (clés d'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →, mots de passe, identifiants de base de données) ne doivent jamais être stockés dans des scripts ou des dépôts de code. Utilisez des gestionnaires de secrets (AWS Secrets Manager, HashiCorp Vault).
2. Moindre privilège : une fois à l'intérieur, l'attaquant avait accès à presque tout. Une segmentationsegmentationDécouper un marché en groupes distincts de clients partageant des besoins, des caractéristiques ou des comportements similaires, afin de traiter chaque groupe avec une approche dédiée.Voir la définition complète → correcte des accès limite le rayon d'impact.
3. Les attaques par MFA fatigue sont une menace réelle : mettez en place une MFA à correspondance de nombre plutôt qu'une simple approbation par push.

Construire un programme de gouvernance du risque data

Le CDO est propriétaire du risque data, en partenariat avec le CISO. Le CISO possède généralement l'infrastructure de sécurité ; le CDO possède la gouvernance des données, la classification et les politiques qui déterminent ce qui est à risque.

Un programme de risque data piloté par le CDO comprend :

• Inventaire des données : on ne protège pas des données dont on ignore l'existence. Balayages mensuels pour repérer les actifs de données non classifiés.
• Revues d'accès : revue trimestrielle de qui a accès aux données confidentielles et restreintes. Retirez les accès qui ne sont plus nécessaires.
• Détection du shadow IT : surveillez les transferts de données non autorisés (outils DLP), le stockage cloud non autorisé, l'usage non autorisé d'outils d'IA avec des données de l'entreprise.
• Surveillance des menaces internes : analytics comportemental sur les schémas d'accès aux données, sans devenir une surveillance qui érode la confiance. Établissez des politiques claires sur ce qui est surveillé et pourquoi.
• Formation régulière : la plupart des incidents data impliquent une erreur humaine. Formation annuelle à la sécurité des données pour tous les salariés ; formation plus fréquente pour ceux qui manipulent les données.