Container Vulnerability Response

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 8 Minuten Lesedauer

    • Die Anwendung ServiceNow® Container Vulnerability Response importiert angreifbare Container-Elemente (CVITs) und ermöglicht gemäß den Regeln die Behebung von Container-Schwachstellen. Schwachstellendaten werden aus internen und externen Quellen abgerufen, z. B. aus der National Vulnerability Database (NVD) oder aus Integrationen von Drittanbietern.

    Ab Version 18.0 von Vulnerability Responsekönnen Sie CVITs in Vulnerability Manager Workspace bzw. IT Remediation Workspace überwachen und korrigieren. Weitere Informationen finden Sie unter Arbeitsbereich des Schwachstellenmanagers und IT Remediation Workspace erkunden.

    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 Anwendung Container Vulnerability Response bietet die folgenden Vorteile:
    • Integration mit Container-Sicherheitsprodukten von Drittanbietern wie Prisma Cloud Compute von Palo Alto Networks.
    • Importiert Schwachstellendaten für die Images, die zur Laufzeit bereitgestellt werden, und erweitert die Schwachstellendaten mit kontextbezogenen Informationen zur Laufzeit (Hosts, Kubernetes-Cluster, Services und Namespaces).
    • Stellt eine Liste der Referenzen bereit, die aus Schwachstellen auf die relevanten Kubernetes-Entitäten in Configuration Management Database (CMDB) mithilfe von ServiceNow Kubernetes Discovery erstellt wurden.
    • Bietet ein umfassendes Dashboard für die Berichterstellung, das Einblicke in die Schwachstellen- und Korrekturtrends bietet.

    Schlüsselfunktionen

    Die Anwendung Container Vulnerability Response verwaltet in den Containern erkannte Schwachstellen. Sie bietet die folgenden Funktionen:
    • Verweist auf Docker-Image aus CVITs, anstatt Container auszuführen.
    • Konfigurieren Sie die Granularität von CVITs für die Nachverfolgung auf Image-, Kubernetes-Cluster-, Namespace- oder Serviceebene.
    • Verfolgen Sie neue Image-Versionen nach, um behobene Schwachstellen zu identifizieren. Alle in älteren Versionen gemeldeten Schwachstellen werden in ServiceNow automatisch behoben, wenn neue Image-Versionen zur Laufzeit bereitgestellt werden.
    • Verfolgen Sie CVITs in Basis-Images getrennt von Anwendungs-Images nach, 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 geringerem Overhead und erhöhter Portabilität bereitzustellen und zu skalieren. Allerdings können Schwachstellen in Container-Images ein Risiko für den zugrunde liegenden Host und letztlich 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, aber es gibt einige Überlegungen und Probleme im Zusammenhang mit der Behebung der Schwachstellen. Container Vulnerability Response kann bei der Lösung verschiedener Probleme oder Anwendungsfälle im Zusammenhang mit der Behebung von Container-Image-Schwachstellen helfen. Erkunden Sie Möglichkeiten, das Modul Container Vulnerability Response zu nutzen:
    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 Images in der Registrierung veröffentlicht werden
    • Phase 3: Wenn Images zur Laufzeit bereitgestellt werden.
    Während es wichtig ist, Schwachstellen in Phase 1 und Phase 2 so früh wie möglich zu identifizieren, ist es ebenso wichtig, die Images zu scannen, die in einer Laufzeitumgebung bereitgestellt werden. Es bietet die folgenden Vorteile:
    • Identifizieren neuer allgemeiner Schwachstellen und Gefährdungen (CVEs), die veröffentlicht wurden
    • Bietet genaue Transparenz der Risikosituation der bereitgestellten Anwendungen.
    • Priorisierung von Schwachstellen, die behoben werden müssen. Der Laufzeitkontext in Bezug auf die Anwendungsservices oder Geschäftsservices, die aufgrund einer Schwachstelle betroffen sind, kann bei der Priorisierung helfen.

    Container Vulnerability Response ist in Container-Sicherheitsprodukte wie Prisma Cloud Compute aus Palo Alto Networks integriert, um die Schwachstellendaten für die Images abzurufen, die zur Laufzeit bereitgestellt werden, und erweitert die Schwachstellendaten um kontextbezogene Informationen zur Laufzeit, z. B. Hosts, Kubernetes-Cluster, Services und Namespaces Diese Container-Images werden bereitgestellt. Kunden, die die Kubernetes-Erkennung ServiceNow verwenden, können die aus Schwachstellen erstellten Verweise auf die relevanten Kubernetes-Entitäten in ihrem Configuration Management Database (CMDB)anzeigen. Zusätzlich zur Anreicherung der Metadaten bietet ServiceNow auch ein umfassendes Berichts-Dashboard, das Einblicke in die Schwachstellen- und Korrekturtrends bietet.Laufzeitkontext

    Identifizieren Sie den Besitzer
    Voraussetzungen

    • Kubernetes-Metadaten und -Referenzen: Damit Container Vulnerability Response Kubernetes-Metadaten (Namespace, Cluster usw.) und Verweise auf Configuration Management Database (CMDB) -Einträge ausfüllt, müssen Sie die Kubernetes-Erkennung aus Information Technology Operations Management (ITOM) implementieren. Die Kubernetes-Erkennung füllt das Docker-Image, die ausgeführten Docker-Container, Pods, Kubernetes-Cluster usw. in CMDB. Container Vulnerability Response identifiziert das Docker-Image in CMDB basierend auf der Image-ID, identifiziert dann die zugehörigen Kubernetes-Entitäten und füllt die Verweise auf diese Entitäten aus angreifbaren Elementen.

    • Cloud-Metadaten und Docker-Image-Bezeichnungen: Container Vulnerability Response füllt auch Docker-Image-Bezeichnungen, Cloud-Konto-IDs und Regionen, in denen ein Image bereitgestellt wird. Diese Daten werden im Datensatz „Erkanntes Container-Image“ verwaltet, das dem angreifbaren Element zugeordnet ist. Es gibt keine Voraussetzungen für das Ausfüllen dieser Daten. Container Vulnerability Response verwendet die von Container-Sicherheitsprodukten zurückgegebenen Daten (z. B. Palo Alto Prisma Cloud Compute), 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 Stellen 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 das Cloud-Konto verwenden können, in dem ein Container-Image bereitgestellt wird, um den richtigen Besitzer zu identifizieren.

    Container Vulnerability Response stellt die erforderlichen Datenmodellelemente bereit, damit Docker-Image-Bezeichnungen, Kubernetes-Cluster-/Service-/Namespace-Metadaten oder Cloud-Account-Metadaten (Cloud-Account-ID, Region, Anbieter usw.) in den Zuweisungsregeln erfasst und verwendet werden können. Modul und weisen Schwachstellen basierend auf den Metadaten des Images oder der Laufzeitumgebung automatisch dem richtigen Anwendungsteam zu.

    Identifizierung des Besitzers

    Verfolgen Sie Schwachstellen in den Basis-Images nach
    Voraussetzungen

    Damit die Eigenschaft „Basis-Image“ in Container Vulnerability Responseausgefüllt wird, müssen Basis-Images explizit in der Konsole Vulnerability Response Integration with Palo Alto Networks Prisma Cloud Compute konfiguriert werden. Weitere Informationen zum Konfigurieren von Basis-Images in Prisma Cloud finden Sie unter https://docs.paloatonetworks.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 Basisschicht, sodass sie einem anderen Team zugewiesen werden können.

    Verfolgen Sie Schwachstellen, die in einem Basisbetriebssystem-Image (z. B. Alpin) identifiziert wurden, anhand der in anderen Ebenen des Container-Images erkannten Schwachstellen nach. Viele Organisationen haben dedizierte Teams, die dafür verantwortlich sind, Basis-BS-Images zu patchen und für alle Anwendungsteams verfügbar zu 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 konfigurieren.

    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 für die Einführung neuer Versionen von Container-Images folgen, um Schwachstellen zu beheben. Um diesem Szenario Rechnung zu tragen, können Sie mit Container Vulnerability Response die Granularität für angreifbare Elemente definieren: Gibt an, ob für jeden Kubernetes-Namespace/-Cluster/-Service ein angreifbares Element erstellt werden soll, auch für jede eindeutige Kombination aus Docker-Image-Version und Schwachstelle.

    VI-Granularität

    Im Beispiel sehen Sie zwei angreifbare Elemente, die für dieselbe Kombination aus Docker-Image und CVE erstellt wurden. Einer für den Kubernetes-Namespace „k8s-finservco-loans“ 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 von Schwachstellendaten in ServiceNow mit Container Vulnerability Response

    Die Risikoberechnung für angreifbare Elemente kann anhand des CI (Docker-Image) und der Relevanz der zugehörigen Services in CMDBerfolgen. Um jedoch die Identifizierung betroffener Services zu erleichtern, bietet Container Vulnerability Response eine 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 Tag-basierten Service in ServiceNowdefiniert sind, stellt Container Vulnerability Response automatisch die Beziehung zwischen einem Docker-Image und dem betroffenen Anwendungsservice her und verwendet den Relevanz dieses Anwendungsservice in der Risikoberechnung.

    Der Flow lautet wie folgt:
    1. Container Vulnerability Response importiert Schwachstellendaten aus dem Container-Sicherheitsprodukt.
    2. Für jedes angreifbare Containerelement füllt Container Vulnerability Response das Docker-Image aus CMDB, das die Schwachstelle aufweist.
    3. Container Vulnerability Response prüft dann die Docker-Image-Bezeichnungen oder die mit Kubernetes-Pods veröffentlichten Bezeichnungen/Schlüsselwerte, in denen dieses Image bereitgestellt wird. Dieses Image ist in CMDB verfügbar, wenn die Kubernetes-Erkennung ausgeführt wird.
    4. Container Vulnerability Response sucht dann nach „Tag-basierten Services“ in CMDB, wobei dieselben übereinstimmenden Schlüssel-Wert-Paare definiert sind.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 Schwachstellenmanagern die Definition von „Korrekturzielregeln“, um Servicelevel-Vereinbarungen (Service Level Agreements, SLAs) für die Behebung von in Container-Images gefundenen Schwachstellen definieren zu können. Das Korrekturzieldatum kann basierend auf einer Bedingung/einem Kriterium für Image-Metadaten oder Schwachstelleninformationen definiert werden. Korrekturbesitzer erhalten E-Mail-Benachrichtigungen über die Schwachstellen, die sich dem Fälligkeitsdatum nähern.Legen Sie das Korrekturziel fest

    Behobene Schwachstellen identifizieren

    Im Gegensatz zu Host-Schwachstellen, die durch Anwenden eines Patches auf einem 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 früheren Versionen der Container-Images gemeldet wurden, aber in der aktuellen Version des Images behoben wurden, und verschiebt diese Schwachstellen automatisch in den Status „Geschlossen/Behoben“, sodass Sicherheitsteams immer einen genauen Einblick in die aktuelle Risikosituation haben.

    Ausnahmen verwalten

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

    • Eine Verringerungskontrolle ist bereits vorhanden
    • Risiko akzeptiert
    • Warten auf das Wartungsfenster, um die Korrektur zu veröffentlichen.

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

    Ausnahmen

    Neuigkeiten

    Weitere Informationen zu den Neuerungen und Änderungen in Washington DCfinden Sie in den Versionshinweisen zu Washington DC.

    Erste Schritte