Banken-SOC wird Pflicht: In 4 Schritten zum Security Operations Center

Die IT-Strukturen von Banken sind oft ein historisch gewachsener Flickenteppich – und dadurch aus dem Blickwinkel der IT-Sicherheit vielfach lückenhaft und angreifbar. Ein Security Operations Center (SOC) kann die einzelnen operierenden Systeme verknüpfen, verborgene Potenziale heben – und so die Anzahl der Sicherheitsvorfälle reduzieren. Wie Banken ein solches SOC aufbauen können und worauf sie achten sollten, erläutert Christian Nern, Partner im Bereich Financial Services bei KPMG.

von Christian Nern, KPMG

Spätestens seit der letzten Aktualisierung der Bankenaufsichtlichen Anforderungen an die IT (BAIT) im August 2021 hat die BaFin eine „ständig besetzte Zentrale, z.B. in Form eines Security Operations Center (SOC)“ als Maßstab für die Absicherung der IT-Systeme von Banken definiert.

Banken sind im Zugzwang, ein SOC oder eine vergleichbare Infrastruktur einzurichten, um ihrer Verantwortung aus regulatorischer Sicht nachzukommen.”

Gleichwohl: Den Aufbau eines SOCs rein unter Berücksichtigung der Compliance zu betrachten, ist zu kurz gedacht. Denn richtig aus- und eingerichtet kann eine vernetzte Security-Infrastruktur nicht nur als Business Differentiator fungieren. Vielmehr dient sie dazu, das Institut, seine Daten und seine Reputation zu schützen, indem es die Anzahl der Sicherheitsvorfälle senkt. Auch wenn ein SOC nicht vorrangig als kostensenkende Maßnahme betrachtet werden sollte, können Unternehmen mit einer vernetzten Sicherheits-Infrastruktur, in denen ein SOC ein zentraler Baustein ist, laut einer Prognose von Gartner zudem

die finanziellen Auswirkungen einzelner Sicherheitsvorfälle um durchschnittlich 90 % reduzieren.“

(Quelle)

Vor allem aber gilt: Unternehmen mit SOC sind in der Lage, aus Fehlern zu lernen und ihre Infrastruktur sukzessive zu optimieren – Institute ohne SOC haben diese Möglichkeit nicht.

Vom Status Quo zum SOC in 4 Schritten

Die Einführung eines SOCs ist ein umfangreiches Projekt, das je nach Ausgangslage, Zielbild und Rahmenbedingungen unterschiedlich lange dauern kann, aber mindestens einige Monate Zeit in Anspruch nimmt.”

Um alle wichtigen Aspekte von vornherein zu berücksichtigen und das Projekt effizient zu gestalten, empfiehlt es sich, das Projekt in vier Phasen einzuteilen:

1. Mindset und Voraussetzungen schaffen (SOC-Programm)

Die erste Phase ist die wichtigste, denn sie bildet das Fundament, auf dem das SOC entstehen soll. Hier geht es vor allem darum, die wichtigsten Stakeholder ins Boot zu holen und ein gemeinsames Mindset zu schaffen. Darüber hinaus gilt es, eine Strategie zu definieren. Finanzinstitute sollten hier unter anderem folgende Fragen beantworten:

• Was erwarten wir aus unserem SOC? Was wollen wir damit erreichen?
• Was sind unsere Business Requirements bzw. Business Drivers?
• Welche Verantwortlichen aus den unterschiedlichen Bereichen bilden das Projektteam?
• Wie wird das Projekt finanziert?

2. Definition der Anforderungen

Die zweite Phase ergibt sich aus den Ergebnissen der ersten Phase. Hier geht es darum, sämtliche Anforderungen aus unterschiedlichen Blickwinkeln an das SOC zu definieren. Dazu gehören unter anderem:

• Risk & Compliance
• Governance
• Funktionale und nicht-funktionale Anforderungen

Ein weiterer wichtiger Aspekt sind Software und Tools: Welche sind vorhanden? Gibt es Cloud-Services? Wie sollen die Tools an das SOC angebunden werden? Phase 2 ist im Grunde eine Bestandsaufnahme: Welche Anforderungen haben wir an unser SOC und welche davon können wir bereits erfüllen, sprich: Wie sieht unsere Infrastruktur derzeit aus?

3. SOC Design

In der dritten Phase wird das SOC theoretisch geplant.

Da es in der Praxis nicht realistisch ist, alle Anforderungen in das SOC zu integrieren, geht es hier vor allem darum zu definieren, welche Anforderungen für das SOC relevant sind, um die in Phase 1 definierten Ziele und Funktionen zu erfüllen.”

Hierbei spielen folgende Überlegungen eine Rolle:

