Es gilt als Tatsache anerkannt, dass das Auftreten von Sicherheitsverletzungen heute leider nur noch eine Frage der Zeit ist. Deshalb gilt es, die Kunst zu beherrschen, die daraus erwachsenden negativen Auswirkungen auf ein Minimum zu reduzieren und gravierende Folgen zu verhindern. Mit anderen Worten, die Detektion von Sicherheitsvorfällen, der geeignete Umgang damit und ein wirkungsvoller Verbesserungsprozess sind wichtiger denn je.

Immer mehr Organisationen setzen deshalb als Teil ihrer Cybersecurity-Strategie auf die Leistungen eines Security Operations Center (SOC), sei dies indem sie selbst eines betreiben oder entsprechende Dienstleistungen in Anspruch nehmen. Ein SOC kann durch das Erkennen von Sicherheitsbedrohungen, das Umsetzen von präventiven Massnahmen und durch den Umgang mit Vorfällen einen wertvollen Beitrag zur Aufrechterhaltung und Wiederherstellung eines angemessenen Sicherheitsniveaus leisten. Dieser Beitrag beleuchtet die für ein effektives SOC erforderlichen Voraussetzungen und seine notwendigen Fähigkeiten.

Ein SOC auszubauen und zu betreiben ist kein einfaches Unterfangen, auch wenn in mancher Hinsicht schon mit vergleichsweise einfachen Mitteln viel zu erreichen ist. Ein Grund dafür liegt darin, dass für ein funktionierendes SOC organisatorische und technische Voraussetzungen erfüllt sein müssen, die selbst schon eine Herausforderung sein können. Ein SOC kann nur auf der Grundlage eines gewissen Mindestmasses an Informationssicherheit erfolgreich sein. Dies schliesst unter anderem einen durchgängig umgesetzten Grundschutz, ein vollständiges Asset-Verzeichnis und solide Policies ein.

Was ist das SOC?

Im Kontext des vorliegenden Beitrags wird der Begriff SOC folgendermassen verstanden:

Ein SOC ist ein Dienstleistungszentrum, das diejenigen Prozesse, Technologien und personellen Ressourcen umfasst, welche mittels laufender Zustandsüberwachung der informationsverarbeitenden Systeme unerwünschte Aktivitäten oder Zustände entdecken, darauf reagieren und daraus erwachsende schädliche Wirkungen verhindern oder minimieren.

Ein SOC kann entweder eine Abteilung innerhalb einer Organisation sein, von einem externen Dienstleister betrieben werden oder eine Mischform davon sein.

Voraussetzungen für ein effektives SOC

Wie auch in anderen Bereichen der IT werden hinsichtlich notwendiger Faktoren eines SOC die Dimensionen personelle Ressourcen, Prozesse und Technologien unterschieden. Deren funktionierendes Zusammenspiel ist gerade für ein SOC besonders bedeutungsvoll. Die Auswirkungen entsprechender Mängel sind in der folgenden Grafik verdeutlicht:

Darüber hinaus kommt der Organisation, für die das SOC tätig ist, eine wesentliche Bedeutung zu. Die vielleicht wichtigste organisatorische Voraussetzung besteht in klar formulierten und kommunizierten Erwartungen an das SOC, also einem klar definierten Leistungsauftrag. Dieser Auftrag sollte von einer hohen Management-Ebene oder bei öffentlichen Organisationen von einer geeigneten politischen Ebene festgelegt sein und kann einen gesetzlichen oder regulatorischen Hintergrund haben.

Der Leistungsauftrag sollte mindestens folgendes beinhalten:

• Definition der Kunden des SOC, also der internen oder externen Zielgruppen, für die das SOC tätig ist
• Definition der Befugnisse des SOC. Es muss klar geregelt sein, zu welchen Aktionen das SOC autorisiert ist, wobei das Spektrum von einer rein beratenden Rolle bis zur Durchsetzung von Massnahmen und Eingriffen in Systeme reicht.
• Service-Katalog, der alle Dienste des SOC wie Incident Response, Vulnerability Handling, Malware-Analyse, usw. auflistet, einschliesslich einer Angabe der Service Levels.

