Die zunehmende Komplexität der Schwachstellenlandschaft macht es praktisch unmöglich sich im Unternehmensumfeld mit allen bekannten Sicherheitslücken auseinandersetzen. Folglich ist es zwingend notwendig herauszufinden welche Schwachstellen das Unternehmen betreffen und wie diese sinnvoll zu priorisieren sind. Schwachstellenmanagement-Systeme automatisieren genau diesen Prozess und sind somit ein unerlässliches Werkzeug im Arsenal der IT-Sicherheit.

Gliederung

1. Notwendigkeit des Schwachstellenmanagements
2. Schwachstellen-Scanner
3. Schwachstellenmanagement-Systeme
4. Prozessmodellierung
5. Quellen

Notwendigkeit des Schwachstellenmanagements

Begriffsdefinition Schwachstellen

Schwachstellen (in der IT) sind Fehler innerhalb von Soft- oder Hardware, welche es ermöglichen ein Produkt über dessen vorgesehenen Funktionsumfang hinaus zur Kompromittierung der Sicherheit von IT-Systemen auszunutzen. (Foreman, 2019, Vulnerability Management – 2nd Edition)

Typische Schwachstellen sind u.a.:

• Fehlkonfiguration von IT-Systemen
• Programmierfehler (Vernachlässigung der IT-Sicherheit in der Software-Entwicklung)
• Veraltete (ungepatchte) Systeme

Prinzipiell existieren Schwachstellen ab dem Release unsicherer Soft-/ Hardware. I.A. sind die Schwachstellen zu diesem Zeitpunkt noch nicht bekannt. So kann der Lebenslauf einer Schwachstelle in etwa folgendermaßen skizziert werden:

Die drei Zeitstränge verlaufen nicht synchron. Insbesondere kann dementsprechend nach dem öffentlichen Bekanntwerden einer Schwachstelle ein funktionaler Exploit vor dem zugehörigen Patch erscheinen (z.B. in der Exploit-DB oder als Modul in Metasploit). Diese Form von Exploits sind als „Zero-Day-Exploits“ (oder auch nur Zero-Days) bekannt. Die Konsequenz dessen ist, dass ein geregeltes Patchmanagement nicht mehr ausreichen kann, um die Bedrohung vor möglichen Angreifern einzudämmen. Vielmehr muss innerhalb eines Unternehmens bekannt sein welche Schwachstellen existieren, sodass diese beim Nichtvorhandensein eines adäquaten Patches temporär anderweitig gesichert werden können (SIEM, Firewall-Restriktionen, ggf. auch Isolation).

Im Schwachstellenmanagement werden vorrangig der Allgemeinheit zugängige Quellen verwendet. Die NVD (National Vulnerability Database), welche den CVE-Katalog (Common Vulnerability Enumeration) der MITRE implementiert, ist hierfür der wichtigste Anlaufpunkt. Eine Absicherung gegen Zero-Day-Vulnerabilities ist praktisch nicht abschließend umsetzbar und für die meisten Unternehmen überflüssig. Der Schutz vor Hacktivistien und Script-Kiddies ist (für die meisten Unternehmen) viel relevanter als der vor organisiertem Verbrechen oder Nation-States.

Maßgaben gemäß IT-Grundschutz

In der aktuellen Version des IT-Grundschutzkompendiums (2021) ist das Schwachstellenmanagement erstmalig konkret verankert:

OPS.1.1.3.A16 Regelmäßige Suche nach Informationen zu Patches und Schwachstellen
Der IT-Betrieb MUSS sich regelmäßig über bekannt gewordene Schwachstellen der Firmware, Betriebssysteme, eingesetzter Anwendungen und Dienste informieren.
Die identifizierten Schwachstellen MÜSSEN so schnell wie möglich behoben werden.

Insbesondere sind somit Betreiber Kritischer Infrastrukturen (s. KRITIS-Gesetz) gesetzlich dazu verpflichtet ein Schwachstellenmanagement aufzubauen und zu betreiben.

Schwachstellen-Scanner

