SOC as a Service: Für Banken ein sinnvolles Modell?

Cyber-Kriminalität läuft „klassischen“ Kriminalfeldern wie Einbruch seit Jahren den Rang ab. Das deutsche Bundeskriminalamt geht in seinem Lagebericht zu Cybercrime im Jahr 2022 von mehr als 135.000 Fällen aus, in denen Privatpersonen, Unternehmen und Organisationen Opfer eines Cyberangriffs wurden. Das sind mehr als doppelt so viele Fälle wie jene von Wohnungseinbrüchen im gleichen Zeitraum. Tendenz weiter steigend.

von Philipp Kleinmanns, Geschäftsführer von Materna Radar Cyber Security

Als Teil der Kritischen Infrastruktur von Staaten stehen Banken und Finanzunternehmen im Fokus von Angreifern. Dabei spielt den Cyberkriminellen in die Hände, dass der Security-Reifegrad von Banken nach wie vor sehr unterschiedlich ist. Wir sehen im Moment Institute, die in puncto Security schon sehr weit voraus gegangen sind. Diese haben eigene Security-Teams mit einem Chief Security Officer, kurz: CSO, geschaffen und sind technologisch ganz vorne mit dabei. Diese Teams entscheiden unabhängig von der IT, operieren jedoch in enger Abstimmung mit den Technologie-Experten. Das ist richtig und wichtig. Es gibt aber auch Banken, die hier noch deutlich höheren Aufholbedarf aufweisen.

Sicher und kontrolliert scheitern, statt Schutzschilde hochziehen

Egal, wie gut ein Finanzdienstleister bisher gegen Cybercrime geschützt ist, wichtig ist, dass wir anerkennen, dass es dennoch zu erfolgreichen Cyberangriffen kommt.”

Die Qualität der Angriffe und die Professionalität der Angreifer steigt und auch Künstliche Intelligenz (KI) wird verstärkt von den Angreifern eingesetzt. Mittels Deep Fakes geht Social Engineering mittlerweile so weit, dass Hacker-Gruppen per Telefon bis zu Personen in hochrangigen Positionen vordringen. Ausgeklügelte, teilweise mehrstufige Angriffskampagnen sind teilweise sogar staatlich organisiert. Selbst hoch sensibilisierte und sicherheitsbewusste Anwender gehen Cyberkriminellen auf den Leim.

Die Frage ist nicht mehr „ob“, sondern „wann“. Es genügt nicht mehr, die Schutzschilde möglichst hochzuziehen und dann davon auszugehen, dass man sicher ist. Diesen Paradigmenwechsel müssen wir anerkennen.

Schlechter geschützte Banken wird es früher und vermutlich auch härter treffen als besser geschützte Institute. Letztere sind vor Cyberangriffen aber nicht gefeit.”

Es wird somit immer wichtiger sich auf den Ernstfall vorzubereiten, ihn zu verproben um wenn es tatsächlich soweit kommen solle „sicher zu scheitern“. Dies hilft in erster Linie auch dabei nach einem erfolgreichen Angriff schnell wieder handlungsfähig und operativ zu sein und Schäden minimal zu halten.

Security Operations Center: Mehr als nur SIEM

Herzstück in diesem Paradigma ist ein Security Operations Center, kurz: SOC. Ein SOC ist eine Funktionseinheit eines Unternehmens, einer Behörde oder einer Organisation, bestehend aus Menschen, Prozessen und Technologie. Seine Aufgabe ist es, Informationsrisiken aus dem Cyberraum zu identifizieren, zu erkennen und davor zu schützen.

Ein SOC reagiert auf potenzielle Sicherheitslücken, informiert darüber und gibt konkrete Handlungsempfehlungen, um Angriffen vorzubeugen.”

Für den erfolgreichen Betrieb eines SOCs ist es wichtig, die richtige Technologie mit den notwendigen Experten im SOC zu kombinieren, welche nach definierten Prozessen agieren und im Falle eines SOC-as-a-Service durch einen Drittanbieter auch bei dessen Kunden gut eingebunden sind. Auf technischer Ebene hängen verschiedene Security-Tools bildlich gesprochen im Datenstrom eines Unternehmens. Diese Tools tracken und analysieren die Daten automatisiert nach zuvor definierten Erkennungslogiken, so genannten Use Cases. In dieser Ebene der automatisierten Erkennung von Sicherheitsvorfällen arbeiten Werkzeuge insbesondere zur Analyse von Logdaten von IT-Systemen. Die Analyse von Logdaten wird auch Security Information and Event Management, kurz: SIEM, genannt.

