© tiero, 123RF.com

2003 als Security Infrastructure Monitor gestartet und jüngst in Version 4.0 freigegeben, ist OSSIM unter Open-Source-Werkzeugen fürs Security Information and Event Management (SIEM) eine beliebte Wahl. Vergleichsweise günstig, leisten sich aber sowohl die freie als auch die kommerzielle Version Schwächen.

Keineswegs im eigenen Tresor, wie sein Name mit “Vault” vermuten lässt, hinterlegte der Security-Spezialist Alien Vault [1] die 35 Millionen Risikokapital ([2], [3], [4]), die ihm zwischen 2010 und 2012 zuflossen. Vielmehr nutzte er das Geld nach eigener Aussage, um das freie Intrusion Detection System OSSIM [5] aggressiv voranzutreiben und parallel dazu unter dem Namen Alien Vault eine kommerzielle Variante der Software zu schaffen. Erfolge hat man dabei durchaus vorzuweisen: Einen großen Teil der Mittel erhielt die Firma, nachdem die Software Schadcode identifizieren konnte, der das US-amerikanische Verteidigungsministerium befallen hatte [6].

Vor wenigen Wochen erschien mit OSSIM 4.0 die neueste Version der auf Debian Squeeze basierenden Software. Dieser Artikel analysiert zunächst die Open-Source-Variante von Alien Vaults Software und vergleicht diese anschließend mit der kommerziellen Version.

Open Source: OSSIM

Die Installationsroutine beruht auf dem Debian-Installer und wie üblich sollte der Admin nach der Installation zunächst die nötigen Updates einspielen. Dies gelingt ihm sowohl auf der Kommandozeile mit »alienvault-update« als auch im übersichtlichen Web-Dashboard (Abbildung 1). Überhaupt findet der Admin alle Funktionen im GUI: Von der Netzwerkkonfiguration über die Benutzerverwaltung bis hin zu Backup und Restore, sogar die Kontrolle der Verfügbarkeit und Funktionsfähigkeit von OSSIM selbst kann er hier überwachen (Abbildung 2).

Abbildung 1: Die OSSIM-Weboberfläche meldet mögliche Updates.

Abbildung 2: OSSIM überwacht sich selbst, hier die System- und Netzwerkressourcen.

Das GUI integriert ebenfalls eine komfortable Suche in den Logfiles, sodass der Zugriff per SSH nur in Notfällen erforderlich ist. Sämtliche Komponenten darf der Administrator einzeln konfigurieren oder durch eigene Komponenten ersetzen, zum Beispiel den automatisch eingebauten Scanner Open VAS durch ein eigenes Nessus.

Speziell bei der Benutzerverwaltung haben die Programmierer von Alien Vault große Unternehmen und Netze berücksichtigt: Neben den üblichen Informationen wie Name, Login und Kennwort legt der Admin genau fest, welche Menüs der Benutzer anschließend sehen, verwenden oder welche Assets er analysieren darf. Als Asset bezeichnet OSSIM Hosts und Netzwerke, die der Admin vorher dem SIEM bekannt machen muss.

Aktive und passive Scans

Für die Assets benutzt OSSIM eine eigene Datenbank, wo sie der Admin entweder manuell einträgt oder einfach über einen Scan aufnehmen lässt, inklusive Betriebssystem und laufender Dienste (Abbildung 3). Solche Asset Discoveries lassen sich auch automatisch durchführen (Abbildung 4), jedoch ist ein Scan nicht in jedem Netzwerk möglich und Vorsicht geboten: Auch ein Nmap-Scan kann schlecht programmierte TCP/IP-Stacks, zum Beispiel in Embedded-Systemen wie Klimaanlagen, zum Absturz bringen. Bei aktiven Scans nutzt OSSIM auch die WMI-Schnittstelle [7], um Windows-Systeme auszulesen. Außerdem ist OCS NG (Open Computers and Software Inventory Next Generation, [8]) in OSSIM integriert und lässt sich wie sein Vorgänger OCS für regelmäßige Prüfungen nutzen.

Abbildung 3: Die Scans für die Asset Discovery lassen sich automatisieren.

Abbildung 4: OSSIM entdeckt Hosts und Dienste.

Mit PRADS [9] ist ein “Passive Realtime Asset Detection System” an Bord, das selbstständig den Netzwerkverkehr überwacht und so Hosts, Betriebssysteme und Dienste erkennt (Abbildung 5). PRADS aktualisiert die Daten in der Asset-Datenbank dynamisch, selbst wenn der Admin keine regelmäßigen Scans eingerichtet hat. Das garantiert OSSIM stets aktuelle Daten für die Analyse.

Abbildung 5: Über das passive PRADS hat OSSIM einen Host gefunden, auf dem Samba, HTTP und SSH-Server laufen.

