Die Last lausiger Logs

10. September 2007, 17:36 Uhr |

Sicherheits-Informationsmanagement – Der Berg der Log- und Event-Meldungen wächst rasant. Security-Information-Management-Tools (SIM) wollen die Menge mit intelligenten Interpretationsmethoden verkleinern und verständlicher organisieren.

Sicherheitsverantwortliche in Unternehmen werden immer stärker von immer mehr Seiten unter Druck gesetzt. Nicht nur die reine Zahl relevanter Informationen wächst unerträglich schnell, auch gesetzliche Vorgaben verlangen von ihnen, die aktuelle Situation im Netz zu qualifizieren und zu dokumentieren. Das bedeutet im Alltag, die Wirkung der Sicherheitskontrollen zu verifizieren und sie dem aktuellen Bedrohungsstand gemäß auszurichten.

Wer diese Aufgabe erledigen will, muss alle Daten, die den Stand im Netz widerspiegeln, sammeln, speichern und auswerten. Und hier beginnt das tägliche Dilemma: Die Daten stammen aus verschiedenen Quellen, seien es Netzwerkkomponenten, Systeme, Applikationen oder Vulnerability-Scanner. Sie alle haben einen eigenwilligen Blick auf das Netz und den Verkehr, gegeben aus ihrer funktionalen Aufgabe. Folglich interpretieren sie Ereignisse in eigener Sprache. Wobei ihre Protokolle im besten Fall umfassend, im Normalfall aber kryptischer Natur sind.

Einige Security-Experten erkannten dieses Dilemma schnell und investierten frühzeitig in SIM-Ansätze. Leider haben diese jungen Lösungen selten mehr als Firewall- und IDS-Events zusammengeführt. Die heutige Situation zeigt ein uneinheitliches Bild: Mehrere Dutzend Hersteller haben ihre Claims auf diesem Produktgebiet abgesteckt, wobei jeder die SIM-Disziplin eigenwillig versteht. Die einzige Gemeinsamkeit zwischen den Herstelleransätzen ist, dass sie einander konsequent widersprechen. In allen wichtigen Teilbereichen, sei es bei der Positionierung, den wichtigen Funktionen oder der Namensgebung. Obwohl die Real-World Labs die Entwicklung der SIM-Produkte schon mehrere Jahre verfolgen, hat sich bisher noch kein einsichtiger und überzeugender Ansatz hervortun können. Wer sich mit dem Thema befasst, wird die Lage sicher ähnlich einschätzen.

Daher gilt es zuerst, den Wirrwarr zu entzerren. Dazu müssen die wichtigen Änderungen der vergangenen Jahre aufgearbeitet und daraus die besten Strategien extrahiert werden. Denn nur eine gute Strategie garantiert, dass das Log-Management und die dazu passende SIM-Initiative effizient funktionieren.

Die gute Nachricht zuerst: Wer sich die Zeit nimmt, die Policy, Prozesse und die Technologie zu verstehen, die sich hinter der jeweiligen SIM-Idee verbergen, kann sich eine gute Ausgangslage erarbeiten, der Log-Flut Herr zu werden. Diese Vorarbeit lässt sich gar nicht hoch genug schätzen, denn sie fällt das Urteil über Erfolg und Misserfolg eines SIM-Projekts. Noch etwas Generelles: Eine große SIM-Lösung mag unter dem Strich für manche Organisationen zu überdimensioniert sein. Trotzdem sollte jedes Unternehmen unbedingt eine Taktik entwickeln, Log-Daten zu verwalten. Wer das versäumt, wird niemals Informationen über Gefahren im Netz aus den Logs extrahieren können – ein heute kaum zu tolerierender Zustand.

Die drei großen Buchstaben
Der Begriff Sicherheits-Informationsmanagement (Security-Information-Management) zirkuliert schon seit Jahren in der Industrie. Aber der Markt, den er eigentlich definieren soll, ist ständig im Fluss. Dies liegt einmal daran, dass die Hersteller ihn gerne semantisch variieren. Einige sprechen von SEM, also Security-Event-Management, andere von SIEM, eine wunderbare Kombination aus beiden Begriffen. Warum sich die Real-World Labs im Jahr 2002 auf den Begriff SIM versteiften, liegt in der Arbeitsweise der frühen Produkte begründet. Nicht alle Informationen, die die Lösungen damals verwerteten, waren an ein bestimmtes Ereignis (Event) gebunden. So importierten die damaligen Produkte die Ergebnisse von Vulnerability-Scannern, die einen Einblick in den Gesundheitszustand der Systeme gewährten. Der Begriff SEM wurde dem nicht gerecht.

