Note de l'auteur :Je teste le service dans le cadre de mon travail au Bielefeld IT Service Center (BITS) de l'université de Bielefeld. Cet article reflète ma vision personnelle de Red Hat Insights. De plus, je tiens à préciser que je suis membre de la communauté Red Hat Accelerators.
Après avoir présenté Red Hat Insights et jeté un coup d'œil à l'Advisor, il est temps d'examiner la gestion des vulnérabilités d'Insights.
Le tableau de bord affiche une boîte appelée Vulnérabilité. La figure 1 montre que nous sommes évidemment affectés par 13 vulnérabilités. Nous sommes maintenant en mesure de les examiner de plus près. Cela se fait comme d'habitude via le lien dans l'encadré ou via le menu de gauche.
Dans la vue des vulnérabilités, la vue tabulaire habituelle nous attend (voir Fig. 2). Ici, les CVE sont répertoriés avec leur ID, la date de publication, une évaluation d'impact, le score de base CVSS et le nombre de systèmes concernés. De plus, vous avez la possibilité d'attribuer un risque commercial et un statut à certains ou à tous les CVE (voir le marquage jaune dans la Fig. 2).
Le risque commercial vous donne la possibilité d'évaluer un CVE spécifique ou un groupe de CVE sur la façon dont ils pourraient affecter votre entreprise ou avoir un impact négatif sur celle-ci (voir Fig. 3). Ce statut peut différer de l'impact dans la deuxième colonne en fonction de certaines mesures de sécurité que vous avez déjà en place. Le statut indique comment les vulnérabilités sont traitées (voir Fig. 4).
Comme dans l'Advisor, vous obtenez une vue détaillée avec une description de chaque CVE, une évaluation et un aperçu des vecteurs d'attaque (voir Fig. 5), ainsi que des liens vers la base de connaissances Red Hat, où des informations détaillées sur le CVE et les errata existants peuvent être trouvés.
Évaluation de la gestion des vulnérabilités
À ce jour, nous n'avons pas de gestion active des vulnérabilités. Nous essayons d'assurer un certain niveau de sécurité avec une gestion des correctifs pour RHEL avec Ansible, que j'ai développée avec des outils inclus dans RHEL et le moteur Ansible. Cela garantit que les avis de sécurité Red Hat disponibles sont obligatoirement installés sur tous les systèmes RHEL une fois par mois s'ils manquent.
Grâce à cette gestion des correctifs, il n'y a que 13 vulnérabilités sur les systèmes de test connectés, et aucune d'entre elles n'a eu un score supérieur à huit.
Parmi les systèmes répertoriés dans le tableau de bord figuraient des systèmes d'une infrastructure de test qui ne sont pas connectés à la gestion centrale des correctifs et qui ne sont corrigés qu'irrégulièrement. Des aperçus m'ont montré ici que le risque est beaucoup trop grand et que ces systèmes seront tout simplement oubliés. Pour cette raison, ces hôtes ont été immédiatement inclus dans la gestion des correctifs.
Les plus intéressantes sont CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 et CVE-2019-11091, que Insights affiche pour certains hôtes.
Ces vulnérabilités ont en commun qu'elles ne peuvent pas être fermées simplement en installant une mise à jour. Comme il s'agit de machines virtuelles (VM) sur un cluster vSphere, une combinaison de mesures est nécessaire pour atténuer les vulnérabilités.
Dans ce cas précis, il suffit d'éteindre et de rallumer les VM concernées. Cela propage les nouvelles fonctions du processeur vers le système d'exploitation invité et l'atténuation est terminée.
Je dois admettre que ces vulnérabilités seraient restées longtemps inconnues sans informations.
Maintenant, je dois supposer qu'il existe d'autres systèmes vulnérables dans notre environnement. Comme je ne suis pas autorisé à les connecter à Insights, j'utiliserai un script fourni par Red Hat pour les trouver. J'apprécie vraiment que Red Hat fournisse de tels scripts pour aider ses clients ici. Il existe encore quelques entreprises qui peuvent suivre cet exemple en toute sécurité.
Personnellement, je pense que la gestion active des vulnérabilités a du sens. Les vulnérabilités ne peuvent être trouvées, évaluées et traitées en conséquence que par un contrôle continu. En même temps, il peut être utilisé pour vérifier si des mesures ont déjà été prises pour améliorer le niveau de sécurité structurelle (par exemple, une gestion des correctifs).
La figure 6 montre qu'il n'y a actuellement aucune vulnérabilité ouverte. Cela devrait toujours être l'objectif.
J'ai moi-même apprécié le test de la fonction de gestion des vulnérabilités et les vulnérabilités trouvées ont pu être fermées en peu de temps.
[ Assistez à une Red Hat Insights Ask Me Anything avec le chef de produit Jerome Marc, axée sur la comparaison des systèmes avec Drift, le 23 juillet 2020. ]