20100910i iT Cube Systems Security Events SIEM oder IT-Search

Seit IBM wissen wir, dass entweder der Niemeier oder das Kabel schuld sind, wenn der Drucker nicht druckt. Wussten Sie, woran es lag, als Ihre Drucker erst kürzlich nicht zu wenig sondern zu viel druckten, also mehr als sie sollten? Und warum dieses Phänomen innerhalb kürzester Zeit von Drucker zu Drucker wechselte? Der Verdacht auf eine LNK-Vulnerability liegt schnell nahe. Aber wie erhärten Sie diesen Verdacht, wenn ein Vorstand in Deutschland der Verursacher ist und die betroffenen Drucker in Spanien stehen? SIEM & SEARCH gibt hierauf eine sichere Antwort.

it den Logdaten verhält es sich wie mit E-Mails: Man hat davon viel zu viel, das meiste besitzt den Wert von Spam, die wichtigen sind nicht zu finden und bei einer Suche sind die Events schnell übersehen. Mit manuellen Methoden oder eigenentwickelten Skripten können Logdaten und Sicherheitsmeldungen nicht mehr zeitnah aufbereitet oder gar ausgewertet werden. Analysen können nur in Stichproben stattfinden: Reaktionen und Maßnahmen kommen zu spät.

Ohne eine zeitnahe Analyse von Logevents, ohne zentralisierte Archivierung, ohne Alerting und Trendanalysen fehlt selbst der Security-Abteilung die Kenntnis über die aktuelle Sicherheitslage im Unternehmen. Was hier notwendig ist, sind geeignete Werkzeuge, um mit Datenmengen von bis zu einigen hundert Gigabyte effizient zu interagieren. Es braucht einen integrativen Ansatz, alle Logdaten an einem zentralisierten Punkt zu erfassen, zu aggregieren, zu korrelieren, zu visualisieren, zu alerten und zu archivieren.

Die Lösungsansätze der Hersteller im Bereich Log-Analyse können derzeit in zwei wesentliche Gruppen unterteilt werden – SIEM und Search (Abbildung 1).

$Beschreibung: Z:\006_Publikationen\Fachartikel\2010-09_manage-it-online\abbildung_1.png$

Abbildung 1: Der Mehrwert von Log-Management-Lösungen besteht in der zentralen Erfassung, Indexierung und Speicherung von Logdaten sowie der Bereitstellung von Such- und Analysemöglichkeiten.

SIEM-Lösungen (Security Information & Event Management) können heute Analyse und Korrelation von Sicherheitsereignissen in Echtzeit automatisiert durchführen. Durch Erfassung, Normalisierung, Aggregation und Korrelation der Logevents unterschiedlicher Systeme verschiedener Hersteller (Cross-Device & Cross-Vendor Data) können aus zehntausenden von Events diejenigen identifiziert werden, die eine tatsächliche Bedrohung kritischer Anwendungen und Daten darstellen. Das schafft Transparenz und spart Aufwand.

SIEM-Lösungen kommen ursprünglich aus dem Security Incident Management und wurden für SOCs entwickelt. Die Verarbeitung von Security Events von zum Beispiel Firewalls, Proxies oder IDS/IPS beherrschen sie heute perfekt und warten mit intelligenter Ereigniskorrelation, Workflow-Unterstützung, Collaboration-Tools, Live Channels und Ticketing-Funktionen auf. SIEM-Lösungen sind wesentlich schneller geworden und können heute Analyse und Korrelation von Sicherheitsereignissen in Echtzeit mit 6.000 EPS / pro System und mehr automatisiert durchführen. Nahezu alle führenden Hersteller von SIEM-Lösungen (zum Beispiel Arc Sight, RSA, Q1Labs, IBM) arbeiten datenbankorientiert und benötigten eine möglichst breite Produktunterstützung durch vorhandene Konnektoren, meist in Form Regex-basierter Parser.

Wenn Unternehmen jedoch in hohem Umfang eigenentwickelte Applikationen einsetzen, gibt es in der Regel dafür keine vorgefertigten Parser oder Konnektoren. Und kaum eine Lösung bietet ein wirklich leistungsfähiges Software Development Kit, mit dessen Hilfe man eigenständig entwickeln könnte.