Die Hersteller sind mit der Wahl von SIM gar nicht glücklich. Sie benutzen lieber Begriffe wie Log-Management oder das allumfassende, daher unpräzise Enterprise-Security-Management, kurz ESM.

Hier ein Vorschlag zur Güte für alle Marketing- und Schlagwort-Schaffenden: Log-Management ist eine Unterdisziplin von SIM, während SIM eine Unterdisziplin von ESM ist. Das soll nun auch der letzte Beitrag zu der Wortklauberei sein.

Entgegen der Marketingwelt sind sich die Real-World Labs bei wichtigen Punkten einig: SIM ist mehr als Logs und Ereignisdaten. Asset-Informationen und ihre Gewichtung, Daten über den Gesundheitszustand von Systemen und der Import von Daten aus zahlreichen verschiedenen Quellen gehören genauso dazu. Denn diese Informationen sind extrem wichtig, um die aktuellen Sicherheitsrisiken zu quantifizieren und qualifizieren. Ein einfaches Beispiel zum besseren Verständnis: Beim Monitoring sollten fehlgeschlagene Logins auf einen kritischen Finanzserver die Alarmglocken schriller läuten lassen als die Aufklärungsversuche externer Drohnen gegenüber der zentralen Firewall. Die Kombination woraus (ein kritischer Server), wo (intern) und wie (mehrere fehlgeschlagene Login-Versuche) gibt den Sicherheitsverantwortlichen nämlich intelligent verpackte Hinweise. Im besten Fall lösen sie die richtige Gegenmaßnahme aus, die ein Risiko rechtzeitig eindämmt.

Natürlich hat es viele Vorteile, die Logdaten an einem Punkt zu zentrieren. Dies kann aber nur der Ausgangspunkt sein. Denn dieses Material muss auch analysiert und vor allem intelligent präsentiert sein. Allesamt Aufgaben, die sich jedes SIM-Produkt auf seine Verpackung schreibt.

Alle Lösungen im Test beherrschen Teile der fundamentalen Funktionen, um Sicherheitsinformationen gescheit zu verwalten. Aber eben nicht alle Basisfunktionen. Die Produkte »ST 3000« und »LX 2000« von Loglogic sind sehr gut darin, Logs zu verwalten, zu speichern und darüber Berichte zu formulieren. Beim Monitoring in Echtzeit schwächeln sie aber. »QRadar« von Q1 Labs verknüpft Ereignisse in Echtzeit gekonnt, kann die Daten aber nicht so flexibel weitergeben wie das Produkt »ESM« von Arcsight. Der Hersteller Network Intelligence hat gerade angefangen, eine grafische Benutzungsoberfläche für die Echtzeit-Analyse zu entwickeln. Auf allen anderen Gebieten hat sein Tool »enVision« Stärken gezeigt. Das Fazit: Alle Herstelleransätze zusammengenommen ergeben eine Schnittmenge von Funktionen, die ein Unternehmen heute tatsächlich braucht.

Kein Produkt hat diesen Reifegrad bisher erreicht. So müsste ein großes Unternehmen Geld für mehrere Einzelprodukte ausgeben, um die jeweiligen Lücken auszufüllen. Dies kostet bei großen Projekten schnell sechs- bis siebenstellige Summen, die die jeweiligen Lizenzen und der externe Integrationspartner für das Zusammensetzen veranschlagen. Dazu ist heute kaum jemand bereit. Ein SIM-Produkt muss von sich aus das am meisten Verlangte abdecken.

Kleine und mittelgroße Firmen werden sicher einen Appliance-Ansatz suchen, der die grundlegenden wichtigen Funktionen abdeckt. Der »Security Event Manager« von High Tower wäre ein Kandidat, zumal er mit 35000 Dollar noch bezahlbar ist. In der Tat bestätigt die Leserumfrage, dass die Mehrheit der Unternehmen die Lösung aus einer Hand bevorzugt. Diese muss den Transport, die Archivierung und Analyse der Logs abdecken. Die Hersteller müssen ihr jetziges Standard-Feature-Set zwingend abrunden, die Lücken auffüllen, sonst werden sie auf Dauer Marktanteile verlieren.