Der Begriff Schwachstellen-Scanner umfasst einige verschiedene Datenakquisitionssysteme:

• Aktive Scanner
• Agenten
• Korrelationssysteme (Loganalyse-Engines)
• Passive Scanner (Sniffer)

Da Passive Scanner bereits in Intrusion Detection Systemen implementiert und Korrelationssysteme Bestandteil des SIEMs (Security Information and Event Management) sind, werden diese Formen des Schwachstellen-Scannens kaum mit dem Schwachstellenmanagement in Verbindung gebracht und nachfolgend nicht weiter betrachtet.

Es ist außerdem zwischen

White-Box-Scans: Schwachstellen-Scanner hat volle Sicht auf das Zielsystem (lesender Zugriff auf das gesamte Dateisystem), bzw. „Sicht von innen“.
Black-Box-Scans: Schwachstellen-Scanner kann das System nur basierend auf dessen Außenschnittstellen (offene Ports, Dienste) untersuchen.

zu unterscheiden. Black-Box-Scans haben trotz ihrer eingeschränkten Sicht einen entscheidenden Vorteil gegenüber Whitebox-Scans, denn dieses Verfahren emuliert die gleiche Vorgehensweise eines potenziellen Angreifers in der Reconnaisance-Phase. Folglich sind kritische Schwachstellen, welche in einem Blackbox-Scan gefunden wurden eine größere Gefährdung als solche, die nur mit einem White-Box-Scan auffindbar waren.

Funktionsweise

Aktive Scanner

Aktive Scanner zeichnen sich dadurch aus, dass sie als eigenständiger Netzwerkteilnehmer agieren. Im Falle eines Whitebox-Scans verbindet sich der Schwachstellen-Scanner per Remotezugriff (SSH, WMI, SMB, Remote Registry) auf seine Scan-Ziele. Üblicherweise erfolgt die Prüfung auf Schwachstellen von dort aus anhand eines OVAL Definition Schemas (Open Vulnerability and Assessment Language)- ein umfangreiches XML-Dokument welches nach den Voraussetzungen für das Vorliegen einer bestimmten Schwachstelle prüft. Zum Beispiel wenn Sudo Version < 1.8.28, dann System anfällig für CVE-2019-14287; wenn Registrykey ABC = „xyz“ und Software 123 ist installiert, dann … .

CVE, CVSS und OVAL sind Bestandteil des SCAP (Security Content Automation Protocol), einer Sammlung von Bezeichnern und XML-Formaten zur standardisierten Beschreibung von Schwachstellen.

Im Falle eines Blackbox-Scans greift ein aktiver Schwachstellen-Scanner auf Fingerprinting-Methoden zurück. Das heißt der Scanner sendet speziell angefertigte Pakete und Segmente über das Netzwerk, die eine bestimmte Reaktion des Scan-Ziels hervorrufen, welche sich wiederum von System zu System (oder Dienst zu Dienst/ Version zu Version) unterscheidet. Anhand dieser Informationen kann korreliert werden, um welches Betriebssystem (Dienst, Version) es sich hier handelt. Zum Beispiel senden manche Betriebssysteme die TCP-Option Timestamp, andere nicht; manche Betriebssysteme reagieren auf eingehende ACK-Pakete vor Kommunikationsaufbau mit einem RST, andere verwerfen das Paket und reagieren nicht.
Ein weiteres beliebtes Mittel ist das Banner-Grabbing. Viele Dienste antworten bei einem Verbindungsaufbau mit einem „Banner“ in welchem sie ungefragt Dienstname und Versionsnummer preisgeben.

Im Vergleich zu einem Whitebox-Scan können, da es keine Notwendigkeit zur Bereitstellung von Credentials gibt, in einem Blackbox-Scan große Netzbereiche auf einmal abgescannt werden ohne davor zu wissen wie viele und welche Systeme sich darin befinden. Aus dieser Perspektive sind aktive Schwachstellen-Scanner sehr ähnlich zu Netzwerkscannern wie nmap.

Agenten