Dienste mit Open VAS und Nagios überwachen

Die erkannten Systeme scannt der Admin gleich mit Open VAS nach undichten Stellen (Abbildung 6). Alle Open-VAS- oder Nessus-Funktionen stehen parat, Nessus 5 unterstützt OSSIM-Software zurzeit nicht. Doch die Integration des Verwundbarkeitsscanners haben die Entwickler gut gelöst: Sobald er eine Schwachstelle erkennt, generiert OSSIM automatisch ein Ticket. Das kann der Admin an einzelne Benutzer delegieren, mit Anhängen versehen und darin die Reaktionen dokumentieren. Geschlossene Tickets zeigt OSSIM per Default nicht an, sie lassen sich aber jederzeit über Einstellungen des Suchfilters wieder aufrufen.

Abbildung 6: 23 potenzielle Sicherheitslücken hat OSSIMs Open VAS gefunden, zwei davon stuft der Scanner als kritisch ein. Schade, dass OSSIM nicht alle verfügbaren Daten zur Analyse nutzt.

Die erkannten Dienste und Hosts kann der Admin durch ein ebenfalls in OSSIM integriertes Nagios überwachen, schlicht über ein entsprechendes Häkchen in der Konfiguration der Asset-Datenbank. Einfacher lässt sich das komplexe Monitoring mit Nagios schwerlich lösen, leider ist eine über die einfache Host-Port-Verfügbarkeitsüberwachung hinausgehende Konfiguration nicht vorgesehen.

Nicht zu Ende gedacht

Die Asset-Datenbank der OSSIM-Software hat aber auch einige Lücken. Trotz hohen Detailgrads landen offenbar weder die Ergebnisse des Nmap- noch des Open-VAS-Scans in der Datenbank, sondern nur PRADS-Daten. Dabei können sowohl Nmap als auch Open VAS sehr interessante Informationen liefern, die die passive Erkennung weit übertreffen, speziell für die Analyse der späteren Security Incidents müsste sich das für den Admin als sehr hilfreich erweisen.

Auch Snort ließe sich besser konfigurieren, ist es doch eine der Kernfunktionen von OSSIM. Sinnvoll wäre es beispielsweise, die Asset-Datenbank direkt für die Konfiguration von Snort einzusetzen. Das Schnüffelschwein bietet ja bereits die Host Attribute Table (siehe Kasten “Host Attribute Table”), die das von jedem Host verwendete Betriebssystem und die angebotenen Dienste enthält. Leider nutzt OSSIM diese Funktion überhaupt nicht.

Die wichtigste Funktionalität der OSSIM-Software bleibt jedoch das Auswerten und Analysieren der Security Incidents, wobei sie für den Admin ähnliche Ereignisse zu einer einzigen, übersichtlichen Meldung aggregiert. Auch die grafische Darstellung des Risikofaktors erleichtert die Auswahl der zu bearbeitenden Meldungen, die sich direkt in ein Ticket umwandeln und einem Benutzer für die Bearbeitung zuweisen lassen.

Als Quelle für die Meldungen dienen die genutzten IDS-Sensoren und Verwundbarkeitsscanner, bei OSSIM also OSSEC und Snort. Letzteres verwendet erfreulicherweise für die Sammlung der Pakete die vom Ntop-Projekt betreute Pfring-Bibliothek [10], die für sehr hohen Durchsatz optimiert ist.

Unvollständig und unsicher?

Überraschenderweise startet OSSIM Snort mit Rootrechten, was unter Linux – vorsichtig ausgedrückt – seit Jahren nicht mehr zeitgemäß ist. Wie alle anderen Netzwerkdienste bietet auch Snort die Möglichkeit, nach dem Start die Rootprivilegien abzugeben. Durch einen Programmierfehler in Snort könnte ein Angreifer OSSIM übernehmen.

Auch benutzt die Software für die Analyse der Security Incidents wieder die Asset-Datenbank und vernachlässigt die gefunden Verwundbarkeiten sträflich. Wünschenswert wäre es vielmehr, wenn die Oberfläche bei einer Meldung dem Admin direkt mitteilen würde, ob der betroffene Host überhaupt über den angegriffenen Dienst verfügt und ob der angegriffene Host verwundbar ist.

Hierzu könnte OSSIM das in der Asset-Datenbank gespeicherte Betriebssystem auswerten und die hier hinterlegten Ports mit den Ports des Angriffs vergleichen. Das aber erfordert entsprechende Informationen, die leider bisher nicht in der Open Source Vulnerability Database (OSVDB, [11]) enthalten sind. OSSIM verwendet als einziges System diese Datenbank, während die Wettbewerber ihren Kunden eigene DBs zur Verfügung stellen. Erst die kommerzielle Variante von Alien Vault bringt diese Funktionen mit, und zwar unter dem Namen Event Context (Abbildung 7).

