Solution originale pour la gestion des secrets

Confrontés à une quantité immense de traitements de mots de passe au sein de notre mission, nous avons décidé d'automatiser un certain nombre de processus pour gagner un temps précieux et augmenter la qualité de nos actions. L'objectif ? Traiter différement les incidents liés aux mots de passe que dans un outil classique, type SIEM, ou même SOAR.

Introduction

Tous les ans, l’entreprise NordPass publie un rapport avec des statistiques sur les mots de passe les plus utilisés, en fonction de catégories (e-commerce, réseaux sociaux...) et des 35 pays que l’étude couvre. Le résultat n’est pas très reluisant... “123456” et ses variantes, “admin”, “password” font partie du top 10 des mots de passe les plus utilisés [1]. Et malheureusement, cela n’a pas lieu que dans le domaine privé, car les mots de passe étudiés venaient également du dark web et de fuites de données d’entreprises. Le problème est donc posé : non seulement les mots de passe ne sont pas assez robustes, mais ils sont parfois stockés où ils ne devraient pas.

Contexte

C’est ce constat qui a été fait chez le client pour lequel j’ai travaillé. La politique sur les mots de passe est pourtant bien définie avec des règles basiques autour de la robustesse et du stockage chiffré. Par ailleurs, le client fournit à ses collaborateurs les moyens de stocker et d’échanger ces données en toute sécurité. En complément, il faut donc installer une surveillance autour de ces données très sensibles dans les espaces de stockage partagés dans l’entreprise. Ce fut l’objet de ma mission : améliorer le projet Password Hunting, qui était à l’époque encore balbutiant.

En effet, lorsque je suis intervenue, le projet Password Hunting était doté d’un outil de détection sur lequel avait été développé des règles, qui étaient activées sur un périmètre défini de fichiers “en clair”. Un premier processus de traitement avait été établi également. Cependant, devant la volumétrie des détections (100 000 par mois !), alors même que le périmètre avait été réduit, la charge de travail pour le traitement de toutes ces détections avait submergé l’équipe. Il est impensable que le RSSI puisse traiter à lui seul tout cela, ainsi, le premier processus de traitement spécifiait que les propriétaires de fichiers détectés devaient eux-mêmes corriger les détections. Une problématique a alors émergé : comment définir et automatiser au maximum la chaîne complète de traitement pour gagner le temps nécessaire pour couvrir tous les espaces de stockage partagés ?

Réalisations

Ce qui prenait beaucoup de temps, c’était l’analyse et le traitement :

• Analyser une à une les détections, reporter le résultat dans un tableur (qui devenait long),
• Puis régulièrement extraire les cas avérés et pour chacun, envoyer un mail au collaborateur concerné,
• Converser parfois avec le collaborateur pour qu’il trouve son fichier à corriger et enfin recueillir sa réponse.

Tout cela n’était pas durable et même, impossible à faire à 100% sans avoir une équipe nombreuse au vu de la volumétrie. J’ai donc travaillé sur la totalité du projet en partant des questions de base :

• Quoi ? Ou plus clairement, qu’est-ce qu’on détecte ? A première vue, la réponse à cette question est plutôt simple : les mots de passe. Cependant cette notion peut être élargie à tous types de secrets, car les mots de passe ne sont pas utilisés partout (et encore heureux). Il y a les mots de passe, les clés (API, cloud...), les tokens, les certificats... Et selon les normes de l’entreprise, tous n’ont pas les mêmes formats. Détecter les secrets au sens large nécessite une définition claire et précise, sinon le taux de faux positif est trop important. Comme un premier travail avait déjà été réalisé sur ce point, et que des règles de détection avaient été créées, j’ai laissé l’amélioration de ces règles de côté et je ne les ai reprises qu’à la fin.
• Où ? Dans le sens, où détecter cette donnée sensible ? Cette question est cruciale car de l’expérience de l’équipe, la volumétrie engendrée pourrait être trop importante pour à la fois avoir une activité de run (donc traiter les détections) et de build (automatiser et améliorer le processus) en même temps. J’ai donc commencé par réduire encore le premier périmètre qui avait été défini, de façon à ménager du temps pour automatiser à côté tout en ayant un échantillon représentatif de ce qu’on peut détecter.
• La plus grosse question ici est le comment. Plusieurs questions sous-tendent ce point :
  • Comment procéder ? Sur ce point, le processus ressemble aux processus de développement classiques :
    • Détecter
    • Analyser
    • Traiter
    • Remédier
    • Surveiller
    • Améliorer
  • Et les questions pour définir chaque étape du processus :
    • Comment détecter ?
    • Comment analyser ?
    • Comment traiter ?
    • ...