Nach dem heutigen Stand gehört zu den Standard-Funktionen unbedingt auch die forensische Analyse, neben dem Monitoring, der Archivierung, dem Transport etc. Der Administrator sollte am Ende herausfinden, welche der vielen Teildisziplinen für sein Projekt die größte Bedeutung haben. Und dann prüfen, welcher Hersteller diese am besten beherrscht.

Diese lästigen Logs
So viel versprechend es klingt, Vulnerability- und Asset-Informationen einzubinden, die wichtigste Aufgabe eines SIMs ist und bleibt es, die große Menge der Log-Daten zu organisieren. Das ist nicht sexy. Und kein Administrator übernimmt diese Arbeit gern. Logs als Datenquelle existieren so lange wie die Computer selbst. Im Gegensatz zu den PCs hat sich die Qualität der Logs aber kaum weiterentwickelt. Obskure Formate, ein lähmendes Volumen und Ströme von Kauderwelsch, das in 99 von 100 Fällen jegliche Relevanz vermissen lässt, prägen noch immer das Bild. Dabei ist die Organisation dieser Informationen wichtig, sei es für die Sicherheitsverantwortlichen oder einen Auditor. IT-Abteilungen müssen diese Daten in den Griff bekommen. Denn sie geben Antworten auf wichtige Fragen: Was ist passiert? Wer hat worauf zugegriffen? Und schließlich: Wer hat es getan? Und sie geben Antworten auf grundlegende Fragen: Wurden tatsächlich alle Rechte eines Users gelöscht? Lässt sich belegen, dass Person X nicht auf Server Y zugreifen darf? Wie viele Personen greifen in einer Woche auf Zone Z zu?

Obwohl das Gewicht der Logs auch aus Sicht der Gesetzesbestimmungen wächst, haben die meisten Versuche, sie zu verwalten, meist rudimentären Charakter. Viele Asset-Zuständige und Administratoren belassen die Logs auf den Systemen und vertrauen die Pflege dieser Daten einem automatischen Mechanismus an. Dieses mit einem Autopiloten vergleichbare Modell verursacht eine Reihe von Problemen, gerade auf den Gebieten der Verfügbarkeit und Integrität. Wird ein System kompromittiert, ist auf dessen lokale Log-Daten kein Verlass mehr. Denn der Cracker könnte längst Root- oder Administratorrechte erlangt haben, mit denen er diese Informationen nach Belieben manipulierte. Wenn aber die Log-Daten ihre Aussagekraft vollkommen verlieren, wie kann der Administrator dann einen Vorfall verifizieren, geschweige denn entschärfen?

Eine fortschrittliche Log-Management-Strategie ist daher obligatorisch. Sie legt fest, dass Kopien lokaler Logs an ein anderes System oder eine andere Lokation transferiert werden. Diese Taktik löst keineswegs alle Probleme, erhöht aber die Wahrscheinlichkeit, dass irgendwo im Netz eine verlässliche Aufzeichnung des Vorfalls platziert ist.

Beim Punkt Verfügbarkeit stellt sich folgendes Problem: Selbst wer kein präventives, aktives Monitoring nutzt, wird im Alltag zu Sofortmaßnahmen und historischen Analysen gezwungen sein. Werden alte Log-Daten aber periodisch überschrieben oder gelöscht, ist der Verantwortliche dazu gezwungen, alte Backup-Daten nach den gewünschten Informationen zu durchsuchen. Ein reines Glücksspiel vor dem Hintergrund großer Log-Mengen und den Rotationsfenstern, die den Archivierungsrhythmus vorgeben. Die Schwächen dieser Prozedur zeigen sich vor allem bei Fällen von Datendiebstahl. Sie werden meist erst Monate nach der eigentlichen Tat bekannt. Die Verantwortlichen müssen also Monate zurückrecherchieren und die Logs von Systemen, Authentifizierungsplattformen und Remote-Access-Geräten durchforsten. Fehlt ein zentrales Log-Management, ist diese Aufgabe nur unter großen Anstrengungen zu lösen.

