Des centaines de RSSI, de CSO et de responsables de la sécurité, qu’ils soient issus de petites ou de grandes entreprises, ne savent pas où sont cachés les secrets de leur entreprise. Peu importe la taille de l’organisation, les certifications, les outils, les personnes et les processus : les secrets ne sont pas apparents dans 99 % des cas. Thomas Segura, Technical Specialist chez Gitguardian, nous livre son analyse.

Cela peut sembler ridicule au premier abord, mais savoir bien gérer ses secrets est vital pour la sécurité du cycle de développement logiciel. Que ce soit dans le cloud ou sur site, les secrets sont stockés en toute sécurité derrière des protections et peu de personnes peuvent y accéder. Ce n’est pas seulement une question de bon sens, il s’agit également d’une exigence de conformité essentielle pour les audits et les certifications de sécurité.

Les développeurs au sein des organisations sont bien conscients que les secrets doivent être manipulés avec une attention particulière. D’ailleurs, des outils et des procédures spécifiques sont mis en place pour créer, communiquer et réinitialiser correctement les identifiants humains ou machine.

A lire aussi : [Chronique] Face au manque de ressources cyber, les entreprises se donnent-elles vraiment les moyens ?

Les secrets se répandent partout dans les systèmes, et plus rapidement que ce que l’on imagine. Ils sont copiés-collés dans des fichiers de configuration, des scripts, du code source ou encore des messages privés, sans que l’on s’en rende compte. Par exemple, un développeur code en dur une clé d’API pour tester rapidement un programme et pousse accidentellement son travail sur un dépôt distant. L’accident pourra-t-il être détecté à temps ?

La gestion des secrets est difficile car les capacités d’audit et de remédiation sont bien insuffisantes. Ces dernières sont aussi les moins mentionnées par les Framework de sécurité. Pourtant, ces zones grises – où des vulnérabilités invisibles restent cachées pendant longtemps – sont des trous flagrants dans les couches de défense.

Il est possible, pour une entreprise, de faire le point sur l’état de la sécurité de ses secrets grâce à un outil d’auto-évaluation et de mesurer ainsi son exposition.

Modèle de maturité de la gestion des secrets

La mise en place d’un système de gestion des secrets complet et sécurisé nécessite de la réflexion et de l’organisation, mais est primordiale en matière de défense. L’organisation doit donc élaborer un cadre pour aider les responsables de sécurité à adopter des pratiques plus matures, en trois phases :

1. Évaluer les risques de fuite de secrets
2. Mettre en place des workflows de gestion des secrets pertinents
3. Créer une feuille de route pour l’amélioration des pans fragiles

Le point fondamental abordé dans ce modèle est le fait que la gestion des secrets va bien au-delà de la manière dont l’organisation stocke et distribue les secrets. Il s’agit d’un programme qui doit non seulement aligner les personnes, les outils et les processus, mais aussi tenir compte de l’erreur humaine. Les erreurs ne sont pas évitables mais leurs conséquences le sont. C’est pourquoi les outils et les politiques de détection et de remédiation, ainsi que le stockage et la distribution des secrets, constituent les piliers d’un modèle de maturité.

Le modèle de maturité de la gestion des secrets prend en compte quatre surfaces d’attaque du cycle de vie DevOps :

– Les environnements des développeurs 

– Les dépôts de code source 

– Les pipelines CI/CD et artefacts 

– Les environnements d’exécution

Il faut ensuite mettre en place un dispositif pour mesurer la maturité sur quatre niveaux, allant de 0 (non initié) à 4 (expert). Le passage de 0 à 1 consiste principalement à évaluer les risques posés par les pratiques de développement de logiciels non sécurisés, et à commencer à vérifier que les actifs numériques ne comportent pas d’informations d’identification codées en dur. Au niveau intermédiaire (niveau 2), l’analyse des secrets est plus systématique, et ils sont utilisés avec davantage de prudence à chaque étape du cycle DevOps. Les niveaux 3 (avancé) et 4 (expert) sont axés sur l’atténuation des risques, avec des politiques plus claires, de meilleurs contrôles et un partage accru des responsabilités pour remédier aux incidents.

Rendre difficile l’utilisation de secrets, dans un contexte DevOps, conduira inévitablement au contournement des protections misent en place. Il est alors nécessaire de trouver un équilibre entre protection et flexibilité. L’utilisation d’un coffre-fort / gestionnaire de secrets ne commence qu’au niveau intermédiaire. L’idée est qu’un tel outil ne doit pas être considéré comme une solution autonome mais comme une couche de défense supplémentaire. Pour être efficace, il faut que d’autres processus, comme l’analyse continue des pull-requests, soient suffisamment matures.