Le cœur du sujet : détailler le processus complet.

1. Comment détecter

Ce point est le plus rapide. Comme je l’ai dit, un outil de détection, Netskope, était déjà présent à mon arrivée, avec les règles de détection implémentées. Cependant, il avait été prévu que l’outil ne pourrait pas être utilisé pour le cas des espaces de stockage on-premise, pour lesquels un autre outil serait utilisé (Forcepoint). Sur le périmètre restreint défini, cet outil n’était pas encore utilisé, mais il fallait prévoir d’intégrer les détections venant de cet outil également.

Les règles de détection ont été laissées dans un premier temps, le temps de définir les étapes suivantes du processus. A la fin de ma mission, elles ont été retravaillées en prenant en compte les normes du client, de façon à pouvoir prioriser les détections de façon plus pertinente. Jusqu’ici, aucune détection n’était priorisée par rapport à d’autres, malgré le fait qu’un mot de passe n’a pas la même criticité qu’un token par exemple. Pour cela, il a fallu travailler sur la définition d’un secret et créer plusieurs règles avec des criticités bien distinctes pour y placer les types de secret par ordre de criticité selon le client. L’idée de cette priorisation est que, lorsque le client élargira le périmètre de détection, il puisse le faire progressivement avec en cible les types de secrets les plus critiques en premier, sans faire exploser la volumétrie des détections.

2. Comment analyser, traiter et remédier

Comme il était prévu d’avoir plusieurs outils de détection, il n’était pas pertinent d’utiliser directement les outils de détection pour analyser, pas sans avoir trouvé un moyen pour réunir les détections au même endroit de façon à avoir une vue d’ensemble des alertes. Il fallait par conséquent un outil supplémentaire pour cette vue d’ensemble. Deux outils ont été comparés pour cela :

• L’outil SIEM Splunk, classique et très utilisé pour récolter tous les événements en un même endroit avec une capacité de synthétisation en tableaux de bord et de création de règles en plus,
• L’écosystème d’outils Microsoft PowerPlatform, composé de PowerAutomate, pour créer des processus automatisés, PowerApps pour la création d’application, et Power BI pour la visualisation de données. Contrairement à Splunk qui fournit une application de base, les outils Microsoft permettent de créer un outil “maison”, modulable à souhait.

Une rapide comparaison a été faite entre ces deux outils : il en a résulté le choix des outils Microsoft PowerPlatform. En effet, ils permettaient la création d’une application plus proche de ce qui voulait être fait, application qui de plus pourrait évoluer plus vite étant donné que l’outil serait seulement utilisé par l’équipe Password Hunting. L’argument décisif fut également le fait que Splunk ne permet pas (de manière simple) d’envoyer des notifications aux utilisateurs et de récolter leur réponse de manière automatique. De plus les outils Power Platform sont intégrés dans les outils de communication de l’entreprise (Outlook, Teams), et l’outil avait commencé à être utilisé avant mon arrivée.

L’étape suivante fut de développer l’application et les processus avec ces outils, qui permettrait de :

• Faire l’analyse des détections depuis l’application (avec potentielle redirection vers les outils de détection si besoin),
• Envoyer des campagnes de notifications aux utilisateurs afin de traiter les cas avérés,
• Suivre la remédiation faite par les utilisateurs en suivant leur réponse aux notifications qui leur sont envoyées.

PowerApps nous a permis de créer l’interface depuis laquelle l’équipe analyse les détections et contrôle l’envoi des campagnes. L’interface a pu être personnalisée de façon à réduire le temps d’analyse au maximum. L’envoi de campagnes est déclenché depuis l’application (un simple bouton) et géré grâce à des flux PowerAutomate (l’équivalent de scripts). Les flux PowerAutomate interagissent avec l’application Microsoft Approvals qui permet de faire les demandes aux utilisateurs via Teams ou Outlook et de recueillir leur réponse. Les données sont stockées dans une base de données Microsoft (Dataverse) ce qui permet que toutes les applications PowerPlatform y aient accès sans limite. La base de données a d’ailleurs été définie de façon à prendre en compte les différentes provenances des détections étant donné qu’il y avait potentiellement 2 outils de détections.