Endpoint-Detection-and-Response (EDR) ergänzt das SIEM. Unter EDR versteht man Software-Lösungen zur Angriffserkennung, die direkt auf den Endgeräten installiert werden und dort den Datenverkehr mitlesen können. EDR-Software hilft zum Beispiel dabei, Schadsoftware zu erkennen, wenn jemand auf eine Phishing-Email klickt. Sie greift auf Basis von Automatismen auch schon direkt am Ort des Geschehens ein, sofern dies erforderlich ist. EDR ist ein gutes Beispiel dafür, dass im SOC bereits auf maschineller Ebene reagiert wird, um Sicherheitsvorfälle einzudämmen und zu verhindern. Es geht bereits hier um mehr als die reine Analyse, insbesondere auch um Schadensbegrenzung.

Zu guter Letzt hilft Vulnerability Management and Compliance dabei, die Infrastruktur proaktiv auf Schwachstellen und Fehlkonfigurationen zu untersuchen.”

Dies unterstützt Security-Verantwortliche dabei, mögliche Einfallstore zu erkennen, bevor es zu einem Angriff kommt.

Sämtliche auf der automatisierten Ebene gesammelten Daten, auch solche zu automatisch ausgeführten Korrekturen und Reaktionen, führt das SOC in einer so genannten Correlation Engine zusammen und bildet sie in einem Dashboard ab. Hier kommt die menschliche Komponente hinzu:

Mithilfe der Correlation Engine entscheiden Security-Analysten im SOC, welche Vorfälle weitere Handlungen erfordern und auf welche Art und Weise reagiert werden soll.”

Mögliche Vorfälle könnten etwa Logins zu ungewöhnlichen Zeiten oder Endpunkte an einer falschen Lokation sein. Ein zweiter Vorfall könnte ein mit Schadcode verseuchter E-Mail-Anhang sein, der massenhaft in die Postfächer der Mitarbeitenden versendet wird.

Im SOC, der Sicherheitsleitstelle, entscheiden die Mitarbeitenden entsprechend zuvor festgelegter Prozesse, wer wie verständigt wird. Bei weniger kritischen Schwachstellen wird die IT-Abteilung mittels Ticket-System informiert. Bei größeren Angriffen, beispielsweise Phishing-Wellen, kann der Kommunikationsweg auch per Telefon verlaufen. Denn hier müssen zeitnah komplexere Entscheidungen getroffen werden.

Das Security Operations Center, kurz: SOC, ist die Sicherheitsleitstelle. Hier werten Security-Analysten gesammelte Informationen aus und entscheiden anhand definierter Prozesse und Notfallpläne, was zu tun ist.”

SOC as a Service: Für Finance-Unternehmen führt kein Weg daran vorbei

Ist die Entscheidung Richtung SOC gefallen sehen sich Kunden oft mit einigen Grundsatzentscheidungen konfrontiert. Soll die SOC-Dienstleistung extern, also als SOC-as-a-service Modell bezogen werden, oder gibt es Gründe dafür ein SOC intern zu etablieren und on premise zu betreiben? Dürfen leicht skalierbare Cloud-Dienste für das SOC verwedet werden? Dies sind Fragestellungen, bei denen wir auf unsere jahrzehntelange Erfahrung in allen genannten Varianten setzen können und unsere Kunden gerne an die Hand nehmen. Die Beratung durch einen erfahrenen Partner ist hier sehr wichtig, um die Lösung zu erarbeiten die auch die Anforderungen und Bedürfnisse abdeckt.

Ein Inhouse-Modell setzt den Aufbau eines eigenen SOCs voraus: die Auswahl und Implementierung der Tools, die Auswahl und Schulung von Experten, das Aufsetzen der Use Cases, die Definition von Prozessen, das Anbinden an Ticket-Systeme und vieles weitere mehr.

Neben den Anschaffungskosten braucht es viel Know-how, Expertise und Zeit. Und hier liegt der Knackpunkt: Das ist ziemlich aufwendig und teuer.”

Und der Aufbau und der Betrieb eines SOCs gehört nicht zu den Kernprozessen von Finanzunternehmen.

