Die 32 Kontrollen des CSCF aus Managementsicht und die zwei Wege zur Konformität

Problem in der Praxis

Die Umsetzungshinweise werden gern als Prüfliste abgehakt. Swift sagt ausdrücklich, dass sie keine starre Auditcheckliste sind: Fehlt ein Element, sind Mitigationen und Besonderheiten der Umgebung zu bewerten. Umgekehrt genügt eine Alternative nur, wenn sie das Kontrollziel nachweislich gleich gut erfüllt. Beides verlangt Urteilsvermögen, nicht nur Dokumentation.

CISO-Einordnung

Die sieben Gruppen in eigenen Worten (CSCF v2027, Übersichtstabelle S. 29 bis 31):

• Gruppe 1, Abschottung (1.1 bis 1.5): Swift-Umgebung und Connector-Umgebung von der übrigen IT trennen, privilegierte Betriebssystemkonten beschränken, Virtualisierung und Cloud wie physische Systeme schützen, Internetzugang auf das geschäftlich Nötige begrenzen.
• Gruppe 2, Angriffsfläche und Schwachstellen (2.1 bis 2.11A): Datenflüsse zwischen Komponenten und zum Back-Office schützen, Updates und Härtung von System und Anwendung, Schutz von Daten außerhalb der Secure Zone (Empfehlung), Sitzungsschutz für Operatoren, Schwachstellenscans, Schutz ausgelagerter Tätigkeiten, Geschäftskontrollen für ausgehende Transaktionen, Kontrolle der RMA-Beziehungen zu Gegenparteien (Empfehlung).
• Gruppe 3, physische Sicherheit (3.1).
• Gruppe 4, Zugangsdaten (4.1 und 4.2): wirksame Passwortregeln und Multi-Faktor-Authentisierung, auch auf Betriebssystemebene (S. 74 bis 77).
• Gruppe 5, Identitäten und Berechtigungen (5.1 bis 5.4): Need-to-have, geringste Rechte und Funktionstrennung, Verwaltung von Token, Überprüfung von Personal (Empfehlung), Schutz gespeicherter Passwörter.
• Gruppe 6, Erkennung (6.1 bis 6.5A): Malwareschutz, Integrität von Software und Datenbanken, Protokollierung und Überwachung, Erkennung von Eindringversuchen (Empfehlung).
• Gruppe 7, Vorfallreaktion und Informationsaustausch (7.1 bis 7.4A): Notfallplanung, Sensibilisierung, Penetrationstests (Empfehlung) und szenariobasierte Risikobewertung (Empfehlung).

Ausgewählte Richtwerte aus den Umsetzungshinweisen (eigene Worte; Vorschlag von Swift, keine starre Vorgabe):

• Passwortregeln (4.1, S. 74 bis 75): Swift setzt keine festen Werte für Länge, Ablauf oder Wiederverwendung, sondern verlangt eine Richtlinie nach aktuellem Branchenstand, die diese Punkte festlegt, dazu Kontosperre oder wachsende Verzögerung nach Fehlversuchen; Fehlversuche werden protokolliert, ein Alarm wird ab einer Schwelle empfohlen (fünf aufeinanderfolgende). Beispiel von Swift: ab 15 Zeichen berechnet Windows keinen LM-Hash mehr. Wirksamkeit der Richtlinie empfohlen jährlich überprüfen.
• Multi-Faktor-Authentisierung (4.2, S. 76 bis 77): Software-Token auf einem Mobilgerät sind als Besitzfaktor zulässig; der zweite Faktor darf aber nicht auf demselben Gerät erzeugt werden, auf dem das Passwort eingegeben wird. Hardware-Token sind damit keine Pflicht.
• Berechtigungen (5.1, S. 80): Konten, auch an Dienstleister delegierte, mindestens jährlich überprüfen; ebenso PKI-Schlüssel und Zertifikate.
• Protokollaufbewahrung (6.4, S. 92): Audit-Logs von Messaging- und Communication-Interface sowie Connector-Anwendungen mindestens zwölf Monate und geschützt gegen eine Kompromittierung auf Ebene der Unternehmensadministration; Logs von Operator-PCs, Firewalls und Datenbanken mindestens 31 Tage, bei Firewall und Datenbank empfohlen länger; Logs anderer Komponenten im Scope mindestens zwölf Monate. Gesetzliche und arbeitsrechtliche Vorgaben gehen vor.
• Inaktivitätssperre: Operator-PCs mit Bildschirmsperre, empfohlen nach 15 Minuten (2.3, S. 53); Operator- und Admin-Sitzungen mit einer Sperre, die die Sitzung auf das betrieblich Nötige begrenzt, notfalls auf Betriebssystem- oder Jump-Server-Ebene (2.6, S. 59).