Die Strategie System-nach-System, bei der die Log-Daten lokal bleiben, hat noch eine weitere Schwäche. Die Log-Rotation und -Laufzeit der verschiedenen Systeme sind selten synchronisiert. Die HP-UX-Maschine in Frankfurt gehorcht sicher einer anderen Log-Policy als ihr Gegenstück in Gladbach und Leipzig. Weil die Logs einem eigenen Rotationsrhythmus folgen, entstehen operative Probleme, gerade bei der Untersuchung von Vorfällen. Zudem ist es in diesen Fall schwierig zu evaluieren, ob alle wichtigen Stellen in der Organisation die Eckpunkte der Log-Policy auch umsetzen. Weil jeder sein eigenes Süppchen kocht. Eine einheitliche Log-Policy, die mit Hilfe zentral überwachter Mechanismen durchgesetzt wird, kann beide Probleme entschärfen. Eine SIM-Lösung wird bei diesen politischen und organisatorischen Aufgaben kaum helfen, kann aber als wichtiger Ausgangs- und Schnittpunkt dienen.

Auch die Analyse der Logs ist problematisch. Selbst Verantwortliche mit herausragendem technischem Verständnis werden dem nicht widersprechen. Selbst wenn die Log-Daten vorliegen, wird nur selten etwas aus ihnen gemacht. Verständlicherweise, denn ohne Technik, die diesen Prozess automatisiert, sind Studien der Logs ekelhaft komplex und aufwändig. Schon Firewalls produzieren Dutzende, wenn nicht Hunderte von Einträgen pro Sekunde. Auch die Implementierung einer Active-Directory-Service-Datenbank (ADS) ist aus Log-Sicht ziemlich geschwätzig. Zehn Events pro Sekunde sind 600 in der Minute, 36000 pro Stunde und 864000 pro Tag. Niemand kann mit diesen Volumina Schritt halten. Daher sind automatische Analysen besonders wichtig. Ein SIM-Produkt liefert diese, indem es die Log-Daten verknüpft und die Menge der Ereignisse drastisch reduziert.

Eckpfeiler einer guten Strategie
Eine wohl durchdachte Taktik beginnt mit einer gesunden Bewertung der Größe und Komplexität der Aufgabe. Wer die Fragen »was, wer, wann und für wie lange« beantworten möchte, wird schnell merken, dass er verschiedene Sektionen und Interessen im Unternehmen koordinieren muss. Zu den Interessenten gehören typischerweise die berühmten Business-Owner, Asset- und System-Owner, Auditoren und natürlich die Rechtsabteilung im Unternehmen. Sie alle werden bei Untersuchungen und Vorfällen unterschiedliche Informationen und Detailtiefen anfordern.

Das führt zu den nächsten Punkten. Was soll gelogged werden? Wo liegen diese Daten und in welchem Format sind sie strukturiert? Über welchen Kommunikationspfad werden sie transferiert, und wie lange müssen sie archiviert werden? Wer diese Fragen mit den jeweiligen Interessenvertretern erörtern möchte, wird viel Zeit mitbringen müssen.

Der weitere Schritt ist die Identifizierung der Ziele. Vor drei Jahren haben die meisten Unternehmen Logs gesammelt, um ihren Sicherheitsverantwortlichen genügend Informationen über einen Vorfall geben zu können. Das hat sich stark geändert, da Firmen mit grundlegenden Audit- und Compliance-Anforderungen konfrontiert sind. Für IT-Abteilungen ist es heute wichtiger, die Einhaltung der Policy zu belegen und die Kontrollziele auch einzuhalten. Wer ein SIM-Produkt sucht, sollte daher unbedingt klar definieren, welche Informationen er darüber gewinnen muss. Sollen die Log-Daten an zentraler Stelle gesammelt oder zuerst in den Außenstellen aggregiert werden? Müssen die Dateien stark belastete WAN-Strecken passieren? Ist das der Fall, so sind Queuing- und Bandbreiten-Managementfunktionen wichtig. Soll die SIM-Plattform auch Incident-Response- und Investigations-Workflows organisieren oder diese Aufgaben mit einem bereits aufgesetzten Ticketing-System abwickeln? Falls kein separates Ticket-System existiert, muss das gewünschte SIM-Produkt diese Workflows in entsprechender Qualität lösen können.