Beim As-a-Service-Modell führt ein Dienstleister den Betrieb des SOCs, stellvertretend für das Bankinstitut und in enger Abstimmung mit unternehmenseigenen Security-Experten. Das hat finanzielle und zeitliche Vorteile, auch in Hinblick auf die Tatsache, dass Security-Spezialisten rar am Markt sind.

Hinzu kommt, dass As-a-Service-Anbieter die Situation unterschiedlicher Kunden im Blick haben und diese Expertise gesammelt auf alle Kunden übertragen können.

Im Hinblick auf Cyber Security verfügen Dienstleister über eine kumulierte Expertise und Wissen, das interne Abteilungen mangels Zeit in der Regel nicht aufbauen können.”

Einen weiteren Mehrwert leistet das Ökosystem eines SOC-Dienstleisters, der mit seiner Datenbank an Use Cases eine treffsichere Detektion von Sicherheitsrisiken ermöglicht.

Das As-a-Service-Modell wird sehr häufig in der Cloud umgesetzt. Hier sind Finanzunternehmen und Banken sehr restriktiv, da sie strengen Compliance-Vorschriften unterliegen. Diese Rahmenbedingungen setzen enge Grenzen, sowohl technisch im Hinblick auf die Nutzung von Clouds als auch rechtlich im Hinblick auf die Auslagerung von Daten.

Diesen Überlegungen gegenüber stehen die Wünsche und der Bedarf, den operative Einheiten von Banken äußern.”

Hier gibt es Vorgaben aus Gesetzen, beispielsweise DORA (Digital Operational Resilience Act). Diese Wünsche und Vorschriften können in vielerlei Hinsicht nur mit As-a-Service- oder auch Cloud-Modellen bedient werden. Banken und Finanzunternehmen setzen daher schon heute konsequent auf Service-Modelle, sei es, indem sie ihr SOC komplett auslagern oder indem sie nur Teilleistungen von einem Dienstleister beziehen, etwa Schwachstellen-Scans oder Pentests.

Gesetzliche Bestimmungen und technische Entwicklungen lassen hier durchaus Spielraum. So sind mehr und mehr gänzlich auf europäischem Boden beheimatete Clouds verfügbar, die den Vorgaben an den Datenschutz entsprechen. Microsoft war dabei einer der stärksten Treiber. Und bankenspezifische Regularien erlauben in einigen Fällen die Nutzung von Cloud-Diensten, wenn einige Rahmenparameter beachtet werden.

Auch wenn es, je nach Größe des Finanzunternehmens, eine Mammutaufgabe sein kann, ein SOC in Betrieb zu nehmen, an Cloud und As-a-Service-Modellen wird kein Weg vorbeiführen.”

Gesetze und Regeln lassen Spielraum für SOC-as-a-Service

In vielen Punkten unterscheiden sich die Anforderungen an SOC-as-a-Service nicht von den Anforderungen an ein gutes IT-Management entsprechend den europäischen Gesetzen. Unter den folgenden Voraussetzungen können Banken und Finanzdienstleister ein SOC as a Service sicher und gesetzeskonform nutzen:

• Europäische Clouds: Die Infrastruktur der genutzten Clouds muss europäischen Datenschutzstandards genügen, beispielsweise Server an europäischen Standorten.
• Redundanz: Berücksichtigung der Vorgaben im Rahmen einer Cloud-Architektur.
• Sicherer Datenaustausch: Nutzung marktüblicher Verschlüsselungstechniken.
• Protokollierung: Kontinuierliches Sammeln und zentrales Speichern von Protokolldaten.
• Integration ins Meldewesen: Verpflichtende Meldung von Sicherheitsvorfällen und freiwillige Meldung von potenziellen Bedrohungen an die Finanzdienstleistungsaufsicht BaFin
• Datensicherung: Für den Fall einer Wiederherstellung von Daten: Datensicherung nach Branchenstandard (etwa 3-2-1 Regel)
• Testing: Alle eingesetzten Tools regelmäßig prüfen und hinterfragen
• Aktualität: Die eingesetzten Tools müssen stets am aktuellen Stand der Technik sein (State of the Art)
• Kontinuierliche Schulung: Mitarbeitende auf SOC-Dienstleister-Ebene sollten ihr Know-how-permanent auf den neuesten Stand bringen und dies durch Zertifikate und interne Tests nachweisen können. Die Schulung interner Mitarbeitender auf Seiten des Finanzdienstleisters sollte, je nach Kompetenz-Level, ebenfalls berücksichtigt werden.Philipp Kleinmanns, Materna Radar Cyber Security