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 :

1. 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.