Während des Tests der Lösungen fielen besonders die funktionalen Unterschiede zwischen Report-zentrischen und Echtzeit-Monitoring-Plattformen auf. Das ist insofern verständlich, da sich die Anforderungen beider Aufgaben stark in der Architektur der Lösungen widerspiegeln. Es ist etwas anderes, einmal die Woche Standard-Berichte zu fertigen, als in Echtzeit einem Security-Operation-Center (SOC) aufgearbeitete Ereignisse zu liefern. Auf lange Sicht muss ein SIM-Produkt aber beide Bereiche adäquat abdecken. Aus heutiger Sicht muss sich das Unternehmen entscheiden, welche der beiden Aufgaben wichtiger ist, und auf dieser Grundlage seine Kaufentscheidung treffen.

Sind die Ziele definiert, so gilt es jene Informationsquellen festzulegen, mit denen sich diese erreichen lassen. Ein Beispiel: Die Beobachtungsziele sind an die Authentifizierung und Zugangskontrolle im Netz gebunden. Der Administrator muss hierbei verifizieren, wer die authentifizierten Anwender sind und an welchen Authentifizierungsmodellen sie partizipieren. Wird er dazu das Hauptverzeichnis im Unternehmen einbinden? Oder die Remote-Access-Systeme, seien es die Dial-in- oder VPN-Server, auf denen die Userprofile ebenfalls eingerichtet sind?

Sobald ein Unternehmen von grundlegenden Aufgaben wie »Ich muss die Logs meiner Server konsolidieren« hin zu fortschrittlichen Analysen wie »Ich brauche Authentifizierungsdaten, die an meinen wichtigen Geschäftsprozess gebunden sind« tendiert, wird es einige Hürden nehmen müssen. Es muss die beteiligten Assets isolieren, deren Verantwortliche einbinden und Transferwege für die Logs schaffen. Den Syslog-Message-Transport auf einer Pix-Firewall von Cisco einzuschalten, ist in wenigen Minuten getan. Wer dagegen die Access-Logs seiner SAP-Implementierung in die globale Logging-Architektur einpflegen möchte, ist wegen der Komplexität dieser Aufgabe schon stärker gefordert. Die meisten SIM-Hersteller kommen dem Administrator mit einer Reihe von angepassten Daten-Handlern entgegen – natürlich kostenpflichtig. Welche Applikationen und Systeme ein SIM als Quelle anzapfen kann, variiert von Hersteller zu Hersteller sehr stark. Daher lohnt es sich, von vornherein zu klären, ob das gewünschte Produkt die wichtigsten Log-Quellen von sich aus unterstützt. Dies bewahrt den Administrator davor, in speziell für das Projekt erstellte Schnittstellen investieren zu müssen.

Ist geklärt, welche Informationen wie im Unternehmen gesammelt werden sollen, gilt es, eine Storage- und Laufzeit-Richtlinie zu entwickeln. Hierbei legt der Verantwortliche fest, welche Datenmenge er archivieren will, wie groß die Speicherkapazität sein und wie lange er die Daten vorhalten muss. Einige Organisationen mit großen Log-Volumen – Terabytes pro Monat oder mehr – legen die Laufzeit individuell für jeden Log fest. Ein Unternehmen, das im Gesundheitssektor tätig ist, erklärte, dass es die Authentifizierungs- länger aufbewahrt als die IDS-Logs. Diese feinstufige Richtlinie erhöht die Komplexität, wobei einige SIM-Produkte diese Policies funktional abbilden und handhaben können. Wer von vornherein weniger kritische Daten schneller löscht, wird mehr speichern oder aber an der Storage-Kapazität sparen können. Organisationen mit kleinerem Log-Volumina wollen die Sache sicher einfacher halten und daher alle Logs für eine bestimmte Zeit archivieren.

Unabhängig von der Laufzeit, bleibt es schwierig, die reinen Storage-Anforderungen zu schätzen. Wenn ein Unternehmen seine Logs bisher nicht zentral zusammengeführt hat, wird es nur grob berechnen können, wieviel die Daten in der Summe ausmachen. Eine Entdeckungstour im Unternehmen hilft hier ungemein, das Volumen besser zu kalkulieren.

