CSCF v2027: Neuerungen und ausgewählte Schwellen für Updates, Tests und Notfallplanung

Problem in der Praxis

Viele Institute haben feste Patchzyklen, die an Wartungsfenstern statt am Risiko hängen. Die v2027-Empfehlungen zu KI-getriebenen Bedrohungen zielen genau darauf: Angriffsketten entstehen schneller, also müssen Priorisierung und Behebung schneller werden. Ebenso werden Penetrationstests oft als jährliches Einzelprojekt gesehen, das nie alle Komponenten erfasst; v2027 erlaubt ausdrücklich eine Abdeckung über ein Programm, verlangt aber, dass alle relevanten Komponenten darin vorkommen.

CISO-Einordnung

Neuerungen laut Änderungsübersicht v2027 (S. 6 bis 8), in eigenen Worten:

• Secrets and Keys Vault: neuer, technologieneutraler Begriff für Speicher von Zugangsdaten, Schlüsseln und Zertifikaten; als Komponente im Scope zu schützen wie die Anwendung, die ihn nutzt, mit den einschlägigen Kontrollen; bei externem Betrieb gilt zusätzlich 2.8, die Verantwortung für die gespeicherten Geheimnisse bleibt beim Nutzer.
• Alliance Connect: Umstieg auf eine neue Netztechnik zwischen 2027 und 2029; die neue virtuelle VPN-Instanz beim Kunden läuft auf einer eigenen virtuellen Maschine und liegt im Scope mehrerer Kontrollen.
• KI: KI-Agenten, die Transaktionen erzeugen oder unterstützen, sind abzusichern und zu steuern, mit menschlicher Kontrolle über Transaktionen (über die CSP-FAQ). Für den Einsatz KI-gestützter Werkzeuge zur Erfüllung der Kontrollen gibt es nach v2027 noch keine besonderen Vorgaben, aber dieselbe Sorgfalt wie bei jedem Werkzeug (S. 10).
• Einzelne Kontrollen: Mikrosegmentierung als möglicher Weg bei 1.1 und 1.5; einheitlichere Erwartungen an den Internetzugang (1.4), auch für Jump-Server in Cloud- oder Hybridumgebungen; erster Back-Office-Hop und Rolle des Bridging-Servers geklärt (2.4); PKI-Schlüssel und Zertifikate über O2M in 2.8 und 5.1; Geschäftskontrollen für ausgehende Transaktionen geklärt, eingehende bleiben optional (2.9); regelmäßige Überprüfung der RMA-Beziehungen (2.11A); risikobasierter Schutz gegen Brute Force (4.1); Swift-HSM ausdrücklich in der Protokollierung (6.4).
• Ausblick: Das Swift Digital Ledger soll in einer künftigen Fassung aufgenommen werden (Ziel v2028).
• Back-Office-Datenflüsse (2.4, S. 54 und Anhang H, S. 141): Pflicht im Scope sind die Flüsse über Bridging-Server zwischen erstem Back-Office-Hop und Swift-Komponente; bestehende direkte Altflüsse zwischen erstem Back-Office-Hop und Swift-Komponente oder Bridging-Server sind vorerst nur Empfehlung. Sie sollen in einer späteren Fassung verpflichtend werden, vorläufig v2028. Swift empfiehlt ein stufenweises Vorgehen: alle Flüsse erfassen, dann risikobasiert priorisieren.

Ausgewählte Schwellen (eigene Worte):