An dieser Stelle prallen zwei Philosophien aufeinander: Index-orientierte Suche versus Datenbank-orientierte Korrelation. Für Novizen dieser Thematik ein schwer zu durchdringender Dschungel.

SEARCH-Lösungen legen ihr Hauptaugenmerk auf die zentrale Erfassung, Indexierung und Speicherung von Logs sowie die Bereitstellung von Such- und Analysemöglichkeiten (Abbildung 2). In der technischen Umsetzung verzichten diese Log-Management-Lösungen folglich auf aufwendiges Parsen und Normalisieren von Logs und setzen stattdessen auf eine teilweise oder vollständige Blind-Indexierung des Logtextes (Universal Indexing). Einige dieser Lösungen sind in der Lage, wiederkehrende Terme und Muster zu lernen und beherrschen dabei eine Volltextindizierung in Echtzeit (zum Beispiel Arc Sight Logger, Log Logic, Splunk).

$Beschreibung: Z:\006_Publikationen\Fachartikel\2010-09_manage-it-online\abbildung_2.png$

SEARCH-Lösungen sind auf hohe Durchsätze getrimmt und speichern Logdaten mit Kompressionsraten von bis zu Faktor 10:1 in sogenannte indexed Flatfiles. Sie verwenden keine Datenbanken zum Ablegen der Loginformationen und arbeiten somit schemalos. Stattdessen werden die Logdaten in der Regel in einem offenen Format (gzip) gespeichert und signiert, um Manipulationssicherheit zu gewährleisten. Sie beherrschen keine komplexen Korrelationen in Echtzeit. Die Möglichkeiten der Loganalyse orientieren sich an einer forensischen Analyse erfasster Daten.

Beide Ansätze verfolgen unterschiedliche Zielsetzungen und weisen jeweils spezifische Vor- und Nachteile auf. Durch Mergers & Acquisitions versuchen Hersteller, Kompetenzen in beiden Bereichen aufzubauen und Gesamtlösungen zu entwickeln. Stellvertretend seien hier Arc Sight (ESM und Logger) und Log Logic (Exaprotect) erwähnt.

Bestimmendes Kriterium für die grundlegende Systemauswahl ist vor allem der Einsatzzweck. Wenn es darum geht, Events von vor allem weitverbreiteten Quellen mit einem hohen Grad an Automatisierung durch komplexe Korrelationen zu verarbeiten, sind klassische, Datenbank-orientiert arbeitende SIEM-Lösungen die erste Wahl.

Müssen die Events einer hohen Anzahl von »legacy Applikationen« mit großer Vielfalt der Log-Schemata, Formate und Inhaltsoptionen analysiert werden, so kann der Aufwand für die Entwicklung von Parsern schnell eine Dimension erreichen, die das Konzept grundsätzlich in Frage stellt. Darin liegt einer der wesentlichen Vorteile von Loganalyse-Systemen begründet, welche auf Universal Indexing setzen: Es sind keine umfangreichen Vorarbeiten nötig, um Logs analysieren zu können. Universal Indexing indiziert alle Arten von Logdaten, jeden Term, jedes Ereignis von allen Quellen in Echtzeit, ohne dabei Datenbanken zu verwenden, teure Konnektoren zu benötigen oder benutzerdefinierte Parser für proprietäre Anwendungen vorauszusetzen. Den Analysten ermöglicht es – in Analogie zu Google – nach beliebigen Termen, Wörtern oder Wortgruppen zu suchen.

Bei fast allen Universal-Indexing-Lösungen kann man mehr oder weniger intelligent mit den Suchergebnissen interagieren. Die Technologieführerschaft nimmt in dieser Disziplin derzeit zweifelsohne Splunk ein. Mit einem Ajax-basiertem Web-2.0-GUI sind Drill-Downs, Zoomfunktionen auf der Zeitachse, Trendanalyse und das Erkennen von Spikes oder Anomalien vorbildlich umgesetzt. Statistiken, Grafiken und andere praktische Werkzeuge, ermöglicht es in kürzester Zeit die Nadel im Heuhaufen zu finden. Der Vorteil von IT-Search ist allerdings auch sein größter Nachteil: Der Analyst muss wissen, wonach er sucht. Korrelation bei Search-Tools bedeutet lediglich das Verknüpfen von Suchausdrücken – mehr aber nicht.

