Finanz & Versicherung
Der Finanzsektor ist dichter reguliert als fast jeder andere und die Aufsicht fragt nicht nur, ob Sicherheit vorhanden ist, sondern ob sie nachweisbar getestet wurde. Das verschiebt den Schwerpunkt von der Schwachstellenliste zur Szenariobetrachtung.
Der Weg hinein führt über Menschen und Dritte
Angriffe auf Finanzunternehmen beginnen selten mit einer technischen Lücke im Kernsystem. Sie beginnen mit einer glaubwürdigen Nachricht an eine Person, mit gestohlenen Zugangsdaten eines Dienstleisters oder mit einem Portal, das mehr preisgibt als vorgesehen.
Das Muster ist bei den bekannten Fällen dasselbe: Die Angreifer verschaffen sich einen gültigen Zugang, bewegen sich anschließend mit legitimen Werkzeugen weiter und fallen deshalb wochenlang nicht auf. Was am Ende auffällt, ist die Auszahlung oder der Datenabfluss, nicht der Einbruch.
Für die Abwehr heißt das: Die entscheidende Kennzahl ist nicht die Zahl der geschlossenen Schwachstellen, sondern die Zeit bis zur Erkennung. Und die lässt sich nicht schätzen, sondern nur messen.
Angriff, Erkennung, Nachweis
Die drei greifen ineinander: Ein Test ohne Messung der Erkennung beantwortet die aufsichtliche Frage nicht.
Realistisch angreifen
Szenariobasierte Red-Team-Übungen entlang plausibler Angreiferprofile, mit Phishing und Social Engineering als Einstieg und klar vereinbarten Grenzen. Ergänzt um die externe Angriffsfläche: Portale, Zahlungsschnittstellen, Authentisierung.
Erkennung messen
Wurde die Aktivität bemerkt, wie lange hat es gedauert und was fehlte an Datenquellen. Diese Auswertung ist der eigentliche Ertrag einer Übung, nicht die Liste der genutzten Techniken.
Nachweise führen
Ein Bericht, der die Widerstandsfähigkeit einer kritischen Funktion beschreibt, nicht zwanzig Einzelbefunde. Das ist die Form, in der die Aufsicht die Frage gestellt hat.
Wie eine Red-Team-Übung abläuft
Ein Red Team arbeitet zielgeführt und über Wochen, nicht über Tage. Vereinbart wird ein Ziel, etwa der Zugriff auf eine kritische Funktion, nicht eine Liste zu testender Systeme. Der Weg dorthin bleibt offen, denn genau darin liegt der Erkenntniswert.
Drittparteien und Auslagerungen sind dabei ein regulärer Zugangsweg, kein Sonderfall. Wer produktiven Zugriff hat, gehört in das Szenario, mit vorher abgestimmten Grenzen.
Parallel läuft die Messung auf der Verteidigungsseite mit. Jeder Schritt wird zeitgestempelt, damit sich hinterher genau sagen lässt, an welcher Stelle etwas gesehen wurde und an welcher nicht.
Wie ein Security Operations Center aufgebaut wird
Der Aufwand steckt nicht in der Plattform, sondern in den Use Cases. Quellen aus Netz, Endgeräten, Identität und Cloud werden auf ein Schema normalisiert und angereichert, bevor die erste Regel entsteht.
Die Detektion selbst wird versioniert und gegen ihre Abdeckung nach MITRE ATT&CK gemessen, damit sichtbar bleibt, welche Techniken erkannt würden und welche nicht. Was in einer Übung durchrutscht, wird zum nächsten Use Case. Diese Rückkopplung entscheidet darüber, ob ein SOC über die Jahre wirksam bleibt.
Dazu Playbooks und ein Prozess für die Fallbearbeitung, damit aus einem Alarm eine Entscheidung wird und nicht ein Ticket.
Was am Ende in den Bericht gehört
Der aufsichtliche Blick richtet sich auf die Widerstandsfähigkeit von Prozessen, nicht auf Einzelbefunde. Ein Bericht, der zwanzig technische Schwachstellen auflistet, beantwortet nicht die Frage, ob ein realistischer Angreifer eine kritische Funktion hätte stören können.
Wir ordnen deshalb zu, welche Anforderung durch welchen Nachweis abgedeckt ist. Für Institute mit entsprechender Systemrelevanz kommt der bedrohungsgeleitete Test hinzu, für alle anderen bleibt die Anforderung, regelmäßig und risikoorientiert zu testen. Nicht testpflichtig zu sein bedeutet nicht, nicht angegriffen zu werden.
Was Institute und Versicherer fragen
Das hängt an Systemrelevanz, Zahlungsverkehrsvolumen und Rolle. Die Einordnung nimmt die Aufsicht vor. Wir klären mit Ihnen, was daraus für Ihr Testprogramm folgt. Das gilt unabhängig davon, ob eine formale Pflicht besteht.
Ein Penetrationstest prüft einen definierten Umfang in die Tiefe. Ein Red Team verfolgt ein Ziel und stellt dabei Erkennung und Reaktion auf die Probe. Die Frage ist eine andere, deshalb ist auch das Ergebnis ein anderes.
Das ist ein verwertbares Ergebnis, kein Misserfolg. Aus der Auswertung ergibt sich, ob die Datenquelle fehlte, der Use Case, oder ob der Alarm da war und in der Bearbeitung unterging.
Vor einer aufsichtlichen Prüfung, nach Konsolidierung oder Neuaufbau des Monitorings, bei Anbindung eines neuen Dienstleisters mit produktivem Zugriff, oder wenn Berichte vorliegen, aber unklar ist, ob die Erkennung funktioniert hätte.
