Cyber Incident Handling Kernfähigkeiten eines Security Operations Center (SOC)

Wer bereits die Gelegenheit hatte, ein SOC in Augenschein zu nehmen, dem bleiben meist eine Reihe von Details gut im Gedächtnis: physische Sicherheitsmaßnahmen am Eingang, bunte Dashboards und Diagramme auf einem großen zentralen Monitor und hochkonzentrierte Analysten vor ihren Bildschirmen. Doch was genau ist notwendig, damit ein SOC seinen Auftrag erfüllen kann?

Anbieter zum Thema

TXOne Networks

Arctic Wolf Networks Germany GmbH

Eye Security GmbH

SecureLink Germany GmbH

Bei einem Security Operations Center (SOC) handelt es sich um eine Verteidigungseinheit, bestehend aus IT-Sicherheitsspezialisten, deren Aufgabe die Erkennung und Abwehr von Cyberbedrohungen ist. Der Erfolg eines SOC fußt auf drei grundlegenden Säulen: Technologien, Prozesse sowie gut geschulte und motivierte Mitarbeiter. Zunehmend wichtiger wird außerdem die Kooperation verschiedener SOCs im Hinblick auf Angriffserkennung und -verteidigung, beispielsweise mit anderen Unternehmen der gleichen Branche.

Der Feind, die sog. Threat Actors, haben den Mehrwert von Kooperationen längst erkannt. Der Austausch und Handel von Informationen, Schwachstellen und Angriffstools floriert prächtig. Genau das ist es allerdings auch, was den konstanten Informationsaustausch für ein SOC so interessant macht. Seien es neu entdeckte Sicherheitslücken, für Malware bekannte Domains oder auch typische Vorgehensweisen der Angreifer. All diese Informationen (Threat Intelligence) unterstützen ein SOC dabei, einen Angriff zu erkennen, bevor echter Schaden entsteht. Je öfter diese Muster auftreten, desto einfacher werden sie identifiziert und abgewehrt. Im Idealfall ist der damit verbundene Incident noch nicht im eigenen Unternehmen aufgetreten, sondern in einem, mit dem ein solcher Informationsaustausch praktiziert wird.

Bildergalerie

Über das treffend benannte Transportprotokoll TAXII (Trusted Automated eXchange of Indicator Information) erreichen genau solche Informationen das SOC und werden in eine Datenbank eingespeist. Mit Hilfe einer Threat Intelligence Plattform wie z.B. CRITs (Collaborative Research Into Threats) können die empfangenen Meldungen bearbeitet und mit eigenen Informationen zusätzlich angereichert werden. Standardisierte Formate wie z.B. STIX (Structured Threat Information eXpression) vereinfachen den Im- und Export dieser Informationen hin zu den aktiven Security-Komponenten des Netzwerks. Die meisten Firewalls, Endpoint Security Systeme und SIEMs (Security Information and Event Management) unterstützen STIX und können so von den SOC-Mitarbeitern direkt mit den relevanten Informationen gefüttert werden.

Relevantes erkennen, Angriffe verhindern

Das SIEM dient gleichzeitig als Sammelstelle für sämtliche Log-Informationen, die im Netzwerk des Unternehmens von Netzwerkgeräten, Servern und Applikationen erzeugt werden. Die Informationen werden an diesem zentralen Ort in so genannten Detection Use Cases korreliert, um verdächtige Muster in der Fülle dieser Ereignisse und sogar über einen längeren Zeitraum zu erkennen. Damit werden bereits bekannte Angriffsmuster direkt dort erkannt, wo sie auftauchen, und sofort mit einem Alarm oder einer automatischen Aktion versehen.

Allerdings gilt auch (und insbesondere) bei Informationen externer Anbieter, die über TAXII bereitgestellt werden: Nicht jede Meldung ist automatisch ein Angriff. False Positives machen SOC-Mitarbeitern das Leben schwer und blockieren Ressourcen, die für die Bearbeitung echter Angriffe benötigt werden. Es braucht Erfahrung und ein geregeltes Vorgehen, um wirklich jeder Meldung die benötigte Aufmerksamkeit entgegenzubringen.

