Security-Information- und Event-Management
Cloud + SIEM = Planungsbedarf
Hebt die Unternehmens-IT ab in die Cloud, ist ausgefeiltes Security-Information- und Event-Management (SIEM) eine gute Ergänzung. Bei der Konzeption allerdings tappen Anwender zuweilen in Fallen. Ein wirklich wirksames Wolken-SIEM bekommt nur, wer ein paar logische Rätsel löst, beim Aufbau der zugehörigen Lösungen "hybrid" vorgeht und die Fachabteilungen einbindet.War das nicht gestern erst, als wir SIEM-Systeme noch als "Raketentechnik" titulierten und darüber philosophierten, wie viele internationale Großkonzerne sich die komplexen Systeme wohl würden leisten können und wollen? Jetzt geht es der IT-Welt damit so ähnlich wie weiland dem IBM-Chef Thomas Watson, der 1943 den weltweiten Bedarf an Computern auf fünf Exemplare schätzte: SIEM boomt plötzlich allerorten. Der Trend zum Outsourcing von IT-Infrastrukturen und zur Cloud ist zu einem wichtigen Treiber für diesen Markt geworden, dessen Wachstum von Kunden- und Anbieterseite zugleich befeuert wird: Anwender, die sich einen SIEM- und SOC-Aufbau (Security Operations Center) für die selbst betriebene IT gar nicht zugetraut hätten, verlangen solche Systeme und Instanzen gern als Zugabe von Outsourcing-Anbietern, sobald sie ihre Infrastruktur in fremde Hände geben. Die Anbieter wiederum bringen SOC und SIEM nur allzu gern in Spiel, weil aus ihrer Perspektive ein entsprechender Security-Service eben immer häufiger das entscheidende Kriterium für die Auftragsvergabe darstellt und außerdem SIEM als Managed Service eine gute Einnahmequelle ist. Als Ergebnis findet man heute durchaus Umgebungen, in denen bereits zwei oder gar drei SIEM-Implementierungen vorhanden sind und irgendwie an ein zentrales SOC berichten sollen: ein SIEM etwa für die ausgelagerte Basisinfrastruktur, eines für die intern belassenen hochwichtigen Systeme ("Kronjuwelen") und eines schließlich für die vielleicht schon seit längerer Zeit fremdbetriebene Endanwenderumgebung oder für irgendein Spezialkonstrukt, etwa die Produktion oder ein Netzwerksegment mit Kreditkartendaten. Also alle glücklich? Je mehr SIEM, desto sicherer? "Es kommt drauf an", lautet die Antwort. Gerade im Zusammenhang mit der Cloud nämlich zeigt SIEM gern seine komplizierten Seiten. Zwei davon sind Thema dieses Beitrags: Er soll erstens zeigen, dass das Outsourcing von SIEM-Systemen niemals eine vollständige Auslagerung des Incident- und Event-Managements bedeuten kann, und er wird sich zweitens damit befassen, wie man mehrere SIEM-Implementierungen so miteinander kombiniert, dass sie sich in ihrer Wirksamkeit nicht gegenseitig beschneiden. Der Zauber der Korrelation Um erklären zu können, warum SIEM-Systeme in den beschriebenen Zusammenhängen nach intelligenter Planung verlangen, ist zunächst ein genauer Blick auf das Konzept hinter den Lösungen nötig. Ein SIEM-System sammelt Sicherheitsinformationen aus unterschiedlichen Quellen und versucht, Beziehungen zwischen ihnen herzustellen, um so mögliche komplexe Angriffe aufzudecken. Dieses Verfahren ist die Korrelation: Während einzelne Sicherheitssensoren im Netzwerk nur Vorgänge an ihrer Position auswerten und gegebenenfalls in einen Alarm umsetzen können (Firewall oder Intrusion-Detection-System "sieht" einen Hacking-Versuch, Virenschutz spürt eine Malware auf, Authentifizierungssystem der Kundendatenbank registriert immer wieder misslingende Anmeldeversuche eines bestimmten Anwenders), nimmt die Engine einer SIEM-Lösung größere Zusammenhänge war. Ein Beispielfall: Es gibt eine nur geringe Zunahme von Fehlanmeldungen an einer zentralen Anwendung; deren Authentifizierungssystem selbst stuft dies noch als harmlos ein; zugleich aber tritt ein von Virenschutz automatisch abgewehrtes "Trojanisches Pferd" auf, zudem ein paar ebenfalls wenig aufregende Anomalien an der Firewall oder im Datenstrom. Hat man dem SIEM-System beigebracht, dass dies auf einen laufenden, anderswo bereits aufgetretenen komplexen Angriff schließen lässt, kann sie auf ihrer höheren technischen Intelligenzebene Alarm schlagen. Außerdem kann man einem solchen System auch unternehmensspezifische Korrelationsregeln an die Hand geben - die etwa besagen, dass ein ganz bestimmtes, gut abgeschirmtes System vermutlich auf ganz bestimmten Wegen mit einem Satz ganz bestimmter Schritte angegriffen werden dürfte. SIEM ist also ein neues und durchaus wirksames Mittel gegen "Blended Threats" (auf Deutsch etwa: miteinander verwobene Bedrohungen) und gezielte Angriffe. Als automatisierte Systeme entlasten SIEM-Lösungen die Menschen außerdem von der für sie mühevollen Aufgabe, im permanenten Grundrauschen der hoch komplexen IT-gestützten Kommunikation durch stundenlanges Logfile-Studium nach Anomalien zu suchen, die sich nur aus der Betrachtung vieler Quellen erschließen. Tatsächlich stecken die Gründe für die oben beschriebenen Problembereiche bereits in dieser an sich einfachen Basisbeschreibung der SIEM-Funktionen. Für den ersten Punkt muss - man nehme dem Autor das nicht übel - zunächst eine penible Begriffsdefinition her. "Wir haben von HP (Arcsight), IBM (Qradar) oder Logrhythm (oder einem anderen Anbieter) ein SIEM implementiert", hört man Security-Spezialisten heute zuweilen sagen. Dies ist eigentlich falsch: Was die Anwender von den Firmen beziehen, sind nämlich nur Tools, die einen Teil des SIEMs unterstützen. "SIEM" bedeutet, wenn man es genau nimmt, das Management von Sicherheitsvorfällen, und zwar technisch, organisatorisch und als Prozess, der mit dem Bewältigen akuter Vorkommnisse noch lange nicht aufhört, sondern zum Beispiel auch abgeleiteteten Input für periodische Aufgaben des Risiko-Managements umfasst. SIEM in diesem Sinne speist zudem auch andere sicherheitsbezogene PDCA-Zyklen (Plan-Do-Check-Act, zum Beispiel für die Priorisierung von Investitionen) und die Dokumentation für potenzielle forensische Zwecke. SIEM ist eine Untermenge des übergeifenden Sicherheits-Managements, wie man es einführt, um beispielsweise ISO 2700x- oder PCI-DSS-Compliance zu erreichen oder gehobenen Datenschutzanforderungen zu genügen. Die oben genannten SIEM-Werkzeuge übernehmen und optimieren in diesem Konstrukt nur das bereits erwähnte Scannen der Sicherheitsmeldungen nach von Einzelsensoren durchgereichten oder übergreifenden Merkmalen, die einen Alarm auslösen und damit Security Incident oder Event werden. Aber dann? Soll ein SIEM-Produkt dann auch selbsttätig Gegenreaktionen auslösen? Produzierende Unternehmen und vor allem Betreiber kritischer Infrastrukturen wie Wasser- und Stromlieferanten fürchten dieses Szenario nicht zu Unrecht fast mehr als die heute gängigen Angriffe selbst. Für sie kann es wichtig sein, betroffene Bereiche notfalls noch Stunden am Laufen zu halten, um die Versorgung bestimmter Kunden nicht unterbrechen zu müssen oder durch Reputationsverlust größere Einbußen zu erleiden als durch direkte Folgen des Sicherheitsvorfalls selbst. Viele Anbieter bieten SIEM-Outsourcing ohne Managed-SOC-Services deshalb gar nicht erst an. Hat das SIEM-Werkzeug seinen Alarm ausgelöst, bringen sie Menschen ins Spiel. Denn die Technik ist besser als ein Mensch darin, deduktiv in einer Masse vorbeirauschender Informationen ermüdungsfrei mehrdimensionale Abweichungen zu erkennen. Dennoch schafft sie es keineswegs, induktiv kreative Maßnahmen einzuleiten, die - in einem komplexen Geflecht aus technischen, organisatorischen, wirtschaftlichen und womöglich gesellschaftlichen Bedingungen - zugleich maximale Wirkung und minimale Nebenwirkungen zeigen. Um das zu schaffen, muss der SOC-Operator erst selbst intensiv nachdenken und sich dann höchstwahrscheinlich mit einer ganze Reihe an Security-Spezialisten, Vertretern der Fachabteilungen und hochrangigen Managern beim Kunden absprechen. Zum Einsatz eines Managed-SIEM-Werkzeugs gehört also eine intelligente Einbindung in die Organisationsstruktur des Anwenders. Deshalb ist solch ein System immer "hybrid": Es lagert bestimmte Funktionen des SIEM-Komplexes aus, muss aber andere zwangsläufig intern besetzen. Und dies betrifft eben nicht nur den spannenden Fall eines tatsächlichen Angriffs und dessen Abwehr. Hier ein paar weitere Beispiele, wie interne und externe Postionen beim hybriden Managed SIEM interagieren: Interne Mitarbeiter helfen bei der Auswahl der Sensoren und Log-Quellen, deren Informationen in ein SIEM-Tool einzuspeisen sind. Es sollen keine relevanten Daten verloren gehen, aber man darf das SIEM-Werkzeug auch nicht überlasten. In großen Unternehmen erreichen allein die Log-Massen nämlich durchaus schon einmal die "Big Data"-Schwelle. Zudem optimieren Mitarbeiter des externen SOCs während des Betriebs eines SIEM-Tools dessen Korrelationsregeln (ebenfalls ein PDCA-Zyklus). Aber bei Änderungen an organisatorischen und wirtschaftlichen Prozessen und damit verbundenen neuen Risikogewichtungen für bestimmte Ressourcen benötigen sie frühzeitige Informationen durch die internen Fachabteilungen. Und schließlich bedingt der schon angedeutete Wert des SIEM-Tool-Outputs für langfristiges Risiko- und Compliance-Management ebenfalls eine bidirektionale Kommunikation zwischen SOC und den genannten Abteilungen. Wie viele und welche Aufgaben jeweils intern verbleiben müssen, extern erledigt werden können oder sogar automatisiert werden dürfen, ist von Anwender zu Anwender verschieden. Als Faustregel kann beispielsweise gelten, dass Anwender mit IT-Umgebungen, die vorwiegend aus Standardgerätschaften und -applikationen bestehen, recht viele Aufgaben an ihren Managed-Service-Anbieter auslagern können. Hier schlägt auch zu Buche, dass in einem solchen Fall das SIEM mit vielen Standardregeln operieren kann, die aus bereits bekannten Vorfällen bei nahezu gleich aufgestellten Organisationen abgeleitet sind. Je spezieller und einzigartiger hingegen die IT-Umgebung und die mit ihrem Betrieb verknüpften Risiken, desto größer ist die Zahl der Aufgaben und Einflussbereiche, die beim Kunden verbleiben sollten. Dies heißt auch: Unternehmen, die wissen, dass es nur wenige vergleichbar aufgestellte Organisationen in der Welt gibt, sollten sich Anbieter von SIEM-Werkzeugen aussuchen, die umfassende Beratung bieten, von sich aus flexible Gestaltungen für hybriden Betrieb aufzeigen und für die intensive Kommunikation zwischen Anwender und externem SOC gerüstet sind. Kombination von SIEM-Systemen Ein zweiter Problembereich ist die Kombination mehrerer SIEM-Systeme. Wieder hilft ein Blick auf die eingangs gelieferte Funktionsbeschreibung, um die Herausforderung zu erkennen: Ein SIEM-Tool soll per definitionem Angriffe erkennen helfen, die eine vom gemeinsamen Organisationszweck zusammengehaltene IT-Umgebung betreffen. Die Angriffe, um die es geht, zielen auf ein Asset oder eine Ressource in einem IT-Verbund und nutzen potenziell alle technischen und kommunikativen Verbindungen, die dieser Verbund auch seinen legitimen Endanwendern zur Verfügung stellt. Diese Verbindungen übergreifen dabei notwendigerweise auch Segmentgrenzen. Es kann durchaus sein, dass sich ein besonders perfidesVorgehen darauf stützt, Informationen aus einem völlig abgetrennten Backoffice-Bereich dazu heranzuziehen, dem eigentlich interessanten Produktions-, Kreditkarten- oder Patientendatenbereich näherzukommen. Seine volle Wirkung erzielt ein SIEM-Tools deshalb theoretisch dann, wenn es Informationen aus dem gesamten IT-Verbund aufeinander beziehen darf. Sogar Meldungen über Social-Engineering-Vorfälle könnte es einbeziehen, wenn man es entsprechend ausrüstet [1, 2]. Einzelne SIEM-Tools nebeneinander zu betreiben steht dem Ziel der detektivischen Gesamtschau entgegen. Sind die jeweils von einem System betreuten Netzwerksegmente oder Ressourcen tatsächlich so stark separiert, dass eine grenzübergreifende Angriffsstrategie völlig unvorstellbar erscheint, kann die Parallelkonstruktion sinnvoll sein; meist exsitieren aber doch signifikante Verbindungen zwischen den Sektoren. Eine Möglichkeit besteht dann darin, alle Funktion an ein einziges Enterprise-SIEM-Werkzeug zu übergeben. In diesem Fall stellt sich allerdings die Frage der maximalen Last an Logdateien und Traffic-Meldungen, die das System verkraftet. Außerdem müssen die Verbindungen zwischen allen Netzwerkbereichen und Rechenzentren eine hinreichende Bandbreite aufweisen, um eine Auswertung aller Daten nahezu in Echtzeit zu ermöglichen, was gerade in Hybrid-Cloud-Umgebungen nicht immer der Fall ist. Mit diesem Aspekt haben schon einzelne Korrelationswerkzeuge ihre Probleme, sie verlagern deshalb je nach Produkt Vorstufen der Korrelation in die Einzelrechenzentren hinein und schicken nur bereits vorgefilterte Ergebnisse weiter an eine zentrale Auswertungskonsole. Auch hat man nichts gewonnen, wenn man eine Architektur mit mehreren SIEM-Tools in eine Variante mit einem einzigen zentralen Werkzeug umwandelt, dann aber aus Kapazitätsgründen - Prozessorleistung, Speicherplatz - wieder Log- und Datenquellen von der Korrelation ausschließen muss. Die Zentraloption ist nur dann im Vorteil, wenn die gewählte Lösung die anfallende Last klaglos bewältigen kann und das Regelwerk für die Korrelation, das eine große Architektur abdecken soll, überschaubar bleibt. Eine zweite Möglichkeit liegt darin, die vorhandenen parallelen SIEM-Implementierungen zu belassen und den Abgleich der Meldungen in einem zentralen SOC menschlichen Spezialisten zu überlassen. Gibt es nur geringe Interaktion zwischen den Infrastruktursegmenten und ihren "Silo-SIEMs", kann auch dies funktionieren. Die speziellen Fähigkeiten der SIEM-Systemtechnik nutzt man hier allerdings nur zum Teil. Den größten Vorteil, aber auch den größten Planungs- und Pflegeaufwand bietet die letzte Option. Hier schaltet man die SIEM-Werkzeuge intelligent zusammen: Jedes korreliert Sicherheitsinformationen für seinen Bereich separat und filtert dabei vor allem Fehlalarme (False Positives) aus; zugleich aber leitet es für das große Ganze interessante Informationen wie eigene Warnungen und spezielle Meldungen von Einzelsystemen an ein übergeordnetes System weiter. Damit dies funktioniert, müssen ein paar Voraussetzungen erfüllt sein: Erstens muss das zentrale System via Regelwerk auf seine spezielle Aufgabe hin optimierbar sein, und der Anbieter sollte mit entsprechenden Konstrukten Erfahrung haben. Zweitens müssen die Regelmechanismen der untergeordneten SIEM-Werkzeuge die Weiterleitungsfunktion anbieten. Drittens gilt es, das Regelwerk (also die Korrelationslogik) der untergeordneten wie auch des übergeordneten Systems auf das for allem logisch komplexe Gebilde mit hohem Aufwand abzustimmen. Dies setzt ein hohes Verständnis für unternehmensspezifische Risiken und mögliche Angriffe auf Einzelsegmente wie auch auf das Gesamtsystem voraus. Gefragt ist hier eine hohe Analysetiefe nicht nur zu Beginn, sondern auch beim stetigen Neujustieren während des Betriebs. Nicht jedes Unternehmen kann dies leisten - oder es sich leisten, diese Aufgaben extern zu vergeben. Wie die optimale Konstruktion aussieht und was "gut genug" ist, variiert von Anwender zu Anwender und sollte vorab mit erfahreren SIEM-Architekten diskutiert werden. "SIEM- und SOC-Consulting" heißt das entsprechende Angebot im Fachjargon. Es wahrzunehmen ist mitunter lohnender, als die ohnehin nicht billigen SIEM-Lösungen und -Services einfach im Mehrfachpack oder mit Maximallleistung zu ordern. Quellen [1] Bettina Weßelmann und Johannes Wiele, "?Human Factor?-Sensoren für SIEM", in KES 4/2014, S. 6-12. [2] Bettina Weßelmann und Johannes Wiele, Vortrag RSA-Conference San Francisco 2014: "A Human Factor Interface for SIEM", www.rsaconference.com/events/us14/agenda/sessions/935/a-human-factor-interface-for-siem
Lesen Sie mehr zum Thema
