Meilleures pratiques pour votre programme de gestion des vulnérabilités

Aujourd'hui, la plupart des organisations ont commencé à mettre en œuvre un programme de gestion des vulnérabilités (PGV), mais sa mise en place représente un défi de taille. La plupart des organisations constatent qu'elles n'ont pas de véritable contrôle sur leurs systèmes ou qu'elles n'ont pas l'autorité nécessaire pour imposer la correction des vulnérabilités identifiées. Dans tous les cas, identifier et appliquer un véritable PGV au sein de nombreuses organisations est une tâche chronophage.

Qu’est-ce qu’un programme de gestion des vulnérabilités ?

Si vous débutez dans la mise en œuvre d'un programme de gestion des vulnérabilités (VMP), vous devez d'abord comprendre ce qu'est la gestion des vulnérabilités. Cela peut paraître évident, mais il s'agit de la gestion (du cycle de vie) de l'identification des risques liés aux systèmes non corrigés, mal configurés et inconnus au sein d'une entité, ainsi que de la mise en œuvre d'un processus de remédiation pour chaque risque identifié.

Tout programme de gestion des vulnérabilités comprend généralement les étapes suivantes :

• Identification des vulnérabilités matérielles et logicielles de gestion des vulnérabilités
• Identification des actifs et des propriétaires
• Politiques relatives à l'analyse, au signalement et à la correction des vulnérabilités

Lors de la mise en œuvre d'une politique de gestion des vulnérabilités (VMP), la plupart des organisations commencent par définir une politique que tous doivent respecter. Cette approche peut fonctionner dans certains cas, mais d'après mon expérience, elle vous limite considérablement, faute d'une vision claire des capacités de correction des vulnérabilités. Je vous recommande donc d'attendre d'avoir une idée précise des capacités avant de mettre en place une telle politique.

Identification des vulnérabilités matérielles et logicielles de gestion des vulnérabilités

La première étape consiste à établir une liste, même infime, des exigences de votre organisation. Concrètement, cela implique de discuter avec les personnes concernées par la politique de gestion des vulnérabilités et de recueillir leurs besoins. D'après mon expérience, poser les questions suivantes vous aidera à définir vos exigences initiales :

1. Identification des actifs et de leurs propriétaires :
   1. Disposez-vous d'un inventaire de tous les systèmes (machines) dont vous êtes responsable ?
   2. Connaissez-vous le degré de criticité de ces systèmes par rapport au système de classification des données de l'organisation ?
   3. Existe-t-il des zones grises où vous êtes propriétaire d'un logiciel spécifique mais pas de l'ensemble du système ?
2. Politiques relatives à l'analyse, au signalement et à la correction des vulnérabilités :
   1. Quelle périodicité d'analyse vous semble raisonnable pour vos systèmes ? Deux semaines ? Quatre semaines ? Tous les trimestres ?
   2. Si vous deviez recevoir un rapport sur tous vos systèmes, quel format vous conviendrait le mieux ?
   3. À quelle fréquence mettez-vous à jour les systèmes dont vous avez le contrôle ?
   4. Existe-t-il des cas où la mise à niveau/la mise à jour du logiciel est impossible sur un système spécifique ? Pourquoi ?

Ces questions devraient vous permettre de définir vos exigences de base pour tout produit de numérisation (matériel ou logiciel) disponible sur le marché, et il en existe un grand nombre. Une fois vos besoins généraux identifiés, recherchez et organisez des démonstrations des produits qui y répondent.

Trouver un produit qui réponde à vos besoins ne sera pas difficile, mais je vous recommande vivement d'en choisir un qui possède une API. J'ai une vaste expérience des deux. Gestion des vulnérabilités QualysGuard (VM) et Tenable une gamme de produits, mais de nombreux autres produits sont également disponibles.

Identification des actifs et des propriétaires

Dans la liste de questions précédente, j'en ai mentionné une qui est extrêmement importante pour identifier un actif et ses propriétaires : Existe-t-il des zones grises où vous êtes propriétaire d'un logiciel spécifique mais pas de l'ensemble du système ?

Cette question semble simple, mais imaginez une application web avec une interface utilisateur, une base de données et un serveur. Chacun de ces éléments peut être géré par un service différent au sein de votre organisation. Qui est alors responsable des mises à jour et des correctifs de cette application ? Définir clairement ces responsabilités et convenir d'un accord à ce sujet est essentiel pour votre plan de gestion des actifs virtuels (PGIV).

Une fois ces zones d'ombre identifiées, déterminer les actifs restants et leurs propriétaires est relativement simple. Vous pouvez procéder soit en effectuant une analyse interne (non authentifiée) pour identifier tous les systèmes de votre ou vos réseaux, soit en contactant votre équipe réseau. Celle-ci dispose de ces informations.

L'identification des propriétaires peut s'avérer plus complexe selon la topologie de votre réseau. Si votre réseau est segmenté, vous devriez pouvoir identifier les propriétaires par sous-réseau. Sinon, il vous suffit d'ajouter les ressources identifiées dans un tableur Excel et de rechercher les propriétaires de chaque système.

Le suivi et la mise à jour continue des relations entre les actifs et leurs propriétaires représentent un défi, surtout au sein d'une grande organisation internationale. L'essentiel, à ce stade, est de créer la liste initiale. La plupart des solutions de gestion des vulnérabilités intègrent un module de gestion des actifs et de leurs propriétaires qui, une fois mis en place, contribuera à atténuer ces difficultés.

