Vulnerability versus Configuration Management
IT-Fachpersonen werden heutzutage von Meldungen über Schwachstellen überhäuft. Meist sind es Produkte, die man selbst nicht im Einsatz hat. Oder das Produkt ist im Einsatz aber aufgrund eines Rebrandings des Herstellers noch unter einem alten Namen, was für Verwirrung und Mehraufwand für Abklärungen sorgt. Neben dem Verständnis wie die Schwachstelle ausgenutzt wird und ein Angriff aussehen könnte, muss der Security-Verantwortliche wissen, welche Produkte aktuell im Einsatz sind. Dies sollte in einer Configuration Management Database (CMDB) ersichtlich sein. Achtung: ein Vulnerability-Management-Werkzeug ist kein Ersatz für ein richtiges Asset-Verwaltungswerkzeug. Ein Vulnerability-Management-Werkzeug bietet Schnittstellen zu solchen CMDBs. Tenable selbst bietet eine Vielzahl von Integrationshilfen.
Die Schwierigkeit ist aber nicht die Implementation des Werkzeugs, sondern den Vulnerability-Management-Prozesses im Unternehmen zu etablieren und mit Leben zu füllen.
Wir unterscheiden fünf Asset-Typen:
1. Klassische IT-Systeme, On-Prem Server, Switches, Clients o. ä.
2. OT-Systeme
3. Hybride Assets, Applikationsserver, z. B. Datenbank Systeme, ERM / ERP Systeme o. ä.
4. Cloud Assets; IaaS, PaaS, SaaS.
5. Private Assets; BYOD z. B: Smartphone mit Kalender-Mail-Anbindung, Private Notebooks (VPN oder Terminal Server Access).
Für die fünf Typen gibt es unterschiedliche Verantwortlichkeiten, Sicherheitsstandards und Stakeholder. Vulnerability Management sollte daher als Prozess verstanden werden, der im gesamten Unternehmen definiert, bekannt und gelebt wird.
Know Your Assets
«Know Your Assets» ist mehr als nur ein Mantra, das IT-Verantwortlichen aufsagen können. Ein funktionierendes Vulnerability Management bedeutet auch, dass man weiss, welche Systeme im Einsatz sind, welche Daten wo aufbewahrt werden und vor allen wer diese betreut. Dies wird dann in einer CMDB (Configuration Management Database) eingetragen. Im besten Fall ist dies mit einem Vulnerability Management Tool verknüpft. Leider ist der Betrieb einer CMDB aufwändig und es gibt selten eine Stelle, die überprüft, inwieweit die Informationen in dieser Datenbank aktuell und vorhanden sind.
Im besten Falle werden Schwachstellen durch regelmässige Scans schnell erkannt und mittels einem Ticketing Tool weitergereicht. Ab hier beginnt dann die eigentliche Arbeit:
- Bewertung der Schwachstelle
- Planung des Patchmanagements
- Koordination mit anderen Stakeholdern
- Bearbeitung des Tickets
- u.v.m.
Diese Arbeiten können nicht alle automatisiert werden. Hier braucht es immer noch eine menschliche Komponente - und wenn es nur um das Nachfragen beim Systemadministrator geht.
Beurteilung von Schwachstellen
Die publizierten Schwachstellen haben meist einen sogenannten CVSS Score (Common Vulnerability Scoring System), der die Gefährlichkeit anzeigt. Dieser Score wird in drei Subkategorien unterteilt Base, Temporal und Environmental.
Der Score legt den Fokus auf die Schwachstelle und ist nicht für jedes Unternehmen anwendbar. Daher ist es wichtig, die eigene «Umgebung» zu berücksichtigen. Wer hat Zugriff - Öffentlichkeit, Kunden, Mitarbeitende? Was braucht es für die Ausnutzung? Netzwerk, physischen Zugriff, lokale User? Das folgende Beispiel soll dies verdeutlichen.
«Wenn ein System über das Netzwerk erreichbar ist, ist es anfälliger, als wenn es sich in einem abgeschlossenen Kellerraum befindet und vom Netzwerk getrennt ist».
Daher ist es wichtig seine Assets zu kennen. Oft wird eine Schwachstelle bekannt, in den Medien heiss diskutiert und in aller Eile gepatcht. Dies übereilte Vorgehen birgt häufig Risiken für den Betrieb und kann dem Ansehen des VM schaden. Halten Sie sich an Ihre Prozesse.
- Ordnen Sie die Schwachstelle ein
- Schätzen Sie das Risikopotenzial ein
- Denke Sie an die Motivation eines potenziellen Angreifers (know your enemy)
- Entscheiden Sie dann, ob ein «emergency patching» nötig ist
Tenable hat hierzu das VPR (Vulnerability Priority Rating) definiert, abgekürzt ist dies eine automatisierte Lagebeurteilung, welche die Schwachstelle in Korrelation mit erweiterten Informationen beurteilt. Die anschliessende Empfehlung zur Patch-Priorisierung ist als Unterstützung des Security Teams gedacht. Dies im Hinblick auf die Frage: Hat unser Security Team immer das Wissen und vor allem die Zeit neue Schwachstellen zu bewerten?
Blog von Tenable: What is VPR and how is it different from SVSS
Cloud und Vulnerability Management
Der Shift von Assets ausserhalb des Perimenters ist in vielen Unternehmen normal geworden. Dadurch entstehen neue Risiken, die mittels Vulnerability-Management-Werkzeug zu überprüfen sind. Tenable Attack Surface Management bietet genau diese Funktion, indem es das Internet scannt und öffentlich zugängliche Informationen verwendet und so eine Auflistung möglicher Angriffsvektoren erstellt. Es gibt zum Beispiel an, welche IPs in meinem Public Adressblock erreichbar sind, welche Schwachstellen vorhanden und welche Assets bei Amazone Web Services mit meiner Firma in Verbindung gebracht werden.
Bei Cloud Assets ist es besonders wichtig zu wissen, wer für was verantwortlich ist, dies ist Teil einer Cloud-Strategie und nicht Bestandteil vom Vulnerability Management. Jeder Cloud-Anbieter wird ein Shared-Responsability-Model haben.
Hier das Beispiel von Microsoft
Auf Grundlage dieses Models werden die Verantwortlichkeit geregelt, wobei es wichtig ist, dass in der Cloud-Strategie das Vulnerability, Patch und Asset Management mit einbezogen werden. Ein Vulnerability-Management-System kann nur prüfen, was es kennt, daher ist eine Zusammenarbeit von Projektbeginn an wünschenswert.
Fazit und Empfehlungen
Ein Vulnerability Management hilft jedem Unternehmen seine Infrastruktur besser zu kennen. Ein funktionierendes Vulnerability Management ist kein Werkzeug, das einmal installiert wird und dann sind alle Probleme gelöst. Es ist ein Prozess, der stetig optimiert und der von allen Beteiligten akzeptiert und gelebt werden muss.
Ein gut funktionierendes Schwachstellen-Management benötigt eine CMDB und ein Patchmanagement. Die CMDB dient als Basis, um Assets zu identifizieren und das Patchmanagement natürlich zum Patchen.
Wir empfehlen, das Vulnerability Management zunächst auf einen Teilbereich der Infrastruktur zu fokussieren, um so Erfahrungen zu sammeln und diese in die Weiterentwicklung des VMs einfliessen zu lassen. Denken Sie daran, dass Assets, Stakeholder und das Sicherheitsniveau sowie dessen Wahrnehmung nicht immer vergleichbar sind.