Vulnerability Management
Effizientes Netzwerk Scannen für maximale Transparenz und aktuelle Übersicht 

 

(Version: 1.03, Oktober 2017)

 

Teil 1 - Einleitung

 

Schwachstellen Analysen und deren Management sind mittlerweile unabdingbare Disziplinen im Rahmen der Unternehmens IT. Ganz entscheidend ist dabei, zu verstehen, dass Angreifer nicht nur von außen kommen, Schäden nicht nur durch Kompromittierung der im Internet sichtbaren Systeme entstehen, sondern vielfältige Schwachstellen auch in internen Systemen zu finden sind. Nahezu kein im Unternehmen eingesetzter Gerätetyp ist frei von Schwachstellen, die sofort an Bedeutung gewinnen, sobald das jeweilige Gerät mit dem Firmennetzwerk verbunden ist.

 

Aufgrund täglich neu hinzu kommender Bedrohungsszenarien mit dem Potenzial, das Firmenkapital massiv zu schädigen, sollte die Schwachstellenanalyse möglichst häufig und möglichst intensiv durchgeführt werden. Dies mag in kleineren Netzwerken noch kein großes Problem darstellen, wird aber schnell zur Herausforderung, je größer und verteilter das Netzwerk wird. Zusätzlich wächst die Häufigkeit von Veränderungen in der eingesetzten Hardware ebenfalls mit der Größe des Netzwerks.

 

Viele IT Sicherheitsverantwortliche setzen daher auf mehr oder weniger systematisches und periodisches Scannen ihrer Netzwerke. Dabei kommen verschiedene Scan Tools zum Einsatz, kommerzielle oder auch Open Source, wie z. B. Tenable Nessus ® oder Security Center ® (beide von Tenable, Inc., Columbia, MD, USA) oder openVAS.

 

Jedes bekannte Scan Produkt hat mehr oder weniger viele False-Positives, Probleme mit dem OS Fingerprinting und andere Schwächen. Darauf soll hier aber nicht weiter eingegangen werden. Auch wenn dies eine zusätzliche Notwendigkeit für den Einsatz möglichst intelligenter Auswertungs- und Reporting-Tools indiziert.

 

Intensive Schwachstellen Scanner wie z. B. Nessus (oder andere) haben insbesondere mit diesen 4 Problemen zu kämpfen

• lange Laufzeiten, abhängig vom Umfang der Scans und der angewendeten Scan Policy
• teils sehr große Reports (mehrere Gigabyte), abhängig von der Größe des zu scannenden Netzwerks und der Scan Policy
• keinerlei Kenntnis der Konfigurationsdaten des Unternehmens, mithin kein Wissen über die jeweils zu scannenden Geräte
• teils massive Störungen des Betriebs durch zu aggressive Scan Policies

 

Alle diese Probleme zusammen führen dazu, dass 

• Scans nicht so häufig und/oder nicht in dem eigentlich erforderlichen Umfang ausgeführt werden
• die Verknüpfung zu Geräten bzw. Geräteklassen schwer bis unmöglich ist
• Scans mit hohem manuellen Aufwand geplant und vorbereitet werden müssen
• die Auswertung ggf. zu lange dauert

 

Dadurch ist ein aktueller Überblick über die Schwachstellen Situation der operativen IT nicht gewährleistet und bestenfalls immer nur punktuell. Dies ist einer Zeit vielfältiger, fast täglich neuer Bedrohungen eine ernste Situation für die gesamte IT und ihre Verantwortungsträger.

 

In diesem Umfeld eine stets tagesaktuelle Übersicht über alle Schwachstellen zu haben oder den Erfolg der Behebungsmaßnahmen täglich messen zu können, wäre daher ein großer Vorteil.

 

Der folgende Artikel beschreibt in den folgenden 4 Teilen 

• Definitionen und Festlegungen
• benötigte Konfigurationsdaten (CMDB)
• einzusetzende Tools und Verfahren 

