Bedrohungserkennung und -abwehr
Mensch und Maschine als Team
In einem Abwehrzentrum (Security Operations Center, SOC) müssen die jeweiligen Stärken maschineller und menschlicher Intelligenz mit Bedacht zum Einsatz kommen. Dies gilt insbesondere beim kritischen Thema der schnellstmöglichen zielführenden Reaktion auf Sicherheitsvorfälle (Incident Response).
"Braucht man für ein Security Operations Center (SOC) denn unbedingt besondere Tools? Geht es nicht auch ohne SIEM (Security-Information- und Event-Management), mit den richtigen Prozessen?" Diese Frage taucht in ersten Sondierungsgesprächen zur komplexen SOC-Thematik immer wieder auf. Hintergrund ist in vielen Fällen: Ein Unternehmen hat im Rahmen eines Security-Audits erfahren, dass es ihm an Möglichkeiten zur Abwehr von Angriffen fehlt, die sich nicht am Perimeter stoppen ließen.
Nicht nur Prävention
Heute geht man grundsätzlich davon aus, dass es keine noch so gute präventive Sicherheitsphalanx immer verlässlich schafft, jedem gezielten und durchgeplanten Angriff Cyberkrimineller im Vorfeld einen Riegel vorzuschieben. Risiko-Manager nehmen eine gewisse Erfolgsquote von Cyberkriminellen als unvermeidlich an und machen den Unternehmen deshalb den Aufbau eines SOCs gern zur Pflicht. Nun fragen sich die Betroffenen, ob sie ein permanentes Security-Monitoring nicht auch manuell hinbekommen könnten. Schließlich verfügen sie fast immer längst über eine ganze Reihe von Sicherheitssensoren im Netzwerk: Firewalls, Router, Intrusion-Detection- und -Prevention-Systeme, Virenschutz, Identitäts-Management und die Anwendungen selbst liefern Informationen über sicherheitsrelevante Vorgänge. Wäre es nicht zu schaffen, all diese Daten einfach sorgfältig und konsequent auszuwerten?
Monitoring ist Maschinensache
Theoretisch ginge das, und tatsächlich gab es in der Vergangenheit SOCs, bei denen man die Konsolen der diversen Security-Tools einfach in einem Raum zusammenfasste und von spezialisierten Mitarbeitern permanent beobachten ließ. In modernen, komplexen Umgebungen allerdings überfordert allein schon die Datenmenge an jeder einzelnen Konsole den dort platzierten Mitarbeiter dabei, tatsächlich alle relevanten Anomalien zu erkennen. Unzureichende oder zu langsame Log-Bearbeitung war in den vergangenen Jahren beispielsweise einer der Hauptgründe, warum Prüfungen der sicheren Verarbeitung von Kreditkartendaten (PCI-DSS-Audits) scheiterten: Die Spezialisten für die einzelnen Systeme schafften es nicht einmal, den Alarmen, Incidents und Events ihrer jeweiligen Einzelsysteme in einem vertretbaren Zeitrahmen auf den Grund zu gehen.
Erschwerend kommt hinzu, dass sich moderne Angreifer genau diese Schwäche zunutze machen. Sie halten ihre Einzelaktionen so unauffällig und gehen genau so langsam und bedächtig vor, dass die Einzelsensoren häufig nicht einmal anschlagen, weil ihre Schwellenwerte generell oder aufgrund des weit auseinandergezogenen Zeitverlaufs nicht erreicht werden. Dass etwas Gefährliches im Gange ist, würde sich erst aus der Gesamtschau der Vorgänge im Netz ergeben. Unser oben beschriebenes manuell arbeitendes SOC-Team würde beispielsweise nur dann etwas von einem solchen Vorgehen merken, wenn sich die Mitarbeiter permanent selbst über kleinste Auffälligkeiten austauschen würden: Leicht erhöhte Fehlanmeldezahlen hier, ein paar seltsame Erscheinungen an der Firewall dort, am Ende eine für sich harmlose Konfigurationsänderung am Router ergeben zusammengenommen möglicherweise eine Angriffsstrategie, die bei bestimmten Ressourcen einen Datendiebstahl einleiten könnte.
Genau solche Konstellationen zu entdecken ist die Aufgabe der "Korrelations-Engines" von SIEM-Systemen. Diese Werkzeuge gleichen permanent und fast in Echtzeit die Logdaten diverser Informationsquellen im Netz untereinander ab und reagieren dabei auf Verhaltensmuster, die auf Angriffe hindeuten. Ihr Vorteil ist, dass sie schnell sind, alle Daten zugleich "sehen" und beim Monitoring nicht ermüden. Informationen darüber, welche Phänomene zusammengenommen Anzeichen eines Angriffs sein könnten, erhalten sie entweder von ihren Herstellern in Form von Regeln, die man aus der Analyse von realen Vorfällen gewonnen hat, oder die Anwender definieren ihnen bekannte potenziell gefährliche Vorgangsketten selbst.
Bei der Erkennung komplexer Anomalien sticht also selbst die rudimentäre künstliche Intelligenz der SIEM-Systeme menschliche Fähigkeiten aus. Bei Anwendern, die dies erkennen, weckt der Erfolg der Technik dann aber oft auch eine zweite Hoffnung: "Können wir auch die konkrete Abwehr damit automatisieren?"
Response erfordert Teambildung
Der Hintergrund: Auch die Abarbeitung der Vorfallhinweise, die ein SIEM-System ausgibt, kostet eine IT-Organisation viel Arbeit und Zeit. Was nicht unmittelbar auf eine hoch brisante Gefahr hindeutet, wird gewöhnlich nach vorgegebenen Kriterien vorsortiert und über automatisierte Schnittstellen ins Incident-Management-System des Unternehmens eingespeist. Dort erzeugt es Tickets, die dann der Bearbeitung durch Major-Incident-Manager, Minor-Incident-Manager oder Spezialisten für besondere Sicherheitsthemen harren. Auch hier also kann wieder ein Security-Flaschenhals entstehen - und dieser wirkt sich besonders bitter aus, wenn das SIEM-System anhand der hinterlegten Risiko- und Kontextinformationen einen Alarm auslöst und das SOC-Team damit allein schon durch das Arbeitsaufkommen überfordert ist.
Die Automation der Incident-Response-Funktionen im SOC hat allerdings Grenzen. Technisch ist es durchaus machbar, SIEM-Output direkt zur Auslösung von Abwehrmaßnahmen zu nutzen und beispielsweise angegriffene Systeme kurzerhand herunterzufahren oder vom Netz zu trennen. In Umgebungen, in denen absolut feststeht, dass der Ausfall eines Endgeräts keine schwerwiegenden Folgen für die Geschäftstätigkeit hat - etwa in reinen Office-Umgebungen mit Windows-PCs, in denen die Arbeitsergebnisse nicht zeitkritisch sind - ließe sich dies auch durchaus hier und da verantworten. In kritischen Infrastrukturen allerdings oder in einer Produktionsumgebung, die auf Just-in-Time-Abläufen basiert, kann ein entsprechender Eingriff mitunter schwerwiegendere Folgen haben als der Angriff selbst.
Ob dies der Fall ist, lässt sich dabei meist nicht einmal absolut definieren, sondern hängt von komplexen Konstellationsgeflechten ab - kann man auf einen bestimmten Service zu einem gegebenen Zeitpunkt vielleicht noch schlechter verzichten als sonst? Muss ein bestimmtes Ziel unbedingt so schnell wie möglich erreicht sein? Oder liegen andere Bedingungen vor, die eine gewöhnlich sinnvolle Abwehrmaßnahme zum gegebenen Zeitpunkt hoch riskant machen?
Abgesehen davon fehlt maschineller Korrelation der "gesunde Menschenverstand". Anomalien etwa müssen nicht immer auf schädlichen Aktivitäten beruhen. Eine Maschine kommt von sich aus nicht darauf, dass sich plötzlich ändernde Datenströme oder die massenhafte Anmeldung neuer Personen an einem bestimmten System mit der Aufnahme der Herstellung eines neuen Produkts zusammenhängen könnten - oder die Folge eine Akquisition, vielleicht lediglich einer Marketing-Aktion sind. Menschen nehmen solche Informationen beiläufig aus den unterschiedlichsten Quellen bis hin zum informellen Gespräch an der Kaffeemaschine auf, der Technik fehlt es dazu an adäquater Sensorik.
Sorgfältige Planung vonnöten
Aus diesen Überlegungen folgt, dass es auch für die Incident Response ein Risiko-Assessment geben sollte, bevor man in diesem Bereich Prozesse automatisiert. Je individueller und geschäftskritischer Systeme einer Umgebung sind, desto wichtiger ist es, dass menschlicher Sachverstand mit intimen Kenntnissen der Umgebung jeden Vorschlag einer Reaktion bewertet, bevor sie zur Ausführung gelangt. Dies setzt übrigens nicht nur der Automatisierbarkeit Grenzen, sondern auch den Möglichkeiten, entsprechende Tätigkeiten komplett Outsourcing-Anbietern zu übergeben.
Seriöse Anbieter von SIEM-Systemen werden aus diesen Gründen mit ihren Anwendern die Response-Prozesse grundsätzlich sorgfältig planen und anhand von Risikobewertungen individuelle, arbeitsteilige Prozesse aufsetzen. Für die Anwender bedeutet dies auch, dass sie um bestimmte Faktoren wie die Einrichtung von Rufbereitschaften und der dazu passenden Kommunikationsmatrix nicht herumkommen. Personalkosten und Arbeitslast lassen sich heute weit eher im Bereich der Bedrohungserkennung reduzieren als im Bereich der aktiven Abwehr aufgedeckter Gefahren.
Hier ist es in der IT nicht anders als in der Alltagswelt: Kameras, Rauch- und Bewegungsmelder sparen heute sicherlich nächtliche Patrouillengänge ein, aber die Feuerwehrmannschaft im Ort zu reduzieren - das wäre ein weit problematischerer Ansatz.
Lesen Sie mehr zum Thema