Ce modèle peut soulever des questions qui peuvent aider à évaluer la maturité de l’entreprise : à quelle fréquence procède-t-elle à la rotation des secrets de production ? Est-il facile de procéder à la rotation des secrets ? Comment les secrets sont-ils distribués en phase de développement, d’intégration et de production ? Quelles sont les mesures mises en place pour empêcher la diffusion non sécurisée des informations d’identification sur les machines locales ? Les informations d’identification des pipelines CI/CD respectent-elles le principe du moindre privilège ? Quelles sont les procédures misent en place lorsque (et non pas si) des secrets sont divulgués ? 

En 2023, la révision de la posture des entreprises face à la gestion des secrets devrait être une priorité. Pour commencer, toute personne travaillant avec du code source doit manipuler des secrets de temps en temps, si ce n’est quotidiennement. Les secrets ne sont plus la spécialité des ingénieurs de sécurité ou DevOps, ils sont requis par de plus en plus de personnes, qu’il s’agisse d’ingénieurs en Machine Learning, de data scientists, de produits, d’ops, et bien d’autres. Enfin, il est nécessaire de savoir où se trouvent les secrets, car si l’entreprise ne le sait pas, les hackers, eux, le savent.

On ne saurait trop insister sur les risques que courent les organisations qui n’adoptent pas des pratiques matures. Les environnements de développement, les dépôts de code source et les pipelines CI/CD sont devenus les cibles favorites des pirates, pour qui les secrets sont une porte d’entrée permettant des mouvements latéraux et la compromission. Il est nécessaire de prendre au sérieux les potentiels risques en cas de non-adoption de pratiques matures.

Des exemples récents soulignent la fragilité de la gestion des secrets, même dans les organisations les plus matures sur le plan technologique.

En septembre 2022, un attaquant a eu accès au réseau interne d’Uber, où il a trouvé des informations d’identification d’administrateur codées en dur sur un volume réseau. Les secrets ont été utilisés pour se connecter à la plateforme de gestion des accès privilégiés d’Uber. L’attaquant a ensuite pu prendre le contrôle de comptes d’administration dans AWS, GCP, Google Drive, Slack, SentinelOne, HackerOne, etc.

En août de la même année, le gestionnaire de mots de passe LastPass a été victime d’un attaquant qui a eu accès à son environnement de développement en volant les informations d’identification d’un développeur. Plus tard en décembre, l’entreprise a révélé que quelqu’un avait utilisé ces informations pour voler le code source et les données des clients.

En 2022, les fuites de code source se sont révélées être un véritable champ de mines pour les organisations : NVIDIA, Samsung, Microsoft, Dropbox, Okta et Slack, entre autres, ont été victimes de fuites de code source. En mai dernier, il fallait être vigilant au volume important d’informations d’identifications qui pouvaient être récoltées en analysant ces bases de code. Armés de celles-ci, les attaquants peuvent s’appuyer sur des centaines de systèmes dépendants dans ce que l’on appelle des attaques de supply chain logicielle.

Enfin, encore plus récemment, en janvier 2023, le fournisseur d’intégration continue CircleCI a également fait l’objet d’une attaque, entraînant la compromission de centaines de variables d’environnement, de jetons et de clés de clients. Les sociétés doivent exhorter leurs clients à changer immédiatement leurs mots de passe, leurs clés SSH ou tout autre secret stocké sur ou géré par la plateforme. Encore fallait-il que les victimes sachent où se trouvent ces secrets et comment ils sont utilisés pour bien réagir à l’urgence ! Voilà une bonne raison d’avoir un plan d’urgence prêt à l’emploi.

La leçon à tirer de tous ces incidents est que les attaquants ont compris que la compromission d’identités humaines ou machines offre un réel retour sur investissement. Ce sont autant de signaux d’alarme qui montrent qu’il est urgent de s’occuper des informations d’identification codées en dur et de dépoussiérer la gestion des secrets en général.

Il y a un dicton dans la cybersécurité : « Le cryptage est facile, mais la gestion des clés est difficile. » Cela reste vrai aujourd’hui, bien qu’il ne s’agisse plus seulement de clés de chiffrement. Notre monde de services hyperconnectés s’appuie sur des centaines de types de clés, ou secrets, pour fonctionner correctement. Ceux-ci peuvent constituer autant de vecteurs d’attaque potentiels s’ils sont mal gérés.

Savoir où se trouvent les secrets, non pas en théorie mais en pratique, et comment ils sont utilisés tout au long de la chaîne de développement logiciel est crucial pour la sécurité. Pour aider les entreprises, il existe un modèle de maturité portant spécifiquement sur la distribution des secrets, la détection des fuites, le processus de remédiation et les habitudes de rotation.

La première étape consiste toujours à obtenir un audit clair de la posture de sécurité de l’organisation en matière de secrets : où et comment sont-ils utilisés ? Où fuient-ils ? Comment se préparer au pire ? Ce dernier élément pourrait s’avérer important dans une situation d’urgence.

Les entreprises qui veulent se défendre efficacement doivent s’assurer que les zones d’ombre de leur cycle de développement soient levées le plus tôt possible.