Politiques de numérisation, de signalement et de correction

Maintenant que vos exigences générales ont permis de sélectionner un produit de gestion des vulnérabilités (même à titre d'essai) et que vous disposez d'une liste centralisée des actifs et de leurs propriétaires, il est temps de procéder au déploiement progressif de votre VMP.

Choisissez un département ou une unité organisationnelle qui, selon vous, collaborera étroitement avec votre équipe. Vous pouvez même commencer par les ressources de votre propre département.

Presque tous les produits de gestion des vulnérabilités proposent deux (ou plus) types d'analyse : non authentifiée et authentifiée.

Non authentifié Les analyses consistent pour le produit de gestion des vulnérabilités à tenter de deviner la nature de chaque système, les ports ouverts, le système d'exploitation utilisé, et à tenter d'identifier les vulnérabilités à partir de ces informations.

Authentifié Une analyse approfondie signifie que le produit de gestion des vulnérabilités se connectera au système à l'aide d'une clé SSH, d'un nom d'utilisateur et d'un mot de passe fournis, ou nécessitera l'installation d'un agent. Ce type d'analyse est plus précieux pour une organisation et fournit des résultats précis, sans approximations. Il identifiera les versions logicielles obsolètes, les mises à jour ou paquets manquants, les ports ouverts, les règles de pare-feu, etc.

Une fois que vous avez choisi un type d'analyse pour un actif spécifique ou pour l'ensemble de vos actifs, vous devez tester les fonctionnalités d'analyse et de génération de rapports de votre solution de gestion des vulnérabilités. La durée de ces tests peut varier de deux semaines à six mois, selon la taille et la structure de votre organisation.

L'objectif est de déterminer quelles configurations d'analyse ont le plus d'impact sur votre organisation. Il existe plusieurs façons de configurer les éléments analysés et ceux qui ne le sont pas. Tout dépend de l'objectif global de votre plan de gestion des vulnérabilités (VMP). Je suggère de se concentrer d'abord sur les points clés. C'est tout à fait subjectif, mais je recommanderais de commencer par les points suivants avant de tenter de tout corriger :

• Analyse externe : Déterminer ce qui est visible depuis l'extérieur.
• Analyse externe : Déterminer quels ports sont ouverts en externe.
• Analyse interne (non authentifiée) : Déterminer la carte/topologie du réseau et les ports ouverts.
• Analyse interne (authentifiée) : Analyse un sous-ensemble d’hôtes à l’aide d’une analyse authentifiée.
• Enfin, établissez un calendrier pour toutes les deux semaines, tous les mois, etc., en fonction de votre organisation.

En établissant d'abord une base de référence, vous pouvez déterminer la faisabilité des analyses en fonction des types de systèmes, au lieu d'imposer une durée arbitraire. Il est crucial de définir une durée d'analyse planifiée qui réponde aux exigences de votre organisation sans surcharger les responsables système. À mesure que ces derniers s'habitueront à ce nouveau processus, ils prendront davantage conscience de leurs responsabilités et seront bien mieux préparés à réagir en cas de vulnérabilités critiques affectant leurs systèmes.

L'objectif d'un plan de gestion des vulnérabilités (VMP) est de corriger les failles de sécurité détectées le plus rapidement possible, mais cela ne se fait pas en déversant une quantité massive d'informations. Si vous fournissez à quelqu'un un rapport indiquant que ses 100 serveurs/systèmes sont vulnérables à 1 000 failles, il ne saura même pas par où commencer. Il est donc important de privilégier les rapports qui mettent l'accent sur les points critiques (par exemple, les ports ouverts, les paramètres de configuration, les vulnérabilités de niveau 5 non corrigées, etc.).

Une fois ces points critiques traités, passez au niveau 4, puis au niveau 3, au niveau 2, etc. Si (et quand) une nouvelle vulnérabilité critique est identifiée, concentrez-vous immédiatement sur sa correction. Une fois les corrections effectuées, poursuivez en éliminant la vulnérabilité de niveau immédiatement supérieur, et ainsi de suite.

Une autre approche consiste à s'attaquer d'abord à vos systèmes les plus critiques. Cela permet de réduire le risque global pour l'organisation tout en améliorant les résultats globaux. D'après mon expérience, les systèmes les plus critiques d'une organisation reposent souvent sur des logiciels obsolètes. Essayez de corriger ces vulnérabilités en collaborant avec vos fournisseurs ou en mettant en place des mesures d'atténuation.

La gestion des vulnérabilités et votre programme de gestion des vulnérabilités (VMP) ne doivent pas être considérés comme une course. Ce nouveau programme est un service continu que votre équipe de sécurité prend en charge ; abordez-le donc avec patience et ne vous attendez pas à ce que toutes les vulnérabilités soient corrigées au cours de la première année. Ce ne sera pas le cas.

Fiche technique sur la gestion des vulnérabilités avec SOAR

Le matériel, les applications, les piles de sécurité, les systèmes, les terminaux et les services cloud non corrigés, non identifiés ou mal configurés peuvent entraîner des failles de sécurité majeures via des ports ouverts, des paramètres de configuration erronés et des vulnérabilités non exploitées. Téléchargez la fiche technique dès aujourd'hui pour découvrir comment Swimlane peut s'intégrer à vos outils de gestion des vulnérabilités et vous offrir une visibilité centralisée sur l'ensemble de votre pile de sécurité.

Lire maintenant