Damit ein SOC seine Tätigkeiten erfolgreich durchführen kann, ist hinsichtlich Informationssicherheit eine gewisse Mindestmaturität der Organisation erforderlich. Dies beinhaltet unter anderem folgendes:

• etablierte Grundsätze zu Aufbau und Aufrechterhaltung der Informationssicherheit, Datenhaltung und -bearbeitung (Governance)
• geeignete Policies und Richtlinien hinsichtlich IT und Informationssicherheit
• eine Datenklassifizierung und ein entsprechend umgesetzter Grundschutz, idealerweise auf der Basis eines etablierten Frameworks wie dem NIST CSF
• regelmässige Beurteilung der Effektivität der technischen und organisatorischen Massnahmen
• ein Verzeichnis aller IT-Assets (Systeme, Infrastrukturkomponenten, Software, usw.)

Welche Ressourcen, Prozesse und Technologien braucht es?

Die folgenden Abschnitte gehen auf die minimal notwendigen Elemente eines SOC in den genannten drei Dimensionen näher ein.

Personelle Ressourcen

Die für den Erfolg eines SOC vielleicht wichtigste Ressource sind seine Mitarbeiter. Leider herrscht häufig ein Mangel an qualifizierten Fachkräften; ein Umstand, den man in der Regel mittels Ausbildungen und Training, aber auch dem Einsatz von technischen Hilfsmitteln (Automatisierung und Orchestrierung, maschinelles Lernen, künstliche Intelligenz) zu mildern sucht. Obwohl die heute verfügbaren Hilfsmittel inzwischen sehr leistungsfähig sind und laufend mächtiger werden, vermögen sie menschliche Fähigkeiten (noch) nicht vollständig zu ersetzen. Eine ausreichende Anzahl qualifizierter Fachpersonen, in der Regel mindestens zwei bis drei, ist deshalb unbedingt nötig.

Prozesse

Als Dienstleistungszentrum ist das SOC notwendigerweise eng mit seinen Kunden verbunden. Die entsprechenden organisatorischen und technischen Schnittstellen und die zugehörigen Prozesse sind enorm wichtig, müssen klar definiert sein und vor allem im Ernstfall reibungslos funktionieren. Die meisten SOC-Prozesse berühren direkt oder indirekt eine oder mehrere solcher Schnittstellen, ein weiterer wichtiger Grund, das SOC als Teil des Ganzen zu betrachten. Die hauptsächlichen Prozesse betreffen folgende Themen:

• Abläufe zur Eskalation ins Management, zu Legal und Compliance und zum HR
• Beizug von Unterstützung, seien dies interne Fachstellen ausserhalb des SOC oder externe Expertise, beispielsweise für Spezialthemen wie Forensik oder Malware-Analyse oder allgemein für das Incident Management
• eine Schnittstelle zum Enterprise Risk Management
• organisationsinterne und externe Kommunikationsprozesse und damit verbunden die Pflege einer umfassenden Kommunikationsmatrix mit allen notwendigen Kontaktinformationen
• sogenanntes Threat Modeling, also das Erstellen von organisations- und situationsspezifischen Bedrohungsmodellen
• darauf basierende Überwachung, Triage und Alarmierung
• Vorgehen für die Analyse von Vorfällen und deren Einstufung hinsichtlich Auswirkungen und Dringlichkeit
• Incident Handling, also das Vorgehen des SOC bei tatsächlichen Sicherheitsvorfällen
• Wiederherstellen des Normalzustandes
• Sicherstellen einer lückenlosen Nachvollziehbarkeit der SOC-Prozesse

Mit den Überlegungen zu den Bedrohungsmodellen lassen sich folgende Fragen beantworten:

• Welche Bedrohungen sind für die Organisation überhaupt relevant?
• Wogegen sollen Vorkehrungen getroffen werden?
• Wie manifestieren sich diese Bedrohungen auf technischer Ebene?
• Wie und mit welchen Werkzeugen kann das SOC diese Bedrohungen detektieren?
• Wie können entsprechende Angriffe abgewehrt oder unschädlich gemacht werden?
• Welche präventiven Massnahmen können ergriffen werden?

