28/02/2024
Cybersecurity Insights
SWIFT CSP : Les évolutions du référentiel pour 2023
Comme chaque année, SWIFT met à jour son standard CSCF et apporte son lot de nouveautés. Notre démarche Almond prévoit une phase d’évaluation à blanc fortement recommandée et réalisable dès maintenant afin de vous positionner vis-à-vis de ces nouvelles exigences.
Dans une logique proactive, nous vous proposons ici quelques clés de lecture associées aux changements fondamentaux apportés par le CSCF v2023.
Disparition du « Delta Assessment »
Le concept de delta-assessment présent en 2022, permettait à un évaluateur SWIFT de s’appuyer sur l’évaluation de 2021 pour l’évaluation de certaines exigences, sous réserve de critères spécifiques définis dans le cadre d’évaluation indépendante SWIFT.
En 2023 le concept de delta-assessment disparait. L’évaluateur se trouvera dans l’obligation de procéder à la réévaluation de la totalité des exigences associées au type d’architecture du client SWIFT. Il sera donc nécessaire en début de cycle d’évaluer pour chacun des contrôles indépendamment si une itération complète de l’évaluation s’avère être nécessaire, ou si les constats de l’année précédentes peuvent être réutilisés, en totalité ou en partie, afin de statuer sur le niveau de conformité des pratiques associées, à condition que le contexte de l’évaluation demeure identique.
Cela vient renforcer notre recommandation que vous retrouverez dans notre article précédent, anticipez l’évaluation SWIFT dès que possible et n’attendez pas le dernier moment !
A noter cependant que si le contexte et donc les constats sont identiques d’une année sur l’autre, l’évaluateur a tout de même la possibilité de s’appuyer sur les conclusions de l’année passée pour justifier d’un résultat conforme ou non.
Revue des types d’architecture
Nouveauté importante et pouvant avoir un impact sur votre conformité, le CSCF v2023 fait évoluer les architectures de type A3, A4 et B.
Pour bien comprendre les évolutions, le standard met l’accent sur la notion de « client » et de « serveur ». Quelques définitions ici :
Le connecteur client comprend notamment les solutions génériques de transfert de fichiers utilisées pour faciliter la communication avec les composants relatifs à SWIFT proposées par un prestataire de service.
Le serveur middleware fait référence aux systèmes locaux utilisés pour l’échange de données entre les composants en lien avec SWIFT (dans l’infrastructure SWIFT locale ou chez un prestataire de services). Celui-ci doit être considéré comme un connecteur client lorsqu’il est utilisé pour faciliter la communication avec les composants liés à SWIFT proposés par un prestataire de services.
Ainsi, l’architecture A4 fait référence à un environnement utilisateur SWIFT où il n’existe pas d’empreinte SWIFT mais qui utilise un serveur exécutant une application (telle qu’une solution de transfert de fichiers, ou un système middleware qui est un connecteur client) pour faciliter la communication d’application à application avec une interface chez un prestataire de service (par exemple un service bureau).
Une note spécifique est mise en avant pour indiquer la possibilité d’une migration vers l’architecture de type A4 :
- Pour les utilisateurs ayant précédemment attesté comme Architecture B parce qu’ils utilisent, comme connecteur client, un serveur middleware pour se connecter à un prestataire de services.
- Pour les utilisateurs ayant précédemment attesté comme Architecture A3 parce qu’ils utilisent, comme connecteur client, un serveur de transfert de fichiers ou un serveur middleware pour se connecter à un prestataire de services sans avoir de connecteur SWIFT.
Les architectures de type B sont donc réservées aux environnements disposant uniquement d’outils back-office et de client de transferts de fichiers. Les architectures de type A4, elles, sont liées aux environnements disposant d’un serveur de transfert de fichiers permettant de faire le lien avec un service bureau par exemple.
La migration vers une architecture de type A4 aura pour conséquence de redéfinir les exigences applicables à l’environnement utilisateur, notamment pour les anciennes architectures de type B, le besoin d’un environnement client sécurisé (exigence 1.5) peut entraîner des travaux relativement importants.
Nous recommandons donc fortement de revoir l’implémentation faite au sein de votre environnement afin de vous assurer que votre architecture et les exigences associées n’ont pas évolué.
Protection de l’environnement client
En lien avec l’évolution des architectures, le CSCF 2023 a fait évoluer l’exigence 1.5 « Protection de l’environnement client » pour la rendre obligatoire, uniquement pour les architectures de type A4.
Les architectures de type A1, A2 et A3 disposent déjà d’une exigence similaire « protection de l’environnement SWIFT » ayant pour objectif de cloisonner l’environnement SWIFT du reste du système d’information du client, afin de limiter les risques de latéralisation d’un attaquant ayant déjà un pied sur l’environnement du client.
Avec cette exigence, SWIFT cherche à protéger les systèmes utilisés pour faire le lien entre le back-office du client et son service bureau. Ces systèmes s’ils sont laissés sans protection pourraient permettre à un attaquant de modifier les transactions ou même de mener des attaques permettant de compromettre l’environnement SWIFT externalisé.
Cette exigence peut être lourde à porter pour des clients de taille réduite, notre conseil est le suivant :
Réalisez une évaluation à blanc au plus tôt pour disposer d’une analyse d’écart exhaustive, vous permettant une prise de décision éclairée :
- Commencer rapidement les travaux de mise en conformité
- Envisager une évolution de votre périmètre pour migrer vers une architecture de type B moins contraignante
Conclusion
Le CSCF est un framework complet, reprenant des exigences connues et éprouvées dans d’autres référentiels, permettant aux CISO et à leurs équipes de traiter ces sujets de manière transverse, et non pas seulement pour se mettre en conformité avec le CSP. D’autres mesures sont en revanche orientées SWIFT, avec leurs spécificités, afin de répondre au mieux aux différents risques identifiés pour chaque thème de la sécurité.
Le CSP n’est donc pas une contrainte, il s’agit d’un recueil de bonnes pratiques repris de différents référentiels et standards en la matière. La plupart de ces mesures sont déjà mises en place par les clients, avant même de commencer l’évaluation, car la gouvernance de la sécurité impose de les considérer dans la politique de l’entreprise.
Des nouveautés font leur apparition chaque année, qu’il faut analyser et considérer au cas par cas, selon son contexte et une étude d’opportunité doit logiquement en découler.
Ces dispositions doivent être considérées afin de mettre toutes les chances de son côté dans le cadre de la réalisation des activités relatives à l’évaluation CSP, afin de reprendre l’objectif principal de SWIFT au travers de cette démarche, à savoir promouvoir les actions permettant de gagner en maturité sur le thème de la cybersécurité, mais également générer et maintenir la confiance entre toutes les parties prenantes de la chaîne d’utilisateurs et de prestataires utilisant des services fournis par SWIFT.
Thierry CASIER
Manager Governance, Risks & Compliance
François PETIOT
Consultant Governance, Risks & Compliance
Pierre ZORDAN
Consultant Governance, Risks & Compliance
Nos valeurs
Excellence
- Dépasser sans cesse nos limites
- Encourager les initiatives
- Améliorer nos services
- Former nos équipes
- Accompagner nos clients
L’excellence est notre énergie.
Innovation
- Nous ouvrir au monde
- Explorer les nouvelles technologies
- Inventer de nouvelles solutions
- Être visionnaire
L’innovation donne un temps d’avance à nos clients.
Engagement
- Ne jamais rien lâcher
- Dépasser les attentes,
- S’engager sur des résultats
- Faire progresser ensemble
Notre engagement forge notre succès.
Titre de la section
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