welche es ermöglichen, auch Netzwerke mit dauerhaft mehr als 500.000 aktiven Geräten täglich zu scannen und so jederzeit über den potenziellen Verwundbarkeitsstatus informiert zu sein.

 

Teil 2 - Beschreibung des gestaffelten Scan Prozesses

 

Szenario

Der hier vorgestellte Lösungsansatz ist in der Lage, die zuvor beschriebene Situation deutlich abzumildern und darüber hinaus in der Praxis erprobt. Er besteht aus diesen Kernelementen

• Einbindung von Informationen aus dem Konfigurations Management (kurz: aus der CMDB)
• Periodische Ausführung schneller Basis Scans (Inventory und Compliance Scans)
• Periodische Ausführung von Tiefen Scans (bezogen auf Asset Types oder getrieben durch Bedrohungspotenziale)

Die Basis Scans werden mithilfe des Tools nmap (Standard in der Unix/Linux Welt) umgesetzt und für die intensiven Tief Scans im Rahmen dieses Szenarios, wird der in der Praxis häufig anzutreffende Nessus ® Scanner bzw. das Security Centre ® angenommen. 

 

Es könnte aber auch genauso gut openVAS oder ein anderer kommerzieller / open Source Vulnerability Scanner verwendet werden.

 

Um den Scan Vorgang einerseits zu beschleunigen und andererseits dennoch ausreichend Sicherheit zu haben, ist es zweckmäßig, auf ein gestaffeltes Vorgehen zu setzen, welches wie folgt aussieht:

• tägliche Durchführung von unternehmensweiten Basis Scans z. B. mit nmap
• Prüfung von Mindestanforderungen an die Compliance von Geräten
• Einbeziehung vielfältiger CMDB Daten für die Verknüpfung von
• gescannter IP Adresse zu physischem Gerät
• ITAO Zuständigkeit
• Lokationsinformationen
• Staging Informationen (DEV / UAT / PRD / DR)
• u.v.a.

• periodische oder situations-getriebene und typ-spezifische Tiefen Scans mit dem Vulnerability Scanner der Wahl

 

Für diese Verfahren sind ein paar wenige Festlegungen zu treffen, sofern nicht bereits geschehen.

 

Festlegungen für die Basis Scans

• Einteilung der im Netzwerk betriebenen Geräte in Typen und Kategorien bzw. Ableitung dieser Daten aus der CMDB
• Definition von „Compliance“ je Gerätetyp
• Definition der wichtigsten/riskantesten TCP- und UDP-Ports die offen/geschlossen sein müssen bzw. dürfen
• Achtung: auch die Öffnung eines Ports kann ein wichtiges Merkmal sein, z. B. Systems Management Agent
• Regeln für Host Namen (DNS-Namen, Aliase, NetBios Namen)
• Definition der zu scannenden/auszulassenden Subnetze inkl. der Scan Perioden und nach Möglichkeit mit Klassifizierung (z. B. End User Subnetz, Data Centre Subnetz, Security-Zone xyz usw.)

 

Festlegungen für die Tiefen Scans

• Definition welche Gerätetypen wann/in welchem Rhythmus gescannt werden sollen
• Definition der gerätetyp-spezifischen Scan Policy

 

Bevor jedoch mit der Umsetzung begonnen wird, widmen wir uns im folgenden Abschnitt zuerst Daten aus dem Konfigurations-Management (CMDB), da diese wie zuvor beschrieben einen nicht unerheblichen Beitrag zum Erfolg dieser Lösung leisten. 

 

Teil 3 - Daten des Konfigurations-Managements und weiterer Quellen

 

Wie in den beiden vorherigen Abschnitten bereits erwähnt, werden bestimmte Daten aus dem Konfigurations-Management bzw. der CMDB für dieses Verfahren benötigt. Darüber hinaus gibt es Konfigurationsdaten, über die zu verfügen sehr hilfreich ist.

 

Erforderliche Daten

