Euer SOC 2 ist nicht eure Sicherheit

Jeder Fintech-Gründer hat irgendwann dasselbe Gespräch mit seinem ersten Enterprise-Kunden. Der Kunde fragt nach dem SOC 2. Der Gründer beauftragt eines. Sechs Monate und vierzigtausend Dollar später schließt das Audit sauber ab — und der Deal damit.

Dann vergeht ein Jahr, das Produkt wächst, und an einem stillen Dienstag findet das Sicherheitsteam etwas, das dort nicht sein sollte. Das Audit war sauber. Das System war es nicht.

Das ist kein Angriff auf SOC 2. Es ist eine ehrliche Beschreibung davon, was SOC 2 ist und was nicht — und wo die Lücke zwischen beidem liegt.

Was SOC 2 tatsächlich bescheinigt

Ein SOC 2 Type II Audit bestätigt, dass ihr Controls vorhanden habt und dass diese Controls über ein Fenster — typischerweise drei, sechs oder zwölf Monate — wie vorgesehen funktioniert haben. Es ist ein Prozess-Audit. Der Prüfer verifiziert, dass ihr das tut, was eure Richtlinien sagen, dass ihr tut.

Die Richtlinien sind von euch geschrieben. Der Umfang ist von euch definiert. Der Prüfer prüft, dass ihr eure eigenen Regeln befolgt habt.

Das ist wirklich wertvoll. Es bedeutet, ein Käufer kann fragen "Loggt ihr Zugriffe?" und der Antwort vertrauen. Es bedeutet, ein Regulator kann sehen, dass ihr Controls ernst nehmt. Es bedeutet, ein Gericht — wenn es so weit kommt — sehen kann, dass ihr angemessene Sorgfalt walten ließt.

Was es nicht bedeutet: dass die Controls, die ihr geschrieben habt, ausreichend sind; dass das Bedrohungsmodell, das ihr euch vorgestellt habt, dem entspricht, dem ihr tatsächlich gegenübersteht; oder dass die Implementierung dieser Controls fehlerfrei ist.

Das Zwei-System-Problem

Fintech-Systeme haben normalerweise zwei Sicherheitshaltungen, die parallel laufen.

Die erste ist die deklarierte Haltung — was eure Richtlinien sagen, was eure Runbooks beschreiben, was der Prüfer sieht. Das ist, was SOC 2 bescheinigt.

Die zweite ist die gelebte Haltung — was tatsächlich in der Produktion um 3 Uhr morgens passiert, wenn ein On-Call-Ingenieur auf einen Vorfall reagiert. Wie die Staging-Umgebung nach sechs Monaten "wir werden das später aufräumen" aussieht. Was das Drittanbieter-SDK, das eure Karten-Tokenisierung übernimmt, tatsächlich tut.

Die meisten Sicherheitsverletzungen passieren nicht, weil die deklarierte Haltung falsch war. Sie passieren, weil die gelebte Haltung davon abgewichen ist — und niemand es bemerkt hat.

Was man tatsächlich tun sollte

Es gibt drei Gewohnheiten, die die Lücke schließen.

Das Audit als Boden behandeln, nicht als Decke. Der Prüfer prüft, dass ihr Zugriffe loggt. Gut. Dann fragen: Loggen wir die richtigen Dinge? Überprüfen wir die Logs? Würden die Aktionen eines entschlossenen Insiders auffallen — oder im Rauschen unsichtbar sein? SOC 2 wird das nicht fragen. Ihr solltet es.

Sicherheitsübungen gegen das gelebte System durchführen. Einen echten Vorfall vierteljährlich am Tisch durchgehen. Jährlich eine Red-Team-Übung durchführen. Jemanden außerhalb des Teams dazu bringen, nur mit öffentlichen Informationen zu versuchen, Testdaten zu exfiltrieren. Die Übungen, die am meisten finden, sind meist diejenigen, die auf die Lücke zwischen Runbook und Realität zielen.

Genau auf langweilige Drift achten. Ein neues SDK wird ohne Sicherheitsreview hinzugefügt. Eine Staging-Datenbank wird mit einem Produktions-Snapshot befüllt. Die Berechtigungen eines Anbieters werden "vorübergehend" erweitert und nie wieder eingeschränkt. Diese Drift ist das, was Audits nicht sehen — und Sicherheitsverletzungen schon.

Die ehrliche Botschaft

Ein sauberes SOC 2 ist notwendig. Es ist auch nicht ausreichend. Die Agenturen und Berater, die es als Ziellinie behandeln — und das sind viele — verkaufen euch das Audit, nicht die Sicherheit.

Wenn wir Fintech-Systeme liefern, liefern wir gegen die gelebte Haltung, nicht die deklarierte. Das Audit schließt meist sauber als Nebeneffekt ab. Das ist die Reihenfolge, in der die Arbeit passieren muss.