Zweitens treten signifikante Unterschiede im Alltag auf. Im Test haben die Perimeter-Firewalls während einiger heftiger externer Scans das bis zu 20-Fache an Logs produziert. Diese Spitzen fallen weniger ins Gewicht, je größer der Zeitraum ist, auf dessen Grundlage der Administrator den Durchschnitt berechnet.

Beim Test wurde die nötige Kapazität anhand von Sampels analysiert. Eine Reihe repräsentativer Systeme und Geräte lieferte die Rohdaten, die das »syslog-ng«-Paket dann als zentrales Log-Archiv zusammenfasste. Die Stellvertretersysteme haben ihre Logs an den Syslog-Server geschickt, der vollständige Kopien der täglichen und wöchentlichen Event- und Log-Daten vorhielt. Einige Wochen später gab das Volumen auf dem zentralen Server gute Indikatoren vor, um die Menge der Logs aller kritischer Produktionssysteme im Netz zu berechnen. Dieser Weg lässt noch einigen Raum für Fehleinschätzungen zu, ist aber allemal besser, als die Kapazität völlig ohne Grundlage zu bestimmen.

Als Nächstes legt der Administrator fest, welche Berichte er braucht und in welchem Intervall er sie anfertigen möchte. Hiermit legt er weitere Auswahlkriterien für das SIM-Produkt fest. Wobei ein Pilotprojekt mit einer kommerziellen SIM-Lösung auf diesem Gebiet die Analyseschritte im Unternehmen recht deutlich verbessern kann. Ein Beispiel: Wer dem Standard »COBIT« folgt und Account-Management-Wechsel belegen muss, wird mit einem Werkzeug, das entsprechende Ereignisse auf allen zentralen Datenbanken automatisch in Berichte gießt, schnell viel Zeit einsparen.

Zurück zu den großen Unterschieden zwischen Berichten und Echtzeit-Monitoring. Bei letzterer Disziplin sind Datenreduktion, Dashboards und Analysetools gefragt, die ein Ereignis auswerten. Der Test zeigte, dass jedes Produkt entweder auf dem einen oder anderen Gebiet überzeugt, aber keines Echtzeit-Analysen und Reporting gleichwertig abgedeckt.

Wenn ein Unternehmen seine SIM-Anforderungen festlegt, sollte es realistisch einschätzen, wie viel es in den Betrieb einer solchen Lösung investieren möchte. Sind genügend kompetente Mitarbeiter dafür abgestellt, vor einer Echtzeitkonsole zu sitzen und auf dortige Ereignisse angebracht zu reagieren? Die aktuelle SIM-Technik reduziert die Zahl der Events zwar recht gut. Fehlt aber das Personal, um die übrig gebliebenen Meldungen zu bearbeiten, sollte die Echtzeitdisziplin im Entscheidungsprozess geringer gewichtet werden. Die Echtzeitfunktion gänzlich vernachlässigen? In Gesprächen teilten einige Unternehmen mit, dass sie ihr SIM-Projekt zuerst als Berichtslösung begriffen und dann später das Monitoring nachrüsten wollten. Sie mussten leider feststellen, dass das installierte SIM-Produkt auf diesem Gebiet auf Grund fehlender wichtiger Funktionen versagte.

Alle untersuchten Produkte reduzieren die Zahl der Events immens, aber sie haben die Ereignisse nicht ganz aus der Welt geschafft. Die korrelierten Meldungen müssen weiterhin untersucht oder verworfen werden. SIM ist noch weit entfernt von Plug-and-Play. Wir Menschen werden sicher noch eine ganze Zeit lang eingebunden sein.

Jüngste Veränderungen
Den größten Einfluss auf die SIM-Technik hat das Thema Compliance. Wer öfter mit amerikanischen Herstellern spricht, mag sich des Eindrucks nicht erwehren, dass das Thema derzeit das einzig relevante in der ganzen EDV sei. Und ihre Berichte sind die Antwort auf alle Fragen. Gezwungen nachzuweisen, dass ein bestimmter Kontrollmechanismus funktioniert? Nur einen Bericht initiieren! Gezwungen nachzuweisen, dass Vorgaben X, Y oder Z auch umgesetzt werden? Nur einen Bericht initiieren!

