Qu'est-ce que la gestion des vulnérabilités ?

La gestion des vulnérabilités est un processus continu qui consiste à identifier, classer, hiérarchiser et corriger les failles de sécurité au sein de votre infrastructure avant que des pirates ne puissent en tirer parti. Si votre entreprise exploite plus d’une poignée d’appareils, vous présentez déjà des vulnérabilités ; la question est de savoir si vous en avez conscience et si vous disposez d’un plan pour y remédier.

Pourquoi la gestion des vulnérabilités est-elle essentielle pour les équipes informatiques et de sécurité ?

Chaque CVE non corrigée, chaque service mal configuré ou chaque version obsolète d’un système d’exploitation constitue un point d’entrée potentiel. Les attaquants recherchent systématiquement les vulnérabilités connues, souvent dans les heures qui suivent leur divulgation publique. La gestion des vulnérabilités est la discipline opérationnelle qui permet de fermer cette brèche.

Les enjeux sont concrets. Selon le rapport « Data Breach Investigations Report » de Verizon, l’exploitation des vulnérabilités figure systématiquement parmi les principales méthodes d’accès initial dans les violations confirmées. Un programme de gestion des vulnérabilités bien rodé réduit en permanence la surface d’attaque de votre organisation, et pas seulement après un incident.

Pour les équipes informatiques gérant des parcs hétérogènes, comprenant notamment macOS, iOS, iPadOS et d’autres plateformes, la complexité s’accroît rapidement. Chaque plateforme possède son propre rythme de publication des correctifs, son processus de divulgation des vulnérabilités et ses exigences en matière d’outils.

Les éléments clés d’un programme de gestion des vulnérabilités

La gestion des vulnérabilités est un cycle, et non un projet ponctuel. Ses composantes essentielles sont les suivantes :

1. L'inventaire des actifs

On ne peut pas gérer ce que l’on ne voit pas. Un inventaire complet et précis des actifs constitue le fondement de tout programme de gestion des vulnérabilités. Cela inclut le matériel, les logiciels, les versions des systèmes d’exploitation et les micrologiciels. Les lacunes dans l’inventaire se traduisent directement par des angles morts dans votre posture de sécurité. La gestion de l’inventaire matériel est une condition préalable, et non une étape facultative.

2. Analyse des vulnérabilités

Les outils d’analyse inspectent vos terminaux, vos serveurs et vos périphériques réseau à la recherche de vulnérabilités connues en comparant les configurations système et les versions logicielles à des bases de données de vulnérabilités telles que la National Vulnerability Database (NVD). Les analyses peuvent être authentifiées (basées sur un agent ou avec identifiants) ou non authentifiées. Les analyses authentifiées produisent des résultats nettement plus précis, car elles permettent d’inspecter directement les paquets installés et les configurations.

Pour mieux comprendre comment l’analyse s’intègre à votre flux de travail, consultez le guide « Analyse des vulnérabilités : guide pratique ».

3. Évaluation et classification des vulnérabilités

Une fois les vulnérabilités identifiées, elles doivent être classées. Le Common Vulnerability Scoring System (CVSS) fournit un score de gravité normalisé compris entre 0 et 10. Cependant, les scores CVSS bruts ne suffisent pas à eux seuls pour établir un ordre de priorité. Une vulnérabilité de gravité « critique » dans un logiciel non exposé à Internet présente un risque différent de celui d’une vulnérabilité ayant le même score sur un service accessible de l’extérieur.

La classification doit tenir compte :

• le score de base CVSS, c'est-à-dire la gravité inhérente de la vulnérabilité
• L'exploitabilité, c'est-à-dire l'existence ou non d'un code d'exploitation public
• la criticité de l’actif, c’est-à-dire l’importance du système affecté pour les opérations de l’entreprise
• L'exposition: si le système est exposé à Internet, s'il se trouve sur un réseau segmenté ou s'il est isolé physiquement (« air-gapped »)
• le statut KEV de la CISA, c'est-à-dire si la vulnérabilité figure dans le catalogue des vulnérabilités connues pour être exploitées (Known Exploited Vulnerabilities) de la CISA

4. Hiérarchisation

C’est au niveau de la hiérarchisation que la plupart des programmes réussissent ou échouent. Les équipes de sécurité sont régulièrement confrontées à des milliers de vulnérabilités ouvertes, alors que leurs capacités de correction sont limitées. Tenter de corriger tout immédiatement n’est pas faisable d’un point de vue opérationnel. Une approche basée sur les risques concentre les efforts sur les vulnérabilités les plus susceptibles d’être exploitées et de causer des dommages réels.