Folgende Daten aus dem Konfigurations-Management müssen maschinell verfügbar sein, am besten permanent oder 1 mal täglich:

• Beschreibung der operativen Subnetze
• Netzwerkadresse und -maske
• Art der Adressvergabe: Static, DHCP, Mixed
• bei Mixed: Regeln der Bereichsdefinition(en)
• Klassifizierungsmerkmale 
• Zonen (End User, Network Administration, Data Centre, VOIP, …)
• Staging (DEV/UAT/PRD…) 

• IT Assets
• Gerätetyp und Kategorie (falls vorhanden)
• IP und Adresstyp (Static, DHCP)
• MAC Adresse
• FQDN, DNS_NAME, DNS_ALIAS oder NetBIOS Name

 

Wünschenswerte Daten

Zusätzlich zu den erforderlichen Daten aus der CMDB wäre folgende Informationen wünschenswert und hilfreich 

• Netzwerk
• Lokationsinformationen, möglichst umfangreich
• Region, Land, Stadt, Straße, Gebäude, Etage, Raum-Nr.
• Typ: VPN, VLAN etc.

• IT Assets
• Betriebssystem und Version bzw. Firmware und Version
• Model (Typ)
• zuständiger ITAO* inkl. Email Adresse
• Regeln für die Bildung der Hostnamen
• Supportgruppen
  
  
• Application Data
  • Relation Applikation <-> Server
  • Relation Applikation <-> verwendete Ports
  • Relation Applikation <-> ITAO

• DHCP Server Log-Dateien, möglichst zeitnah
• IP Adresse, Hostname

 

 

*ITAO IT Asset Owner

 

Teil 4 - Beschreibung der Basis Scans

 

Die täglichen Basis Scans können sehr gut mit dem Quasi-Standard Werkzeug nmap ausgeführt werden. Dieses ist auf nahezu allen Plattformen verfügbar.

 

Um Bandbreitenbelastung und Laufzeit der Scans so gering wie möglich zu halten, ist es sinnvoll, wenn nicht sogar erforderlich, die Anzahl auszuführender Scans auf das erforderliche Minimum zu beschränken. Je größer die Anzahl zu scannender Geräte / Subnetze ist, um so wichtiger wird diese Anforderung.

 

Schnelles Ermitteln des Scan Umfangs durch PING Scan

Um den genauen Scan Umfang fest zu legen, werden in einer Vorstufe die tatsächlich aktiven IP Adressen in den zu scannenden Netzen ermittelt. Dies kann durch einen PING Scan erfolgen oder durch Abfrage geeigneter Daten aus allen beteiligten ARP-Caches. Letzteres ist schwieriger umzusetzen, erhöht aber die Genauigkeit der Identifizierung der Geräte in den nachfolgenden Schritten, da so nicht nur IP, sondern auch MAC Adressen bekannt werden.

 

In besonders großen Netzen kann es darüber hinaus sinnvoll oder gar erforderlich sein, die PING Scans zu segmentieren. Hierbei werden je Subnetz oder - je nach Größe des Subnetzes - je nach Anzahl möglicher IP Adressen im jeweiligen Subnetz, einzelne Scan Jobs erstellt und ausgeführt. Dabei kann die Anzahl parallel laufender PING Scans ebenfalls festgelegt und so der Bandbreiten Verbrauch an alle Bedürfnisse angepasst werden.

 

Ausführen des Basis Scans

Sobald für ein Subnetz bzw. eine Untermenge von IP Adressen die tatsächlich aktiven Adressen ermittelt wurden, wird unmittelbar darauf der eigentliche Basis Scan - ebenfalls mit nmap - mit der Liste der aktiven IP Adressen und für alle zuvor festgelegten Ports gestartet. Hierbei wird nicht nach Gerätetypen unterschieden.

 

