Principaux enseignements
- La version 2026 du CSCF a déjà élargi le périmètre d'application, en intégrant les connecteurs clients (tels que les points de terminaison d'API , les intergiciels et les clients de transfert de fichiers) dans le champ d'application de 14 contrôles, en fonction du type d'architecture.
- La version v2027 du CSCF poursuit cette évolution vers un champ d'application élargi avec 32 contrôles, dont 26 obligatoires, en vue de la période d'attestation prévue de juillet à décembre 2027.
- Les classifications architecturales antérieures à la version 2026 pourraient devoir faire l'objet d'une réévaluation en cas de présence de connecteurs client ou d'autres facteurs modifiant le périmètre ; les évaluateurs examineront le deuxième cycle de périmètre élargi.
- Un principe de sécurité concret pour le périmètre étendu consiste à inspecter, à assainir et à contrôler les fichiers et les flux de données avant qu’ils n’atteignent l’infrastructure de paiement critique.
- Les points de contrôle mis en place le long de ces flux peuvent fournir des éléments utiles à des fins d'enregistrement, de suivi et de certification, même si la conformité reste de la responsabilité de l'institution.
Préparation à l'évaluation CSCF de 2027
La plupart des établissements connectés à Swift peuvent définir leur « zone d’ Secure » à partir de leur propre expérience : l’interface de messagerie, les serveurs relais, le segment sécurisé où transite le trafic de paiement. Il s’agit là de l’un des secteurs les mieux protégés au sein de l’organisation. La norme CSCF v2027 s’interroge sur le niveau de protection de tous les éléments qui y mènent.
Le changement le plus important a déjà eu lieu. La version CSCF v2026, publiée en juillet 2025, a rendu obligatoire la mise en œuvre progressive du contrôle 2.4, « Sécurité des flux de données back-office », et a intégré les connecteurs clients dans le champ d'application de 14 contrôles.
Les échanges de données directs hérités du back-office restent pour l'instant à titre indicatif, la date de 2028 étant provisoirement envisagée pour une future transition obligatoire. Le cadre actuel compte 32 contrôles de sécurité répartis en sept principes, dont 26 sont obligatoires, et le champ d’application élargi est maintenu pour le cycle 2027. La version CSCF v2027, publiée en juillet 2026, n’ajoute aucun nouveau contrôle obligatoire mais intègre la norme SKV (Secrets and Keys Vault ) dans le champ d’application de la plupart d’entre eux. Les contrôles consultatifs restent des pratiques recommandées qui pourraient devenir obligatoires dans des versions ultérieures. Les institutions procèdent à leur première attestation au regard du champ d’application élargi entre juillet et décembre 2026, et la période d’attestation pour la version v2027 s’étend de juillet à décembre 2027, sur la base d’une évaluation indépendante.
Si la classification de votre architecture date encore d’avant la version 2026, réévaluez-la dès maintenant, en particulier si des connecteurs client, des flux de fichiers externes ou de nouveaux chemins d’intégration ont été mis en place depuis la dernière évaluation. Les équipes dont la première attestation à champ élargi est le fruit d’une improvisation devront faire face, en 2027, à des évaluateurs qui s’attendront à ce que le travail sous-jacent ait été mené de manière réfléchie. Quoi qu’il en soit, la question est de savoir si votre architecture de sécurité est prête pour ce qui se trouve désormais au-delà de la zone « Secure ».
Les connecteurs client et l'élargissement du champ d'application
Un environnement de paiement est rarement attaqué par son point le plus fort. Les fichiers et les données parviennent aux systèmes liés à Swift via les portails clients, les téléchargements effectués par les partenaires, les plateformes de transfert de fichiers gérées, les files d’attente des intergiciels, les intégrations « API » et les supports amovibles introduits dans le centre de données. Chacun de ces canaux peut acheminer du contenu malveillant ou non fiable vers une infrastructure que les analyses d’architecture antérieures considéraient comme hors de danger.
Le cadre considère désormais ces chemins d’accès comme faisant partie intégrante de l’architecture de sécurité concernée. Les connecteurs clients sont inclus dans le champ d’application par leur nom : points de terminaison « API », intergiciels et clients de transfert de fichiers, qu’ils s’exécutent sur des serveurs ou sur des terminaux clients. L’examen s’étend au logiciel lui-même, depuis les mises à jour de sécurité et l’analyse des vulnérabilités jusqu’à l’intégrité du logiciel, soumettant ainsi le code des connecteurs internes au même examen que les fichiers qu’ils transportent.
Si la classification de votre architecture est antérieure à la version 2026, les composants que vous considériez auparavant comme hors périmètre (un service de téléchargement destiné aux clients, un bus d'intégration ou un serveur de transfert de fichiers) pourraient devoir faire l'objet d'une réévaluation, en particulier lorsqu'ils utilisent ou constituent un connecteur client.
Notre infographie Swift présente ces points d'accès sur une seule page.
Pour les responsables de la sécurité, les enjeux se résument à deux scénarios. Un fichier malveillant qui parvient à pénétrer l'infrastructure de paiement menace la disponibilité même de l'activité de paiement, et une lacune de couverture découverte lors d'une évaluation devient un constat documenté porté à la connaissance du conseil d'administration. Chacune de ces conséquences coûte plus cher que la réévaluation qui permettrait de les éviter.
La sécurité des fichiers doit faire partie intégrante de votre analyse d'architecture
La quasi-totalité des canaux couverts par ce champ d'application élargi a pour but de transférer des fichiers ou des données structurées : téléchargements provenant de clients et de partenaires, transferts par lots entre institutions, pièces jointes transitant par des intergiciels et fichiers acheminés au-delà des limites de l'API . Un moteur antivirus unique déployé à la périphérie du réseau a été conçu pour répondre à un problème plus restreint que celui-ci.
La sécurité des fichiers relève donc d'un choix architectural. Un principe pratique consiste à inspecter, à assainir et à contrôler les fichiers et les flux de données avant qu'ils n'atteignent l'infrastructure de paiement critique, tout en veillant à ce que les contrôles mis en œuvre soient adaptés à chaque flux et au risque qu'il présente.
Vérification des fichiers avant leur transmission aux systèmes de paiement
Un partenaire télécharge un lot de factures via votre portail client. Le fichier est acheminé vers une plateforme de transfert de fichiers gérée, où une file d’attente de middleware le récupère ; un service d’intégration reformate ensuite son contenu, et le résultat est transmis à une application disposant d’un chemin d’accès vers les systèmes connectés à Swift. Quatre étapes séparent un fichier externe de l’infrastructure de paiement critique, et dans de nombreuses institutions, chaque étape se fie à celle qui la précède.
L'application du principe « inspecter, assainir et contrôler » implique la mise en place d'un contrôle spécifique à chaque étape du processus. MetaDefender™ Core et MetaDefender ICAP Server analysent les fichiers téléchargés via des applications web destinées aux clients, via l'intégration REST API ou ICAP . MetaDefender Managed File Transfer inspecte le contenu circulant entre les systèmes de back-office et ceux liés à Swift, conformément à la norme Control 2.4, « Sécurité des flux de données de back-office ».
Les deux fichiers sont acheminés via Metascan™ Multiscanning, où plus de 30 moteurs anti-malware effectuent une analyse en parallèle. Cette analyse multi-moteurs prend en charge Control 6.1 et la protection contre les logiciels malveillants, détectant les contenus malveillants connus avec une précision supérieure à celle de n’importe quel moteur utilisé seul. La technologie Deep CDR™ assainit et régénère ensuite chaque fichier pris en charge, en supprimant le contenu actif intégré avant que le fichier ne poursuive son chemin. Les fichiers suspects sont acheminés vers Adaptive Sandbox , où une analyse basée sur l’émulation permet de détecter les menaces furtives et de type « zero-day », conformément à la recommandation Control 6.5A, « Détection des intrusions ».
Ce même traitement s'étend aux référentiels de stockage où sont conservées les sauvegardes et les extraits, Proactive DLP™ vérifiant la présence de contenus sensibles dans les fichiers au repos. Il couvre également les supports amovibles et les périphériques temporaires, que MetaDefender Kiosk et MetaDefender Drive analysent et nettoient à un point de contrôle avant leur entrée, conformément à la norme Control 3.1, « Sécurité physique ».
En ce qui concerne les logiciels de connecteurs développés en interne, MetaDefender ,Software etSupply Chain analysent les paquets et leurs dépendances à la recherche de vulnérabilités et de composants malveillants avant leur déploiement, ce qui répond aux exigences des contrôles 2.2 (« Mises à jour de sécurité »), 2.7 (« Analyse des vulnérabilités ») et 6.2 (« Intégrité de l'Software »).
Il en résulte une couche de prévention appliquée de manière cohérente à l'ensemble des flux de fichiers qui la traversent, placée en amont des systèmes qu'elle est censée protéger.
Les rapports d'inspection qui étayent votre évaluation
Lorsque la période de 2027 s'ouvrira en juillet, les évaluateurs examineront le deuxième cycle d'attestation dans le cadre du champ d'application élargi, et les preuves attestant de l'existence et du bon fonctionnement des contrôles auront plus de poids que les intentions déclarées.
Les points de contrôle mis en place tout au long de vos flux de fichiers et de données peuvent générer des éléments de preuve utiles : événements de contrôle, pistes d’audit transmises à votre SIEM et enregistrements relatifs à l’application des politiques, qui documentent la manière dont le contenu est examiné lors de son acheminement vers les systèmes de paiement. Ces éléments de preuve viennent étayer le contrôle 6.4, « Journalisation et surveillance », ainsi que l’attestation CSCF elle-même.
La conformité reste de la responsabilité de l'établissement lui-même, et les évaluateurs examinent l'architecture dans son ensemble. Ce travail aboutit à une réponse défendable à la question centrale posée par l'évaluateur : quels éléments peuvent accéder à votre infrastructure de paiement, et que leur arrive-t-il en cours de route ?
Trois questions à poser à votre équipe d'architectes
Trois questions permettent de dresser un premier bilan utile en vue de la période de 2027 :
- Quels fichiers externes et flux de données peuvent, en fin de compte, atteindre votre infrastructure de paiement ?
- Comment les fichiers sont-ils vérifiés avant d'être intégrés aux flux de travail liés à Swift ?
- L'élargissement du champ d'application du CSCF modifie-t-il votre classification architecturale actuelle ou vos contrôles ?
Notre fiche technique SWIFT CSCF v2027 résume en quelques pages le champ d'application élargi, l'infrastructure concernée et les contrôles préventifs pertinents ; vous pouvez la partager avec les équipes chargées de l'architecture et de la GRC.
Télécharger la fiche technique du SWIFT CSCF v2027
Si vous préférez explorer votre propre environnement, n'hésitez pas à discuter avec un expert d'OPSWAT et à apporter avec vous la classification actuelle de votre architecture.