• Updates (2.2, S. 50 bis 51): Hard- und Software in der Secure Zone und auf Operator-Rechnern im Herstellersupport; Pflichtupdates von Swift-Komponenten in der vom Hersteller gesetzten Frist; Sicherheitsupdates nach Risikobewertung mit eigenen Fristen; ohne eigene Prozesse und Fristen die CVSS-Ziele oben (gerechnet ab Veröffentlichung des Updates), darunter selbst festgelegt; wegen KI-getriebener Bedrohungen schneller einspielen, nach Ausnutzbarkeit priorisieren, bei Verzug kompensierende Maßnahmen.
• Schwachstellenscans (2.7, S. 61): mindestens jährlich oder nach wesentlicher Änderung.
• Notfallplanung (7.1, S. 95 bis 96): Plan jährlich aktualisieren und überprüfen, mindestens alle zwei Jahre testen; er umfasst unter anderem die zügige Benachrichtigung der Leitung, der zuständigen Aufsicht und Strafverfolgung sowie des Swift-Kundensupports, Eindämmung, Einbindung von Fachleuten und die Überprüfung der eigenen Attestierung, die nach der Policy gegebenenfalls für ungültig zu erklären und neu abzugeben ist.
• Sensibilisierung (7.2, S. 97): jährlich für alle mit Zugang zu Swift-Systemen.
• Penetrationstests (7.3A, Empfehlung, S. 99 bis 100): regelmäßig nach Regulierung und Risiko, typischerweise mindestens alle zwei Jahre und nach wesentlichen Änderungen der Umgebung; vollständige Abdeckung aller relevanten Komponenten im Scope alle vier Jahre über ein Gesamtprogramm; dabei dürfen frühere Übungen einschließlich Red-Team- oder TLPT-Übungen angerechnet werden, die bei Abgabe der Attestierung nicht älter als vier Jahre sind; keine destruktiven Tests in der Produktion; Tiefe nach Exponierung.

Umsetzungsperspektive

• Patchprozess für die Swift-Umgebung mit eigenen, risikobasierten Fristen nach Kritikalität, Systemtyp und Testbedarf festlegen; fehlen solche Fristen, greifen die CVSS-Empfehlungen von Swift.
• Geheimnis- und Schlüsselspeicher inventarisieren und in den Scope aufnehmen.
• Notfallplan mit Swift-spezifischen Schritten ergänzen und testen.
• Pentest-Programm mit Tests typischerweise mindestens alle zwei Jahre und nach wesentlichen Änderungen planen, Gesamtabdeckung in vier Jahren, vorhandene TLPT-Übungen anrechnen.
• Netzumstellung von Alliance Connect in die Architekturplanung aufnehmen.
• Bestehende direkte Back-Office-Flüsse jetzt erfassen und priorisieren; sie werden voraussichtlich mit v2028 Pflicht (2.4).

Typische Fehler

1. Patchzyklen folgen Wartungsfenstern statt dem Risiko.
2. Schlüssel- und Geheimnisspeicher werden als Infrastruktur außerhalb des Scopes betrachtet.
3. Der Notfallplan nennt Swift nicht und wird nie getestet.
4. Pentests decken Jahr für Jahr dieselben Komponenten ab.
5. Die Attestierung wird nach einem Vorfall nicht überprüft.

Risiken und Trade-offs

Schnelleres Patchen erhöht das Betriebsrisiko durch ungetestete Updates; kompensierende Maßnahmen sind dann der vorgesehene Ausgleich, kein Ersatz. Ein mehrjähriges Pentest-Programm spart Aufwand je Jahr, verlangt aber eine Abdeckungsplanung, die einer Bewertung standhält.

Entscheidungspunkte

• Welche Patchfristen setzen wir selbst, und liegen sie innerhalb der Empfehlungen?
• Wo liegen unsere Geheimnis- und Schlüsselspeicher, und wer betreibt sie?
• Wann testen wir den Notfallplan mit Swift-Szenario?
• Wie verteilen wir Pentests über die Jahre?

Praktische Empfehlungen

1. Setzen Sie risikobasierte Patchfristen und messen Sie sie.
2. Nehmen Sie Secrets and Keys Vaults ausdrücklich in den Scope.
3. Testen Sie den Notfallplan mindestens alle zwei Jahre mit Swift-Szenario.
4. Planen Sie Penetrationstests als Programm mit Abdeckungsnachweis.
5. Prüfen Sie nach jedem Vorfall die eigene Attestierung.

Relevante Normreferenzen

• Swift, Customer Security Controls Framework v2027 (10.07.2026), Overview of Changes, Kontrollen 2.2, 2.7, 7.1, 7.2, 7.3A.
• Swift CSP-FAQ und Knowledge-Base-Artikel (im Korpus nicht verfügbar).