Sind IP Adressen aus dem zuvor ermittelten Umfang während des Scans nicht mehr erreichbar, führt dies nur zu geringem Overhead. Kommen während des Scan Vorgangs weitere IP Adressen hinzu, werden diese zwar nicht mehr berücksichtig. Allerdings tritt diese Situation auch bei jeder anderen Vorgehensweise auf, sobald ein Scanner eine höhere Adresse bearbeitet, als die neu hinzu gekommene.

 

Durch geeignetes Scripting in dieser Vorphase können die nicht mehr erreichten IP Adressen in eine Re-Scan Queue gestellt werden, die immer wieder von Zeit zu Zeit abgearbeitet wird, bis sie keine Einträge mehr enthält. Allerdings ist ein solches Vorgehen in Adressbereichen mit DHCP Adressen wenig sinnvoll, da sich hinter der verpassten Adresse längst ein ganz anderes Gerät verbergen kann.

 

Die hier aufgezeigten systemischen Schwächen lassen sich nur abfangen, wenn DCHP Log-Dateien sehr zeitnah zur Verfügung stehen, ausgewertet und die Ergebnisse von einem permanent laufenden Scanner sofort verarbeitet werden.

 

Der Basis Scan erzeugt einen Scan Report, der je nach Präferenz im csv oder xml erstellt und maschinell weiter verarbeitet wird. Diese Verarbeitung sollte unmittelbar auf die Report Erstellung erfolgen und beinhaltet diese Schritte:

• die Identifikation gescannter Gerät anhand verknüpfter CMDB Daten
• Matching auf Basis von MAC Adressen, FQDN bzw. Hostnamen, ggf. IP Adressen wenn statisch vergeben
• Ermittlung des Gerätetyps

• Anwendung einer Regel Engine zur Feststellung der Compliance
• anhand des Gerätetyps kann die Policy (Festlegung der Ports und ihrer Sollzustände) ermittelt werden
• formale Prüfung auf den Hostnamen, sofern Namenskonventionen bestehen

 

Werden diese Ergebnisse in eine geeignete Datenbank geschrieben, sind so 3 verschiedene Informationen verfügbar:

• Liste der Geräte, bei denen keine Identifikation möglich war
• fehlender CMDB Eintrag
• fehlende Identifikationsmerkmale (MAC Adresse, Hostname) 
• unzureichender Identifikationsalgorithmus 
• Liste der Geräte, die als „compliant“ eingestuft wurden
• Liste der Geräte, die als „non-compliant“ eingestuft wurden

 

Auf diese Weise ist nicht nur ein schneller Überblick über die grundlegende Schwachstellen Situation ermöglicht, sondern darüber hinaus werden die CMDB Daten auch einer permanenten aktiven Überprüfung ausgesetzt. Dadurch wird die Qualität der CMDB dauerhaft erhöht bzw. auf hohem Niveau etabliert. Dafür sind lediglich die erforderlichen Sanierungsprozesse zu definieren und abzuarbeiten.

 

Darüber hinaus entsteht eine revisionsfähige Historie über alle Scan Aktivitäten und Ergebnisse. Auch die Erstellung und Verfolgung von Sanierungsaufträgen kann durch diese Grundlagen automatisiert werden.

 

Teil 5 - Beschreibung der Tiefen Scans

 

Aus den Daten, die im vorherigen Schritt gewonnen wurden, lassen sich nun ebenso leicht die Scan Parameter für die Tiefen Scans ableiten:

• Liste von IP Adressen als Scan Parameter für
• Gerätetypen (Asset Types)
• Regionen, Länder, Unternehmenseinheiten (sofern diese Informationen in den verknüpften CMDB Daten vorhanden sind)
• Gerätestatus (compliant, non-compliant)

 

je nach Wunsch bzw. Erfordernis. 

 

Insbesondere durch die vorherige Identifikation eines Gerätes und Zuordnung zu einem Typ (Desktop, Laptop, Server Windows, Server Linux, Switch, Router, VOIP um nur einige zu nennen) werden die Verwendung von typ-spezifischen Scan Policies und Bedrohungsprofilen angepasste, gezielte Tiefen Scans erheblich erleichtert. 

 