La hiérarchisation et la correction des CVE constituent une discipline à part entière. Les équipes qui la maîtrisent s’appuient sur des flux de renseignements sur les menaces, des systèmes de notation prédictive des exploits (EPSS) et le contexte des actifs pour prendre des décisions de triage justifiables.

5. Correction

La correction peut prendre plusieurs formes :

• L’application de correctifs, c’est-à-dire l’installation des mises à jour fournies par les éditeurs pour éliminer la vulnérabilité
• Le renforcement de la configuration, c’est-à-dire la modification des paramètres pour supprimer la vulnérabilité (par exemple, la désactivation d’un service inutile)
• Contrôles compensatoires: lorsque l’application d’un correctif n’est pas immédiatement possible, ajout de contrôles d’atténuation tels que la segmentation du réseau ou une surveillance renforcée
• Acceptation: documentation formelle indiquant qu’un risque a été examiné et accepté, avec une date d’examen définie

Une correction efficace nécessite une coordination entre les équipes de sécurité, les opérations informatiques et les responsables d’applications. La définition de SLA en fonction du niveau de gravité (par exemple, correctifs pour les vulnérabilités critiques dans les 24 heures, pour celles de niveau élevé dans les 7 jours) permet d’établir une responsabilité claire.

6. Vérification et rapports

Une fois la correction effectuée, vérifiez que le correctif a bien été appliqué en analysant à nouveau les systèmes concernés. Le reporting boucle la boucle : il démontre la conformité aux SLA internes, répond aux exigences d’audit et offre à la direction une visibilité sur la santé du programme au fil du temps.

Gestion des vulnérabilités vs gestion des correctifs

Ces termes sont souvent utilisés de manière interchangeable, mais ils ne sont pas identiques. La gestion des correctifs est un sous-ensemble de la gestion des vulnérabilités. L’application de correctifs permet de remédier aux vulnérabilités, mais de nombreuses vulnérabilités ne peuvent pas être résolues par un simple correctif. Les erreurs de configuration, les paramètres par défaut non sécurisés et les logiciels en fin de vie nécessitent des mesures correctives allant au-delà de la simple application de correctifs.

Un programme de gestion des vulnérabilités abouti intègre la gestion des correctifs, mais couvre également la gestion des configurations, la gouvernance du cycle de vie des logiciels et les contrôles compensatoires.

Cadres et normes courants

Plusieurs cadres sectoriels fournissent une structure pour les programmes de gestion des vulnérabilités :

• La norme NIST SP 800-40 (Guide pour la planification de la gestion des correctifs en entreprise) fournit des conseils pratiques sur la mise en place et l’évaluation d’une capacité de gestion des correctifs
• CIS Controls v8, contrôle n° 7 (gestion continue des vulnérabilités), définit des mesures de protection spécifiques, notamment l’analyse automatisée, le suivi des mesures correctives et la hiérarchisation des priorités en fonction des risques
• La normeISO/IEC 27001, annexe A.12.6, traite de la gestion technique des vulnérabilités dans le cadre d’un SMSI plus large
• L’exigence 6 dela norme PCI DSS impose l’identification des vulnérabilités et l’application de correctifs pour les systèmes qui stockent, traitent ou transmettent des données de titulaires de cartes

Aligner votre programme sur l’un de ces référentiels vous offre une base solide et simplifie l’établissement des rapports de conformité lors des audits.

Gestion des vulnérabilités sur les appareils Apple

Les terminaux Apple présentent des particularités spécifiques. macOS, iOS et iPadOS ont leurs propres calendriers de divulgation des vulnérabilités et leurs propres mécanismes de correction. Apple publie des informations de sécurité pour chaque version sur sa page dédiée aux mises à jour de sécurité, mais pour rester à jour, il faut recourir à une gestion MDM (Mobile Device Management), et non se contenter d’alertes aux utilisateurs.

Parmi les défis courants spécifiques à Apple, on peut citer :