Wie eine Kontrolle aufgebaut ist (S. 27): Nummer und Titel, Art (Pflicht oder Empfehlung), Geltung je Architekturtyp; dann Ziel, Komponenten im Scope und Risikotreiber als verbindliche Definition; schließlich Kontrollaussage, Kontext und Umsetzungshinweise als Vorschlag.

Zwei Wege zur Konformität (S. 28):

• Weg A: Umsetzung nach den Hinweisen von Swift; fehlen Elemente, sind Mitigationen und Besonderheiten bei der Bewertung zu berücksichtigen.
• Weg B: eine Alternative, die die Kontrolldefinition gleich gut erfüllt, bewertet über Wirksamkeit und Risiko.
• Beide gelten aus Risikosicht als gleichwertig; Swift erwartet Alternativen vor allem bei wenigen Nutzern mit hoher Reife im Informationssicherheits-Risikomanagement.
• Nach dem Independent Assessment Framework darf für jede Kontrolle auf aktuelle Zertifizierungen, Audits, andere Bewertungen oder Antworten an die Aufsicht zurückgegriffen werden (S. 28).

Umsetzungsperspektive

• Je Kontrolle Ziel, Scope-Komponenten und Risikotreiber als Maßstab nehmen, nicht die einzelnen Hinweise.
• Für jede Abweichung von den Hinweisen Mitigation und Begründung dokumentieren.
• Vorhandene Nachweise (ISO-27001-Audit, SOC-2-Bericht, Prüfungsberichte) gezielt wiederverwenden, wo sie die Swift-Umgebung abdecken.
• Empfehlungskontrollen priorisiert planen.
• Architekturtyp-abhängige Geltung je Kontrolle aus dem Dokument selbst ablesen.

Typische Fehler

1. Umsetzungshinweise werden wie eine Checkliste abgehakt, ohne das Kontrollziel zu prüfen.
2. Alternativen werden behauptet, aber nicht mit Risikobewertung belegt.
3. Bestehende Zertifikate werden herangezogen, obwohl die Swift-Umgebung nicht in ihrem Geltungsbereich liegt.
4. Empfehlungskontrollen werden als irrelevant abgetan.
5. Geschäftskontrollen für Transaktionen werden der IT überlassen, obwohl sie meist im Fachbereich liegen.
6. Zahlen aus Sekundärquellen werden als CSCF-Vorgabe ausgegeben, etwa Hardware-Token als MFA-Pflicht, feste Passwortlängen und Ablaufzeiten oder quartalsweise Schwachstellenscans; v2027 sieht so nichts davon vor.

Risiken und Trade-offs

Weg A ist einfacher zu begründen, passt aber nicht jeder großen oder komplexen Umgebung. Weg B erlaubt passgenaue Lösungen, verlangt aber eine belastbare Risikobewertung und mehr Begründungsaufwand in der Bewertung. Die Wiederverwendung vorhandener Nachweise spart Aufwand, trägt aber nur, wenn sie aktuell ist und die Swift-Umgebung wirklich abdeckt.

Entscheidungspunkte

• Wo folgen wir den Hinweisen von Swift, wo wählen wir eine Alternative?
• Welche vorhandenen Nachweise decken die Swift-Umgebung tatsächlich ab?
• Welche Empfehlungskontrollen setzen wir in diesem Zyklus um?
• Wer verantwortet die Geschäftskontrollen für ausgehende Transaktionen?

Praktische Empfehlungen

1. Prüfen Sie jede Kontrolle am Ziel, nicht an der Einzelmaßnahme.
2. Dokumentieren Sie Alternativen mit Risikobewertung und Wirksamkeitsnachweis.
3. Nutzen Sie vorhandene Prüfungen nur, wenn ihr Geltungsbereich die Swift-Umgebung umfasst.
4. Planen Sie Empfehlungskontrollen als künftige Pflichten ein.
5. Binden Sie den Fachbereich für Transaktions- und RMA-Kontrollen ein.

Relevante Normreferenzen

• Swift, Customer Security Controls Framework v2027 (10.07.2026), Security Controls Structure, Security Controls Compliance, Security Controls Summary Table, Detailed Control Descriptions 1.1 bis 7.4A.
• Swift Independent Assessment Framework (im Korpus nicht verfügbar).