Verwundbarkeiten im Unternehmen finden und verwalten
Softwareliste
Mit der MITRE-CVE-Liste und der daraus gespeisten National-Vulnerability-Datenbank existieren fundierte Informationsquellen zur Schwachstellenanalyse. Für einen automatisierten Abgleich mit der im Unternehmen eingesetzten Software sind jedoch einige Klippen zu umschiffen.
Als der Administrator und IT-Sicherheitsbeauftragte Armin A. eines Montagmorgens ins Büro kommt, schrillen bereits die Alarmglocken. Sein Chef hat in den Onlinenachrichten gelesen, dass der im Unternehmen eingesetzte Browser eine kritische Verwundbarkeit aufweist, die schon beim Aufruf einer bösartigen Internetseite die Ausführung von Schadcode ermöglicht. Er möchte nun umgehend wissen, ob das Unternehmen betroffen ist, und, wenn ja, um welche Rechner und Nutzer es sich handelt. Keine einfache Aufgabe, da die Verwundbarkeit mehrere Plattformen umfasst und die Browser dort teils unterschiedliche Versionsnummern tragen.
In solchen Situationen ist es Gold wert, wenn es eine gut gepflegte Inventardatenbank (auch Configuration Management Database genannt) gibt, die neben Systemen, Benutzern et cetera aktuelle Informationen über die auf jedem System installierte Software enthält. Dieser Artikel stellt nachfolgend Open-Source-Ansätze zunächst für eine solche Inventardatenbank und dann für die automatisierte tägliche Suche nach neuen Verwundbarkeiten in der damit aufgebauten Softwareliste vor. Damit dieses automatische Überprüfen funktioniert, muss man jedem Softwareprodukt zuerst manuell eine sogenannte CPE-ID zuweisen (mehr dazu weiter unten). Darauf basierend kann dann ein automatischer täglicher Abgleich mit einer CVE-Datenbank erfolgen.
Basiskomponente Inventardatenbank
Wie der Artikel „Mit Übersicht“ zeigt [1], existieren im Open-Source-Bereich für diese Aufgabe zwei weitverbreitete Produkte. Eines davon ist das sehr umfassende und schon lange existierende GLPI („Gestion Libre de Parc Informatique“, ix.de/ix1805076). Die GPLv2-lizenzierte, vollständige CMDB- und Helpdesk-Software bietet unter anderem Issue Tracking, Lizenzverwaltung, Berichterzeugung sowie automatische Benachrichtigungen. GLPI läuft auf einem handelsüblichen LAMP-Unterbau und ist sogar in den Software-Repositories einiger Linux-Distributionen enthalten – teilweise allerdings in veralteten Versionen, sodass sich für den Produktivbetrieb eventuell eine manuelle Installation anbietet. Der Kasten „Freie Inventarisierungssoftware“ stellt die wesentlichen Fakten kurz vor.
Der Versuch, ein Softwareinventar manuell zu füllen und aktuell zu halten, gleicht einem Kampf gegen Windmühlen. Zum Füttern einer plattformübergreifenden Inventardatenbank bieten sich deshalb Softwareagenten an, die sich auf Rechnern mit unterschiedlichen Betriebssystemen installieren lassen und regelmäßig und automatisch Inventarisierungsdaten an einen zentralen Server senden. GLPI kann man zu diesem Zweck durch das ebenfalls freie FusionInventory erweitern. Letzteres besteht aus einem Server und Agenten für verschiedene Plattformen. Der Server ist als Plug-in für GLPI realisiert, während die Agenten aus einem Fork von OCS Inventory NG hervorgegangen sind. Im Gegensatz zu OCS kann der FusionInventory-Agent allerdings nicht nur aktiv Inventarisierungsdaten an den Server senden (Push-Prinzip), sondern auch selbst als Server fungieren. Somit lässt er sich jederzeit beziehungsweise bei Bedarf vom Inventarisierungsserver abfragen – solange die Netzarchitektur es erlaubt. Diese Funktion lässt sich aus Sicherheitsgründen deaktivieren.
Methoden zum Inventarisieren
Informationen über Verwundbarkeiten in der inventarisierten Software hat man damit allerdings noch nicht gewonnen. Hierfür gibt es grundsätzlich zwei Philosophien: die Patch- und die verwundbarkeitsorientierte. Bei ersterer interessiert man sich nur für Verwundbarkeiten, für die schon Patches existieren. Da sich der überwiegende Teil aller Softwareprodukte heute regelmäßig und automatisch aktualisiert, muss man im Normalfall lediglich belegen, welche Systeme für längere Zeit keine Patches erhielten und warum – beispielsweise weil benötigte Komponenten nicht mit neuen Versionen kompatibel sind oder das System nur eingeschränkte Wartungsfenster erlaubt.