Intelligente Systeme sind Trumpf

Die Grundidee, dass man durch intelligente Korrelation der Protokollmeldungen von Firewalls, VPN-Gateways oder Authentisierungsservern Angriffe erkennen kann, ist nur begrenzt richtig. Bei näherer Betrachtung zeigt sich, dass nur wenige Beispiele von Angriffsszenarien überhaupt Indikatoren in diesen Protokollen erzeugen. Bereits Angriffe auf Web-Applikationen mit Methoden wie SQL Injection, die seit zehn Jahren sehr beliebt sind, können erst mit spezialisierten Web Application Firewalls annähernd zuverlässig erkannt und verhindert werden. Ein IDS- oder IPS-Produkt wäre für diesen Zweck eine Fehlinvestition. Entsprechend gibt es typische Beispiele, bei denen erfolgreiche Kompromittierungen von Webportalen nicht dem SOC-Dienstleister, sondern den Anwendern aufgefallen sind.

Ein wesentlicher Einflussfaktor auf die Fähigkeit, Angriffe erkennen zu können, ist neben dem nötigen Personal mit entsprechender Kompetenz auch die richtige Technik. Hier werden in vielen Fällen die Lösungen zur Erkennung und Korrelation weit überschätzt oder mit ungeeigneten Ausgangsdaten beliefert. Die Verlagerung auf einen externen Dienstleister ändert an dieser Situation zunächst nichts.

Fragt man Kunden von externen SOC-Dienstleistern, was sie von ihrem Dienstleister bekommen, so berichten auch heute viele Firmen, dass sie neben Rechnungen vor allem Tagesberichte, Wochenberichte und Monatsberichte erhalten, die sie dann abheften.

Im Fall der Fälle: Incident Response

Wenn der Verdacht auf einen Sicherheitsvorfall besteht, muss ein Incident-Response-Prozess starten. In diesem müssen Experten zunächst klären, ob es sich tatsächlich um ein Sicherheitsproblem handelt oder ob eine einfache Störung den Alarm ausgelöst hat. Diese Klärung erfordert in der Regel Zugriff mit administrativen Rechten auf die betroffenen Endgeräte beziehungsweise Server. Ein externer Dienstleister, der lediglich Sicherheits-Gateways oder Sensoren überwacht oder administriert, hat in der Regel keinen vollen Zugriff auf die internen Server und Datenbanken seiner Kunden. Das führt dazu, dass die Kunden selbst auf die potenziell betroffenen Systeme schauen müssen. Den Kunden fehlen jedoch sowohl die Werkzeuge als auch das Know-how, um Einbrüche zuverlässig erkennen zu können.

Falls der externe Dienstleister nicht nur die Sicherheitssysteme betreut, sondern auch die gesamte interne IT im Outsourcing verantwortet, vereinfacht das die Situation erheblich - und erst dann könnte ein externes SOC seine eigentlichen Aufgaben auch wirklich erfüllen. Ob der externe Dienstleister dies auch tut, ob er das dafür nötige Personal und die Kompetenz besitzt und ob er die nötige Technik auch aufbaut - all das bleiben offene Fragen.

Servicequalität leidet

Doch auch jenseits der Sicherheitsaspekte hat das vollständige Outsourcing der IT seine Tücken und führt oftmals zu großen Enttäuschungen in Bezug auf die Servicequalität.

Der prinzipiell erreichbare Sicherheitsgewinn eines externen SOC skaliert mit dem Umfang des Outsourcings. Je mehr Rechte und Pflichten ein externes SOC übernimmt, umso mehr könnte es prinzipiell die erhoffte Leistung auch erbringen.

Große Unternehmen sind selbstverständlich auch in der Lage, eigene SOCs aufzubauen, und einige bekannte Firmen haben dies bereits getan oder sind momentan dabei, entsprechende Strukturen zu etablieren oder zu verstärken.

SOC vs. CERT

Vergleicht man die Inhalte und Aufgaben eines SOC mit einem CERT (Computer Emergency Response Team), zeigen sich einige Parallelitäten. Ein CERT wird in Firmen häufig etabliert, um bei Sicherheitsvorfällen klare Rollen und Verantwortlichkeiten definiert zu haben und um auf die nötige Kompetenz zugreifen zu können. Eine Kernfunktion eines CERT ist immer Incident Response. Darüber hinaus übernehmen CERTs häufig auch präventive und planerische Aufgaben, beispielsweise im Verwundbarkeitsmanagement oder in der internen Sicherheitsberatung.

CERTs bilden daher oftmals ein Kompetenzzentrum im Unternehmen, in dem viel Know-how in Bezug auf Schwachstellen, Angriffstechniken und die Analyse von Vorfällen zusammen kommt. Wenn aber tatsächlich ein Vorfall stattfindet, mangelt es den CERT-Teams häufig am Einblick in die verschiedenen IT-Bereiche, Server und Applikationen sowie an Weisungsbefugnis und Durchgriff, um die nötige Arbeit zu erledigen. Gerade die größeren Unternehmen, die sich den Aufbau eines CERT leisten können, stehen mit ihren ausgeprägten Hierarchien beziehungsweise Silostrukturen dem Erfolg eines solchen Teams häufig im Weg. Müssen die Mitarbeiter des CERT beispielsweise bei einem Vorfall zuerst über mehrere Stufen eskalieren, um vollen Zugriff auf eine Datenbank im Rechenzentrum zu bekommen, kostet dies unnötig wertvolle Zeit.

SOC oder CERT? Ein Praktiker im O-Ton

Um Gemeinsamkeiten und Unterschiede von SOC und CERT noch genauer zu verstehen, hat CW-Redakteur Simon Hülsbömer Kai Grunwitz, Vice President Professional Services Central Europe von NTT Com Security, einem Security-Dienstleister, der in Deutschland sowohl SOCs als auch CERTs betreibt, gefragt. Hören Sie seine ausführliche Antwort in folgendem Audioclip: