Die SWIFT hat letztes Jahr im Rahmen des CSP (Customer Security Programme) die v2020 der Customer Security Controls herausgegeben, worüber wir bereits in einem früheren Blogartikel berichtet haben. Da in diesem Jahr die Überprüfung der Einhaltung des Standards durch unabhängige Audits Pflicht wird, ist es Zeit, einen klaren und unverstellten Blick auf den Status Quo zu werfen. Denn wer mag schon unliebsame Überraschungen? In diesem Artikel zeigen wir Ihnen auf, welche Änderungen gegenüber den v2019 Controls durchgeführt wurden, was aus unseren praktischen Erfahrungen als externer Dienstleister und Assessor besonders wichtige Controls sind und wie Sie als Teilnehmer am SWIFTNet die Umsetzung der Kontrollen effektiv anpacken können.
Hinweis: Das SWIFT Security Attestation hat entschieden, dass aufgrund von COVID-19 das ursprünglich veröffentlichte Timing neu gestaffelt wird. Dieses Jahr müssen Unternehmen compliant gegenüber dem CSPv2019 mit Self-Attestation sein. Das «Mandatory» externer Assessments wird auf 2021 verschoben.
Alle Unternehmen, die am SWIFTNet zur Abwicklung des Zahlungsverkehrs teilnehmen (also einen eigenen SWIFT BIC besitzen), müssen die Sicherheitsanforderungen des SWIFT-eigenen Security Standard CSP (Customer Security Programme) erfüllen.
Die SWIFT (kurz für Society for Worldwide Interbank Financial Telecommunication) unterscheidet bei den Controls einerseits bezüglich der Anwendbarkeit (Scope), die je nach Architekturtyp in die Kategorien A (von A1 bis A3) sowie B unterteilt wird – diese werden wir später noch etwas genauer beleuchten. Daneben gibt es die Kategorisierung zwischen «Mandatory» und «Advisory» Controls, wobei die «Mandatory» Controls eingehalten werden müssen; die «Advisory» Controls zur Umsetzung werden lediglich empfohlen. Dabei werden Jahr für Jahr ausgewählte Advisory-Controls in den Status «Mandatory» hochgestuft, weshalb es sich lohnt, auch die Advisory-Controls im Auge zu behalten.
CSP v2020: Worauf gilt es zu achten?
Die in der Version v2020 von Advisory zu Mandatory hochgestuften Controls sind folgende:
- 1.3 Virtualisation Platform Protection / Schutz von virtuellen Umgebungen:
Virtuelle Umgebungen und virtuelle Maschinen (VMs), die SWIFT-Komponenten hosten, müssen gleichermassen geschützt werden wie physische Systeme. - 2.10 Application Hardening / Anwendungshärtung:
Auf SWIFT-zertifizierten Messaging- und Kommunikations-Schnittstellen sowie deren zugehörigen Anwendungen, muss die Angriffsfläche durch Härtung der Applikation reduziert werden.
Folgende neue Advisory Control ist in der v2020 hinzugekommen:
- 1.4A Restriction of Internet Access / Einschränkung des Internetzugriffs:
Innerhalb der geschützten SWIFT-Zone sollen Anwender-PCs und andere Systeme einen eingeschränkten Internet-Zugriff haben, um die Gefahr von Internet-basierten Angriffen zu verringern.
Anpassung der Anwendbarkeit (Scope):
- 2.4A Back Office Data Flow Security / Sicherheit der Datenflüsse im Back Office:
Wurde zu «Advisory» ernannt, sofern Middleware / MQ Server genutzt werden (Architekturtyp A3 – Variante «Middleware Server (as connector)») - Die Kontrollen zu RMA (Relationship Management Application) sowie Kontrollen zur Sicherheit von Transaktionen wurden in zwei separate Advisory-Controls aufgesplittet:
- Neu: 2.11A RMA Business Control / Kontrollen von RMA-Geschäften
- Neu: 2.9A Transaction Business Controls / Kontrollen des Transaktionsgeschäfts:
Dabei sollen Massnahmen in der RMA (Relationship Management Application) implementiert werden, um die Transaktions-Aktivitäten auf tatsächliche geschäftliche Gegenparteien zu beschränken. Das Risiko, mit einer unautorisierten Gegenpartei eine Transaktion durchzuführen, soll damit verringert werden. Die SWIFT weist jetzt schon darauf hin, dass diese Massnahme in einer nächsten Version des Dokuments (v2021) zu Mandatory hochgestuft wird.
SWIFT weist im Customer Security Controls Framework (CSCF) ausdrücklich darauf hin, dass das Framework nicht als «Audit-Checkliste» verwendet werden soll. Die beschriebenen Umsetzungsrichtlinien sind lediglich als Hinweise und Möglichkeiten zu verstehen. Es sind somit jeweils auch Implementierungen möglich, die von den Umsetzungsrichtlinien abweichen. Die Implementierung soll dabei risikobasiert vorgenommen werden. Dieser Umstand ist auch vom Prüfer zu berücksichtigen.
Was spricht für einen CSP-Architekturtyp?
Die SWIFT stellt eine nützliche Anleitung zur Bestimmung des CSP-Architekturtyps zur Verfügung. Allerdings wird ausgeführt, dass die untenstehenden, beispielhaften Veranschaulichungen keine «einschränkende Bedeutung» haben. Oder anders ausgedrückt: Man kann sich zur definitiven Bestimmung des Architekturtyps nicht auf die (allgemein formulierten) Grundsätze und Beispiele berufen – dazu gelten die Richtlinien der SWIFT.
Wenn Sie folgende Produkte im Einsatz haben und diese unter Ihrer Kontrolle stehen («I own»), finden Sie hier eine tabellarische Übersicht der in Frage kommenden Architekturtypen:
| Architekturtyp | Indikative Komponente |
| B |
|
| A1 |
|
| A2 |
|
| A3 |
|
Das folgende Beispiel zeigt schematisch den Architekturtypen A1. Es gibt beim Architekturtypen A durch SWIFT insgesamt drei Varianten mit mehr oder weniger SWIFT-Komponenten (messaging interface, communication interface, RMA etc.), die durch den Teilnehmer kontrolliert werden.
Erwähnenswert ist insbesondere der «Middleware Server». Sofern ein solcher Server als «Connector» die lokalen SWIFT-Komponenten verbindet, wird dies neu als Architekturtyp A3 eingestuft. (Bisher wurde dies eher dem Architekturtypen B zugeordnet).
Dem gegenübergestellt sehen Sie in der nachstehenden Abbildung ein schematisches Beispiel des Architekturtyps B «ohne lokalen User-Footprint». Die SWIFT-Komponenten stehen dabei nicht unter der Kontrolle der Teilnehmer, sondern werden (vollständig) durch einen Service Provider betrieben. Die Teilnehmer greifen über eine Schnittstelle (API) und / oder eine (Web-)Applikation auf das SWIFT-Netzwerk zu.
Wichtige SWIFT CSP-Kontrollen aus unserer Erfahrung – wie können diese adressiert werden?
Die SWIFT CSP-Kontrollen können in drei Kategorien zusammengefasst werden:
- Sichere deine Umgebung
- Kenne und begrenze den Zugriff
- Erkenne und reagiere
Im CSCF sind 31 Sicherheitskontrollen aufgeführt, wovon 21 (für Typ A; 14 für Typ B) obligatorisch sind und 10 empfehlenden Charakter haben. Innerhalb jeder Sicherheitskontrolle hat die SWIFT die häufigsten Risikotreiber dokumentiert, zu deren Abschwächung die Kontrolle führen soll.
Aus unserer Erfahrung sind folgende Kontrollen in der praktischen Umsetzung herausfordernd.
1: «Sichere deine Umgebung»
2.2 Sicherheitsupdates:
Sicherheitsupdates werden zwar eingespielt, doch die Herausforderung in der Praxis ist die möglichst lückenlose Umsetzung. Das heisst, dass alle Applikationen, Betriebssysteme und Systemkomponenten zeitnah und regelmässig mit Sicherheitsupdates versehen werden sollen. Ebenfalls ist es in der Praxis nicht immer möglich, Sicherheitsupdates «umgehend», also innerhalb weniger Stunden oder Tage, auf allen Systemen auszurollen. Zusätzlich stellt die Integritätsprüfung (Validierung von Check-Summen und digitalen Signaturen von Sicherheitsupdate-Files) zusätzliche Anforderungen an Aufwand und Prozessabläufe.
Ideale Umsetzung: Sicherheitsupdates werden lückenlos auf SWIFT-Systemen eingespielt; spätestens wenige Tage nach deren Verfügbarkeit. Dies bedingt entsprechend auch die dazu notwendigen Testkapazitäten vor dem Roll-out von Security Patches. Generell ist bei CVSS-Scores von über neun geboten, einen Security Patch so rasch wie möglich auszurollen.
2.3 Systemhärtung / Absicherung:
Die Kontrolle ist eher vage spezifiziert und je nach System-Hersteller gibt es zur Härtung keine Anleitung. Die Umsetzungsrichtlinien der SWIFT enthalten aber nützliche Hinweise, beispielsweise auf CIS (CIS Hardened Images). Solche Richtlinien sollten bei der Härtung von Systemen angewendet werden, und zwar so umfassend wie möglich.
2: «Kenne und begrenze den Zugriff»
2.6 Vertraulichkeit und Integrität der Benutzersitzung:
In Unternehmensnetzwerken werden interne Systemverbindungen (Client-zu-Server, Server-zu-Server) noch nicht überall flächendeckend und konsequent verschlüsselt. Nach dem Grundsatz «encrypt everything» sollte in einer modernen Infrastruktur grundsätzlich jede Kommunikationsverbindung – sowohl interne als auch externe – verschlüsselt werden. SWIFT empfiehlt an dieser Stelle den Einsatz von aktuellen Algorithmen und Protokollen, in diesem Sinne also mindestens TLS v1.2 und auf keinen Fall SSL. Ebenfalls zu berücksichtigen sind Time-Out-Einstellungen bei Inaktivität (Idle Time-Out), die auf angemessene Werte konfiguriert werden sollen. Üblich sind zehn bis zwanzig Minuten.
4.2 Authentifizierung mit mehreren Faktoren:
Bei der sogenannten MFA (Multi-Faktor Authentifizierung), früher auch als 2FA (Zwei-Faktor-Authentifizierung) bezeichnet, wird von der SWIFT erwartet, dass:
- zum einen der Anwenderzugang zu SWIFT-relevanten Anwendungen explizit erwähnt ist («dedicated operator PC / dedizierte SWIFT-Arbeitsplätze», «jump server» (wenn vorhanden und messaging/communication interfaces (sofern Typ A)).
- und zum anderen – insbesondere – auch deren Betriebssysteme mit MFA geschützt wird.
In der Praxis wird MFA vornehmlich im Bereich des Fernzugriffs (Remote Access) eingesetzt, jedoch weniger ausgeprägt bei Anwendungen und (internen) Systemen (Betriebssystem). Eine solch umfassende Umsetzung wird leider auch von Herstellern nicht immer unterstützt – eine gründliche Konzipierung von unternehmensinterner Multi-Faktor Authentifizierung ist damit kritisch. MFA sollte heutzutage beispielsweise über eine Out-of-Band-Kommunikation wie Authenticator Apps erfolgen.
3: «Erkenne und reagiere»
6.4 Protokollierung und Überwachung & 7.1 Aktionsplanung für Cybervorfälle:
Zunehmend wird in Unternehmens-Systemumgebungen umfassend protokolliert. Trotzdem sind die Fähigkeiten zur effektiven Entdeckung von ungewöhnlichen Aktivitäten noch weniger vorhanden. Entsprechend schwierig wird es, einen Aktionsplan bei (erkannten) Sicherheitsvorfällen auszulösen. Es empfiehlt sich die Erstellung eines Reaktionsplans, der idealerweise verschiedene Vorfall-Szenarien berücksichtigt und mit individuellen Verfahren auf Cybervorfälle reagiert. Dazu bedarf es die Kooperation mit verschiedenen Fachstellen im Unternehmen. Anschliessend dürfen auch regelmässige Tests der Entdeckungs- und Reaktionsfähigkeiten in diesem Bereich nicht vernachlässigt werden.
Diese Aufzählung stellt keinesfalls eine abschliessende Liste von wichtigen Kontrollen dar und soll nicht zur Priorisierung oder Gewichtung von Kontrollen herangezogen werden. Nichtsdestotrotz können wir aus Erfahrung sagen, dass sie diese Punkte im Auge behalten sollten.
SWIFT Compliance sicherstellen – handeln Sie jetzt
Die Attestation-Phase für CSCF v2020 endet (neu!) im Dezember 2021. Sind Sie sich über den aktuellen Stand Ihrer Compliance im Klaren? Benötigen Sie Unterstützung bei der Interpretation und Umsetzung der notwendigen Massnahmen? Suchen Sie einen qualifizierten externen Dienstleister, der in Ihrem Unternehmen das Assessment durchführt?
InfoGuard ist SWIFT CSP Assessment-, sowie Cyber Security Service-Provider und kann ein Compliance-Assessment für die im zweiten Halbjahr 2020 notwendige Bestätigung vornehmen. Wir stehen Ihnen gerne zur Verfügung bezüglich Unterstützung bei der Umsetzung der SWIFT CSCF-Kontrollen oder für ein Compliance Assessment Ihrer Umsetzung des SWIFT CSP. Mit unserem SWIFT-Assessment erhalten Sie einen umfassenden Überblick über Ihren IST-Zustand sowie Massnahmenempfehlungen, um die Compliance v2020 zu erfüllen. Mehr Informationen und ein Kontaktformular finden Sie hier:
Note: SWIFT does not certify, warrant, endorse or recommend any service provider listed in its directory and SWIFT customers are not required to use providers listed in the directory.
Quellen:
- Tabelle: SWIFT «Decision Tree Guidance»
- Grafiken: «SWIFT Customer Security Controls Framework v2020 – Detailed Description»