Abbildung 7: Nur die kostenpflichtige Version kann über den Event Context erkennen, ob ein Angriffsversuch erfolgversprechend wäre – der freien Version fehlt dieses Feature.

Freie Version – absichtlich verkrüppelt?

Da der freien OSSIM-Variante auch die entsprechenden Korrelationsregeln fehlen, entstehen aus den vom IDS gemeldeten Ereignissen nur in den seltensten Fällen tatsächliche Incidents. Die Präzision der Erkennung hängt von den wenigen im freien Alien-Vault-Feed mitgelieferten Korrelations-Direktiven ab, auch hier hat die kommerzielle Variante mehr zu bieten (Abbildungen 8 und 9).

Abbildung 8: Das freie OSSIM kann nur wenige Ereignisse korrelieren und als Incident aufbereiten.

Abbildung 9: Alien Vault liefert in seinem Feed über 1400 Regeln für das automatische Erzeugen von Incidents.

Vor allem bei den Korrelationsdirektiven drängt sich der Eindruck auf, dass der Hersteller versucht die freie Version in ihren Funktionen zu beschneiden – allzu mager sind sie im Vergleich mit der kommerziellen Version geraten. Natürlich könnte jeder Anwender seine eigenen Direktiven erzeugen, jedoch ist dies ein sehr aufwändiges Unterfangen, das enormes Wissen verlangt. Ein öffentliches Repository, in dem freie Direktiven gespeichert und getauscht werden, wäre wünschenswert.

Enterprise Alien Vault

Besser macht das die kommerzielle Variante, zu der ein Upgrade über einen Evaluation-Key in drei simplen Schritten führt: Dafür ruft der Admin an der Kommandozeile »alienvault-setup« auf und wählt dort im Menü die Option »System-Upgrade« und anschließend »Alien Vault 4« . Nach Eingabe des Schlüssels verbindet sich das System mit dem geschlossenen Repository bei Alien Vault und bezieht hier zusätzliche Pakete und Signaturen. Alien Vault selbst bietet neben der reinen, Software-basierten Version auch Hardware-Appliances an. Die “All-In-One Appliances” vereinen sowohl den Sensor, den Protokollanalysator und das SIEM und schlagen mit knapp 20 000 Euro zu Buche. Dafür gibt’s den Alien-Vault-Feed für die Direktiven und Regeln im ersten Jahr als Subskription, jedes weitere Jahr kostet gut 3000 Euro.

Für so viel Geld gibt es aber auch einigen Gegenwert: Die Alien-Vault-Installationen (Appliance und Softwareversion) verfügen auch über wesentlich umfangreichere Signaturen für Snort. Als Partner von Emerging Threats [12] hält der Hersteller für seine kommerziellen Kunden den ET-Pro-Regelsatz [13] bereit. Für die Sourcefire-VRT-Regeln reicht es dagegen noch nicht, weil Alien Vault noch kein Snort-Integrator ist.

Enttäuschend ist, dass die kommerzielle Variante die oben aufgeführten Kritikpunkte auch nicht besser bewältigt als die freie. Snort ist auch hier ein Rootprozess. Dass das gefährlich ist, haben Sicherheitslücken in der Vergangenheit bereits gezeigt [14]. Auch die Host-spezifische Konfiguration von Snort mit Hilfe der Host-Attribute-Tables nutzt Alien Vault nicht. Mit intelligenter manueller Fragmentierung oder Segmentierung des Angriffs glückt also ein Angriff so, dass Alien Vault ihn nicht erkennt, obwohl es über eine entsprechende Signatur verfügt. Auch Dienste auf ungewöhnlichen Ports (ein Webserver auf Port 10000) kann Alien Vault daher nicht schützen.

Unzureichende Asset-DB

Dafür sollte das System nun die Asset-Datenbank besser nutzen, um den Analysten bei der Bearbeitung der Incidents zu unterstützen. Leider werden diese Daten aber nur unzureichend aufgearbeitet. Der Event Context eines Incident, der in der freien Version nicht verfügbar ist, bietet in der kommerziellen Variante nur geringe zusätzliche Funktionen (Abbildung 10).

Abbildung 10: Zwar kommt die kommerzielle Version mit Event Context, überzeugen kann der aber nicht.

Das überrascht, da die Asset-Datenbank doch weitreichende Informationen über das System hat. Sie kennt das Betriebssystem und den Wert des Zielsystems eines Angriffs. Bei dem in Abbildung 11 gezeigten Ereignis handelt es sich um einen gezielten Angriff auf den SSH-Port des Zielsystems.

Abbildung 11: Auch Alien Vault nutzt nicht alle verfügbaren Informationen aus seiner Asset-Datenbank.