• la fragmentation des mises à jour du système d’exploitation: sans application des règles via MDM, les versions du système d’exploitation au sein du parc s’écartent considérablement, en particulier après les versions majeures
• les vulnérabilités des applications tierces: les navigateurs, les outils de productivité et les utilitaires de développement introduisent des vulnérabilités indépendamment du rythme de publication des correctifs d’Apple
• Les scénarios BYOD: la présence d’appareils personnels dans les environnements d’entreprise complique à la fois la visibilité et l’autorité de correction ; la gestion des appareils BYOD nécessite une approche d’application différente
• Des outils cloisonnés: de nombreux scanners de vulnérabilités ont été conçus pour des environnements centrés sur Windows et fournissent des résultats incomplets sur macOS

Pour les organisations utilisant principalement du matériel Apple, c’est là que la gestion des appareils Apple et la gestion des vulnérabilités se recoupent directement.

L’approche d’Iru en matière de gestion des vulnérabilités

Iru est spécialement conçu pour les parcs d’appareils Apple, ce qui signifie que ses capacités de gestion des vulnérabilités sont conçues en fonction du comportement réel des appareils Apple, et non adaptées à partir d’une architecture initialement axée sur Windows.

Concrètement, cela se traduit par :

• Inventaire continu du système d’exploitation et des logiciels: Iru offre une vue en temps réel de la version du système d’exploitation de chaque appareil, des applications installées et de l’état des correctifs, sans nécessiter de requêtes manuelles. Ces informations alimentent directement les workflows d’évaluation des vulnérabilités.
• Workflows de correction automatisés: lorsqu’Apple publie une mise à jour de sécurité, Iru peut l’appliquer à l’ensemble du parc via des mécanismes natifs MDM, avec des délais de report configurables et l’imposition de dates limites pour les utilisateurs finaux.
• Scripts personnalisés et application des configurations: pour les vulnérabilités nécessitant des modifications de configuration plutôt que des correctifs (désactivation des protocoles non sécurisés, activation de FileVault, gestion de l’état SIP), la bibliothèque d’Iru, composée de scripts prédéfinis et de paramètres de conformité, accélère la correction sans nécessiter d’outils personnalisés.
• Intégration avec les solutions de détection et de réponse au niveau des terminaux (EDR): Iru s’intègre aux principales solutions EDR afin que le contexte des vulnérabilités alimente la surveillance active des menaces, et inversement.
• Rapports de conformité: les vues de conformité d’Iru mettent en correspondance l’état de sécurité des appareils avec des référentiels tels que les benchmarks CIS et les contrôles NIST, fournissant ainsi aux équipes de sécurité une documentation prête pour les audits sans avoir à effectuer de travail manuel sur des feuilles de calcul.

Le modèle de plateforme unifiée joue ici un rôle essentiel. Lorsque votre solution MDM et vos outils de sécurité partagent les mêmes données sur les appareils, vous éliminez le décalage de synchronisation qui fait que des correctifs apparaissent comme déployés dans un outil mais non vérifiés dans un autre.

Mettre en place un programme de gestion des vulnérabilités évolutif

La gestion des vulnérabilités n’est pas un outil que l’on déploie pour ensuite l’oublier. Elle exige une discipline opérationnelle : une couverture d’analyse cohérente, une responsabilité clairement définie en matière de correction et des revues régulières du programme.

Pour démarrer ou améliorer un programme déjà en place :

1. Commencez par vous assurer que votre inventaire des actifs est complet. Si ce n’est pas le cas, corrigez cela en premier lieu. Un scanner couvrant 80 % de votre parc vous donne une fausse impression de couverture.

2. Définissez explicitement vos SLA de gravité. Documentez les délais de correction attendus pour les résultats critiques, élevés, moyens et faibles. Obtenez l’aval de la direction.

3. Intégrez ce processus à votre gestion des changements. Les correctifs nécessitant un redémarrage du système ou des modifications de configuration doivent être coordonnés avec les équipes opérationnelles afin d’éviter toute interruption de service imprévue.

4. Automatisez autant que possible. L’application manuelle de correctifs à grande échelle n’est pas viable. Les mises à jour du système d’exploitation imposées par la gestion des appareils mobiles (MDM) et le déploiement automatisé des applications éliminent des catégories entières de retards.

5. Établissez des rapports sur les tendances, et non pas uniquement sur des instantanés ponctuels. Un nombre de vulnérabilités en baisse au fil du temps, associé à une amélioration du respect des SLA, est plus révélateur qu’un simple rapport d’audit ponctuel.

Si vous souhaitez découvrir comment Iru gère les vulnérabilités au sein d’un parc Apple, demandez une démonstration afin de parcourir le workflow en tenant compte de votre environnement spécifique.