Daraus ergeben sich wertvolle Erkenntnisse, mit deren Hilfe vordefinierte Abläufe für die als relevant eingestuften Angriffe und das entsprechende Incident Handling erstellt werden können. Diese Playbooks spielen eine zentrale Rolle beim effektiven und effizienten Umgang mit Vorfällen wie dem Ausbruch von Malware, DDoS-Angriffen, festgestelltem Datenabfluss, usw. aber auch bei den Verfahren zur Wiederherstellung des Soll-Zustands.

Technologien

Die wichtigsten technischen Bereiche eines SOC sind:

• Eine Plattform mit Sicherheitsinformationen (Security Intelligence)
• Werkzeuge zur Untersuchung und Analyse von Vorfällen
• Ein vollständiges und aktuelles Verzeichnis aller IT-Komponenten (Asset Database), einschliesslich der entsprechenden Zuständigkeiten und Kontaktinformationen. Schützen kann man Systeme nur, wenn man von ihrer Existenz weiss.
• Ein System zum Erfassen, Verwalten und Dokumentieren von Sicherheitsvorfällen und zugehörigen Abläufen (Incident Management System)

Die Informationsplattform ist meistens ein klassisches SIEM oder bietet zumindest einen Teil der entsprechenden Funktionen, kann aber auch ein gut konfiguriertes Logmanagement-System mit geeigneten Monitoring-Regeln sein. Wichtig hierbei ist die Integration möglichst aller relevanten Informationsquellen aus der gesamten Organisation, sicher aber folgende:

• Sicherheitsrelevante Aktivitäten aller Endpoints, d.h. nicht nur der Arbeitsstationen der Benutzer
• Sicherheitsrelevante Aktivitäten im Netzwerk (Netzwerkverkehr, Firewall-Logs, Proxy Logs, Vulnerability Scans, usw.)
• Authentisierungs- und Autorisierungsvorgänge (LDAP, Active Directory, VPN, usw.)

Diese Informationen werden idealerweise durch externe Informationsquellen wie Threat und Vulnerability Feeds ergänzt.

Für den Fall, dass die üblichen Kommunikationsmittel nicht zur Verfügung stehen oder deren Verwendung während eines Vorfalls nicht erwünscht ist, empfiehlt es sich, alternative Kommunikationsmittel (out-of-band) wie Mobiltelefone verfügbar zu halten. Die entsprechenden Kontaktmöglichkeiten sollten auch den Kunden des SOC bekannt sein. In diesem Zusammenhang muss auch die Möglichkeit einer Reserveverbindung ins Internet erwogen werden, besonders wenn die Geschäftstätigkeiten stark von einer funktionierenden Internetverbindung abhängig sind.

Weiter empfiehlt es sich, Möglichkeiten für forensische Abklärungen bereit zu halten oder den Abruf entsprechender Dienstleistungen vorzubereiten, um deren Einsatzmöglichkeit im Bedarfsfall sicher zu stellen.

Ausserdem ist es aus Gründen der Nachvollziehbarkeit, aber auch für künftige Verbesserungen unabdingbar, die Aktivitäten des SOC aufzuzeichnen, z.B. unter Zuhilfenahme eines vorhandenen Ticketingsystems.

Schliesslich ist es sehr wichtig, die Qualität und die Performance des SOC regelmässig zu messen, um einerseits eine objektive Grundlage für künftige Verbesserungen zu erhalten und andererseits den geschäftsrelevanten Nutzen und Wert des SOC besser darlegen zu können.

Die entsprechenden Überlegungen betreffen die Auswahl geeigneter Datenquellen wie Ticketingsystem, SIEM, Automatisierungswerkzeuge, Kundenrückmeldungen usw. und die Wahl eines geeigneten, möglicherweise bereits vorhandenen Rapportierungswerkzeugs. Es empfiehlt sich eine Konzentration auf wenige, aber aussagekräftige Messpunkte und deren sorgfältige Darstellung, um Falschinterpretationen möglichst zu vermeiden.

Als besonders wichtige Kennzahl gilt die Zeit, die zwischen der initialen Sicherheitsverletzung und der Detektion des Angriffs verstrichen ist (Time to Detection). Diese Metrik sagt etwas über die gesamte Kaskade von Detektion, Identifikation, Einstufung und Reaktion aus und setzt eine gründliche Analyse der Ursache (Root Case Analysis) und der initialen Kompromittierung voraus.

