Vulnerability Response pour conteneurs
L’application ServiceNow® Vulnerability Response pour conteneurs importe les éléments vulnérables du conteneur (CVIT) et, selon les règles, vous permet de corriger les vulnérabilités du conteneur. Les données de vulnérabilité sont extraites de sources internes et externes, telles que la base de données de vulnérabilité nationale (NVD) ou des intégrations tierces.
À partir de la version 18.0 de Vulnerability Response, vous pouvez surveiller et corriger les CVIT dans Vulnerability Manager Workspace et IT Remediation Workspace respectivement. Pour plus d'informations, consultez Espace de travail du gestionnaire de vulnérabilité et Exploration de l'Espace de travail de remédiation IT.
Demander des applications dans l'App Store
Visitez le site Web ServiceNow Store pour découvrir toutes les applications disponibles et pour obtenir des informations sur la procédure à suivre pour soumettre des demandes à la boutique. Pour obtenir des informations sur les notes de publication cumulatives pour toutes les applications publiées, consultez les ServiceNow Storenotes de publication relatives à l'historique des versions.
Avantages
- S’intègre à des produits de sécurité de conteneur tiers, tels que Prisma Cloud Compute de Palo Alto Networks.
- Importe les données de vulnérabilité pour les images déployées en cours d’exécution et enrichit les données de vulnérabilité avec des informations contextuelles d’exécution (hôtes, clusters Kubernetes, services et espaces de noms).
- Fournit une liste des références créées à partir des vulnérabilités aux entités Kubernetes pertinentes dans l’application Base de données de gestion des configurations (CMDB)ServiceNow Kubernetes Discovery.
- Offre un tableau de bord de génération de rapports complet, fournissant des informations sur les tendances en matière de vulnérabilité et de rattrapage.
Fonctionnalités principales
- Pointez vers l’image Docker source à partir de CVIT au lieu d’exécuter des conteneurs.
- Configurez la granularité des CVIT à suivre au niveau de l’image, de la grappe Kubernetes, de l’espace de noms ou du service.
- Suivre les nouvelles versions d’image pour identifier les vulnérabilités corrigées. Toutes les vulnérabilités signalées dans les versions antérieures sont automatiquement résolues lorsque de nouvelles versions d’image sont déployées lors de l’exécution ServiceNow .
- Suivez les CVIT dans les images de base séparément des images d’application pour permettre une correction indépendante.
- Émettez des demandes d’exception ou des demandes de faux positif, qui peuvent être examinées par le biais d’un processus d’approbation à plusieurs niveaux.
- Définissez des règles d’exception pour différer automatiquement les CVIT.
Cas d'utilisation
- Contexte d'exécution
- Les vulnérabilités dans les images de conteneurs peuvent être découvertes en analysant l’image dans les étapes suivantes du cycle de vie de l’application.
- Étape 1 : lorsque des images sont en cours de création dans le pipeline CI/CD.
- Étape 2 : lorsque les images sont publiées dans le registre
- Étape 3 : lorsque les images sont déployées pour l’exécution.
S’il est important d’identifier les vulnérabilités le plus tôt possible aux étapes 1 et 2, il est tout aussi important d’effectuer une analyse des images déployées dans un environnement d’exécution. Il offre les avantages suivants :- Identification de toutes les nouvelles vulnérabilités et expositions courantes (CVE) qui ont été publiées.
- Fournir une visibilité précise sur la posture vis-à-vis du risque des applications déployées.
- Hiérarchisation des vulnérabilités qui doivent être résolues. Le contexte d’exécution en termes de services d’application ou de services d’entreprise affectés en raison d’une vulnérabilité peut aider à établir des priorités.
Vulnerability Response pour conteneurs s’intègre aux produits de sécurité de conteneur tels que Prisma Cloud Compute pour extraire les données de Palo Alto Networks vulnérabilité des images déployées pour l’exécution et enrichit les données de vulnérabilité avec les informations contextuelles d’exécution telles que les hôtes, les clusters Kubernetes, les services et les espaces de noms où ces images de conteneur sont déployées. Les clients qui utilisent la ServiceNow détection Kubernetes peuvent voir les références créées à partir des vulnérabilités vers les entités Kubernetes pertinentes dans leur Base de données de gestion des configurations (CMDB)fichier . En plus d’enrichir les métadonnées, ServiceNow offre également un tableau de bord de reporting complet pour fournir des informations sur les tendances de vulnérabilité et de correction.
- Identifier la propriété
- Conditions préalables
Métadonnées et références Kubernetes : pour Vulnerability Response pour conteneurs renseigner les métadonnées Kubernetes (espace de noms, cluster, etc.) et les références aux Base de données de gestion des configurations (CMDB) entrées, vous devez implémenter la détection Kubernetes à partir de Information Technology Operations Management (ITOM). La détection Kubernetes remplit l’image Docker, les conteneurs Docker en cours d’exécution, les pods, les grappes Kubernetes, etc., dans le . Vulnerability Response pour conteneurs identifie l’image Docker en CMDB fonction de l’ID de l’imageCMDB, puis identifie les entités Kubernetes connexes et renseigne les références à ces entités à partir d’éléments vulnérables.
- Métadonnées dans le cloud et étiquettes d’image Docker : Vulnerability Response pour conteneurs renseignent également les étiquettes d’image Docker, les ID de compte cloud et les régions où une image est déployée. Ces données sont conservées dans l’enregistrement « Image du conteneur détectée » associé à l’élément vulnérable. Il n’y a aucune condition préalable pour que ces données soient renseignées. Vulnerability Response pour conteneurs utilise les données renvoyées par les produits de sécurité des conteneurs (par exemple, Palo Alto Prisma Cloud Compute) pour renseigner ces entrées.
La propriété de l’application de correctif à une vulnérabilité dans une image de conteneur peut varier d’une organisation à l’autre. Ces informations peuvent être capturées à différents endroits. Certaines organisations utilisent des étiquettes d’image Docker pour identifier les équipes d’application propriétaires d’une certaine image de conteneur, tandis que d’autres peuvent utiliser l’espace de noms Kubernetes ou le compte cloud dans lequel une image de conteneur est déployée pour identifier le propriétaire du droit.
Vulnerability Response pour conteneurs fournit les éléments de modèle de données nécessaires pour pouvoir capturer et utiliser les étiquettes d’image Docker, les métadonnées de cluster/service/espace de noms Kubernetes ou les métadonnées du compte cloud (ID de compte cloud, région, fournisseur, etc.) dans le module « Règles d’affectation » et affecter automatiquement les vulnérabilités à la bonne équipe d’application en fonction des métadonnées de l’image ou de l’environnement d’exécution.
- Suivre les vulnérabilités des images de base
- Conditions préalables
Pour que la propriété 'Image de base' soit renseignée dans Vulnerability Response pour conteneurs, les images de base doivent être configurées explicitement dans la Vulnerability Response Integration with Palo Alto Networks Prisma Cloud Compute console. Pour plus d’informations sur la configuration des images de base dans Prisma Cloud, consultez https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin- compute/vulnerability_management/base_images.
Vulnerability Response pour conteneurs Permet la création d’enregistrements de vulnérabilité distincts pour une couche de base afin qu’ils puissent être affectés à une autre équipe.
Suivez les vulnérabilités identifiées dans une image de système d’exploitation de base telle qu’Alpine à partir des vulnérabilités détectées dans d’autres couches de l’image du conteneur. De nombreuses organisations disposent d’équipes dédiées chargées d’appliquer des correctifs aux images de système d’exploitation de base et de les mettre à la disposition de toutes les équipes d’application.
- Définir la granularité des éléments vulnérables
- Conditions préalables
Configurez la granularité des CVIT en accédant à .
Par défaut, un élément vulnérable est créé pour chaque combinaison unique de CVE et de la version de l’image Docker (référence + balise). Toutefois, quelques images Docker peuvent être déployées dans plusieurs espaces de noms Kubernetes et chaque espace de noms peut appartenir à différentes unités commerciales ou équipes. Chaque équipe peut suivre sa propre cadence pour déployer de nouvelles versions d’images de conteneurs afin de corriger les vulnérabilités. Pour prendre en charge ce scénario, vous permet de définir la granularité des éléments vulnérables : s’il convient de créer un élément vulnérable pour chaque espace de noms/cluster/service Kubernetes, Vulnerability Response pour conteneurs même pour chaque combinaison unique de version et de vulnérabilité de l’image Docker.
Dans l’exemple, vous pouvez voir deux éléments vulnérables créés pour la même combinaison d’image Docker et de CVE. L’un pour l’espace de noms Kubernetes 'k8s-finservco-loans' et l’autre pour 'k8s-finservco-wealthandinsurance'.
- Identifier les services impactés à l’aide de l’identification de service basée sur les balises
- Conditions préalables
- Identifiez les différents services de votre application et définissez les balises/paires clé-valeur qui représentent ces services.
- Déployez des images Docker et des pods Kubernetes avec ces balises ou étiquettes.
- Déployer la détection Kubernetes ITOM Définissez les « services basés sur les balises » avec les balises ou les étiquettes appropriées.
- Déployer ITOM Kubernetes Discovery
- Définissez les « services basés sur les balises » avec les balises appropriées ou les paires clé-valeur appropriées.
- Importer des données de vulnérabilité dans à l’aide de ServiceNowVulnerability Response pour conteneurs
Le calcul du risque pour les éléments vulnérables peut être effectué en examinant le CI (image Docker) et la criticité des services associés dans CMDB. Toutefois, pour faciliter l’identification des services impactés, Vulnerability Response pour conteneurs propose une identification des services basée sur les balises.
Lorsque des pods ou des entités Kubernetes sont publiés avec des clé-valeurs ou des étiquettes correspondant aux clés-valeurs définies dans un « service basé sur les balises » dans ServiceNow, Vulnerability Response pour conteneurs établit automatiquement la relation entre une image Docker et le service d’application impacté et utilise la criticité de ce service d’application dans le calcul des risques.
Le flux est le suivant :- Vulnerability Response pour conteneurs Importe les données de vulnérabilité à partir du produit de sécurité du conteneur.
- Pour chaque élément vulnérable de conteneur, Vulnerability Response pour conteneurs renseigne l’image Docker à partir de CMDB laquelle présente la vulnérabilité.
- Vulnerability Response pour conteneurs examine ensuite les étiquettes d’image Docker ou les étiquettes/clé-valeurs publiées avec les pods Kubernetes où cette image est déployée. Cette image est disponible si CMDB la détection Kubernetes est en cours d’exécution.
- Vulnerability Response pour conteneurs recherche ensuite « Services basés sur les balises » avec CMDB les mêmes paires clé-valeur correspondantes définies.
- Vulnerability Response pour conteneurs utilise la « criticité opérationnelle » du « service basé sur les balises » correspondant (le cas échéant trouvé) pour calculer le risque d’un élément vulnérable du conteneur.
- Suivi des vulnérabilités
- Définition des cibles de rattrapage
ServiceNow permet aux gestionnaires des vulnérabilités de définir des « règles de cibles de rattrapage » afin de pouvoir définir des accords sur les niveaux de service (SLA) pour corriger les vulnérabilités trouvées dans les images de conteneurs. La date cible de rattrapage peut être définie en fonction d’une condition/d’un critère sur les métadonnées d’image ou les informations de vulnérabilité. Les propriétaires de rattrapage reçoivent une communication par e-mail sur les vulnérabilités qui approchent de la date d’échéance.
- Gérer les exceptions
Les équipes d’application ou les propriétaires de rattrapage des vulnérabilités peuvent avoir besoin de demander une exception pour les raisons suivantes.
- Un contrôle d’atténuation est déjà en place
- Risque accepté
- En attente de fenêtre de maintenance pour appliquer le correctif.
ServiceNow permet aux administrateurs de sécurité de définir plusieurs niveaux d’approbateurs pour les demandes d’exception. Vous pouvez également définir des règles d’exception automatique qui peuvent être utilisées pour différer automatiquement les vulnérabilités correspondant à une condition donnée.
Nouveautés
Pour en savoir plus sur les nouveautés et les changements apportés à Washington DC, consultez les notes de Washington DC publication.
Premiers pas
- Pour obtenir une vue d’ensemble sur Security Operations votre Now Platform instance, consultez Présentation de Security Operations.
- Pour en savoir plus sur toutes les Security Operations applications disponibles au téléchargement à partir de ServiceNow Store, consultez Security Operations et ServiceNow Store.