Natürlich sind solche Argumente weit von der Realität entfernt. Viele Compliance-Themen lassen sich mit Berichten unterfüttern, aber keineswegs sind damit alle Fragen geklärt. Wobei die Compliance-Anforderungen immens mit IT-sicherheitsrelevanten Fragen korrespondieren.

Denn unabhängig, welches Gesetz auf ein Unternehmen zutrifft, liegt der Weg zur Compliance und stärkeren IT-Security in den Logs und ihren Informationen. Es stellt sich nicht die Frage, ob diese Informationen ausgewertet werden, sondern wann und wie.

Auch auf dem Markt der SIM-Hersteller stehen Änderungen an. Abhängig davon, welchem Analysten man glaubt, ist das Marktvolumen mit 200 bis 500 Millionen Dollar taxiert. Verglichen mit anderen Security-Segmenten kein großer, aber stetig wachsender Bereich. Ein Markt, der jedoch heiß umkämpft ist. Vor drei Jahren tummelten sich darauf sechs Hersteller, heute sind es mindestens 17. Zu den Marktführern zählen Arcsight und Network Intelligence. Aber CA, Cisco, IBM und Symantec entwickeln ihre Lösungen in diese Richtung, so dass es für kleinere Hersteller schwer werden könnte, hier zu überdauern.

Die speziellen Lösungen, beispielsweise von Arcsight, sind auf Grund ihrer klaren Zielrichtung ausgereifter. Es wird allerdings spannend bleiben, wie sich diese kleinen Anbieter gegenüber den großen etablierten Herstellern behaupten können, zumal Letztere gleich das Hard- und Software-Equipment in Projekte einbringen. Glücklicherweise sind viele kleine SIM-Anbieter profitabel, wodurch sie ihre Autonomie durchaus schützen könnten. Wer ein SIM-Produkt kaufen möchte, sollte trotzdem das finanzielle Rückgrat des gewünschten Lieferanten überprüfen. Denn es ist unwahrscheinlich, dass alle Anbieter überleben werden. Die großen Hersteller wie IBM, Novell oder Symantec werden durch Akquisitionen zusätzlich dazu beitragen, dass hier eine Konsolidierung stattfindet.

Eine weitere Änderung auf dem Gebiet SIM betrifft die Geräte, die abgefragt werden. Viele der ersten Lösungen konzentrierten sich auf das Perimeter und integrierten daher Firewalls, IPS, Vulnerability-Assessment-Scanner und andere Plattformen, die am Rand des Netzes positioniert waren. Interne Systeme und Applikationen standen damals nicht auf ihrer Liste. Zu der Zeit war dieser Ansatz auch sinnvoll. Denn viele Sicherheitsinitiativen waren vor fünf Jahren darauf ausgerichtet, den Rand des Netzes abzudichten und zu überwachen. Außerdem war es damals unüblich, fortschrittliche Zugangskontrollsysteme und Monitoring-Werkzeuge bis tief in die Datenzentren hinein wirken zu lassen. Heute dagegen geht nahezu jedes Unternehmen so vor. Daher sind interne Anwendungen wie Human-Ressources und selbst die physische Zugangskontrolle wichtige Log-Quellen, die ein SIM anzapfen sollte. Leider ist kein Hersteller in der Lage, alle diese Plattformen zu unterstützen.

Viele der Anbieter sind gut darin, eine oder zwei große Applikationswelten abzudecken. Aber von Default-Agenten und Integrationskomponenten zu sprechen, die sich sofort in die interne, wichtige Anwendung einklinken, wäre verfrüht. Zwar können viele SIM-Produkte auch Informationen aus unbekannten Quellen importieren. Sie wissen aber nicht viel mit diesen Daten anzufangen, weil ihnen die Kompetenz fehlt, sie richtig aufzuarbeiten und zu interpretieren.

Der Stand der SIM-Lösungen ist also noch weit davon entfernt, die wichtigen Anwendungen im Netz schnell und einfach zu integrieren. Die Hersteller haben diese Herausforderung aber immerhin angenommen.
pm@networkcomputing.de


Jetzt kostenfreie Newsletter bestellen!

Matchmaker+