Statt im Kontext lediglich zu zeigen, dass dieser Port auf dem Zielsystem geöffnet ist, wäre es hilfreich, auch das dort lauschende Produkt anzuzeigen, wenn diese Informationen wie hier in der Asset-Datenbank ohnehin vorliegen. Aus der OSVDB könnten auch direkt mögliche bekannte Sicherheitslücken dieser Software dazustoßen. Außerdem wurde dem Zielsystem eine Rolle zugewiesen, die ebenfalls nicht angezeigt wird. Auch dies könnte dem Admin bei der Analyse durchaus helfen.

Darüber hinaus fehlen in der Anzeige einige Schwachstellen auf dem Zielsystem, die Alien Vault erkannt hat (Abbildung 12). Auch die wären für die Analyse hilfreich, wenn sie direkt im Event Context angezeigt würden.

Abbildung 12: Obwohl Alien Vault weitere Schwachstellen erkannt hat, zeigt es diese dem Admin nicht an.

Open Threat Exchange

Eine unter Security-Experten in letzter Zeit sehr beliebte Idee ist es, statistische Informationen über Angriffe, deren Herkunft und Art automatisch und anonymisiert auszutauschen. Ob Senderbase von Iron Port und Cisco für die Spam-Bekämpfung oder der Open Threat Exchange von Alien Vault, die Idee ist dabei immer, eine weltweite Korrelation der Bedrohungen zu schaffen.

Hier versucht Alien Vault sich von den anderen Mitbewerber abzusetzen, indem es diese Dienstleistung allen OSSIM- und Alien-Vault-Anwendern kostenlos zur Verfügung stellt, wenn sie selbst ihre Installationen als Sensoren veröffentlichen. Alien Vault hat OTX im Februar 2012 erstmals vorgestellt und nutzt die Daten in erster Linie zur Korrelation der als gefährlich bekannten IP-Adressen. Im August hat Alien Vault die ersten gewonnenen Erkenntnisse veröffentlicht [15]. Diese Daten lassen sich dann in OSSIM oder Alien Vault als IP-Reputation angezeigen (Abbildung 13).

Abbildung 13: Alien Vault nutzt statistische Daten der OSSIM- und Alien-Vault-Installationen, um die Reputationen von IP-Adressen zu bewerten.

Snort selbst und alle hierauf aufbauenden Produkte sind für die forensische Analyse von Angriffen ungeeignet. Snort protokolliert nur das eine Paket, das die von Snort erkannte Signatur enthält. Alle Pakete, die vorher oder nachher über die Verbindung liefen, lassen sich anschließend nicht mehr analysieren. Für die Protokollierung der später übertragenen Pakete besitzt Snort zwar eine Funktion, die meisten Regeln nutzen sie jedoch nicht.

Aufwändige Forensik

Für seine forensischen Analysen kann der Admin sowohl in der freien als auch in der kommerziellen Version die umfangreiche Deep-See-Software von Solera Networks [16] anbinden, die den gesamten Netzwerkverkehr aufzeichnet.

Erkennt nun Alien Vault einen Angriff über das Netzwerk, so kann der Forensiker direkt über die Solera-Oberfläche auf die gesamte Netzwerkverbindung zugreifen und so den Angriff in seinem Kontext analysieren. Dies benötigt allerdings erhebliche Ressourcen für die Speicherung der Daten, daher bieten die wenigsten Systeme dies direkt an.

Ein gelungenes GUI, viele Schwächen – aber günstig

OSSIM bietet eine ansprechende Weboberfläche für die Analyse und Bearbeitung von Sicherheitsereignissen. Dem SIEM-Anspruch wird die freie Software nicht gerecht, da ihr die für die Korrelation der Daten wichtigen Direktiven fehlen und so automatisch kaum Incidents erzeugt werden. Die Software birgt lediglich eine gefällige und benutzerfreundliche grafische Oberfläche für den Zugriff auf viele verschiedene Informationen wie Security Events, erkannte Verwundbarkeiten und die Asset-Datenbank. Die Korrelation muss jedoch der Anwender selbst vornehmen, was ihn in vielen Fällen überfordern dürfte.

Die kommerzielle Variante bringt durch die bessere Unterstützung mit Korrelationsdirektiven einen einfacheren Zugang zu den Daten, nutzt jedoch ebenfalls nicht sämtliche Quellen, um dem Admin diese Daten konzentriert zu präsentieren. Für die Analyse muss der Anwender sich diese daher selbst zeitraubend zusammenklicken. Die Konkurrenz beherrscht dieses Feature sehr wohl, verlangt jedoch meist auch deutlich mehr Geld. Das Alien-Vault-SIEM stellt trotz seiner Einschränkungen eine preiswerte Variante dar.