Dazu ein Beispiel: Ein Administrator legt einen neuen User in einer MS-Windows-Domäne an und weist diesem umfassende Zugriffs- und Administrationsrechte zu. Anschließend nutzt er diesen Account, um über einen Zeitraum von fünf Tagen vertrauliche Daten in kleinen Mengen zu kopieren. Danach löscht er den Account. Zwar stehen in den Security Event Logs Einträge über das Anlegen und Löschen dieses Accounts, da diese aber zeitlich verteilt sind, würde ohne einen konkreten Verdachtsmoment vermutlich niemand danach suchen. Anders bei einem SIEM: Hier würden vordefinierte Regeln auch dann verdächtige Ereignisse erfassen, wenn diese zeitlich stark verteilt auftreten.

Durch die Normalisierung und Kategorisierung können in SIEM-Systemen umfangreiche Regelwerke aufgebaut werden. Deren Logik arbeitet losgelöst von den spezifischen Produkteigenschaften der Logquelle, was einer der Gründe für Normalisierung & Kategorisierung ist. Der einmal erbrachte Aufwand, die zumeist in großem Umfang bereits enthaltenen Regelwerke auf das konkrete Einsatzfeld zu adaptieren, zahlt sich spätestens im Betrieb aus. Mit wenigen personellen Ressourcen, jedoch intelligenter, automatisierter Korrelationslogik können Rechtemissbrauch, Informationsdiebstahl und Insider Threat erkannt und gestoppt werden.

Ausgehend von der Tatsache, dass Angriffe auf Applikationsebene und Insider Threat die wesentlichsten Bedrohungen auf Applikationen und Daten darstellen, ist die Absicherung der Applikation und die Erkennung sowie Verhinderung von Missbrauch und Insider Threat die dringlichste Aufgabe für die IT-Security. Klassische Host- und Netzwerk-Intrusion-Detection-Systeme (HIDS, NIDS) sind grundsätzlich jedoch kaum in der Lage, Angriffe aus Rechtemissbrauch, Missbrauch von Benutzeridentitäten und Insider Threat zu erkennen, da sie in erster Linie mit wissensbasierten Erkennungsmethoden (Signaturen) arbeiten. Hinzu kommt, dass die Sinnhaftigkeit eines Einsatzes von NIDS/ NIPS dann in Frage gestellt werden muss, wenn an den derzeit technisch möglichen Integrationspunkten überwiegend verschlüsselter Datenverkehr keine effektive Angriffserkennung zulässt.

Die effiziente Erfassung und Auswertung von Loginformationen aller Datenquellen, die sicherheitsrelevanten Ereignisse aufzeichnen, auswerten, alarmieren, speichern und archivieren ermöglicht oft einen wesentlich höheren Zuwachs an Sicherheit und kann auch unter Compliance-Aspekten im Sinne einer Erkennung und/oder Verhinderung von Eindringversuchen durchaus als »Intrusion Detection System« betrachtet werden. Laut Compliance-Vorschrift PCI DSS 1.2.1 können zur Konformität mit Anforderung 10.6 Protokoll-Harvesting-, -Analyse- und Alarmtools eingesetzt werden. Damit bietet sich der Einsatz von Universal Indexing mit intelligenten Searches und Reporting gerade in Bereichen an, die Kreditkarteninformationen verarbeiten und somit PCII DSS unterliegen.

IT-Search-Tool testen:

Als Freeware-Version kann Splunk von registrierten Nutzern für ein Logvolumen von 500 MB pro Tag ohne zeitliche Beschränkung verwendet werden. Somit eignet sich die Software gut zum Testen für Einsteiger.

Splunk ist für alle gängigen Betriebssysteme verfügbar: Solaris 9, 10 (x86, SPARC), Linux Kernel Vers 2.6.x (x86: 32/64 Bit), FreeBSD 6.1 / 6.2 (x86: 32/64 Bit), Windows 2003 (32/64 Bit), Windows 2008, XP und Vista.

Copyright © 2003-2012 ap Verlag GmbH