3. Comment surveiller

Ce point fut résolu grâce à l’utilisation de Dataverse pour stocker les données : en effet, l’outil PowerBI est directement connecté à Dataverse et permet d’utiliser directement ces données pour construire des tableaux de bord automatisés qui synthétisent l’activité Password Hunting pour le management. Il a suffi de créer les tableaux de bord sous forme de rapports PowerBI, puis de partager ces rapports au management.

Les bonnes pratiques quand on travaille avec Microsoft PowerPlatform

• Le développement, c’est en environnement de développement, le test, en environnement de test, et la production, c’est en environnement de production. La distinction est à faire comme dans tout processus de développement.
• Garder des copies du travail qui fonctionne, au cas où, même si Microsoft PowerPlatform a un outil de gestion de versions.
• Eviter de trop séparer la base de données en plusieurs tables : c’est propre, mais cela fait surgir des contraintes de “délégation”. Cette fonctionnalité de PowerPlatform permet les calculs non autorisés par les sources de données, mais limite le nombre de lignes sur lesquelles le calcul est fait. La limite n’est pas possible à contourner, le conseil est donc de rester au maximum sur des opérations autorisées par les sources de données (Sharepoint, Dataverse ont des opérations autorisées différentes).
• Flux PowerAutomate : un run d’un flux est limité à 30 jours d’exécution une fois lancé. Pour contourner cette limite, on peut essayer de relancer le flux juste avant les 30 jours limite, par exemple en modifiant l’élément Sharepoint qui a déclenché le flux. Dans le flux, il faudra alors trouver un moyen de distinguer les étapes. Les approbations (Microsoft Approvals) ont également une date d’expiration par défaut de 30 jours après la date de création. Pour la modifier, il suffit de modifier l’approbation dans la table des approbations une fois que l’approbation a été créée.
• Si la documentation Microsoft ne suffit pas, la communauté des outils PowerPlatform est très étendue, ne pas rester bloqué si l’on ne trouve pas par soi-même, quelqu’un a déjà potentiellement posé la question sur un forum.
• Se méfier des limites Microsoft : limite de caractères dans un champ de table, limite d’exécution de flux, limite de récupération des données d’une source...
• Se méfier aussi des dates et des différences de fuseau horaire : dans la base de données, les dates sont stockées en UTC, et adaptées pour l’utilisateur en fonction de ses paramètres (même avec le décalage horaire hiver/été en Europe).

Conclusion 

La mise en place d’un outil créé par l’équipe et pour l’équipe a permis de gagner du temps pour le traitement des détections. Déjà, le temps d’analyse pour la même quantité de détection a été divisé par 2. Le temps de traitement a également largement diminué, nous permettant de répondre aux sollicitations lorsque le collaborateur avait besoin d’aide, alors qu’avant nous n’aidions pas les collaborateurs au cas par cas. Finalement, le temps de préparation qui était nécessaire pour faire le point sur l’activité au management a simplement été supprimé, car aujourd’hui cette partie est entièrement automatique. Par ailleurs, le management a apprécié avoir des KPIs bien plus complets qu’avant.

Au niveau des détections, la surveillance fonctionne : le nombre de détections a nettement diminué et le nombre de cas avérés après analyse également. L’impact a donc été visible : les collaborateurs ont appris, se sont responsabilisés grâce à leur action dans le processus de remédiation et font donc plus attention. Le management a d’ailleurs pu le voir au travers des tableaux de bord automatisés qui leur a été fourni. De plus le périmètre de détection qui avait été choisi est maintenant maîtrisé, et il va pouvoir être élargi, ce qui était un réel enjeu pour le client.

De mon côté, j’ai surtout appris qu’un SIEM n’est pas forcément la réponse à tout, et j’ai pu découvrir la suite Microsoft Power Platform qui est très complète et facile à prendre en main. J’ai pu reprendre un projet dans sa totalité, et le construire petit à petit, ce qui m’a également apporté une vision plus stratégique.

Lucille AUBRY

Consultante Cybersécurité