Diese können in etwas größeren Zeitabständen ausgeführt werden. Es ist ohnehin davon auszugehen, dass intensivere Tiefen Scans Schwachstellen hervor bringen, deren Beseitigung im Einzelfall aufwändiger ist, als nur einfach FTP oder TELNET auf einem Gerät abzuschalten. Daher muss für die Beseitigung eine entsprechende Dauer berücksichtigt werden, während derer sich an der festgestellten Sicherheitslage aber nichts ändert. Gleichsam ist das gezielte Nach-Scannen bezogen auf Schwachstellen, Gerätetypen oder andere Ordnungskriterien ja jederzeit möglich.

 

Der in diesem Szenario angenommene Einsatz von Nessus ® erlaubt ebenfalls den Export der Scan Reports u. a. im csv Format. Dieses kann ebenfalls maschinell weiter verarbeitet und über die im vorigen Abschnitt bereits erwähnte Datenbank ausgewertet und archiviert werden.

 

Bei der Verarbeitung von Nessus ® Reports ist ein wenig Aufmerksamkeit erforderlich: Nessus ® erzeugt einerseits teils sehr große Dateien, zum anderen ist das Format etwas unhandlich: Feldinhalte mit mehreren Megabyte Größe und Zeilenvorschub Zeichen im Inhalt fordern den Entwickler eines Verarbeitungsprozesses ein wenig heraus.

Teil 6 - Zusammenfassung

 

Permanente Netzwerk Scans sind heutzutage ein Muss für jeden verantwortungsbewussten IT Sicherheitsverantwortlichen. 

 

Dabei ist es wichtig, einerseits einen täglich aktuellen Überblick zu erhalten, was insbesondere in größeren Netzwerken nur mit schnellen, reduzierten Scans möglich ist. Andererseits sind aber auch intensive Tiefen Scans erforderlich, um einen umfassenden Überblick über möglichst alle Schwachstellen zu erhalten.

 

Diese beiden Ziele stehen in einem Konflikt miteinander, da intensive Scans teils sehr lange Laufzeiten bedeuten und ebenfalls einen großen Teil der Netzwerk Bandbreite konsumieren. Darüber hinaus stellen intensive Scans immer auch ein Risiko für den ordnungsgemäßen Betrieb der gescannten Geräte dar.

 

Das in den vorigen Abschnitten beschriebene Verfahren erlaubt es nun, beide Ziele mit vertretbarem Aufwand und Risiko (durch Verzicht) zu erreichen, gleichzeitig noch den Informationsgehalt der Analysen zu erhöhen und die Qualität vorhandener CMDB Daten zu verbessern.

 

Dies wird durch den gestaffelten Einsatz von

• schnellen Basis Scans in allen Subnetzen und für alle Geräte unter Einbeziehung der CMDB für ausgewählte, Hochrisiko-Ports,
• ausgewählten Tiefen Scans (typ-, subnetz- oder szenrio-bezogen) mit angepassten Policies

 

erreicht.

 

Damit sind die Grundlagen für einen stets aktuellen Überblick bei sinnvoller Resourcennutzung ohne Verlusten an Flexibilität gelegt. 

Im nächsten Teil wenden wir uns dann den verschiedenen Auswertungsmöglichkeiten der aus diesem Verfahren anfallenden Reports zu. Dafür werden eine eigene, DWH-ähnliche Datenbank, kommerzielle Analyse- und Reporting Werkzeuge, sowie eine Mischform aus beidem vorgestellt und beschrieben.

 

Sämtliche in dieser Reihe vorgestellten Lösungen sind bei einem sehr großen und global agierenden Unternehmen entwickelt worden und in Anwendung befindlich, die zur Umsetzung notwendigen Scripte (Unix Shell) und Programme (perl), DDL und SQL-Abfragen (für MySQL und Oracle) sind verfügbar und können bei mir angefragt werden.