Faites donc un test, interrogez un RSSI relativement proche de ses équipes, et demandez-lui quels sont ses pires « cauchemars » !
Gestion de la surface d’attaque : les nouvelles pratiques autour des méta-connecteurs et des puits de données adaptifs
Faites donc un test, interrogez un RSSI relativement proche de ses équipes, et demandez-lui quels sont ses pires « cauchemars », il vous répondra irrémédiablement avec les éléments suivants :
- La lutte contre les ransomwares
- La sécurité d’Active Directory
- La gestion des patchs sur les différents systèmes
Bien sûr, l’ordre des réponses nous importe peu
Globalement, la gestion de ce que l’on appelle la surface d’attaque est un défi quotidien pour les équipes du RSSI – mais que les choses soient claires, ne vous laissez pas abuser par le terme « surface », nous l’employons ici car il s’agit du terme consacré. Bien évidemment, votre exposition générale intègre également vos applications dans le Cloud public, vos sites web, votre code hébergé dans GitHub, etc. Le terme de « surface d’attaque » englobe donc l’ensemble de votre exposition aux risques cyber, quelle que soit sa « localisation ». De plus, cette notion ne se limite pas aux systèmes en surface mais prend bien en compte les réseaux locaux profonds ou n’importe quelle « machine » gérée par l’IT.
Lorsque l’on tente de plonger dans les détails de l’utilisation de la surface d’attaque par un acteur malveillant, on réalise rapidement que la partie offensive utilise ce que l’on désigne habituellement comme étant un « chemin d’attaque » – pour le novice, un chemin d’attaque représente le parcours emprunté par un attaquant pour passer d’un point A à un point B, par exemple l’attaquant commence par compromettre un de vos firewalls et terminera administrateur de votre domaine Active Directory.
Le chemin d’attaque n’exploite finalement que deux éléments :
- Une mauvaise configuration d’un système
- Une CVE non patchée sur un système
Ensuite, la logique du chemin se mettra en place pour sauter d’actif en actif et compromettre globalement l’organisation :
Comme vous pouvez le constater sur le schéma précédent, la gestion des CVEs représente un élément extrêmement important dans le périmètre des équipes de sécurité. L’objectif de cet article est de donner un coup de balai dans le monde poussiéreux de la gestion des vulnérabilités et de vous exposer les nouvelles pratiques qui vous permettront de gagner en efficacité et globalement augmenter votre niveau de résilience.
Les deux pratiques historiques liées aux vulnérabilités : Vulnerability Management & Patching
Le cycle de gestion des vulnérabilités
Traditionnellement, le cycle de gestion des vulnérabilités s’organise autour de 5 grandes étapes :
- Evaluation
cette étape initiale consiste principalement à découvrir ses actifs et les étudier pour lister les vulnérabilités présentes :
- Identification des actifs
- Scan des actifs
- Rapport sur les vulnérabilités liées aux actifs
2. Priorisation
en se basant sur l’étape d’évaluation, il s’agit ici de définir une priorisation des actions, car il n’est généralement pas possible de patcher l’ensemble des vulnérabilités au sein d’un même cycle :
- Enrichir le contexte de l’actif – assigner une valeur à l’actif
- Comprendre le score CVSS
- Décider du plan de correction
3. Correction
cette étape représente globalement le fait d’appliquer les correctifs/patchs fournis par les éditeurs afin de corriger les CVEs présentes sur les systèmes :
- Action de remédiation
- Documentation des actifs non patchés et atténuation des risques
4. Vérification
suite à l’étape de patching, il s’agit maintenant de vérifier que les actifs sont effectivement patchés afin de s’assurer du niveau de sécurité réel :
- Re-scan des actifs
- Validation des hypothèses
5. Amélioration continue
comme tout cycle vertueux, le cycle de gestion des vulnérabilités devra s’améliorer lors de l’exécution de chaque itération :
- Evaluer les mesures
- Evolution des procédures et traitement des problèmes rencontrés
Des outils et des équipes différentes
Comme vous pouvez le constater sur le schéma précédent, l’implémentation du cycle nécessite à minima l’usage de deux types d’outils différents :
- Les scanners de vulnérabilités
- Les outils de patching
Historiquement, l’équipe sécurité est en charge de découvrir quels sont les actifs vulnérables et d’évaluer le risque lié à chaque actif, de plus c’est généralement l’équipe sécurité qui se chargera de définir quels sont les actifs à patcher en priorité. Ces informations sont ensuite transmises à l’équipe de production, garante du maintien opérationnel, qui devra appliquer les correctifs aux différents systèmes listés par l’équipe sécurité.
Cette séparation des responsabilités et des outillages est extrêmement complexe à gérer et produit irrémédiablement des difficultés opérationnelles et organisationnelles majeures. Il est donc primordial que le responsable de production et le RSSI puissent travailler de façon concertée et dans la plus grande transparence, car les enjeux liés au bon déroulé des opérations sont majeurs pour maintenir le niveau de résilience de l’organisation.
Les challenges actuels dans le domaine de la gestion des vulnérabilités
Un nombre toujours plus important de CVEs
Premièrement, si vous désirez comprendre comment les scores de CVE sont attribués, je vous conseille fortement la lecture de cet article sur le site web cve.org : https://www.cve.org/ResourcesSupport/AllResources/CNARules
De plus, si vous désirez consulter la liste de toutes les CVEs connues, vous pourrez télécharger différents fichiers depuis le site du MITRE : https://cve.mitre.org/data/downloads/index.html
Lorsque l’on consulte les différents référentiels de CVEs, on constate instantanément deux choses :
- Le nombre de CVEs ne fait que grandir
car il s’agit d’un nombre cumulé au fil des années – bien sûr les CVEs de l’année 2022 ne remplacent pas les CVEs de l’année 2021, donc le nombre global de CVEs à gérer ne peut que grandir au fil du temps
- Le nombre de CVEs découvertes chaque année (et non en cumulé maintenant) grossit lui aussi !
Pour illustrer le deuxième point, le schéma suivant représente le nombre de CVEs identifiées sur les environnements Microsoft, année par année :
En conclusion, non seulement le nombre de CVEs à gérer augmente au fil du temps, car il s’agit d’un nombre cumulé, ensuite, il y a statistiquement de plus en plus de CVEs découvertes chaque année !
Un manque d’automatisation et d’alignement entre les outils et les données
Comme indiqué au début de cet article, le cycle de gestion des vulnérabilités nécessite l’intervention d’équipes différentes ainsi que d’outils divers et variés. Cet état de fait contribue à augmenter l’entropie autour de cette activité. De plus, des facteurs « aggravants » doivent être pris en compte :
- Manque de communication entre les équipes de production et les équipes sécurité
- Des référentiels de données disparates et peu d’alignement entre les bases de vulnérabilités, les outils de scan et les outils de patching
- Une confiance relativement faible des équipes sécurité envers la qualité des données résidant en CMDB, voire, une pratique de sécurité qui ignore les données de gestion des actifs et qui se concentre uniquement sur le scan de vulnérabilité
- Peu ou pas de connexion et d’échanges de données entre les différents référentiels, il en résulte des ressaisies manuelles occasionnant de nombreuses erreurs, des capacités de reporting centralisé très médiocres et une difficulté grandissante à aligner les exigences de sécurité avec les enjeux du business
En conclusion, il apparait que les données et les processus manquent cruellement de liant.
Le cauchemar de la priorisation
La priorisation demeure actuellement l’enjeu majeur de la gestion des vulnérabilités. En effet, l’organisation doit être en capacité de définir quels sont les actifs critiques, quels sont les risques associés et définir un plan de remédiation cohérent se basant sur une priorisation des actions à mener.
En effet, comme nous l’avons vu précédemment, le nombre de CVEs augmentant sans cesse, et de façon exponentielle, il n’est plus possible de patcher l’ensemble des CVEs présentes sur le parc informatique, et ce sur des cycles de plus en plus courts. De plus, de nombreuses vulnérabilités critiques étant découvertes chaque jour, les équipes de production sont soumises à une pression quotidienne pour corriger en urgence la dernière faille critique découverte la veille…
Pour rappel, les CVEs sont « notées » selon un degré de criticité allant de 0 à 10, il s’agit du score CVSS. Si vous désirez comprendre comment est calculé ce score CVSS, je vous invite à consulte cette page du NIST : https://nvd.nist.gov/vuln-metrics/cvss
Il faut accepter l’idée qu’actuellement le score CVSS seul ne permet plus de définir une priorisation efficace liée à la remédiation des risques.
Téléchargez cette ressource
Travail à distance – Guide complet pour les Directions IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
Des évolutions nécessaires prévues par les analystes
La plupart des analystes recommandent une évolution majeure des pratiques liées au cycle de gestion des vulnérabilités afin d’assurer un niveau de sécurité minimal dans les organisations. En effet, la situation actuelle ne permet plus d’assurer un équilibre sain entre charge de travail et sécurité opérationnelle.
La pratique dite d’« Attack Surface Management » devra être mise en œuvre dans l’ensemble des organisations, soit comme pratique interne, soit sous la forme d’un service managé.
Cette pratique s’appuie sur 3 piliers :
- « Cyber Asset Attack Surface Management »
C’est certainement l’élément le plus important, nous l’évoquerons dans le chapitre suivant, car il mérite un éclaircissement dédié – globalement il s’agit ici de casser les silos et d’unifier les données puis de permettre la collaboration des équipes via des outils dédiés
- « External Attack Surface Management »
Ce pilier réalise un focus sur la découverte des actifs rattachées à l’organisation mais qui sont exposés directement sur Internet – le niveau de risque lié à ces actifs externes sera donc lui aussi évalué
- « Digital Risk Protection Services »
Globalement, cette pratique consiste à enrichir son puits de données « interne » avec des informations provenant de référentiels externes, tel que par exemple l’étude des données disponibles sur le Deep Web ou le Dark Web
« Pratique Attack Surface Management »
Par expérience, toute pratique Cyber s’appuie sur les trois piliers principaux que sont les outils, les hommes et les process. Les outils jouent un rôle fondamental dans l’exécution de la mission car ils permettent d’assurer une cohérence générale et assurent de guider l’organisation dans l’implémentation de sa pratique.
Mise en exécution d’une pratique Cyber
Un nouveau monde, les solutions de Cyber Asset Attack Surface Management (CAASM)
Les solutions de type CAASM permettent généralement d’exécuter les missions suivantes :
- Consolidation des données et priorisation du traitement des vulnérabilités
- Vue holistique des actifs et des risques présents au sein de l’organisation
- Alignement des pratiques de cybersécurité au sein des différents silos organisationnels et techniques
- Pilotage de la remédiation des risques majeurs
- Contrôle des écarts entre les mesures réalisées et la réalité de la production
Ces solutions possèdent une architecture particulière, hautement adaptive, permettant globalement de prendre en compte n’importe quel type de données. Ils proposent des fonctions permettant d’alimenter sans cesse le référentiel et d’adapter le schéma structuré des informations consolidées afin de pouvoir gérer les besoins présents et futurs. Elles s’appuient sur un certain nombre de briques fonctionnelles majeures que nous listons ci-après.
CAASM – Les meta-connecteurs
Une solution de type CAASM possède des connecteurs permettant d’absorber ou d’envoyer des informations depuis ou vers les outils déjà déployés dans l’organisation. Ces connecteurs permettent de maximiser les investissements existants, en effet, il ne s’agit pas ici de rajouter un énième outil de sécurité mais bel et bien de magnifier le potentiel des investissements déjà réalisés. On peut catégoriser les différentes familles de connecteurs :
- Les scanners de vulnérabilités: le connecteur permettra de rapatrier toutes les informations liées aux scanners de vulnérabilités présents dans l’organisation, ils peuvent être de type open-source ou commerciaux – généralement l’organisation possède plusieurs scanners de vulnérabilités, en fonction des actifs étudiés : scanner des système IT, scanner du code, scanner des actifs web, etc.
- Les CMDBs (Configuration Management DataBase): ce connecteur n’est généralement pas vu comme un élément de sécurité informatique, pourtant comment gérer les vulnérabilités des systèmes si l’on ne possède pas une vue holistique de ces actifs ? Les connecteurs CMDBs permettent finalement de réconcilier la vue « Actif » avec la vue « Vulnérabilité »
- Les outils de Pentest et de BugBounty: le connecteur permettra d’enrichir les informations collectées en amont par des apports contextualisés et liés à un test d’intrusion ou à un test d’exploitation de vulnérabilité
- Les Orchestrateurs de Sécurité: Il s’agira ici d’envoyer des informations vers les Orchestrateurs de Sécurité afin qu’ils puissent consolider leur vision des états et enfin appliquer les meilleurs scénarios de remédiation possible
- Les outils ITSM (Information Technology Service Management) et Helpdesk: ces connecteurs permettront d’interagir avec les outils de gestion de service IT existants et assureront une intégration en profondeur dans les processus de l’organisation
De nombreux autres types de connecteurs existent généralement dans les solutions CAASM : lien vers les outils de gestion des risques, connexion aux SIEMs, intégration avec les bases de CVEs officielles, etc.
CAASM – Le puits de données adaptif
Le puits de données contenant l’ensemble des données collectées est hautement adaptif, cela signifie qu’il n’est pas limité à un type de données spécifique et que son schéma est adaptable aux besoins actuels et futurs. Ce point est très important car il assure la pérennité du modèle et permettra demain de rajouter des connecteurs pour des usages encore inconnus actuellement !
De plus, l’outil CAASM doit permettre la déduplication des données et assurer leur unicité – par exemple si l’organisation utilise plusieurs scanners de vulnérabilités et que les dits scanners remontent 95% de vulnérabilités communes, il faut nécessairement que l’outil CAASM soit en mesure de repérer ses informations doublonnées et n’affiche qu’une seule fois les vulnérabilités associées à chaque actif.
Enfin, un modèle de corrélation doit permettre d’associer les différents objets et attributs collectés via les connecteurs – par exemple, il faut pouvoir associer automatiquement les actifs gérés au sein de la CMDB avec les vulnérabilités repérées sur ces mêmes actifs via les scanners de vulnérabilités.
Il faut donc comprendre que le puits de données est un élément critique d’une solution CAASM et doit permettre l’adaptation à n’importe quel usage actuel ou futur. De plus, la conservation des données selon un modèle unifié permettra à l’organisation de changer facilement les outils s’exécutant derrière les connecteurs – Par exemple, comme les données sont standardisées, il sera aisé de changer de fournisseur pour le scanner de vulnérabilité sans que l’historique ne soit affecté.
CAASM – Le portail de gestion
Une fois les données récoltées, dédupliquées et corrélées, un portail de gestion permettra de naviguer dans le puits de données. Les interfaces varient en fonction des fournisseurs, mais l’un des plus grands challenges sera de fournir une vision claire des informations, permettant alors de prioriser les actions à réaliser en fonction de l’étude du jeu de données.
Il est donc primordial que l’interface utilisateur soit la plus claire possible et que les dashboards associés soient facilement personnalisables – dans cette optique, l’interface du Français Hackuity est particulièrement remarquable.
Exemple de dashboard CAASM chez l’éditeur Français Hackuity
Le portail doit permettre un usage différencié au travers des différentes équipes, il devra gérer un modèle RBAC afin de constituer des interfaces adaptées en fonction de l’utilisateur. Le portail CAASM devient l’outil unique pour le pilotage des vulnérabilités au sein de l’organisation et permettra de s’affranchir des nombreuses interfaces disparates associées aux différents outils s’exécutant derrière les connecteurs.
Les futurs enjeux
Les éditeurs de solutions associés à la pratique CAASM investissent massivement pour le futur de leur plateforme, il s’agit, en effet, d’un des domaines les plus innovants dans le monde de la cybersécurité. Nous pouvons considérer que l’adoption à venir du Machine Learning permettra d’enrichir considérablement les scénarios d’usage de ce type de plateforme. Grace au volume des données collectées, nous pourrons repérer certains modèles répétitifs dans l’objectif de créer des règles automatiques d’aide à la décision et d’aide à la priorisation.
Les solutions CAASM permettent de surmonter de nombreux challenges de sécurité liés à la gestion des vulnérabilités, n’hésitez pas à vous renseigner pour comprendre comment cette pratique pourrait aider votre propre organisation.
Merci d’avoir consacré du temps à la lecture de cet article.
Sylvain Cortes – Security Evangelist & Microsoft MVP