Container Vulnerability Response

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 8 Minuten Lesedauer

    • Die ServiceNow® Container Vulnerability ResponseAnwendung importiert angreifbare Container-Elemente (CVITs) Und gemäß den Regeln können Sie Container-Schwachstellen beheben. Schwachstellendaten werden aus internen und externen Quellen abgerufen, z. B. der nationalen Schwachstellendatenbank (National Vulnerability Database, NVD) oder Integrationen von Drittparteien.

    Apps im Store anfordern

    Besuchen Sie die ServiceNow Store-Website, um alle verfügbaren Apps anzuzeigen und Informationen zum Senden von Anforderungen an den Store zu erhalten. Kumulative Informationen zum Release für alle veröffentlichten Apps finden Sie in den Release-Hinweisen zum ServiceNow Store-Versionsverlauf.

    Vorteile

    Die Container Vulnerability ResponseAnwendung bietet die folgenden Vorteile:
    • Integriert in Container-Sicherheitsprodukte von Drittanbietern, z. B. Prisma Cloud Compute von Palo Alto Networks.
    • Importiert Schwachstellendaten für die Images, die zur Laufzeit bereitgestellt werden, und ergänzt die Schwachstellendaten mit kontextbezogenen Informationen zur Laufzeit (Hosts, Kubernetes-Cluster, Services und Namespaces).
    • Stellt eine Liste der Referenzen bereit, die aus Schwachstellen zu den relevanten Kubernetes-Entitäten in erstellt wurden Configuration Management Database (CMDB)Wird verwendet ServiceNowKubernetes-Discovery.
    • Bietet ein umfassendes Reporting-Dashboard, das Einblicke in die Trends bei Schwachstellen und Fehlerkorrekturen bietet.

    Schlüsselfunktionen

    Die Container Vulnerability ResponseDie Anwendung verwaltet in den Containern erkannte Schwachstellen. Es bietet die folgenden Funktionen:
    • Verweisen Sie auf das Docker-Quellbild aus CVITs, anstatt Container auszuführen.
    • Konfigurieren Sie die Granularität von CVITs, um sie auf Image-, Kubernetes-Cluster-, Namespace- oder Servicelevel nachzuverfolgen.
    • Verfolgen Sie neue Image-Versionen nach, um behobene Schwachstellen zu identifizieren. Alle in älteren Versionen gemeldeten Schwachstellen werden automatisch in gelöst ServiceNowWenn neue Image-Versionen zur Laufzeit bereitgestellt werden.
    • Verfolgen Sie CVITs in Basis-Images getrennt von Anwendungsbildern, um eine unabhängige Korrektur zu ermöglichen.
    • Stellen Sie Ausnahmeanforderungen oder falsch positive Anforderungen, die durch einen mehrstufigen Genehmigerprozess überprüft werden können.
    • Definieren Sie Ausnahmeregeln, um CVITs automatisch zurückzustellen.

    Anwendungsfälle

    Container sind eine großartige Möglichkeit, Anwendungen in mehreren Umgebungen mit weniger Overhead und erhöhter Portabilität bereitzustellen und zu skalieren. Schwachstellen in Container-Images können jedoch ein Risiko für den zugrunde liegenden Host und letztendlich für die Infrastruktur darstellen, in der Container von diesen Images gestartet wurden. Zwar gibt es viele Container-Sicherheitsprodukte, die Container-Images auf Schwachstellen scannen, es gibt jedoch einige Überlegungen und Probleme im Zusammenhang mit der Behebung der Schwachstellen. Container Vulnerability ResponseKann bei der Lösung verschiedener Probleme oder Anwendungsfälle helfen, die bei der Behebung von Schwachstellen in Containerbildern beteiligt sind. Erkunden Sie, wie Sie die Vorteile von nutzen können Container Vulnerability ResponseModul:
    Laufzeitkontext
    Schwachstellen in Container-Images können erkannt werden, indem das Image in den folgenden Phasen des Anwendungslebenszyklus gescannt wird.
    • Phase 1: Wenn Images in der CI/CD-Pipeline erstellt werden.
    • Phase 2: Wenn Bilder in der Registrierung veröffentlicht werden
    • Phase 3: Wenn Images zur Laufzeit bereitgestellt werden.
    Es ist zwar wichtig, Schwachstellen in Phase 1 und Phase 2 so früh wie möglich zu identifizieren, aber die Durchführung eines Scans für die Bilder, die in einer Laufzeitumgebung bereitgestellt werden, ist gleichermaßen wichtig. Es bietet die folgenden Vorteile:
    • Identifizierung neuer allgemeiner Schwachstellen und Risiken (CVEs), die veröffentlicht wurden.
    • Bietet einen genauen Einblick in die Risikosituation bereitgestellter Anwendungen.
    • Priorisierung von Schwachstellen, die gelöst werden müssen. Der Laufzeitkontext in Bezug auf die Anwendungsservices oder Business-Services, die aufgrund einer Schwachstelle betroffen sind, kann bei der Priorisierung helfen.

    Container Vulnerability ResponseIst in Container-Sicherheitsprodukte wie Prisma Cloud Computing von integriert Palo Alto NetworksDient zum Abrufen der Schwachstellendaten für die Images, die zur Laufzeit bereitgestellt werden, und ergänzt die Schwachstellendaten mit den kontextbezogenen Laufzeitinformationen wie Hosts, Kubernetes-Cluster, Services und Namespaces, auf denen diese Container-Images bereitgestellt werden. Kunden, die verwenden ServiceNowDie Kubernetes-Discovery kann die aus Schwachstellen erstellten Referenzen zu den relevanten Kubernetes-Entitäten in ihren anzeigen Configuration Management Database (CMDB). Zusätzlich zur Ergänzung der Metadaten ServiceNowBietet auch ein umfassendes Reporting-Dashboard, um Einblicke in die Trends bei Schwachstellen und Fehlerkorrekturen zu bieten.Laufzeitkontext

    Identifizieren Sie den Besitz
    Voraussetzungen

    • Kubernetes-Metadaten und -Referenzen : Für Container Vulnerability ResponseZum Ausfüllen von Kubernetes-Metadaten (Namespace, Cluster usw.) und Verweisen auf Configuration Management Database (CMDB)Einträge, müssen Sie die Kubernetes-Discovery aus implementieren Information Technology Operations Management(ITOM). Die Kubernetes-Discovery füllt das Docker-Image, die ausgeführten Docker-Container, Pods, Kubernetes-Cluster usw. in aus CMDB. Container Vulnerability ResponseGibt das Docker-Image in an CMDBBasierend auf der Bild-ID identifiziert und dann die zugehörigen Kubernetes-Entitäten und füllt die Verweise auf diese Entitäten aus angreifbaren Elementen aus.

    • Cloud-Metadaten und Docker-Image-Bezeichnungen : Container Vulnerability ResponseFüllt auch Docker-Image-Bezeichnungen, Cloud-Account-IDs und Regionen aus, in denen ein Image bereitgestellt wird. Diese Daten werden im Datensatz „erkanntes Containerbild“ verwaltet, der dem angreifbaren Element zugeordnet ist. Es sind keine Voraussetzungen zum Ausfüllen dieser Daten vorhanden. Container Vulnerability ResponseVerwendet die Daten, die von Containersicherheitsprodukten (z. B. Palo Alto Prisma Cloud Compute) zurückgegeben werden, um diese Einträge auszufüllen.

    Die Verantwortung für das Patchen einer Schwachstelle in einem Container-Image kann von Organisation zu Organisation variieren. Diese Informationen können an verschiedenen Orten erfasst werden. Einige Organisationen verwenden Docker-Image-Bezeichnungen, um die Anwendungsteams zu identifizieren, die ein bestimmtes Container-Image besitzen, während andere Organisationen den Kubernetes-Namespace oder den Cloud-Account verwenden, in dem ein Container-Image bereitgestellt wird, um den richtigen Besitzer zu identifizieren.

    Container Vulnerability Response Stellt die erforderlichen Datenmodellelemente bereit, um Docker-Image-Bezeichnungen, Kubernetes-Cluster/Service/Namespace-Metadaten oder Cloud-Account-Metadaten (Cloud-Account-ID, Region, Provider usw.) im Modul „Zuweisungsregeln“ erfassen und verwenden zu können und Schwachstellen automatisch dem richtigen Anwendungsteam basierend auf den Metadaten des Images oder der Laufzeitumgebung zuzuweisen.

    Eigentümeridentifizierung

    Verfolgen Sie Schwachstellen in den Basis-Images nach
    Voraussetzungen

    Für die Eigenschaft „Basisbild“, die ausgefüllt werden soll Container Vulnerability Response, Basis-Images müssen explizit in konfiguriert werden Vulnerability Response Integration with Palo Alto Networks Prisma Cloud ComputeKonsole. Weitere Informationen zum Konfigurieren von Basis-Images in Prisma Cloud finden Sie unter https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin- Compute/Vulnerability_Management/Base_images.

    Container Vulnerability Response Ermöglicht die Erstellung separater Schwachstellendatensätze für eine Basisebene, damit sie einem anderen Team zugewiesen werden können.

    Verfolgen Sie Schwachstellen, die in einem Basis-BS-Image wie Alpine identifiziert wurden, anhand der Schwachstellen, die in anderen Ebenen des Container-Images erkannt wurden. Viele Organisationen verfügen über dedizierte Teams, die für das Patchen von Basis-BS-Images verantwortlich sind und sie für alle Anwendungsteams verfügbar machen. Basis-Image

    Definieren Sie die Granularität für angreifbare Elemente
    Voraussetzungen

    Konfigurieren Sie die Granularität von CVITs, indem Sie zu navigieren Alle > Container Vulnerability Response > Administration > VI-Granularität konfigurierenan.

    VI-Granularität

    Standardmäßig wird für jede eindeutige Kombination aus CVE und Docker-Image-Version (Referenz + Tag) ein angreifbares Element erstellt. Einige Docker-Images können jedoch in mehr als einem Kubernetes-Namespace bereitgestellt werden, und jeder Namespace kann verschiedenen Geschäftsbereichen oder Teams gehören. Jedes Team kann seinem eigenen Rhythmus folgen, um neue Versionen von Container-Images bereitzustellen, um Schwachstellen zu beheben. Um dieses Szenario zu berücksichtigen, Container Vulnerability ResponseErmöglicht Ihnen das Definieren der Granularität für angreifbare Elemente: Ob ein angreifbares Element für jeden Kubernetes-Namespace/Cluster/Service erstellt werden soll, auch für jede eindeutige Kombination aus Docker-Image-Version und Schwachstelle.

    VI-Granularität

    Im Beispiel können Sie zwei angreifbare Elemente sehen, die für dieselbe Kombination aus Docker-Image und CVE erstellt wurden. Einer für den Kubernetes-Namespace „k8s-finservco-Darlehen“ und der andere für „k8s-finservco-wealthandInsurance“.

    Identifizieren Sie betroffene Services mithilfe der Tag-basierten Serviceidentifizierung
    Voraussetzungen
    • Identifizieren Sie verschiedene Services in Ihrer Anwendung, und definieren Sie die Tags/Schlüssel-Wert-Paare, die diese Services darstellen.
    • Stellen Sie Docker-Images und Kubernetes-Pods mit diesen Tags oder Bezeichnungen bereit.
    • ITOM Kubernetes Discovery bereitstellen Definieren Sie „Tag-basierte Services“ mit den richtigen Tags oder Bezeichnungen.
    • Stellen Sie ITOM Kubernetes Discovery bereit
    • Definieren Sie „Tag-basierte Services“ mit den richtigen Tags oder Schlüssel-Wert-Paaren.
    • Importieren Sie Schwachstellendaten in ServiceNowWird verwendet Container Vulnerability Response

    Die Risikoberechnung für angreifbare Elemente kann durchgeführt werden, indem das CI (Docker-Image) und die Relevanz der zugehörigen Services in betrachtet werden CMDB. Um jedoch die Identifizierung betroffener Services zu erleichtern, Container Vulnerability ResponseBietet Tag-basierte Serviceidentifizierung.

    Wenn Kubernetes-Pods oder -Entitäten mit Schlüsselwerten oder Bezeichnungen veröffentlicht werden, die den Schlüsselwerten entsprechen, die in einem beliebigen „Tag-basierten Service“ in definiert sind ServiceNow, Container Vulnerability ResponseStellt automatisch die Beziehung zwischen einem Docker-Image und dem betroffenen Anwendungsservice her und verwendet die Relevanz dieses Anwendungsservice bei der Risikoberechnung.

    Der Flow lautet wie folgt:
    1. Container Vulnerability Response Importiert Schwachstellendaten aus dem Container-Sicherheitsprodukt.
    2. Für jedes angreifbare Container-Element Container Vulnerability ResponseFüllt das Docker-Bild aus CMDBDas hat die Schwachstelle.
    3. Container Vulnerability Response Betrachtet dann die Docker-Image-Bezeichnungen oder die Bezeichnungen/Schlüsselwerte, die mit Kubernetes-Pods veröffentlicht wurden, auf denen dieses Image bereitgestellt wird. Dieses Bild ist in verfügbar CMDBWenn die Kubernetes-Discovery ausgeführt wird.
    4. Container Vulnerability ResponseSucht dann in nach „Tag-basierte Services“ CMDBMit denselben übereinstimmenden Schlüssel-Wert-Paaren definiert.Risikoberechnung

      Risikoberechnung

    5. Container Vulnerability Response Verwendet die „Geschäftskritikalität“ des übereinstimmenden „Tag-basierten Service“ (falls vorhanden), um das Risiko eines angreifbaren Containerelements zu berechnen.

      Risikoberechnung

      Risikoberechnung
    Nachverfolgung Von Schwachstellen
    Korrekturziele werden festgelegt

    ServiceNow Ermöglicht Schwachstellenmanager, „Korrekturzielregeln“ zu definieren, um Servicelevel-Vereinbarungen (Service Level Agreements, SLAs) zur Behebung von Schwachstellen in Container-Images definieren zu können. Das Korrekturzieldatum kann basierend auf einer Bedingung/einem Kriterium für Bildmetadaten oder Schwachstelleninformationen definiert werden. Korrekturbesitzer erhalten E-Mail-Kommunikation zu den Schwachstellen, die dem Fälligkeitsdatum nähern.Legen Sie das Korrekturziel fest

    Identifizierung behobener Schwachstellen

    Im Gegensatz zu Host-Schwachstellen, die durch Anwenden eines Patches auf einen Host behoben werden können, können Container-Schwachstellen nicht gepatcht werden. Neue Versionen von Container-Images müssen erstellt und bereitgestellt werden, um die älteren Versionen zu ersetzen. Die neuen Versionen haben einen anderen Bezeichner (Image-ID) als die vorherigen Versionen, was es schwierig macht, nachzuverfolgen, welche Schwachstellen bereits behoben wurden.

    ServiceNow Identifiziert Schwachstellen, die in den vorherigen Versionen der Container-Images gemeldet wurden, aber in der neuesten Version des Images gelöst wurden, und verschiebt diese Schwachstellen automatisch in den Status „Geschlossen/behoben“, damit Sicherheitsteams immer genaue Einblicke in die aktuelle Risikosituation haben.

    Ausnahmen verwalten

    Anwendungsteams oder Korrekturbesitzer für die Schwachstellen benötigen möglicherweise die Möglichkeit, aus den folgenden Gründen eine Ausnahme anzufordern.

    • Eine Minderungssteuerung ist bereits vorhanden
    • Risiko akzeptiert
    • Warten auf Wartungsfenster, um die Korrektur zu verschieben.

    ServiceNow Ermöglicht Sicherheitsadministratoren, mehrere Genehmigerebenen für Ausnahmeanforderungen zu definieren. Sie können auch automatische Ausnahmeregeln definieren, die verwendet werden können, um automatisch Schwachstellen, die einer bestimmten Bedingung entsprechen, aufzuschieben.Ausnahmen

    Ausnahmen

    Neuigkeiten

    Um mehr darüber zu erfahren, was in neu ist und was sich geändert hat Yokohama, Siehe YokohamaRelease-Hinweise.

    Erste Schritte