Um dieses Vorgehen und den Betrieb im Allgemeinen zu optimieren und zu standardisieren, müssen Prozesse an die Technologien angeknüpft werden. Runbooks innerhalb des Security-Incident-Response-Prozesses sind ein konkreter Teil davon. Über diese Anleitungen wird genau festgelegt, welche Reaktion einem Vorfall zu folgen hat, was im Detail analysiert, wer angesprochen und informiert werden muss. Runbooks dienen zum einen dem SOC-Mitarbeiter als Handlungsanleitung, um den vermeintlichen Incident auf dessen Validität zu analysieren, um den Schaden durch den Security Incident einzudämmen (sog. Containment) und um die Auswirkungen des Incidents zu beseitigen (sog. Remediation). Zum anderen können Runbooks in Incident-Response-Werkzeuge implementiert werden, um dem Mitarbeiter einen Großteil der manuellen Aufgaben abzunehmen. Das Incident-Response-Werkzeug dient damit als Schaltzentrale für die Bearbeitung des Incidents und ermöglicht die Ansteuerung verschiedenster Security-Tools über definierte Schnittstellen.

Mitarbeiter sind mehr als nur Ressourcen

Prozesse, Runbooks und auch Incident Response Tools sind Hilfestellungen für die Mitarbeiter im SOC. Für die Einschätzung der Validität und Kritikalität eines Incidents und dessen Abarbeitung bedarf es trotzdem großer Erfahrung. Es gilt also, die Fluktuation unter den Mitarbeitern besonders gering zu halten. Dies kann erreicht werden, indem beispielsweise eine sinnvolle Schichtplanung eine ausgewogene Work-Life-Balance erlaubt oder der Arbeitsplatz nicht den SOCs aus Hollywood-Streifen gleicht und sich im dunklen, dritten Untergeschoss eines tristen Betonklotzes befindet. Um abwechslungsreiche Tätigkeiten für die Mitarbeiter sicherzustellen, sind sogar Rollentausche innerhalb des SOC-Teams denkbar. Die Rollen der 1st und 2nd Level-Analysten sowie die des Schichtleiters könnten unter den Mitarbeitern flexibel zugeteilt werden. Um dies zu ermöglichen, sind eingängige Prozesse und Prozessbeschreibungen sowie eine funktionierende Tool-Landschaft unabdingbar.

Doch wie kann festgestellt werden, ob das SOC gut funktioniert? Eine Vielzahl so genannter KPIs (Key Performance Indicators) – oder auch Kennzahlen – erlaubt eine Beurteilung der Effizienz und Effektivität von Technologien, Prozessen und Mitarbeitern. Wichtig ist hierbei die Betrachtung der Kennzahlen im richtigen Kontext. Eine alleinige Messung der bearbeiteten Incidents ist wenig aussagekräftig. Vielmehr muss beispielsweise diese Betrachtung im Verhältnis zur Gesamtzahl und der Schwere der jeweiligen Incidents und auch der Anzahl der Mitarbeiter im SOC durchgeführt werden. Die wichtigste Kennzahl für die Effektivität des SOCs ist jedoch die so genannte MTTD (Mean Time to Detect): Wie lange dauert es, bis ein Angriff erkannt wird? Daran schließt sich direkt eine weitere sehr wichtige Kennzahl an – MTTR (Mean Time to Resolution): Wann wurde der Incident behoben? Kennzahlen dieser Art lassen sich für jede der drei Säulen – Technologien, Prozesse und Mitarbeiter – finden.

Diese und weitere Kennzahlen helfen bei der Optimierung der Technologien und Prozesse und erlauben außerdem die Erstellung individueller Weiterbildungskonzepte für die einzelnen Mitarbeiter im SOC-Team. So ist es möglich, den Reifegrad des SOC zu erhöhen und damit die Effektivität und Effizienz nachhaltig zu steigern.

* Johannes Potschies ist Managing Consultant und Trainer bei iT-CUBE.

(ID:44525281)