Security Operations Center (SOC) Organisiert gegen Cyberkriminalität

Das Security Operations Center (SOC) bildet die perfekte Kombination aus innovativen Werkzeugen, effizienten Prozessen und hervorragend ausgebildeten Mitarbeitern, um gegen heutige digitale Bedrohungen gewappnet zu sein. Meist verortet man ein SOC allerdings nur bei großen Konzernen, dabei lohnt sich auch für den Mittelstand die Investition in ein SOC.

Anbieter zum Thema

Vogel IT-Medien GmbH

Arctic Wolf Networks Germany GmbH

SecureLink Germany GmbH

Das Security Operations Center (SOC) bildet die perfekte Kombination aus innovativen Werkzeugen, effizienten Prozessen und hervorragend ausgebildeten Mitarbeitern, um gegen heutige digitale Bedrohungen gewappnet zu sein.

Wer bereits die Gelegenheit hatte, ein Security Operations Center (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 an ihren Arbeitsplätzen. Doch was genau ist notwendig, damit ein SOC seinen Auftrag effizient und effektiv erfüllen kann? Der Erfolg eines SOCs fußt auf drei grundlegenden Säulen: Technologien, Prozesse sowie gut geschulte und motivierte Mitarbeiter.

SOC as a Service

Security Operations Center (SOC) als Dienstleistung

Einer für alle, alle für einen!

Zunehmend wichtiger wird außerdem die Kooperation verschiedener SOCs im Hinblick auf Angriffserkennung und -verteidigung, beispielsweise mit anderen Unternehmen der gleichen Branche. Die Feinde, 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 schon im Ansatz zu erkennen, bevor Schaden entsteht. Je öfter 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.

Über das Transportprotokoll TAXII (Trusted Automated eXchange of Indicator Information) erreichen solche Informationen das SOC und werden in eine Datenbank eingespeist. Mit Hilfe einer Threat Intelligence Plattform wie CRITs (Collaborative Research Into Threats) können die empfangenen Meldungen bearbeitet und mit eigenen Informationen ergänzt werden. Standardisierte Formate wie STIX (Structured Threat Information eXpression) vereinfachen den Im- und Export 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.

SIEM – Das Gehirn des Nervensystems

Das SIEM dient als Sammelstelle für sämtliche Log-Informationen, die im Netz 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 auch ü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 können nie ganz vermieden 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 werden soll, wer angesprochen und informiert werden muss. Runbooks dienen SOC-Mitarbeitern als Handlungsanleitung, um den Incident auf dessen Validität zu analysieren, den Schaden einzudämmen (sog. Containment) und die Auswirkungen des Incidents zu beseitigen (sog. Remediation).

…damit ich dich besser sehen kann!

Für die Analyse, das Containment und die Remediation ist es unerlässlich, so viele Informationen wie möglich über die betroffenen Systeme zu haben. Dabei werden die Analysten des SOCs durch die CMDB (Configuration Management Database) unterstützt. Diese enthält die Informationen darüber, welche Anwendungen auf den Systemen laufen, wer der Owner des Systems ist, welche Kritikalität das System hat und wo dieses System überhaupt steht. Ohne diese Informationen muss sich der Analyst mühsam einen Überblick über das Ausmaß eines Security Incidents verschaffen.

Automation is key! – Eingängige Prozesse erarbeiten

Runbooks können im Übrigen auch 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.

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, weshalb starke Fluktuation der Mitarbeiter vermieden werden sollte. Eine gute Strategie dafür liefert beispielsweise eine Schichtplanung, die eine ausgewogene Work-Life-Balance erlaubt. Ebenso sollte der Arbeitsplatz nicht den SOCs aus Hollywood-Streifen gleichen und sich im dunklen, dritten Untergeschoss eines tristen Betonklotzes befinden. Um abwechslungsreiche Tätigkeiten für die Mitarbeiter sicherzustellen, ist auch ein Rollentausch innerhalb des SOC-Teams denkbar. Die Rollen der 1st und 2nd Level-Analysten sowie die des Schichtleiters können unter den Mitarbeitern flexibel zugeteilt werden. Um dies zu ermöglichen, sind eingängige Prozesse und Prozessbeschreibungen sowie eine funktionierende Tool-Landschaft unabdingbar.

Reale Angriffsszenarien trainieren

Allgemein beschränkt sich die Ausbildung von Analysten auf spezifische Produktschulungen oder Hacking-Kurse, die jedoch nicht vollumfänglich das Incident Handling betrachten. Sinnvoller ist hier ein ganzheitlicheres Konzept: In einer so genannten Cyber Simulation Range trainieren Cyber-Security-Spezialisten im Rahmen eines realen Angriffsszenarios Wissen und Fähigkeiten, um den Kampf gegen Industriespionage, Infrastrukturangriffe und Erpressung zu gewinnen.

Security first!

Schlussendlich hat jedes SOC nur ein Ziel: Die Sicherheit der Organisation zu wahren. Diese Sicherheit lässt sich messen, indem die MTTD (mean time to detect) und MTTR (mean time to resolve) für Security Incidents auf ein Minimum reduziert wird. Aufeinander abgestimmte Tools, Prozesse und Mitarbeiter sind die beste Basis, um das zu gewährleisten. Idealerweise werden die Security Incidents damit erkannt und aufgelöst, bevor Produktionsanlagen still stehen, Transaktionen nicht ausgeführt werden können oder geistiges Eigentum die Organisation verlässt.

Über den Autor: In seiner jetzigen Position ist Johannes Potschies Managing Consultant und Trainer bei iT-CUBE. Seine Schwerpunkte die Themen SIEM & Logmanagement (HPE ArcSight, Splunk) und SOC-Prozesse. Auf diesem Gebiet führte er bereits in zahlreichen nationalen sowie internationalen Projekten die Planung, Implementierung und Betriebsvorbereitung durch. Johannes ist des Weiteren zertifizierter HPE ArcSight Trainer und bildet IT-Security Experten u.a. in folgenden Kursen aus: ArcSight ESM 6.5 Administrator and Analyst – ATP, ArcSight ESM 6.5 Advanced Analyst – ASE, ArcSight ESM 6.5 Advanced Administrator – ASE und ArcSight Logger 6.0 Administration and Operations – ASE. Johannes studierte Informatik mit dem Schwerpunkt Software Engineering an den Hochschulen in Aalen und Mannheim.

(ID:44902379)