Anmerkung des Autors:Ich teste den Dienst im Rahmen meiner Tätigkeit am Bielefelder IT Service Center (BITS) der Universität Bielefeld. Dieser Artikel spiegelt meine persönliche Sicht auf Red Hat Insights wider. Außerdem möchte ich klarstellen, dass ich Mitglied der Red Hat Accelerators Community bin.
Nachdem Sie Red Hat Insights vorgestellt und einen Blick auf den Advisor geworfen haben, ist es an der Zeit, einen Blick auf das Schwachstellenmanagement von Insights zu werfen.
Das Dashboard zeigt ein Feld namens Vulnerability. Abb. 1 zeigt, dass wir offensichtlich von 13 Schwachstellen betroffen sind. Diese können wir nun genauer unter die Lupe nehmen. Dies geschieht wie gewohnt über den Link in der Box oder über das Menü links.
In der Schwachstellenansicht erwartet uns die übliche tabellarische Ansicht (siehe Abb. 2). Hier werden CVEs mit ihrer ID, dem Datum der Veröffentlichung, einer Folgenabschätzung, dem CVSS-Basiswert und der Anzahl der betroffenen Systeme aufgelistet. Zusätzlich haben Sie die Möglichkeit, für ausgewählte oder alle CVEs ein Geschäftsrisiko und einen Status zu vergeben (siehe gelbe Markierung in Abb. 2).
Das Geschäftsrisiko gibt Ihnen die Möglichkeit, ein bestimmtes CVE oder eine Gruppe von CVEs dahingehend zu bewerten, wie sie Ihr Geschäft beeinträchtigen oder negativ beeinflussen könnten (siehe Abb. 3). Dieser Status kann sich von den Auswirkungen in der zweiten Spalte unterscheiden, abhängig von bestimmten Sicherheitsmaßnahmen, die Sie bereits getroffen haben. Der Status gibt an, wie die Schwachstellen verarbeitet werden (siehe Abb. 4).
Wie im Advisor erhalten Sie eine Detailansicht mit Beschreibung jeder CVE, Bewertung und Übersicht der Angriffsvektoren (siehe Abb. 5), sowie Links zur Red Hat Knowledge Base, wo detaillierte Informationen über die CVE und vorhandene Errata gefunden werden.
Bewertung des Schwachstellenmanagements
Stand heute haben wir kein aktives Schwachstellenmanagement. Wir versuchen, ein gewisses Maß an Sicherheit mit einem Patch-Management für RHEL mit Ansible zu gewährleisten, das ich mit Tools entwickelt habe, die in RHEL und der Ansible Engine enthalten sind. Dadurch wird sichergestellt, dass verfügbare Red Hat Security Advisories einmal im Monat auf allen RHEL-Systemen zwingend installiert werden, falls sie fehlen.
Dank dieses Patch-Managements gibt es auf den angeschlossenen Testsystemen nur 13 Schwachstellen, und keine davon hatte einen Score von mehr als acht.
Unter den im Dashboard aufgelisteten Systemen befanden sich Systeme einer Testinfrastruktur, die nicht an das zentrale Patchmanagement angebunden sind und nur unregelmäßig gepatcht werden. Insights haben mir hier gezeigt, dass das Risiko viel zu groß ist und diese Systeme einfach in Vergessenheit geraten. Aus diesem Grund wurden diese Hosts nun sofort in das Patchmanagement aufgenommen.
Interessanter sind CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 und CVE-2019-11091, die Insights für einige Hosts anzeigt.
Diese Schwachstellen haben gemeinsam, dass sie nicht einfach durch die Installation eines Updates geschlossen werden können. Da es sich um virtuelle Maschinen (VM) auf einem vSphere-Cluster handelt, ist eine Kombination von Maßnahmen erforderlich, um die Schwachstellen zu mindern.
In diesem konkreten Fall müssen die betroffenen VMs nur einmal aus- und wieder eingeschaltet werden. Dadurch werden neue CPU-Funktionen an das Gastbetriebssystem weitergegeben, und die Schadensbegrenzung ist abgeschlossen.
Ich muss zugeben, dass diese Schwachstellen ohne Erkenntnisse lange Zeit unentdeckt geblieben wären.
Nun muss ich davon ausgehen, dass es in unserer Umgebung noch weitere anfällige Systeme gibt. Da ich diese nicht mit Insights verbinden darf, verwende ich ein von Red Hat bereitgestelltes Skript, um diese zu finden. Ich schätze es sehr, dass Red Hat solche Skripte bereitstellt, um seinen Kunden hier zu helfen. Es gibt immer noch ein paar Unternehmen, die diesem Beispiel getrost folgen können.
Ich persönlich halte ein aktives Schwachstellenmanagement für sinnvoll. Nur durch kontinuierliche Kontrolle können Schwachstellen gefunden, bewertet und entsprechend behandelt werden. Gleichzeitig kann damit überprüft werden, ob bereits Maßnahmen zur Verbesserung der Standsicherheit ergriffen wurden (z. B. ein Patch-Management).
Abb. 6 zeigt, dass derzeit keine offenen Schwachstellen vorhanden sind. Dies sollte immer das Ziel sein.
Der Test der Vulnerability Management Funktion hat mir selbst viel Spaß gemacht und die gefundenen Schwachstellen konnten innerhalb kurzer Zeit geschlossen werden.
[Nehmen Sie am 23. Juli 2020 an Red Hat Insights Ask Me Anything mit Produktmanager Jerome Marc teil, bei dem es um den Vergleich von Systemen mit Drift geht.]