Hierbei handelt es sich um eine auf den Zielsystemen installierte Applikation, welche auf Anfrage des Agenten-Managers (bei Tenable – Nessus-Manager) einen Whitebox-Scan ausführen. Agenten sind im Allgemeinen aktiven Whitebox-Scans vorzuziehen, denn sie:

• benötigen keine dauerhaft bestehende Verbindung zum Zielsystem für die gesamte Scan-Zeit (es genügt die Scan-Ergebnisse nach dem Scan, sobald eine Verbindung besteht, zu übermitteln)
• verursachen wesentlich weniger Netzwerkverkehr
• brauchen keine zusätzlichen Credentials für einen Remote-Zugriff (man stelle sich vor auf jedem System sei ein spezieller Automations-User mit vollem Lesezugriff hinterlegt)

Allerdings sind Agenten nicht zwingend für alle Betriebssysteme verfügbar (es wird wohl kaum einen Agenten-Installer für CISCO IOS geben).

Installation und Verwendung am Beispiel von Nessus

Installation

Für bis zu 16 Scan-Ziele ist der Schwachstellen-Scanner Nessus kostenfrei (Nessus Essentials). Die Beschränkung bezieht sich dabei auf die Anzahl der IP-Adressen, die einem vollständigen Schwachstellen-Scan unterzogen werden. Das heißt Discovery-Scans (mit nur Plugins gemäß https://community.tenable.com/s/article/Which-Plugin-IDs-are-ignored-by-Tenable-sc-when-considering-the-total-IP-count-for-licensing-Formerly-SecurityCenter) können unbegrenzt viele Geräte umfassen.

Zunächst muss eine Lizenz für Nessus-Essentials unter

https://de.tenable.com/products/nessus/nessus-essentials

angefordert werden.

Nessus ist für die meisten Betriebssysteme als Installer, als Appliance oder auch als vorgefertigter Docker-Container verfügbar. In diesem Beispiel wurde sich für die Docker-Variante entschieden.

docker pull tenableofficial/nessus
docker run --name "nessus" -d -p 8834:8834  -e ACTIVATION_CODE=<activation code> -e USERNAME=<username> -e PASSWORD=<password> tenableofficial/nessus

Es dauert einen Moment bis alle Plugins heruntergeladen wurden. Gegebenenfalls kann mithilfe von docker attach in einem separaten Konsolenfenster der Installationsfortschritt eingesehen werden. Anschließend ist das Webinterface über https://127.0.0.1:8834 erreichbar.

Bedienung

Links auf der oberen Menüleiste findet man die zwei Schaltflächen Scans und Settings. Unter Settings findet man u.a. die Lizenz-Nutzung, Performance-Monitoring des Scanners, SMTP- und System-Einstellungen sowie Angaben zum Benutzerkonto.

Beim Erstellen eines neuen Scans (New Scan) werden einige Scan-Templates vorgeschlagen. Über Policies können weitere Scan-Templates dieser Auswahl hinzugefügt werden. Man kann die bereits existierenden Policies grob in generische Scans:

• Host Discovery: Es werden lediglich offene Ports und Hosts. Somit eignet sich dieser Scan gut, um schnell einen Überblick über die im Unternehmensnetzwerk aktiven Assets zu erhalten. Für diesen Scan gibt es keine Lizenz-Beschränkung.
• Basic Network Scan: vollständiger Schwachstellenscan mit vorgefertigten Scan-Einstellungen und wenig Konfigurationsmöglichkeiten
• Advanced Scan: Frei konfigurierbarer Schwachstellenscan.

und spezifische Scans z.B.:

• Malware Scan: Nur als Whitebox-Scan sinnvoll, da Dateisignaturen geprüft werden. Integration von Yara-Regeln (s. Project Valhalla)
• Web Application Tests: Reduziert den vollständigen Plugin*-Satz auf nur solche, die für Webserver/-anwendungen zutreffen.
• PrintNightmare: (stellvertretend für einen Scan für eine spezifische Schwachstelle und somit nur den zugehörigen Plugins). PrintNightmare ist eine der prominentesten Schwachstellen aus dem Jahr 2021.

unterteilen.

*Plugins: ein Plugin beschreibt ein bestimmtes NASL-Script (Nessus Attack Scripting Language), welches Tests (spezielle Pakete, PDUs, etc.) zu Discovery-Zwecken oder zur Prüfung auf die Existenz einer spezifischen Schwachstelle ausführt. Stand Dezember 2021 gibt es 165769 Nessus Plugins

Durchführung eines Schwachstellenscans mit Nessus an der HTWK

Da diese Webseite öffentlich zugänglich ist werden weder der Scope (IP-Adressen/-Bereiche) noch die Ergebnisse des Schwachstellenscans hier gezeigt.

Folgende Scans wurden ausgeführt:

1. Discovery-Scan mit Nessus

New Scan -> Host Discovery

2. Vollständiger Schwachstellen-Scan auf ausgewählten Geräten mit Nessus

New Scan -> Advanced Scan (mit allen Plugins auf allen Ports)

Schwachstellenmanagement-Systeme

Schwachstellenmanagement-Systeme (engl. VMS – Vulnerability Managment System) enkapsulieren Schwachstellen-Scanner, beziehen aktuelle Informationen von Security-Feeds und bieten eine verbesserte Verwaltungsoberfläche mit Dashboards, Nutzermanagement, Report-Vorlagen und einer API. Scan-Ergebnisse werden in einer Datenbank gespeichert. Mit ihnen wird das Schwachstellenmanagement im Unternehmen besser skalierbar. Abgesehen von einigen Ausnahmen wie der Greenbone Community Edition sind Schwachstellenmanagement-Systeme kostenpflichtig. Es besteht auch die Option sich ein eigenes VMS basierend aus Netzwerk-/Schwachstellenscannern, Datenbanksystem und unter Einbindung externer Datenquellen (NVD, Exploit-DB) aufzubauen. Nachstehend sind einige der bekanntesten Schwachstellenmanagement-Systeme aufgeführt:

1. Tenable

• On-Prem (Tenable.sc – Security Center) und Cloud Option (Tenable.io)
• Nutzt den unternehmenseigenen Schwachstellenscanner Nessus

2. Greenbone

• deutsches Unternehmen
• als Community-Version erhältlich (erst kürzlich umbenannt in GSM Trial)
• Schwachstellenscanner OpenVAS (weiterentwickeltes „Open-Source“-Nessus; 2005 wechselte Nessus zu einer proprietären Lizenz – OpenVAS basiert auf der letzten Opensource-Version von Nessus)

3. Qualys

• nur als Cloud-Option verfügbar

4. Rapid7

• InsightVM (Cloud) oder Nexpose (OnPrem)

Datenquellen

Intern

• Schwachstellenscanner
• Asset-Management (Configuration Management Database,  Softwareverteilung und Standardsoftware)
• Risiko-Management, interne Bewertung der Infrastruktur
  
• auch Kommunikation/Absprache mit Asset-Ownern

Extern

• Common Vulnerability Enumeration (CVE) der MITRE
  
• National Vulnerability Database (NVD)
• Exploit-DB, Searchsploit und Metasploit
  
• Warnmeldungen des BSI, Computer Emergency Response Team (CERT)
  
• Warnmeldungen der Hersteller (Security Advisories, Microsoft Bulletins, …)
  
• Metriken kommerzieller Schwachstellenmanagement-Systeme (z.B. Tenable – Vulnerability Priority Rating)

Prozessmodellierung

Begriffserklärungen

• Audit: Der Begriff Audit wird im Kontext des Schwachstellenmanagements synonym zum Schwachstellen-Scan verwendet.
• Contextualize: Im Ergebnis eines Schwachstellenscans wird nur der Schweregrad einer Schwachstelle losgelöst von dem Asset auf dem sie gefunden wurde beziffert. Es ist somit in diesem Schritt die Aufgabe der Security-Analysten die vorgefundenen Schwachstellen in den Unternehmenskontext zu bringen und somit eine korrigierte Kritikalität zu berechnen. Faktoren die dabei zu berücksichtigen sind, sind z.B.:
  – bereits existierende Sicherheitsmechanismen (vorgeschaltete Firewalls, VLANs, IPS)
  – Asset-Wert (potenzieller Schaden durch einen Angriff auf das System)
• Ranking: Bewertung/Priorisierung der vorliegenden Schwachstellen. Es ist üblich den bekannten CVSS-Wert (Common Vulnerability Scoring System) zusammen mit den Erkenntnissen aus dem Schritt Contextualize in das Ranking einfließen zu lassen
• Culling: Es ist in der Regel nicht möglich alle Schwachstellen (insbesondere wegen der enormen Menge neu entdeckter Schwachstellen – s. Statistik der NVD) in einem Zyklus des Schwachstellenmanagement-Prozesses abzuhandeln. Stattdessen ist es gängige Praxis nur die kritischsten (z.B. Top 10) Schwachstellen den jeweiligen Asset-Ownern mitzuteilen. Schließlich müssen diese die Schwachstellen-Bearbeitung während ihrer regulären Arbeit erbringen.
• Remediate: Beseitigung der Schwachstelle durch bspw. Patching, Behebung unsicherer Konfigurationen oder Abschaltung des Dienstes
• Mitigate: Möglicherweise existiert noch kein Patch für die entsprechende Schwachstelle; der Betrieb des vulnerablen Dienstes ist dennoch notwendig. In solchen Fällen können temporär zusätzliche Kontrollmechanismen eingebaut werden, die spezifisch prüfen, ob die Schwachstelle auf dem Gerät ausgenutzt wird (IDS oder SIEM Use-Cases).
• Remediation Scan: Hierbei handelt es sich um einen speziell angefertigten Schwachstellen-Scan der das betreffende Asset nur auf die vermeintlich behobene Schwachstelle untersucht.

Schnittstellen zu anderen Management-Prozessen

• Asset Management: Als Beiprodukt eines aktiven Schwachstellenscans über einem Netzbereich (oder durch einen dedizierten Discovery Scan) erhält man eine Übersicht der aktuell im entsprechenden Netzsegment aktiven Geräte mit zugehöriger IP, FQDN und MAC-Adresse (über SNMP). Ein Abgleich dieser Informationen mit der CMDB (Configuration Management Database) gibt Auskunft über Vorkommnisse von Schatten-IT (Rogue Assets)

• Risk Management: Im Schwachstellenmanagement-Prozess muss stets abgewogen werden, welche Schwachstellen (auf Assets unterschiedlichen Wertes) am kritischsten sind. Die zuvor im Risiko-Management ermittelten Asset-Werte fließen in die Priorisierung von Schwachstellen ein.

• Incident Management: Schwachstellen-Funde können über ein bereits im Unternehmen etabliertes Ticketing-System abgehandelt werden.

• Service Level Management: Parameter des Schwachstellenmanagements (wie z.B. Anzahl behobener Schwachstellen pro Zeiteinheit, Anzahl kritischer Schwachstellen; s. Executive Report) lassen sich in SLAs (Service Level Agreements) verankern. Somit kann ein Unternehmen die Bemühungen zur Aufrechterhaltung der IT-Sicherheit stringent ausdrücken.

Quellen

• Foreman Park: Vulnerability Management. 2. Auflage. 2019. CRC Press
• Magnusson Andrew: Practical Vulnerability Management. 2020. No Starch Press
• https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs_2021/04_OPS_Betrieb/OPS_1_1_3_Patch_und_Aenderungsmanagement_Edition_2021.pdf;jsessionid=8691C86321214AFEF9B2CE2349F26830.internet461?__blob=publicationFile&v=2
• http://www.bpmb.de/index.php/BPMNPoster
• https://de.tenable.com/products/tenable-sc
• https://docs.tenable.com/nessus/Content/DeployNessusDocker.htm
• https://oval.mitre.org/language/about/definition.html