SIEM & IT-SEARCH: Intelligente Verarbeitung von Security Events
Angesichts des erdrückenden Logaufkommens sind Security-Analysten heute kaum mehr in der Lage, mit manuellen Methoden oder eigenentwickelten Skripten Logdaten und Sicherheitsmeldungen zeitnah aufzubereiten und auszuwerten. Folglich finden, wenn überhaupt, nur Stichproben statt. Die Lösungsansätze der Hersteller im Bereich Log-Management und Log-Analyse können derzeit in zwei wesentliche Gruppen unterteilt werden: IT-Search und SIEM.
Der bestimmende Aspekt von IT-Search-Lösungen besteht in der zentralen Erfassung, Indexierung und Speicherung von Logs sowie der Bereitstellung von Such- und Analysemöglichkeiten. 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).
SIEM-Lösungen kommen ursprünglich aus dem Security Incident Management und wurden für SOCs entwickelt. Die Verarbeitung von Security Events von Firewalls, Proxies, IDS/IPS, etc. 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 (also unmittelbar zum Zeitpunkt des Auftretens) mit 6.000 EPS / pro System und mehr automatisiert durchführen.
Ohne eine zeitnahe Analyse von Logevents, ohne zentralisierte Archivierung, ohne Alerting und Trendanalysen, fehlt der gesamtheitliche Überblick über die aktuelle Sicherheitslage im Unternehmen.
Die Security-Abteilung kann nur noch reaktiv handeln und ihre Maßnahmen greifen zu spät. Es kommt noch schlimmer: Weil Policy– und Compliance-Richtlinien nicht oder nur ungenügend erfüllt werden, läuft das Unternehmen Gefahr, das nächste Audit nicht zu bestehen. Was fehlt, sind geeignete Werkzeuge, um mit Datenmengen von mehreren Terabyte effizient zu interagieren. Was fehlt, ist der integrative Ansatz, alle Logdaten an einem zentralisierten Punkt zu erfassen, zu aggregieren, zu korrelieren, zu visualisieren, zu alerten und zu archivieren.
SIEM-Lösungen (Security Information & Event Management) können heute Analyse und Korrelation von Sicherheitsereignissen in Echtzeit (also unmittelbar zum Zeitpunkt des Auftretens) 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.
Leider funktioniert dieser Ansatz nicht immer. Klassische SIEM-Lösungen arbeiten Datenbank- / Schemaorientiert und erfordern deshalb die Normalisierung von Logdaten. Wenn Unternehmen jedoch in hohem Umfang eigenentwickelte Applikationen einsetzen, gibt es in der Regel dafür keine vorgefertigten Parser bzw. Konnektoren. An dieser Stelle prallen zwei Philosophien aufeinander: Index-orientierte Suche versus Datenbank-orientierte Korrelation. Für Novizen dieser Thematik ein schwer zu durchdringender Dschungel.
Die Lösungsansätze der Hersteller im Bereich Log-Analyse können derzeit in zwei wesentliche Gruppen unterteilt werden – IT-Search und SIEM.
Lager 1: IT-Search
Der bestimmende Aspekt von IT-Search-Lösungen besteht in der zentralen Erfassung, Indexierung und Speicherung von Logs sowie der Bereitstellung von Such- und Analysemöglichkeiten. 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 (z.B. ArcSight Logger, LogLogic, Splunk, etc.).
IT-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 Informationen und arbeiten somit schemalos. Stattdessen werden die Logdaten i.d.R. 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.
Lager 2: SIEM
SIEM-Lösungen kommen ursprünglich aus dem Security Incident Management und wurden für SOCs entwickelt. Die Verarbeitung von Security Events von Firewalls, Proxies, IDS/IPS, etc. 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 (also unmittelbar zum Zeitpunkt des Auftretens) mit 6.000 EPS / pro System und mehr automatisiert durchführen.
Nahezu alle führenden Hersteller von SIEM-Lösungen (z.B. ArcSight, RSA Envision, Trigeo, Q1Labs) arbeiten datenbankorientiert und benötigten eine möglichst breite Produktunterstützung durch vorhandene Konnektoren, meist in Form RegEx-basierter Parser.
Nur wenige SIEM-Lösungen bieten eine umfangreiche Normalisierung und Kategorisierung. Erfolgt dies nicht, sinkt der Informationsgehalt und damit die Aussagekraft gegenüber dem Raw Event beträchtlich. Kaum eine Lösung bietet ein wirklich leistungsfähiges SDK, mit dessen Hilfe man eigenständig Parser bzw. Konnektoren entwickeln kann um z.B. eigene Applikationen einzubinden.
Beide Ansätze verfolgen unterschiedliche Zielsetzungen und weisen jeweils spezifische Vor- und Nachteile auf. Durch Mergers & Acquisitions versuchen Unternehmen beider Lager seit ca. 12 - 18 Monaten Kompetenzen in beiden Bereichen aufzubauen und Gesamtlösungen zu entwickeln. Stellvertretend seien hier ArcSight (ESM und
Logger) und LogLogic (Exaprotect) erwähnt.
Bewertung und Einsatz
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 Parsen 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. Um es auf den Punkt zu bringen: „Universal Indexing frisst einfach alles.“ Den Analysten ermöglicht es - in Analogie zu Google - nach beliebigen Termen, Wörtern oder Wortgruppen zu suchen.
Die Geschwindigkeit der Suchabfragen hängt allgemein von der Anzahl der gleichzeitigen Searches, von deren Komplexität, vom zu durchsuchenden Logdatenvolumen und dessen Verteilung auf verschiedene Systeme sowie von der Hardware-Performance ab. 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 Web2.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öglich 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. Das System korreliert nicht automatisch.
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 5 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 die verschiedene Watchlists auswerten 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.
Weitere Aspekte
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 / 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 z.B. 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. Beispielweise findet sich folgende Aussage in der Compliance-Vorschrift PCI DSS 1.2.1: „Zur Konformität mit Anforderung 10.6 können Protokoll- Harvesting-, -Analyse- und Alarmtools eingesetzt werden.“ Industrien, die Kreditkarteninformationen verarbeiten, und somit PCII DSS unterliegen, nutzen jedoch in hohem Maße eigenentwickelte Lösungen mit proprietäten Logformaten. Hier bietet sich der Einsatz von Universal Indexing in Verbindung mit intelligenten Searches und Reporting geradezu an.
Unternehmensinformation / Kurzprofil:
Datum: 16.03.2011 - 17:23 Uhr
Sprache: Deutsch
News-ID 732
Anzahl Zeichen:
Kontakt-Informationen:
Kategorie:
New Media & Software
Art der Fachartikel: Produktinformation
Versandart: Veröffentlichung
Freigabedatum: 16.03.2011
Anmerkungen:
Veröffentlichung nur mit Quellennachweis
Dieser Fachartikel wurde bisher 845 mal aufgerufen.