• Welche Capabilities soll das SOC enthalten? Nur Monitoring, auch Logging oder sogar Incident Response?
• Welche Use Cases soll es enthalten, sprich: Welche Bedrohungsszenarien sollen abgedeckt werden? Zu den häufigsten Szenarien gehören Ransome- und Malware, Phishing, DDoS-Attacken sowie Lost and Stolen Devices; für weitere Use Cases können Verantwortliche sich am MITRE ATT&CK Framework orientieren.
• Wie soll das Reporting aussehen? Welche Informationen muss das SOC für die unterschiedlichen Stakeholder – zum Beispiel den Chief Information Security Officer (CISO), die Geschäftsführung oder Aktionäre – generieren?
• Wie soll das SOC betrieben werden – inhouse, über einen Provider oder hybrid? Bei hybridem Modell: Wer soll wann welche Aufgaben übernehmen?

Beim SOC-Design müssen Finanzinstitute jedoch nicht nur die im SOC selbst operierenden Systeme betrachten, sondern auch Input gebende Systeme. So setzt ein SOC auf einem Security Information and Event Management (SIEM) auf, das wiederum von weiteren Systemen mit Informationen und Daten gefüttert wird – zum Beispiel Firewalls, Identity- und Schwachstellenmanagement sowie Threat Intelligence Systemen. Ob und wenn ja welche dieser Systeme und Daten in das SOC integriert werden und wie das erfolgen soll, ist ebenfalls Teil des SOC-Designs.

4. Implementierung bzw. Transition

Sind die Grundlagen geschaffen, Anforderungen definiert und das SOC designt, wird das SOC praktisch umgesetzt (bei inhouse-Betrieb) bzw. Transition (bei Beauftragung eines Providers). Damit ist die initiale Einführung des SOCs abgeschlossen, die jedoch nahtlos in einen kontinuierlichen Verbesserungsprozess (KVP) übergeht: Nun gilt es, Erfahrungen zu sammeln und aus ihnen zu lernen – und Runbooks, Use Cases, Tools sowie die gesamte Infrastruktur kontinuierlich an die Bedrohungslage und Rahmenbedingungen anzupassen.

SOC 2.0: Automatisierung mittels SOAR und Runbooks

Grundlage eines SOCs ist ein SIEM, das sämtliche Log-Daten speichert und aufbereitet. Im SOC sind dann verschiedene Regeln definiert, sogenannte Use Cases, die aus Sicherheitssicht bedenklich sein könnten. Erzeugt ein Use Case einen Alarm, geht dieser in Form eines Tickets an eine Incident-Response-Plattform (z.B. BM Resilient, Service Now, Gira), wo Analysten sie dann bearbeiten. Wer sich etwas fortschrittlicher aufstellen möchte, kann wiederkehrende Analysetätigkeiten, die bei einer bestimmten Klasse an Bedrohungen immer wieder erfolgen müssen, mittels Security Orchestration Automation and Responses (SOAR) automatisieren — und so manuelle Analystentätigkeiten reduzieren.

Dies erfolgt anhand von Runbooks, die Abläufe für bestimmte Prozessschritte vorgeben. Nehmen wir als Beispiel Phishing-Mails, bei denen ein Runbook unter anderem folgende Anweisungen enthält: “Ist die Absenderadresse der Mail bekannt? Wenn nein: Schicke die Mail an eine Sent-Box. Wenn hierbei Auffälligkeiten entstehen: Setze die Mail in Quarantäne. Wenn die Absenderadresse bekannt ist: Blockiere sie und lösche die Mail. Schaue zudem im X-Mail-Server nach, ob es dort ähnliche Adressen gibt. Wenn dies der Fall ist: Verfahre mit diesen Adressen genauso.“

Gute Runbooks enthalten nicht nur Anweisungen, sondern ebenso Verantwortlichkeiten und Meldepflichten.”

Sie stellen sicher, dass an alles Wichtige gedacht wird — zum Beispiel, indem sie bei gewissen Sicherheitsvorfällen anzeigen, welche Behörden (Bundeskriminalamt, Aufsicht, ggf. BSI bei kritischer Infrastruktur) informiert werden müssen. Im Vergleich zu Phishing-Mails, die eher einfachere Bedrohungen darstellen, sind etliche Bedrohungen allerdings deutlich komplexer. Sie brauchen daher Runbooks, die initiale Anweisungen enthalten, sich jedoch mit zunehmender Erfahrung dynamisch anpassen und weiterentwickeln können.

Was SOCs mit Airbags gemeinsam haben

Stellen Sie sich vor, ein Autohersteller würde Autos ohne Airbags zum Verkauf anbieten – mit der Begründung, dass ja nicht alle Autofahrten zu einem Unfall führen und diese sogar nur in den seltensten Fällen tödlich ausgehen. Würden Sie ein solches Auto kaufen? Und welches Licht würde das auf den Hersteller werfen – würden Sie diesem noch vertrauen? In gewisser Weise könnte man sagen, dass dein SOC der Airbag eines Finanzinstituts ist.

Deshalb ist die Entscheidung für ein SOC aus meiner Sicht weder eine finanzielle, noch eine strategische oder operative. Es ist eine Business-Entscheidung.”

Es ist die bewusste Entscheidung, alle denkbaren Maßnahmen zu ergreifen, um die Sicherheit der unternehmenseigenen Informationen und Strukturen zu maximieren. Und das verlangt nicht nur der Regulator, das erwarten auch Kunden und Mitarbeiter.Christian Nern, KPMG