Verschiedene Studien zeigten, dass heute nur ein kleiner Teil der SOCs überhaupt Metriken erhebt, wovon die meisten rein quantitativer Natur sind, beispielsweise die Anzahl von Angriffen oder die Menge behobener Schwachstellen. Hier liegt die Kunst darin, auch solche Kennzahlen zu messen, die für das Business relevant sind, also beispielsweise das Verhindern negativer Auswirkungen auf die Geschäftstätigkeit.

Abschliessende Hinweise und Ratschläge

Die folgenden Abschnitte gehen auf weitere Gesichtspunkte ein, die den Aufbau eines SOC vereinfachen oder seine Effektivität und Effizienz steigern können.

Falls Teile des SOC ausgelagert werden (“Outsourcing”), sollten besonders für diejenigen Aktivitäten, welche ein tiefes Verständnis interner Geschäftsabläufe oder Prozesse voraussetzen, die Vor- und Nachteile und die damit verbundenen Risiken sorgfältig abgewogen werden.

Die oft anzutreffende, relativ betrachtet höhere Maturität von externen Service Providern in spezifischen Bereichen rührt vielfach daher, dass diese Anbieter sich selektiv und restriktiv auf bestimmte Technologien und Leistungen konzentrieren. Falls eine Organisation die Anforderung umfangreicher individueller Anpassungsmöglichkeiten hat, sei deshalb auch hier zur sorgfältigen Betrachtung der Vor- und Nachteile geraten.

Sollte die betrachtete Organisation neben dem SOC über weitere Abteilungen verfügen, die Aufgaben des SOC wahrnehmen – beispielsweise ein Network Operations Center (NOC) oder ein CERT (Computer Emergency Response Team) – muss auf eine enge Zusammenarbeit mit dem SOC geachtet werden, um Ineffizienzen und Probleme durch doppelte Abläufe, Überlappungen und interne Konkurrenzen zu vermeiden.

Der Aufbau und der Betrieb eines SOC ist mit substanziellen Kosten verbunden. Es ist deshalb unerlässlich, mit Hilfe realistischer Simulationen regelmässig zu prüfen, ob die getätigten Investitionen ihre beabsichtigte Wirkung entfalten und das SOC auch wirklich für den Ernstfall bereit ist. Mit den Ergebnissen können anschliessend gezielte Verbesserungen eingeführt und die Leistungsfähigkeit des SOC gesteigert werden. Die Steigerung der Erfolgsrate eines SOC ist zu einem grossen Teil Übungssache.

Fazit

Auf das Minimum reduziert ergeben sich folgende Empfehlungen:

• organisatorisches Umfeld und klaren Leistungsauftrag sicherstellen
• funktionierenden, soliden Grundschutz sicherstellen, z.B. auf Basis eines anerkannten Frameworks wie NIST CSF
• klein anfangen, wichtigste Use Cases definieren
• Kennzahlen erheben und zur laufenden Verbesserung verwenden

Abschliessend bleibt zu erwähnen, dass nicht jede Organisation ein vollständiges SOC braucht. In kleineren Umgebungen können auch einzelne der erwähnten Funktionen und Technologien ausreichend sein. Auf einen angemessenen Grundschutz, eine geeignete Datenhaltung und -Bearbeitung, ein paar solide Policies und ein Mindestmass an Überwachung sollte aber keine Organisation verzichten.

Weiterführende Informationen

• Recommendations for CSIRTs on how to improve, mature and be better prepared
• Assessing the maturity of CSIRT capabilities
• The SIM3 CSIRT Maturity Model
• A SOC Maturity Model

Über den Autor

Tomaso Vasella hat seinen Master in Organic Chemistry an der ETH Zürich abgeschlossen und ist seit 1999 im Bereich Cybersecurity aktiv. Positionen als Berater, Engineer, Auditor und Business Developer zählen zu seinen Erfahrungen. (ORCID 0000-0002-0216-1268)

Links

• https://opencsirt.org/maturity/sim3/
• https://vuldb.com
• https://www.enisa.europa.eu/publications/csirt-capabilities
• https://www.enisa.europa.eu/topics/csirts-in-europe/csirt-capabilities/csirt-maturity
• https://www.nist.gov/cyberframework