05/06/2023
Cybersecurity Insights
Evaluation SWIFT : rétrospective des évaluations 2022 pour planifier sereinement l’exercice 2023
Depuis 2021, tous les clients SWIFT se trouvent dans l’obligation de réaliser une évaluation de conformité dans le cadre du Customer Security Program (CSP) de SWIFT. C’est dans ce cadre que ces derniers sont amenés à réaliser ces activités d’évaluation en interne ou à les faire réaliser par des évaluateurs indépendants externes tels qu’Almond, afin de démontrer leur niveau de conformité.
Rappel du contexte et des enjeux de SWIFT
Le CSP s’appuie sur le CSCF (Customer Security Controls Framework) qui inclut en 2023 :
- d’une part 24 mesures de sécurité obligatoires pour les utilisateurs de SWIFT et définies pour un type d’architecture (A1, A2, A3, A4 ou B) ; Ces architectures peuvent pour un BIC unique inclure différents éléments techniques et fonctionnels
- d’autre part 8 mesures de sécurité recommandées que les utilisateurs peuvent mettre en œuvre dans leur environnement relatif à l’utilisation des services SWIFT
- Cette évaluation doit être réalisée sur le périmètre de responsabilité de chaque utilisateur, et sur la totalité des mesures du Framework concernant la ou les architectures employées
Chaque utilisateur SWIFT peut attester de sa conformité vis-à-vis du framework, et ainsi participer au maintien de la confiance entre les différents maillons de la chaîne SWIFT.
Les attestations d’évaluation du niveau de conformité devront être ensuite publiées par les utilisateurs dans l’application KYC-SA de SWIFT (Know Your Customer – Security Attestation) pour le ou les BIC associés, jusqu’au 31 décembre de chaque année.
Comment se déroule une évaluation de conformité SWIFT ?
Chaque utilisateur consommant des services SWIFT doit se conformer à cet exercice.
Celui-ci doit se dérouler entre juillet et décembre de chaque année, avec l’obligation de compléter le formulaire (KYC) afin de détailler pour chaque mesure, le niveau de conformité associé.
Il est alors nécessaire de faire réaliser cette évaluation soit par une équipe d’audit interne (indépendante des équipes métiers, et IT / sécurité), soit par un prestataire indépendant, spécialisé dans l’audit de sécurité et référencé sur le site de SWIFT comme étant habilité à mener ce type de démarches.
Almond accompagne ainsi depuis 2021 plusieurs dizaines d’entreprises dans la réalisation de leur évaluation de conformité SWIFT et l’amélioration du niveau de sécurité de leur environnement.
Quelques chiffres sur plusieurs dizaines de clients évalués par Almond
Suis-je éligible à l'évaluation SWIFT ?
Les principes suivants s’appliquent dans la grande majorité des contextes. Aussi, seront éligibles les entreprises concernées par un ou plusieurs de ces cas de figure :
Je suis une grande entreprise
J’utilise des applications de trésorerie et les services SWIFT, en direct ou via certains prestataires (notamment les services bureaux), je suis éligible au programme CSP et donc à l’évaluation de conformité SWIFT.
Je suis une PME ou TPE
J’utilise les services SWIFT, je suis également éligible, au même titre que les grandes entreprises. La plus simple architecture est généralement utilisée dans ce contexte (Architecture de type B, avec une application SaaS de trésorerie)
Je suis une PME ou TPE
J’utilise les services SWIFT, je suis également éligible, au même titre que les grandes entreprises. La plus simple architecture est généralement utilisée dans ce contexte (Architecture de type B, avec une application SaaS de trésorerie)
En cas de non-réalisation de ces évaluations, et donc d’absence de complétion du KYC, ou de démarche inadaptée (autre qu’audit de seconde ou tierce partie), les accès aux services SWIFT ne seront pas suspendus.
Néanmoins SWIFT sera en mesure de communiquer cette non-conformité vers tous les partenaires et clients de l’entreprise en défaut, utilisateurs également de ces services, avec ce que cela implique en termes de déficit d’image et de confiance.
SWIFT se réserve également le droit dans le CSP d’exiger une évaluation indépendante auprès du client SWIFT pour s’assurer de son niveau de conformité au standard.
Retour d'expérience de la campagne 2022
L’année 2022 a été marquée par une campagne intense, avec une sensible hausse des demandes d’évaluations SWIFT pour la seconde année consécutive. Almond a eu l’opportunité d’accompagner plusieurs dizaines de ces entreprises, évoluant dans différents secteurs d’activités, avec un dénominateur commun, les efforts orientés vers la réduction du risque cyber et la conformité au framework CSCF.
Fort de cette expérience, nous souhaitons aujourd’hui partager avec vous les principaux concepts et points du référentiel qui font parfois l’objet d’incompréhensions, ou d’un manque de rigueur.
Quand réaliser l’évaluation ? Le plus tôt sera le mieux !
Vous le savez, les évaluations SWIFT peuvent être complétées à partir du mois de juillet et ce jusqu’au 31 décembre de l’année en cours.
Sur la base d’une évaluation SWIFT positive l’année précédente, il est très fréquent de retarder l’évaluation, parfois jusqu’au dernier moment. En effet, nous avons pu constater que 60% des évaluations SWIFT ont lieu sur les deux derniers mois !
Il est cependant nécessaire de rester vigilant, chaque année le CSCF est mis à jour et comporte de nouvelles instructions qui nécessiteront peut-être des travaux importants pour vous mettre en conformité. L’évolution du contexte cyber est également pris en compte par les évaluateurs, des mesures jugées nécessaires et suffisantes en 2022, ne le seront peut-être plus en 2023. Il est donc important d’assurer une veille portant sur l’état des menaces (Almond Threat Landscape), et les évolutions des référentiels pour la conformité.
Pas d’inquiétude cependant, au sein d’Almond nous avons conscience des enjeux associés à l’évaluation SWIFT et nous proposons plusieurs approches, complémentaires et pragmatiques, permettant de réaliser ces activités dans les temps et sans pression.
La méthode est basée sur une évaluation à blanc pouvant être réalisée à tout moment de l’année afin de sécuriser la démarche et évaluer le niveau de conformité de façon plus sereine, permettant de disposer du plan d’action détaillé permettant un gain majeur en termes de maturité Cyber, mais également en termes de conformité vis-à-vis de SWIFT.
Authentification Multi-Facteurs (MFA), un sujet simple pourtant si complexe
L’authentification multi-facteurs est largement répandue dans nos accès quotidiens, à nos outils collaboratifs, ou nos applications métiers, notamment dans le cadre du télétravail pour permettre les connexions à distance à ces environnements.
Dans ses principes fondamentaux, l’exigence 4.2 du CSCF reprend les meilleures pratiques en la matière et requiert l’utilisation de 2 facteurs à minima parmi les suivants :
- Ce que je sais (tel qu’un mot de passe) ;
- Ce que j’ai (tel qu’un token USB, un TOTP, une carte à puce ou une 3skey pour les signataires) ;
- Ce que je suis (tel qu’une empreinte digitale par exemple).
Cependant, d’autres éléments sont à prendre en compte dans l’implémentation du MFA pour être conforme au CSCF et leur manque de considération peut induire un risque pour l’entreprise.
En premier lieu, lorsqu’un facteur de connaissance (mot de passe) est combiné avec un facteur de possession (tel qu’un TOTP), l’équipement utilisé pour obtenir le facteur de possession doit être distinct de celui utilisé pour renseigner le premier facteur.
L’utilisation du même équipement, très souvent l’ordinateur portable du collaborateur, pourrait permettre à un individu malveillant ayant compromis cet équipement d’obtenir les deux facteurs nécessaires à la connexion à l’environnement associé à SWIFT.
L’implémentation de ces facteurs sur le même équipement est souvent liée à un besoin de simplifier l’usage. Ainsi, bien que des mesures techniques complémentaires pourraient être mises en place pour protéger de manière plus adéquate le second facteur pour ce cas d’usage précis, cela nuirait à l’objectif premier de simplicité et il est bien souvent plus simple de séparer les équipements.
Enfin, il a été constaté une autre dérive liée au MFA bien souvent incomprise des utilisateurs SWIFT. Dans le cas d’une architecture de type B, aucune emprise SWIFT n’est dans le périmètre de responsabilité du client (hormis bien entendu les postes utilisateurs de l’entreprise. Le client ne dispose donc pas de zone sécurisée en interne (au sens SWIFT, comme des serveurs applicatifs interfacés directement à SWIFT ou à un service bureau par exemple) et dispose bien souvent uniquement d’un accès à la GUI qui est alors le seul composant dans le périmètre de l’exigence liée au MFA.
Certains clients ont donc réalisé l’implémentation suivante :
- L’utilisateur se connecte au réseau de l’entreprise (via MFA) ;
- L’utilisateur se connecte ensuite à l’interface GUI de l’application via un compte local à l’application et un mot de passe séparé.
Cette implémentation présente cependant plusieurs défauts :
- L’objectif de SWIFT, tel que cela peut être constaté à travers les exigences 1.1 et 1.5 sur les environnements sécurisés, est de protéger l’environnement SWIFT considéré de confiance de menaces en provenance du reste du SI qui pourrait être potentiellement compromis. C’est donc bien l’accès à la GUI, composant de l’environnement sécurisé qui doit être protégée par MFA et non les accès préalables.
- Dans certains cas, le chemin d’accès nominal indiqué ci-dessus n’est pas le seul à exister et des modes dégradés existent permettant une connexion en direct à la GUI sans implémentation de MFA.
Il a été constaté à maintes reprises à travers ces exemples que l’implémentation du MFA nécessite une réflexion poussée pour être conforme à l’exigence du CSCF tout en étant compatible avec les usages de l’entreprise et une simplicité d’utilisation pour l’utilisateur.
Par ailleurs, certains éditeurs d’applications de trésorerie proposent une fonction de MFA intégrée, compatible avec de nombreuses solutions du marché (Microsoft Authenticator par exemple), et d’autres non, laissant les utilisateurs désœuvrés face à ce chantier complexe, leur faisant prendre du retard, avec pour conséquence de ne pas être conforme en fin d’année sur ce dispositif. Afin d’aider les utilisateurs SWIFT dans leur choix, la version 2023 du CSCF recommande la lecture du référentiel NIST SP 800-63B.
Le durcissement : très souvent LE maillon faible
Le durcissement des systèmes s’applique à tout type d’architecture et d’équipement, tel que cela est décrit dans l’exigence 2.3 du CSCF.
Il a pu cependant être constaté que les aspects de durcissement sont complexes à mettre en œuvre, notamment pour les raisons suivantes :
- Les postes opérateurs SWIFT non dédiés font très souvent partie du parc global de l’entreprise et ne bénéficient pas de configuration dédiée. Le déploiement d’un durcissement à grande échelle peut avoir de nombreux effets de bords, particulièrement sur les compatibilités applicatives.
- Les référentiels tels que le CIS1 ou le STIG, suivis tels quels peuvent représenter un challenge difficile à surmonter et décourageant pour certaines équipes, le guide CIS Windows 10 contient par exemple plus de 1300 pages.
- Un faux sentiment de sécurité lié aux mesures de sécurité implémentées par le constructeur / éditeur par défaut, ces travaux sont donc jugés non prioritaires.
- La méconnaissance du sujet par la plupart des équipes IT, et l’aspect pouvant paraitre comme étant colossal du projet de durcissement touche de nombreuses entreprises, et débouche sur le strict minimum ou aucune action. Très rares sont les entreprises étant matures sur ce point.
Almond vous recommande donc :
- De vous outiller afin de vous permettre de déployer à grande échelle les nouvelles configurations et de les vérifier/pousser régulièrement tel que cela est requis par le standard CSCF.
- De réaliser des phases de tests préalables sur un échantillon représentatif, en laissant l’opportunité de déverrouiller les paramètres en cas de problème, pour ne pas susciter de frustration chez les utilisateurs.
- Les standards de sécurité tels que le CIS ou le STIG2 classe leurs recommandations selon différents niveaux. Par exemple le guide W10 du STIG contient 257 points de configuration classés en 3 catégories selon leur criticité. Il pourrait être intéressant de prioriser pour diminuer la charge de travail tout en assurant une couverture de plus en plus importante dans le temps. Almond met notamment en avant certains de ces points comme étant incontournables, les autres étant dans la plupart des contextes superflus ou trop poussés pour une PME par exemple.
- De documenter les écarts avec le ou les standards sélectionné(s). Il ne s’agit pas de mettre en avant les lacunes mais de faciliter les mises à jour. En plus d’être demandé par le standard CSCF, cela permet de justifier chacune des exceptions accordées afin de pouvoir revenir dessus si cela n’est plus nécessaire et cela permet aussi de conserver l’historique de vos travaux afin de ne pas avoir à tout recommencer dès qu’une nouvelle version du guide de référence est publiée. Il s’agit bien ici d’un standard de durcissement, qui évoluera au fil des années, permettant de garder une vision claire de la conformité des OS déployés sur le parc.
Les configurations des équipements ne sont pas fixes, celles-ci peuvent évoluer via l’action d’un administrateur isolé ou d’une politique globale plus ou moins ancienne. Afin de diminuer la surface d’exposition de vos équipements, il est impératif de procéder à l’application d’un durcissement adapté à ses besoins.
Conclusion
Cet exercice de rétrospective couvrant les principales difficultés rencontrées par les entreprises lors de l’évaluation 2022 nous permet d’aborder plus en profondeur certains sujets spécifiques du CSCF. Dans un prochain article, nous aborderons les évolutions du référentiel CSCF pour la campagne 2023 et comment s’y préparer.
La démarche Almond propose justement un accompagnement complet, basé sur un audit à blanc préalable à l’évaluation finale, vous permettant de vous guider sur chaque point du référentiel et d’identifier toute non-conformité avant qu’elle n’impacte votre KYC.
La campagne 2023 est déjà lancée ! Prenez de l’avance en nous contactant au plus vite, pour aborder ce projet de manière sereine et avoir plus de temps pour effectuer les corrections nécessaires à la validation de l’évaluation finale.
Thierry CASIER
Manager Governance, Risks & Compliance
François PETIOT
Consultant Governance, Risks & Compliance
Pierre ZORDAN
Consultant Governance, Risks & Compliance
