CSCF v2021 01072020 FR-FR

SWIFT Customer Security Controls Framework
v2021
Customer Security Programme
Présentation détaillée
Le présent document définit un ensemble de mesures de sécurité obligatoires et conseillées pour l’environnement
opérationnel des utilisateurs de SWIFT. Les mesures de sécurité obligatoires s’appuient sur des instructions
existantes et établissent une base de sécurité pour l’ensemble de la communauté des utilisateurs. Les mesures
conseillées sont des bonnes pratiques facultatives que SWIFT recommande aux utilisateurs de mettre en œuvre
dans leur environnement opérationnel. Ce document doit être lu conjointement avec le CSP FAQ SWIFT Knowledge
Base TIP 5021823 qui fournit de nombreuses informations complémentaires.
1er juillet 2020

Présentation détaillée Table des matières
Table des matières

Sommaire/Résumé ...............................................................................................................................4
Aperçu des changements ....................................................................................................................6
Objectifs et principes du cadre .........................................................................................................10
Périmètre des mesures de sécurité ..................................................................................................12
Types d’architecture ..........................................................................................................................16
Structure des mesures de sécurité ..................................................................................................21
Conformité des contrôles de sécurité ..............................................................................................22
Tableau récapitulatif des mesures de sécurité Tableau.................................................................23
Descriptions détaillées des mesures de sécurité ...........................................................................26
1 Limiter l’accès à Internet et séparer les systèmes critiques de l’environnement TI général ..26
1.1 Protection de l’environnement SWIFT .................................................................................26
1.2 Contrôle des comptes à privilèges dans le système d’exploitation .....................................31
1.3 Protection de la plateforme de virtualisation ........................................................................33
1.4 Restriction de l’accès à Internet ...........................................................................................35
2 Réduire la surface d’attaque et les vulnérabilités ........................................................................38
2.1 Sécurité des flux de données internes .................................................................................38
2.2 Mises à jour de sécurité .......................................................................................................40
2.3 Sécurisation des systèmes ..................................................................................................42
2.4A Sécurité du flux de données d’application métier ..............................................................44
2.5A Protection des données transmises en externe ................................................................47
2.6 Confidentialité et intégrité de la session opérateur ..............................................................49
2.7 Analyse des vulnérabilités....................................................................................................51
2.8A Externalisation des activités critiques ................................................................................53
2.9A Contrôles opérationnels des transactions .........................................................................55
2.10 Sécurisation des applications ............................................................................................57
2.11A Mesures opérationnelles RMA ........................................................................................59
3 Sécuriser physiquement l’environnement ....................................................................................60
3.1 Sécurité physique .................................................................................................................60
4 Prévenir les vols d’identifiants ......................................................................................................63
4.1 Politique en matière de mots de passe ................................................................................63
4.2 Authentification à facteurs multiples ....................................................................................65
5 Gérer les identités et séparer les privilèges .................................................................................67
5.1 Contrôle d’accès logique ......................................................................................................67
6 Détecter les activités anormales dans les systèmes ou les relevés d’opérations ...................74
6.1 Protection contre les logiciels malveillants ...........................................................................74
6.2 Intégrité des logiciels ............................................................................................................76
6.3 Intégrité des bases de données ...........................................................................................77
6.4 Journalisation et surveillance ...............................................................................................78
6.5A Détection des intrusions ....................................................................................................80
7 Plan d’intervention en cas d’incident et partage d’informations ...............................................82
7.1 Planification de l’intervention en cas de cyber-incident .......................................................82
7.2 Formation et sensibilisation à la sécurité .............................................................................84
7.3A Tests d’intrusion .................................................................................................................86
7.4A Évaluation des risques fondée sur des scénarios .............................................................88
Tableau récapitulatif des facteurs de risque ..........................................90
Architectures de référence de la zone sécurisée...................................93
Exemples de scénarios de menaces .......................................................96
1er juillet 2020 2

Présentation détaillée Table des matières
Glossaire ..................................................................................................102
Mise en correspondance des normes de l’industrie ...........................................109
Services et composants dans le champ d’application par type d’architecture118
Responsabilités partagées dans un modèle de Cloud IaaS ...............125
Mentions légales...............................................................................................................................126
1er juillet 2020 3

Présentation détaillée Sommaire/Résumé
Sommaire/Résumé
La menace cybernétique qui pèse sur le secteur financier est plus forte que jamais. On
observe une évolution continue depuis 2016 et les utilisateurs SWIFT sont confrontés à des
attaques cybernétiques de plus en plus sophistiquées. Le modus operandi, la Tactique, les
Techniques et Procédures (TTP) ont progressé et changé à mesure que les institutions
renforçaient les mesures de sécurité. La persistance de ces menaces nécessite de rester
vigilant et proactif sur le long terme. Si les clients sont responsables de la protection de leur
propre environnement et de leur accès à SWIFT, ils peuvent compter sur le Customer
Security Programme (CSP) pour les aider et pour favoriser une collaboration à l’échelle du
secteur dans la lutte contre la cyber-fraude. Le CSP établit un ensemble commun de
mesures de sécurité connu sous le nom de Cadre de contrôle de la sécurité des clients. Ce
cadre est conçu pour aider les clients à sécuriser leur environnement local et à favoriser un
écosystème financier plus sûr.
Le cadre des mesures de sécurité des clients de SWIFT (CSCF) comprend à la fois des
mesures de sécurité obligatoires et des mesures de sécurité conseillées pour les utilisateurs
de SWIFT. Les mesures de sécurité obligatoires établissent une base de sécurité pour la
communauté tout entière, et doivent être mises en œuvre par tous les utilisateurs au niveau
de leur infrastructure SWIFT locale. SWIFT a choisi d’imposer en priorité ces mesures afin
de fixer un objectif réaliste à court terme: une amélioration tangible de la sécurité associée à
une réduction de risques. Les mesures conseillées sont basées sur des bonnes pratiques
que SWIFT recommande aux utilisateurs de mettre en œuvre. Au fil du temps, les mesures
obligatoires pourraient changer en fonction de l’évolution des menaces, et des mesures
conseillées en ce moment, pourraient devenir obligatoires.
Tous les contrôles s’articulent autour de trois objectifs primordiaux: « sécuriser votre
environnement », « identifier et limiter l’accès », et « détecter et réagir ». Les mesures ont
été mises au point sur la base d’une analyse par SWIFT de renseignements sur les cyber-
menaces, avec la contribution de spécialistes du secteur et de retours d’information des
utilisateurs. Les définitions des mesures sont délibérément alignées sur les standards en
vigueur dans l’industrie de la sécurité de l’information.
Les mesures présentées dans le présent document sont des mesures génériques
applicables pour tous les produits. Elles ne sont pas exhaustives et ne remplacent pas un
cadre de gestion de la sécurité et des risques bien structuré couvrant l’ensemble de la
chaîne de transaction, un jugement éclairé ou l’application des bonnes pratiques de
sécurité.
Étant donné la nature évolutive des cyber-menaces, la mise en place de nouvelles
technologies et d’initiatives stratégiques par SWIFT, les contrôles seront régulièrement
évalués, perfectionnés et renforcés, les modifications seront publiées dans une nouvelle
version de ce document. Par conséquent, il est recommandé de toujours utiliser la dernière
version de ce document ; celle-ci est disponible dans le Knowledge Centre. Pour consolider
l’adoption des mesures, SWIFT a mis au point un processus par lequel les utilisateurs
doivent attester leur respect des mesures obligatoires et, s’ils le souhaitent, des mesures de
sécurité conseillées. Il est demandé aux utilisateurs de soumettre leur attestation dans
l’application Know Your Customer-Security Attestation (KYC-SA). Avant la fin de chaque
année, les utilisateurs doivent attester leur respect des mesures de sécurité obligatoires et,
éventuellement, des mesures de sécurité conseillées, tel que documenté dans le CSCF en
vigueur à cette date. La nouvelle version du CSCF est généralement publiée début juillet et
recense les mesures obligatoires et conseillées pour les attestations à partir du mois de
juillet de l’année consécutive à la mise en œuvre de l’application KYC-SA. Par exemple, les
utilisateurs doivent soumettre leurs attestations entre le mois de juillet et le mois de
décembre 2021 pour les mesures de sécurité répertoriées dans le CSCF v2021 ayant été
publié courant 2020.
Comme notifié précédemment à la communauté SWIFT, nous avons revu les calendriers
initialement publiés pour la CSCF afin de nous assurer que les prochains renforcements
resteront efficaces pour notre communauté. Les utilisateurs devront à nouveau soumettre
leur attestation CSCF v2019 d’ici à la fin de 2020. Les mesures de contrôle précédemment
définies dans la version 2020 du CSCF sont intégrées dans la version 2021 du CSCF, et les
utilisateurs devront s’y conformer au cours du second semestre 2021.
1er juillet 2020 4

Présentation détaillée Sommaire/Résumé
Chaque utilisateur garde le contrôle de ses propres données et peut accorder ou non l’
accès à ses contreparties pour leur permettre de consulter ses données d'évaluation. Ce
mécanisme promeut la transparence et crée une dynamique entre institutions visant à
améliorer la sécurité en permettant à d’autres utilisateurs du réseau d’appliquer une prise
de décision basée sur les risques relatifs à leurs relations d’affaires. Pour en savoir plus sur
le processus d’attestation et de reporting, consultez la dernière version de la SWIFT
Customer Security Controls Policy disponible dans le Knowledge Centre.
Le Customer Security Programme (CSP) repose sur une collaboration entre SWIFT et ses
utilisateurs, avec pour objectif le renforcement de la sécurité globale de l’écosystème
financier. Par conséquent, tous les utilisateurs doivent lire attentivement les définitions des
mesures figurant dans le présent document, et se préparer à mettre en œuvre ces mesures
au sein de leur propre organisation.
1er juillet 2020 5

Présentation détaillée Aperçu des changements
Aperçu des changements

La version 2021 du SWIFT Customer Security Controls Framework (CSCF) est construite
incrémentalement sur la version de l’année dernière - CSCF v2020. Les changements ont
été réduits au minimum par rapport à la version v2020 du CSCF afin de garantir que la
communauté dispose de suffisamment de temps pour pleinement mettre en œuvre les
mesures introduites avec les versions précédentes du CSCF.
Sur papier, la CSCF v2021 « rend » la mesure « 1.4 - Restreindre l’accès à Internet »
obligatoire. Toutefois, dans la pratique, cette mesure figurait déjà dans la mesure obligatoire
« 1.1 - Protection de l’environnement/Cloisonnement du réseau » depuis le lancement des
mesures initiales en 2017.
En outre, un certain nombre de lignes directrices et de définitions de champ d’application
(principalement relatives aux « connecteurs ») ont été clarifiées afin de mieux appuyer les
attestations et les évaluations. De plus, un nouveau type d’architecture identifié comme A4
a été mis en place, il tient compte de l’empreinte non-SWIFT. Sa mise en place permet de
renforcer progressivement l’utilisation des technologies résultant de la stratégie de SWIFT
(telles que le Cloud et les API) et ouvre la voie aux évolutions futures ; cette introduction
sera de manière consultative dans un premier temps.
Des clarifications supplémentaires ont été apportées afin d’aider les utilisateurs à mettre en
œuvre le cadre prévu et de préciser les attentes concernant les cyber-cibles initiales
habituelles: les PC des opérateurs généraux se connectant à une infrastructure locale ou
distante.
Certaines mises en œuvre suggérées par les utilisateurs ont également été intégrées (voir
contrôles 1.1, 2.9A, 6.1, 6.5A et 7.4).
Afin d’améliorer l’efficacité et d’assurer l’identification des composants du périmètre
d’application des mesures, une première liste est proposée à l’annexe F. Cette liste sera
régulièrement mise à jour dans un TIP.
Enfin, pour faciliter davantage les évaluations indépendantes, il est rappelé aux utilisateurs
que:
− La mise en conformité des objectifs de contrôle est une approche fondée sur le
risque. Les lignes directrices de mise en œuvre fournies peuvent être utilisées
comme point de départ, mais ne peuvent être considérées comme des « grilles
d’audit » strictes,
− Les utilisateurs qui s’engagent avec des tiers (y compris les fournisseurs de
service cloud computing) pour héberger et/ou exploiter entièrement ou
partiellement leur propre infrastructure SWIFT, doivent obtenir de ces tiers un
confort raisonnable que les activités externalisées et/ou les composants hébergés
en externe sont protégés conformément aux mesures de sécurité. À titre
d’exemple, l’annexe G présente les responsabilités partagées dans le cadre d’un
modèle IaaS (Infrastructure as a Service) sur le cloud.
Le tableau suivant résume les principaux changements apportés au contenu du présent

document par rapport à la version précédente. Le tableau n’inclut pas les modifications
rédactionnelles qu’effectue SWIFT pour améliorer la facilité d’utilisation et la compréhension
du présent document. Il est toujours suggéré de consulter la « version CSCF v2021
comparée à la version v2020 » (disponible en Anglais seulement) de ce document pour voir
le détail complet de tous les changements.
Mesure ou section Changement
Confirmer la scission des mesures de contrôle existantes dans un souci

d’efficacité
Poursuivre le démantèlement du Rassembler dans la mesure 1.4 les
contrôle 1.1 en transférant la restriction orientations relatives à l’accès à Internet et
de l’accès à Internet au contrôle 1.4 supprimer ces dernières de la mesure 1.1 d)
et e)
1er juillet 2020 6

Clarifications sur les définitions du champ d’application et la nouvelle

architecture - Alignement sur la réalité et nouveaux modèles
Définition des connecteurs Intégrer les serveurs middleware/MQ et les
points terminaux API lorsqu’ils sont utilisés
pour connecter ou transmettre des
transactions aux prestataires de services ou
à SWIFT
Différencier les connecteurs relatifs à SWIFT
(tels que SIL, DirectLink, AutoCLient,
MicroGateway) des connecteurs clients
(basés sur des serveurs de fichiers, des
serveurs middleware/MQ ou des points
terminaux API personnalisés)
Postes de travail opérateur à usage Il est précisé dans ce document que les
général infrastructures ou les applications
accessibles peuvent être
hébergées/exploitées localement ou de
manière externe.
Référence explicite au PC opérateur à usage
général dans les mesures de contrôle et les
clarifications pertinentes pour faciliter une
mise en œuvre appropriée quand cela est
nécessaire
Tiers La définition de tiers est étendue au
fournisseur de service cloud computing.
Il est rappelé que lorsqu’ils s’engagent avec
un tiers, les utilisateurs restent responsables
de la sécurisation de leur infrastructure et
doivent obtenir des tiers un confort
raisonnable que les activités externalisées
et/ou les composants hébergés en externe
sont protégés conformément aux mesures de
sécurité du CSP.
Ajout de l’annexe G pour illustrer
l’externalisation dans le cadre d’un modèle
IaaS
Types d’architecture - Architecture A4 Un nouveau type d’architecture est introduit
pour différencier les utilisateurs qui se basent
sur des connecteurs relatifs à SWIFT (ou
empreinte SWIFT), actuellement désignés
comme A3, de ceux qui se basent sur des
connecteurs clients (sans empreinte SWIFT),
ce dernier représente la nouvelle architecture
de type A4.
L’extension précédente v2020 du champ
d’application aux serveurs middleware/MQ et
le repositionnement des solutions de
serveurs de fichiers comme connecteur client
pourraient nécessiter la conversion de
certaines architectures B ou A3 existantes en
architectures de type A4
Mise en conformité des mesures de sécurité - Soutien des évaluations
indépendantes
Section ‘Conformité des contrôles de Pour rappel, les lignes directrices de mise en
sécurité’ et ajout sur chaque mesure de œuvre ne sont pas des grilles d’audit strictes,
contrôle mais la conformité doit être évaluée selon
une approche fondée sur les risques
Clarifications des mesures de contrôle existantes dans un souci d’efficacité et
d’alignement avec la réalité
1er juillet 2020 7

1.1 Protection de l’environnement Ajout d’un accès temporaire comme

SWIFT alternative potentielle aux différents serveurs
de rebond pour les connexions utilisateur et
administrateur à la zone sécurisée
1.3 Protection de la plateforme de Référence explicite à une plateforme de
virtualisation et mesures de contrôle virtualisation externe (hébergée ou exploitée
connexes en externe) pour renforcer la conscientisation
dans le cadre d’une collaboration avec un
tiers ou lors d’un passage à une solution
cloud
2.4A Sécurité des flux de données du Les nouveaux connecteurs clients sont
back-office et mesures de contrôle traités de la même manière que les serveurs
connexes middleware/MQ locaux: extension du champ
d’application pour certaines mesures de
contrôle (conseille en cas d’utilisation)
2.7 Analyse des vulnérabilités Mesure conseillée uniquement pour
l’architecture B (à savoir une amélioration
optionnelle pour les PC opérateurs à usage
général)
2.8A Externalisation des activités Rappel de la responsabilité de l’utilisateur
critiques lorsqu’il s’engage avec un tiers ou un
prestataire de services
2.9A Contrôles opérationnels des Prise en compte de l’environnement
transactions opérationnel 24 h/24 et 7 j/7 et réorganisation
des méthodes de mise en œuvre proposées;
clarification de l’orientation ‘sortante’ de ce
contrôle
2.10 Sécurisation des applications Les interfaces de messagerie et de
communication sont désormais régies par le
programme d’interface SWIFT renommé
comme « compatible »
4.2 Authentification à facteurs multiples L’AMF (authentification multifactorielle) est
également attendue lors de l’accès à un
service ou à une application relatifs à SWIFT
et exploités ou hébergés par un tiers
5.2 Gestion des jetons Référence aux jetons personnels et
précisions sur la manière d’établir et de gérer
correctement les connexions au PED distant
lorsqu’il est utilisé
5.4 Stockage physique et logique des La certification des coffres-forts est
mots de passe considérée comme une amélioration
facultative
6.1 Protection contre les logiciels Référence à l’utilisation de la plateforme de
malveillants protection des points finaux (EPP) comme
alternative potentielle de mise en œuvre et
requête explicite visant à intervenir en
fonction des résultats ; clarification
supplémentaire concernant le processus de
scannage
6.2 Intégrité des logiciels Requête explicite visant à intervenir en
fonction des résultats
6.3 Intégrité des bases de données Requête explicite visant à intervenir en
fonction des résultats. Avertissement mis en
place pour tenir compte des rares cas
d’architecture A1 qui n’incluent pas
d’interface de messagerie
1er juillet 2020 8

6.5A Détection des intrusions Référence à l’utilisation de la solution EDR

(Endpoint Detection and Response) comme
alternative potentielle de mise en œuvre
7.3A Tests d’intrusion Clarifications sur (i) le champ d’application
étayé par la FAQ correspondante et (ii) la
définition de « changements significatifs »
7.4A Évaluation des risques fondée sur Référence aux cyber-guerres
des scénarios
Annexes A-E Mises à jour
Annexe F Cette annexe est mise en place pour faciliter
l’identification des éléments entrants dans le
champ d’application et de leur type
d’architecture habituel. Ces informations sont
valables au moment de la publication du
présent document
Annexe G Cette annexe est mise en place pour illustrer
le partage des responsabilités entre le client
et le fournisseur de solution cloud dans un
modèle IaaS
1er juillet 2020 9

Présentation détaillée Objectifs et principes du cadre
Objectifs et principes du cadre

Objectifs et principes
Les mesures de sécurité reposent sur trois objectifs principaux, eux-mêmes appuyés par
huit principes de sécurité. Les objectifs représentent le cadre général de sécurité au sein de
l’environnement local de l’utilisateur. Les principes associés précisent les axes prioritaires
dans chaque objectif. Les objectifs et principes associés incluent:
Figure 1: Objectifs et principes du cadre
Les 31 mesures de sécurité (22 mesures obligatoires et 9 mesures conseillées) détaillées

dans le présent document sous-tendent ces objectifs et principes. Les mesures aident les
utilisateurs de SWIFT à atténuer les risques spécifiques liés à la cyber-sécurité auxquels ils
sont confrontés. Pour chaque mesure de sécurité, SWIFT précise les facteurs de risque les
plus courants que la mesure doit aider à réduire. La maîtrise de ces risques vise à prévenir
ou limiter les conséquences commerciales indésirables et les fraudes potentielles,
notamment:
• L’envoi ou la modification non autorisés de transactions financières
• Le traitement de transactions SWIFT entrantes (c’est-à-dire reçues) modifiées ou non
autorisées
• Transactions réalisées avec des contreparties non autorisées
1er juillet 2020 10

Présentation détaillée Objectifs et principes du cadre
• L’atteinte à la confidentialité (des données commerciales, des systèmes informatiques,

ou des informations des utilisateurs)
• L’atteinte à l’intégrité (des données commerciales, des systèmes informatiques, ou des
informations des utilisateurs)
Enfin, ces conséquences représentent des risques pour l’entreprise, y compris:
• Risque financier
• Risque juridique
• Risque réglementaire
• Risque d’image
Intégration avec la gestion de la sécurité et des risques

SWIFT encourage les utilisateurs à appréhender la gestion des cyber-risques de la manière
la plus large possible, et notamment au-delà du cadre de leur infrastructure SWIFT et des
mesures de sécurité SWIFT. Pour une gestion optimale des risques, les utilisateurs ne
doivent pas voir la mise en œuvre de ces mesures de sécurité comme une activité
ponctuelle ou unique, ni exhaustive ou « tout-en-un ». Au contraire, les utilisateurs doivent
intégrer les mesures SWIFT dans un programme continu de gestion des risques de la
cyber-sécurité et des risques au sein de leur organisation, basé sur un jugement éclairé et
les dernières bonnes pratiques, en tenant compte de l’infrastructure et de la configuration
spécifiques de chaque utilisateur. Ainsi, les utilisateurs peuvent réutiliser et tirer profit des
politiques, procédures et mécanismes de réduction de risques existants qui ont été mis en
place pour gérer d’autres domaines des cyber-risques. Pour aider les utilisateurs dans cette
démarche, l’annexe E présente une mise en correspondance des mesures de sécurité
SWIFT avec trois cadres internationaux de normes de sécurité: Cadre de cyber-sécurité du
NIST v1.1 ; ISO 27002 (2013) et PCI-DSS 3.2.1. SWIFT a également publié un document
de référence afin d’aider les établissements financiers à évaluer la cyber-sécurité de leurs
contreparties et à l’intégrer dans leur cadre de gestion des risques.
Une approche holistique des cyber-risques sera plus efficace pour prévenir les risques pour
l’entreprise, en améliorant ainsi la sécurité globale de chaque organisation individuelle et de
la communauté financière dans son ensemble.
En outre, les utilisateurs doivent avoir le niveau de responsabilité et de supervision adéquat
pour leurs activités de gestion des cyber-risques. En général, un Responsable de la sécurité
des systèmes d’information joue un rôle de premier plan dans ce domaine en définissant les
priorités du programme de sécurité et en sollicitant le soutien et les conseils de la direction.
1er juillet 2020 11

Présentation détaillée Périmètre des mesures de sécurité
Périmètre des mesures de sécurité

Le périmètre des mesures de sécurité présenté dans ce document englobe un ensemble de
composants de l’environnement local de l’utilisateur (cf. Figure 2).
Figure 2: Périmètre des mesures de sécurité
Les mesures de sécurité s’appliquent aux éléments visés suivants:

• Infrastructure SWIFT locale – La collection de composants spécifiques à SWIFT,
hébergés localement ou à l’extérieur, gérés par ou pour les utilisateurs, y compris les
applications, les composants de réseau, les jetons et autres supports amovibles, et le
matériel de soutien. Quelques exemples de configuration et de composants de
l’infrastructure SWIFT locale, en fonction du type d’architecture, sont:
− Zone sécurisée SWIFT - Zone segmentée séparant les systèmes relatifs à
SWIFT des autres systèmes de l’entreprise (cf. mesure 1.1 pour plus de
précisions). Cette zone peut être étendue au-delà de l’infrastructure SWIFT locale
et inclure des systèmes non SWIFT.
− Interface de messagerie - Logiciel d’interface de messagerie prenant en
charge l’utilisation des normes de messagerie MT, MX ou ISO 20022, par le
biais des services de messagerie instantanée SWIFT FIN, InterAct, FileAct et
SWIFTNet. Le logiciel permet aux utilisateurs de connecter ces applications
métier aux services de messagerie SWIFT, et est généralement connecté
directement à l’interface de communication. Les interfaces de messagerie sont
fournies par SWIFT (par exemple, Alliance Access et Alliance Messaging Hub,
ou Alliance Messaging Hub Instant). Les interfaces de messagerie dotées d’un
label compatible avec SWIFT peuvent également être fournies par des
fournisseurs tiers. Une interface de messagerie est considérée comme une
empreinte SWIFT.
− Interface de communication - Logiciel d’interface de communication qui fait la
liaison entre le réseau SWIFTNet et l’interface de messagerie. Les interfaces de
communication permettent une intégration centralisée, automatique et rapide avec
différentes applications financières internes et interfaces propres aux services.
Les interfaces de communication sont fournies par SWIFT (par exemple, Alliance
Gateway ou Alliance Gateway Instant). Les interfaces de communication dotées
d’un label compatible avec SWIFT peuvent également être fournies par des
vendeurs tiers. Une interface de communication est considérée comme une
empreinte SWIFT.
− Connecteur - Les connecteurs sont des logiciels conçus pour faciliter la
communication avec une interface de messagerie et/ou de communication, ou
avec un prestataire de services. Lorsqu’on utilise un connecteur, les composants
d’interface sont généralement proposés par un prestataire de services (par
exemple, par un service bureau, une infrastructure de concentrateurs ou SWIFT).
Les termes « connecteur SWIFT » et « connecteur client » sont définis comme
suit:
1er juillet 2020 12

− Le connecteur SWIFT est un connecteur fourni par SWIFT (par exemple, Alliance
Cloud SIL, DirectLink, Alliance Lite2 AutoClient, en combinaison avec SIL ou non,
ou MicroGateway). Un connecteur SWIFT doté d’un label compatible avec SWIFT
peut éventuellement être fourni par des vendeurs tiers. Un connecteur SWIFT est
considéré comme une empreinte SWIFT.
Le connecteur client comprend les solutions génériques de transfert de fichiers
ou les implémentations de systèmes middleware locaux, tels que le serveur
IBM® MQ, utilisés pour faciliter la communication avec les composants relatifs à
SWIFT proposés par un prestataire de services. Ces éléments génériques non
fournis par SWIFT ou non certifiés compatibles avec SWIFT sont considérés
comme une empreinte non-SWIFT.
À l’avenir, une application mettant en œuvre des API SWIFT (utilisant les
spécifications ou intégrant le SDK SWIFT) pour connecter et transmettre
indépendamment 1 des transactions commerciales aux services de messagerie
SWIFT 2 exposés par la passerelle API SWIFT, sera également considérée
comme un connecteur client (API sur mesure) ou une empreinte non-SWIFT.
Le terme connecteur seul désigne à la fois les connecteurs SWIFT et les
connecteurs clients.
− SWIFTNet Link (SNL) - SNL est un logiciel obligatoire qui permet d’accéder aux
services de messagerie FIN, InterAct et FileAct via un réseau IP sécurisé. Le
présent document fait référence à SNL dans le cadre de l’interface de
communication.
− SWIFT Hardware Security Modules, jetons personnels connectés et cartes à
puce.
− Pare-feu, commutateurs, routeurs, etc. à l’intérieur ou autour de l’infrastructure
SWIFT (dédiée ou partagée). Également appelés dispositifs de réseau.
− Interface graphique utilisateur (GUI) – Logiciel qui produit l’interface graphique
pour un utilisateur (par exemple, Alliance Web Platform Server-Embedded et
produits équivalents).
• Opérateurs – Les opérateurs sont des utilisateurs finaux et des administrateurs qui
interagissent directement avec l’infrastructure SWIFT locale au niveau de l’application
ou du système d’exploitation.
• PC opérateur - Ce terme désigne le dispositif informatique de l’utilisateur final ou des
administrateurs (généralement un ordinateur de bureau ou portable) utilisé pour
exercer leurs fonctions: a) utiliser, exploiter ou entretenir l’infrastructure SWIFT locale
résidant localement ou hébergée à l’extérieur et/ou b) utiliser une infrastructure ou une
application SWIFT distante exploitée par un prestataire de services (tel qu’un service
bureau, un fournisseur d’applications Lite2 ou SWIFT), en fonction de votre type
d’architecture.
− Les termes « PC opérateur à usage général » et « PC opérateur dédié » sont
définis de la manière suivante:
Un PC opérateur à usage général est situé dans l’environnement informatique
général de l’entreprise et utilisé pour les activités commerciales quotidiennes,
notamment pour accéder à l’infrastructure SWIFT locale ou distante ou à une
application exploitée par un prestataire de services, selon le type d’architecture.
Un PC opérateur dédié est situé dans la zone sécurisée et sert à interagir avec
des éléments de la zone sécurisée (parfois également appelé « console
système »).
1
Indépendamment signifie sans utiliser une interface de communication ou un connecteur SWIFT tel que SIL, DirectLink ou
MicroGateway
2
Les transactions commerciales vers les services de messagerie désignent les demandes instaurant ou affectant des paiements
SWIFT (telles que la création de MT103, 101, 202, 205 ou l’annulation/l’arrêt/le rappel/la modification de ces demandes). D’autre
part, les interrogations sur les transactions précédentes (par exemple via le Basic Tracker), la prévalidation, la conversion ou le
filtrage effectués avant de soumettre des transactions commerciales ne sont pas considérés comme affectant les services de
messagerie et peuvent être considérés comme hors de ce champ d’application, à moins qu’ils n’exigent les mêmes
rôles/autorisations que les transactions commerciales aux services de messagerie (aucune séparation des tâches et aucun
principe de précaution ne doivent être appliqués).
1er juillet 2020 13

Le terme PC opérateur seul désigne à la fois les PC à usage général et les PC

opérateurs dédiés.
• Couche d’échange de données – Le transport des données entre les composants
relatifs à SWIFT (dans l’infrastructure SWIFT locale ou chez un prestataire de services)
et le premier back-office d’un utilisateur, au niveau applicatif, en partant des
composants liés à SWIFT.
• Serveur middleware – Les implémentations de systèmes middleware locaux, tels que
le serveur IBM® MQ (y compris le gestionnaire de files d’attente MQ, les appliance MQ
ou les deux), utilisés pour l’échange de données entre les composants relatifs à SWIFT
(dans l’infrastructure SWIFT locale ou chez un prestataire de services) et le back-office
de l’utilisateur. Celui-ci doit être considéré comme un connecteur client lorsqu’il est
utilisé pour faciliter la communication avec les composants relatifs à SWIFT proposés
par un prestataire de services (tel qu’un service bureau, ou éventuellement un
fournisseur d’applications Lite2).
Les éléments suivants ne sont pas visés par les mesures:

• Back-office de l’utilisateur - Systèmes qui prennent en charge la logique métier, la
génération de transactions (financières) et d’autres activités intervenant avant la
transmission dans l’infrastructure SWIFT locale. Par exemple:
− Les mises en œuvre de back-office telles que SAP, gestionnaires de comptabilité
ou les applications utilisant un client MQ pour assurer la liaison avec une
infrastructure SWIFT sont exclues du champ d’application, sauf si ces applications
sont co-hébergées avec un composant entrant dans le périmètre d’application.
− Une application ou un système se connectant a :
a) une interface de communication (telle que le SAG - voir Figure 3b) ou
b) un connecteur SWIFT (tel que Direct Link ou MicroGateway - voir Figure 5) ou
c) à l’avenir, un connecteur client (voir Figure 6b)
pour ses appels API à SWIFT reste un back-office et est exclu du champ
d’application à moins d’être co-hébergé avec l’interface de communication ou le
connecteur.
• Environnement TI général de l’entreprise - L’infrastructure TI générale utilisée pour
appuyer l’organisation dans son ensemble (par exemple, PC à usage général, serveur
de messagerie, services d’annuaire, etc.).
Les connexions au réseau SWIFT fournies par les partenaires du réseau SWIFT, connexion
Internet au réseau SWIFT et boîtiers VPN Alliance Connect, ou leurs instances virtuelles 3,
gérés à distance par SWIFT sont également exclues du champ d’application. Toutefois, les
boîtiers VPN Alliance Connect et leurs instances virtuelles (systèmes ou machines
d’hébergement) doivent se trouver dans un environnement doté de contrôles physiques
appropriés, conformément au contrôle 3.1.
Bien qu’elles ne soient pas obligatoires dans le cadre du processus de certification, les
mesures de sécurité correspondent à des bonnes pratiques de sécurité qu’il convient de
mettre en œuvre au-delà de l’environnement SWIFT concerné, et tout au long de la chaîne
de transaction.
Remarque: Les utilisateurs doivent attester sur tous les composants du champ
d’application dans leur environnement de production, de sauvegarde et de reprise après
sinistre, en tenant compte de leur architecture spécifique, mais complète (en déclarant le
type d’architecture le plus englobant).
De préférence, les systèmes recettes sont séparés des systèmes de production (y compris
des HSM) et configurés de manière à prendre en charge uniquement le trafic recette (par
exemple, en utilisant uniquement des certificats Lite et en configurant uniquement les
3
Également appelé vSRX
1er juillet 2020 14

terminaux logiques de recette). S’ils ne sont pas totalement séparés, ces systèmes doivent
être maintenus au même niveau de sécurité que les systèmes de production.
Les systèmes de développement ne sont pas inclus dans la zone sécurisée et ne sont pas
connectés au réseau SWIFT.
Remarque: Les utilisateurs collaborant avec des tiers (par exemple, un prestataire
informatique externe ou un prestataire de cloud computing) ou des prestataires de services
(comme un service bureau ou un fournisseur d’applications Lite2 qui, dans ce cas précis,
doit être considéré comme un tiers) pour héberger ou exploiter en tout ou en partie
l’infrastructure SWIFT de l’utilisateur:
- Sont toujours responsables et redevables de l’attestation de leur type d’architecture
globale (comme si elle était exploitée localement) et par conséquent
- Doivent obtenir 4 de ces tiers ou prestataires de services un confort raisonnable que les
activités externalisées sont protégées, au minimum, selon les mêmes normes de soins
que si elles étaient exercées au sein de l’organisation d’origine et conformément aux
mesures de sécurité CSCF.
L’annexe G illustre une répartition typique, mais aussi un partage des responsabilités à
prendre en compte lors de l’externalisation vers un fournisseur de cloud computing selon le
modèle Infrastructure as a Service (IaaS).
4
Voir le Glossaire pour la définition
1er juillet 2020 15

Présentation détaillée Types d’architecture
Types d’architecture
Chaque utilisateur doit identifier lequel des cinq types d’architecture de référence
(Figures 3-7) correspond le mieux à son propre déploiement d’architecture afin de
déterminer quels composants sont concernés. En fonction du type d’architecture, certaines
mesures de sécurité s’appliqueront ou pas.
La propriété des composants ou des licences d’utilisation des logiciels est le facteur clé de
différenciation entre les cinq architectures de référence suivantes:
• Architecture A1 – Utilisateurs détenant l’interface de communication (et généralement
l’interface de messagerie)
L’interface de communication est la propriété de l’utilisateur.
La Figure 3a illustre le cas où les licences de l’interface de messagerie et de l’interface
de communication sont détenues par l’utilisateur et résident dans son environnement.
Figure 3a: Architecture A1 - Interfaces dans l’environnement de l’utilisateur
Les utilisateurs qui n’utilisent pas ou ne détiennent pas d’interface de messagerie, mais
uniquement une interface de communication (comme dans la Figure 3b ci-dessous)
sont également considérés comme une architecture A1.
Figure 3b: Architecture A1 - Interface de communication uniquement dans l’environnement de

l’utilisateur
Ce type d’architecture A1 inclut également des solutions hébergées où l’utilisateur

détient l’interface de communication (possède une licence) a) qu’il exploite pour le
compte d’autres utilisateurs ou b) qu’il exploite pour lui-même par l’intermédiaire d’un
tiers dans ou (sous forme d’hébergement) en dehors de l’environnement local de
l’utilisateur.
1er juillet 2020 16

• Architecture A2 – Utilisateur détient l’interface de messagerie, mais pas l’interface de

communication
L’interface de messagerie est détenue par l’utilisateur, mais c’est un prestataire de
services (par exemple, un service bureau, SWIFT 5 ou un hub de groupe) qui détient la
licence pour l’interface de communication et qui la gère.
La Figure 4 montre le cas où l’interface de messagerie est la propriété de l’utilisateur et
se situe dans l’environnement de l’utilisateur.
Figure 4: Architecture A2 - Interface de messagerie uniquement dans l’environnement de

l’utilisateur
Ce type d’architecture comprend également les solutions hébergées où l’utilisateur

dispose de la licence pour l’interface de messagerie qui est exploitée pour lui-même
par un tiers ou un prestataire de services.
• Architecture A3 – Connecteur SWIFT

Un connecteur SWIFT 6 est utilisé, comme illustré dans la Figure 5, dans
l’environnement utilisateur pour faciliter la communication d’application à application
avec une interface chez un prestataire de services (par exemple, un service bureau, un
hub de groupe) ou avec les services SWIFT (tels qu’Alliance Cloud, Alliance Lite 2 et, à
l’avenir, un service de messagerie ou la Plateforme de transaction 7 exposée par
SWIFT).
Éventuellement, cette configuration peut être utilisée en combinaison avec une solution
GUI (d’utilisateur à application). Dans ce cas, les contrôles relatifs à l’interface
graphique utilisateur doivent également être mis en œuvre.
Ce type d’architecture comprend également les solutions hébergées du connecteur
SWIFT.
5
Dans le cadre de SWIFT Alliance Remote Gateway
6
Par exemple, Alliance Cloud SIL, DirectLink, Alliance Lite2 AutoClient, en combinaison avec SIL ou non, ou MicroGateway
7
À déployer à l’avenir dans le cadre de la Stratégie SWIFT approuvée par le Conseil d’administration
1er juillet 2020 17

Figure 5: Architecture A3 – Connecteur SWIFT
• Architecture A4 – Connecteur client

Un serveur exécutant une application logicielle (par exemple, une solution de transfert
de fichiers ou un système middleware tel que le serveur IBM® MQ ou similaire qui sont
des connecteurs clients - Figure 6a) est utilisé dans l’environnement utilisateur 8 pour
faciliter la communication d’application à application avec une interface chez un
prestataire de services (par exemple, un service bureau, un fournisseur d’applications
Lite2 ou un hub de groupe).
Figure 6a: Architecture A4 – Middleware/Transfert de fichiers comme connecteur
Cette architecture spécifique nécessitera que certains utilisateurs adoptent

l’Architecture A4:
- Les utilisateurs ayant précédemment attesté d’une architecture B parce qu’ils
utilisaient comme connecteur client, un serveur middleware, comme un serveur MQ.
- Les utilisateurs ayant précédemment attesté d’une architecture A3 parce qu’ils
utilisaient, comme connecteur, une solution de transfert de fichiers ou un serveur
middleware, comme un serveur MQ.
Ces utilisateurs devront tenir compte des contrôles incluant le serveur middleware dans
leur champ d’application.
En préparation du futur, cette architecture de type A4 comprend également des

connecteurs clients constituant des applications propres utilisées dans l’environnement
utilisateur 9 et qui mettront en œuvre les API de SWIFT pour connecter directement et
transmettre indépendamment 10 les transactions commerciales aux services SWIFT (un
8
Localement ou en hébergement externe, dans le Cloud ou non.
9
Localement ou en hébergement externe, dans le Cloud ou non.
10
Sans l’utilisation d’une interface de communication ou d’un connecteur SWIFT (API) dédié.
1er juillet 2020 18

futur service de messagerie 11 ou une Plateforme de transaction 12 exposée par SWIFT).

La mise en œuvre par le client des API de SWIFT (utilisant les spécifications ou
intégrant le SDK de SWIFT) fait de ces applications un point final d’API sur mesure et
appelé connecteur client ou empreinte non-SWIFT - Figure 6b).
Cette dernière configuration pourrait également intégrer une solution GUI (d’utilisateur
à application). Dans ce cas, des contrôles relatifs à l’interface graphique utilisateur
devront également être mis en œuvre.
Figure 6b: Architecture A4 - Connecteur client (API maison)
• Architecture B - Aucune empreinte chez l’utilisateur

Aucun élément d’infrastructure spécifique à SWIFT n’est utilisé dans l’environnement
de l’utilisateur. Deux types de configuration sont couverts par ce type d’architecture:
− Les utilisateurs accèdent aux services de messagerie SWIFT exclusivement via
une application GUI fournie par le prestataire de services (d’utilisateur à
application). Le PC ou le dispositif utilisé par ces utilisateurs pour soumettre ou
affecter des transactions commerciales doit être considéré comme un PC
opérateur (à usage général) et protégé en conséquence.
− Les applications de back-office des utilisateurs communiquent directement avec le
prestataire de services (d’application à application) en utilisant les API du
prestataire de services ou d’un client middleware (tel que MQ Client) sans se
connecter ou transmettre indépendamment des transactions commerciales à
SWIFT Alliance Cloud, un service de messagerie SWIFT, la passerelle API de
SWIFT 13 ou, à l’avenir, la Plateforme de transaction 14 exposée par SWIFT. Dans
ce cas, le prestataire de services doit assurer la sécurité de son environnement et
de l’échange de données avec l’utilisateur conformément aux contrôles du CSCF.
La classification de cette configuration en tant que type d’architecture B est
conforme à la portée des mesures de sécurité, qui exclut les applications de back-
office des utilisateurs. Toutefois, SWIFT recommande vivement de mettre déjà en
œuvre les contrôles de type A4 de l’architecture sur ces applications intégrant une
API ou un client middleware (tel que MQ Client).
11
Les transactions commerciales vers les services de messagerie désignent les demandes instaurant ou affectant des paiements
(telles que la création de MT103, 101, 202, 205 ou l’annulation/l’arrêt/le rappel/la modification de ces demandes). D’autre part, les
interrogations sur les transactions précédentes (par exemple via le Basic Tracker), la prévalidation, la conversion ou le filtrage
effectués avant de soumettre des transactions commerciales ne sont pas considérés comme affectant les services de
messagerie.
12
13
Dans le cas contraire, ce système serait considéré comme une architecture de type A4 avec un connecteur client.
14
1er juillet 2020 19

Figure 7: Architecture B - Aucune empreinte d’utilisateur se connectant à un prestataire de

services (non SWIFT)
Ce type d’architecture inclut également les utilisateurs dont l’accès se fait uniquement
avec un navigateur, les services de messagerie SWIFT (user-to-application) exposés
par Alliance Cloud et Alliance Lite2. Les PC utilisés par ces utilisateurs pour soumettre
ou affecter des transactions commerciales doivent être considérés comme des PC
opérateur (à usage général) et protégés en conséquence.
Les mesures de sécurité applicables aux architectures A1, A2 et A3 sont identiques 15

et moins de mesures s’appliquent à l’architecture A4. Ces architectures sont désignées
collectivement dans les pages suivantes comme des architectures de type « A ». Moins
de mesures de sécurité s’appliquent aux utilisateurs utilisant le type d’architecture
« B » (voir la section Tableau récapitulatif des mesures de sécurité pour les identifier).
15
Sauf pour la mesure 6.3 Intégrité de la base de données qui ne s’applique pas explicitement à l’architecture de type A3
1er juillet 2020 20

Présentation détaillée Structure des mesures de sécurité
Structure des mesures de sécurité

Ce chapitre présente chaque mesure de sécurité en trois parties: informations générales sur
la mesure, définition de la mesure et guide de mise en œuvre.
Informations générales sur la mesure
• Numéro et titre de la mesure – Chaque mesure a son numéro unique et son titre.
Lorsque le numéro de contrôle est suffixé par un « A », cela indique que le contrôle est
« Conseillé ».
• Type de mesure – Une mesure est soit « Obligatoire » soit « Conseillée ». Les
utilisateurs doivent mettre en œuvre toutes les mesures obligatoires qui s’appliquent à
eux, compte tenu de leur type d’architecture. Les mesures conseillées sont
considérées comme de bonnes pratiques de sécurité dont la mise en œuvre est
vivement recommandée.
• Applicabilité aux types d’architecture - Les contrôles sont applicables soit aux
utilisateurs dotés d’une architecture de type A1, A2 et A3), de type A4, de type B ou
d’une combinaison de types. Ainsi, les utilisateurs ayant une architecture de type B ne
sont pas tenus de se conformer aux contrôles uniquement applicables aux types A1,
A2 et A3.
Définition de la mesure
• Objectif de la mesure – Énonce l’objectif de sécurité à atteindre, quelle que soit la
méthode de mise en œuvre utilisée.
• Éléments visés – Composants spécifiques relatifs à SWIFT qui sont couverts par cette
mesure particulière. (voir également Périmètre des mesures de sécurité).
Remarque: lors de l’extension du périmètre aux nouveaux éléments, ces nouveaux
éléments visés peuvent être initialement qualifiés de Conseillés 16.
• Facteurs de risque – Précisent les risques spécifiques qui sont traités par cette
mesure de sécurité. Une matrice complète des risques est fournie en annexe A.
Guide de mise en œuvre
• Description de la mesure – Moyen suggéré par lequel l’Objectif de la mesure peut
être atteint.
• Contexte de la mesure – Informations générales supplémentaires sur cette mesure.
• Principes de mise en œuvre – Méthode élaborée par SWIFT pour la mise en œuvre
de la mesure.
Les utilisateurs doivent attester leur conformité à tous les objectifs de mesures
obligatoires.
Des informations complémentaires sur les différentes options de mise en œuvre pour la
mise en conformité sont fournies dans la section suivante. Les utilisateurs peuvent
également obtenir d’autres informations utiles dans le CSP FAQ (SWIFT Knowledge Base
TIP 5021823) et dans le Security Guidance Document (connexion sur swift.com requise)
16
Le processus de gestion des changements garantit que la communauté SWIFT dispose de suffisamment de temps pour
comprendre et mettre en œuvre toute modification future des exigences de contrôle. Les nouvelles mesures obligatoires sont
généralement d’abord introduites sous la forme de mesures conseillées afin de laisser aux utilisateurs au moins deux cycles pour
les planifier, les budgéter et les mettre en œuvre.
1er juillet 2020 21

Présentation détaillée Conformité des contrôles de sécurité
Conformité des contrôles de sécurité

Conformément à la structure des mesures de sécurité présentée ci-dessus, l’objectif d’une
mesure indique l’objectif de sécurité à atteindre, quelle que soit la méthode de mise en
œuvre utilisée.
Pour se mettre en conformité avec une mesure de sécurité CSP, les utilisateurs doivent
mettre en place une solution qui:
1. Répond à l’Objectif du contrôle énoncé,
2. Traite les facteurs de risque (voir l’annexe A pour obtenir une matrice des risques et
l’annexe C pour obtenir une illustration de ces risques), et
3. Couvre les éléments visés documentés pertinents pour l’architecture de l’utilisateur.
La Description de la mesure suggère un moyen d’atteindre l’Objectif de la mesure et les
Principes de mise en œuvre indiquent des méthodes courantes de mise en œuvre de la
mesure.
Pour obtenir la mise en conformité, les deux méthodes suivantes sont disponibles:
A) Mettre en place une solution conforme aux principes de mises en œuvre de SWIFT,
énoncés dans le présent document.
La section Guide de mise en œuvre ne doit pas être considérée comme une « grille
d’audit stricte » dans la mesure où chaque mise en œuvre utilisateur est différente. Par
conséquent, si certains éléments des principes de mise en œuvre ne sont pas abordés
ou ne le sont que partiellement, les limitations ainsi que les particularités de
l’environnement concerné doivent être prises en compte pour évaluer correctement la
conformité aux principes.
B) Mettre en place une solution alternative aux orientations de mise en œuvre formulées
par SWIFT, qui répond à l’objectif énoncé de la mesure tout en réduisant les risques
associés.
Dans ce type de situation, les mesures déployées, leur efficacité et les particularités de
l’environnement concerné doivent être prises en compte pour évaluer correctement la
conformité aux objectifs de la mesure appliquée à la solution (approche d’évaluation
des risques).
Les deux méthodes doivent être considérées comme valables et tout aussi robustes du
point de vue du risque.
Il appartient aux utilisateurs d’évaluer si la solution de mise en œuvre formulée par SWIFT
est adaptée à leur environnement ou de décider d’adopter une solution alternative.
Seul un petit nombre d’utilisateurs – généralement ceux appartenant à une organisation
disposant d’un niveau élevé de maturité dans la gestion des risques de sécurité liés aux
informations – devrait opter pour des solutions de mise en œuvre alternatives pour une ou
plusieurs mesures afin de prendre en charge des configurations complexes ou de grande
envergure.
1er juillet 2020 22

Présentation détaillée Tableau récapitulatif des mesures de sécurité Tableau
Tableau récapitulatif des mesures de sécurité

Tableau
Le tableau ci-dessous donne un aperçu de toutes les mesures de sécurité obligatoires et
conseillées, organisées suivant le principe qu’elles appuient, en indiquant le type
d’architecture concerné. En outre, le tableau permet d’identifier les mesures applicables en
fonction du type d’architecture. Dans le présent document, les mesures conseillées sont
identifiées par un « A » à la fin du numéro de la mesure (par exemple « 2.4A ») et sont
également grisées dans le tableau ci-dessous.
Type d’architecture
Mesures de sécurité obligatoires et conseillées A1→A3 A4 B
1 Limiter l’accès à Internet et séparer les systèmes critiques de l’environnement TI général

1.1 Protection de l’environnement SWIFT ●
1.2 Contrôle des comptes à privilèges dans le système d’exploitation ● ●
1.3 Protection de la plateforme de virtualisation ● ●
1.4 Restriction de l’accès à Internet ● ● ●
2 Réduire la surface d’attaque et les vulnérabilités
2.1 Sécurité des flux de données internes ●
2.2 Mises à jour de sécurité ● ● ●
2.3 Sécurisation des systèmes ● ● ●
2.4A Sécurité du flux de données d’application métier: ● ● ●
2.5A Protection des données transmises en externe ● ●
2.6 Confidentialité et intégrité de la session opérateur ● ● ●
2.7 Analyse des vulnérabilités ● ● ●
2.8A Externalisation des activités critiques ● ● ●
2.9A Contrôles opérationnels des transactions ● ● ●
2.10 Sécurisation des applications ●
2.11A Mesures opérationnelles RMA ● ● ●
3 Sécuriser physiquement l’environnement
3.1 Sécurité physique ● ● ●
4 Prévenir les vols d’identifiants
4.1 Politique en matière de mots de passe ● ● ●
4.2 Authentification à facteurs multiples ● ● ●
5 Gérer les identités et séparer les privilèges
5.1 Contrôle d’accès logique ● ● ●
5.2 Gestion des jetons ● ● ●
5.3A Processus Ressources humaines de validation du personnel ● ● ●
5.4 Stockage physique et logique des mots de passe ● ● ●
6 Détecter les activités anormales dans les systèmes ou les relevés d’opérations
6.1 Protection contre les logiciels malveillants ● ● ●
6.2 Intégrité des logiciels ●
6.3 Intégrité des bases de données ● 17
17
Non applicable à A3
1er juillet 2020 23

6.4 Journalisation et surveillance ● ● ●

6.5A Détection des intrusions ● ●
7 Plan d’intervention en cas d’incident et partage d’informations
7.1 Planification de l’intervention en cas de cyber-incident ● ● ●
7.2 Formation et sensibilisation à la sécurité ● ● ●
7.3A Tests d’intrusion ● ● ●
7.4A Évaluation des risques fondée sur des scénarios ● ● ●
Les deux figures suivantes illustrent les composants où les contrôles s’appliqueraient en
utilisant comme référence l’une des nombreuses configurations possibles d’une
architecture A1 (voir également l’annexe B pour quelques autres architectures de
référence).
La Figure 8 illustre les mesures appliquées au niveau de l’infrastructure et des hôtes
combinées aux mesures organisationnelles jouxtant ce type d’environnement. La Figure 9
montre les contrôles de flux interactifs ou applicatifs entre les composants relatifs à SWIFT
et les PC opérateurs ou les systèmes de back-office.
Figure 8: Mesures organisationnelles et statiques de l’infrastructure
1er juillet 2020 24

Figure 9: Mesures des flux homme/application vers machine/application
1er juillet 2020 25

Présentation détaillée Descriptions détaillées des mesures de sécurité
Descriptions détaillées des mesures de sécurité

1 Limiter l’accès à Internet et séparer les
systèmes critiques de l’environnement TI
général
1.1 Protection de l’environnement SWIFT
A1→A3 A4 B
Type de contrôle: Obligatoire Applicable à l’architecture: ●
Objectif du contrôle: Protéger l’infrastructure SWIFT locale de l’utilisateur contre des éléments potentiellement
compromis de l’environnement informatique et bureautique général ainsi que de l’environnement externe.
Éléments dans le périmètre:

• Interface de messagerie
• Interface de communication
• GUI
• SWIFTNet Link
• Hardware Security Module (HSM)
• Connecteur SWIFT
• Jump server
• PC opérateur dédiés et à usage général
Facteurs de risque:
• Piratage du système d’authentification de l’entreprise
• Vol d’identifiants utilisateur
• Rejeu d’identifiants
• Exposition aux attaques sur Internet
• Accès non autorisé à l’hyperviseur et à ses modules de configuration
Description de la mesure:
Une zone sécurisée cloisonnée protège l’infrastructure SWIFT de l’utilisateur des attaques visant l’environnement
global de l’entreprise et l’environnement externe.
Contexte de la mesure:
Séparer l’infrastructure SWIFT locale du reste du réseau de l’entreprise réduit la surface d’attaque et s’avère
efficace pour empêcher les cyber-attaques qui ciblent souvent l’environnement TI général d’une entreprise. Un
cloisonnement efficace inclut une séparation au niveau du réseau, des restrictions d’accès et des restrictions de
connexion.
Principes de mise en œuvre:

Les principes de mise en œuvre sont des méthodes communes pour mettre en œuvre les contrôles
appropriés. Ces principes peuvent constituer un bon point de départ pour une évaluation, mais ne
doivent jamais être considérés comme une « grille d’audit », car les mises en œuvre peuvent varier d’un
utilisateur à l’autre. Par conséquent, dans les cas où certains éléments des principes de mise en œuvre
1er juillet 2020 26

A1→A3 A4 B
ne sont pas présents ou sont partiellement appliqués, les mesures d’atténuation ainsi que les spécificités
environnementales particulières doivent être prises en compte pour évaluer correctement le niveau
global de conformité (conformément aux principes de mise en œuvre suggérés ou à d’autres solutions).
a) Objectifs de conception générale pour la mise en œuvre du cloisonnement de l’environnement
• Créer une « zone sécurisée » pour séparer et protéger l’infrastructure SWIFT locale de systèmes et
services potentiellement compromis situés en dehors de la zone sécurisée.
• Si possible, les mots de passe et autres authentificateurs utilisables dans la zone sécurisée (surtout pour
les comptes à privilèges) ne sont pas stockés ni utilisés sous quelque forme que ce soit (hachés, chiffrés
ou en texte brut) dans des systèmes extérieurs à la zone sécurisée. Cela ne s’applique pas aux fichiers
de sauvegarde chiffrés. Si le système de services d’authentification est situé en dehors de la zone
sécurisée SWIFT:
− Soit le système est dans une autre zone sécurisée existante disposant de contrôles similaires
− Soit le système est utilisé uniquement pour filtrer les connexions à l’élément de l’infrastructure SWIFT
(en contrôlant la connectivité aux points d’entrée de la zone sécurisée). Dans ce cas, l’accès logique à
l’élément de l’infrastructure SWIFT est assuré par un autre mécanisme d’authentification situé dans la
zone sécurisée (une autre gestion des identités et des accès, ou l’élément accédé lui-même).
• La délimitation de la zone sécurisée est adaptée à l’environnement de chaque utilisateur, en réutilisant
éventuellement des zones sécurisées existantes (par exemple, un « environnement de production », un
« environnement métier » ou une « zone des systèmes de paiement ») et incluant l’infrastructure SWIFT
locale.
• Les éléments inclus dans la zone sécurisée sont tous protégés au même niveau ou avec un niveau
équivalent de sécurité, de contrôle d’accès et de confiance, et peuvent interfacer librement à l’intérieur de
la zone.
• L’annexe B présente des schémas d’architecture illustrant quelques-unes des nombreuses façons
possibles de concevoir une zone sécurisée.
b) Périmètre de la zone sécurisée

• La zone sécurisée contient entre autres tous les éléments de l’infrastructure SWIFT locale, à savoir: Ce
périmètre inclut: l’interface de messagerie, l’interface de communication, une GUI basée sur un
navigateur, SWIFTNet Link, Hardware Security Module (HSM), un connecteur SWIFT, un jump server
(voir informations complémentaires ci-dessous), ainsi que les PC opérateur dédiés exclusivement à
l’exploitation ou à l’administration de l’infrastructure SWIFT locale.
− Les PC opérateur à usage général sont exclus de la zone sécurisée.
− Les PC opérateur sur lesquels un logiciel pour SWIFT est installé (c.-à-d. un logiciel avec GUI « client
lourd ») sont situés dans la zone sécurisée, ou bien le logiciel est installé uniquement sur le jump
server accessible par les PC opérateur à usage général en dehors de la zone sécurisée.
− Les systèmes back-office et middleware (par exemple, le serveur IBM® MQ) ne sont pas forcément
inclus dans la zone sécurisée, mais peuvent l’être, suivant la taille et le périmètre choisis de la zone
sécurisée.
− De préférence, les systèmes recettes sont séparés des systèmes de production (y compris des HSM)
et configurés de manière à prendre en charge uniquement le trafic recette (par exemple, en utilisant
uniquement des certificats Lite et en configurant uniquement les terminaux logiques de recette). S’ils
ne sont pas totalement séparés, ces systèmes doivent être maintenus au même niveau de sécurité
que les systèmes de production.
Les systèmes de développement ne sont pas inclus dans la zone sécurisée et ne sont pas connectés
au réseau SWIFT.
− Les boîtiers VPN Alliance Connect ou leurs instances virtuelles (systèmes ou machines
d’hébergement) se trouvent dans un environnement sécurisé avec des contrôles physiques appropriés
(conformément à la mesure 3.1).
• La taille et le périmètre de la zone sécurisée sont définis en fonction de l’environnement de l’utilisateur.
Les différentes options possibles incluent entre autres:
− Une zone sécurisée SWIFT dédiée uniquement à l’infrastructure SWIFT locale.
− Une extension d’une zone sécurisée existante (par exemple, un « environnement de production » ou
une « zone des systèmes de paiement » sécurisés) de manière à y intégrer l’infrastructure SWIFT
1er juillet 2020 27

A1→A3 A4 B
locale. La taille et le périmètre de cette zone peuvent varier considérablement, en fonction de

l’environnement existant.
• L’utilité des logiciels, systèmes et services qui se trouvent dans la zone sécurisée est évaluée et ceux qui
ne sont pas utiles à l’exploitation ou à la sécurité de la zone sont supprimés, par exemple, utilité évaluée
pour l’accès aux courriels.
c) Protection de la zone sécurisée

Protection du périmètre de la zone sécurisée
• Des pare-feu dynamiques au niveau de la couche transport sont utilisés pour créer une séparation
logique à la limite de la zone sécurisée.
− Les pare-feu situés au niveau de la couche transport et qui délimitent la zone sécurisée doivent être
physiquement ou virtuellement dédiés à la protection de la zone sécurisée. Dans le cas où un pare-feu
est partagé pour séparer d’autres zones, il convient de prendre des précautions au niveau de sa
gestion pour que la compromission de ce pare-feu n’affecte pas la protection de la zone sécurisée.
− Des ACL et des pare-feu d’applications peuvent être utilisés comme protections supplémentaires pour
la zone sécurisée, mais ne suffisent pas à eux seuls.
• Des dispositifs de couche 2 (couche liaison de données, comme des switchs) peuvent être partagés entre
la zone sécurisée et d’autres utilisations (cloisonnement VLAN).
• L’accès des administrateurs aux périphériques de réseau est protégé soit avec un réseau hors bande soit
via un accès intrabande contrôlé (par exemple, un VLAN de gestion). L’accès des administrateurs au(x)
pare-feu qui protège(nt) la zone sécurisée ne repose pas sur le système d’authentification des utilisateurs
de l’entreprise, mais un système situé dans une zone sécurisée existante possédant les mêmes mesures
que celles de la zone sécurisée SWIFT.
• Les connexions entrantes et sortantes pour la zone sécurisée sont limitées dans la mesure du possible.
Un processus est mis en place pour analyser, vérifier et appliquer les règles de pare-feu régissant les
connexions.
− Aucune règle de pare-feu « autoriser tout » n’est mise en place, et tous les flux réseau sont
explicitement autorisés (établissement d’une liste blanche). Pour atteindre cet objectif, un serveur
général de l’entreprise doit être initialement utilisé pour filtrer l’accès légitime à la connectivité vers la
zone sécurisée sans perdre la traçabilité de ces connexions.
− En général, les connexions qui franchissent les limites de la zone sécurisée sont limitées aux
communications bidirectionnelles avec les applications back-office et MV-SIPN 18, aux communications
entrantes de PC opérateur à usage général approuvés vers le jump server, et aux données
d’administration sortantes (journalisation des données, sauvegardes).
− Les règles de pare-feu sont revues au moins une fois par an.
− Les connexions qui passent par les pare-feu de la zone sont journalisées.
d) Accès aux systèmes de la zone sécurisée

d.1 Accès des opérateurs locaux (utilisateurs finaux et administrateurs)
• La zone sécurisée a mis en place l’un des mécanismes suivants pour restreindre l’accès des opérateurs
(sessions interactives ou en ligne de commande) à la zone sécurisée:
− Les opérateurs se connectent avec des PC opérateur dédiés situés dans la zone sécurisée (c’est-à-
dire des PC situés à l’intérieur de la zone sécurisée et utilisés exclusivement pour les besoins de la
zone sécurisée).
− Les opérateurs se connectent à la zone sécurisée avec leur PC opérateur à usage général via un jump
server (par exemple, en utilisant une solution de type Citrix ou Microsoft Terminal Server) situé dans la
zone sécurisée ou dans une autre zone sécurisée existante possédant des mesures similaires.
En tant que point d’entrée dans la zone sécurisée, le jump server applique des règles de sécurité
strictes, y compris:
o Vérifier que toutes les mesures de sécurité applicables sont mises en œuvre (par exemple: mises à
jour de sécurité, sécurisation des systèmes),
18
Multi-Vendor Secure IP Network
1er juillet 2020 28

A1→A3 A4 B
o Séparer le jump server pour les administrateurs du système (avec une authentification
multifactorielle) et les utilisateurs finaux,
Comme alternative aux jump servers séparés, n’autoriser qu’un accès temporaire aux
administrateurs système avec un processus d’approbation efficace et un enregistrement
de l’activité de la session.
o Limiter l’accès aux opérateurs autorisés uniquement,
o Supprimer les logiciels inutiles,
o Limiter les activités à risque (par exemple: envoi/réception de courriels),
o Activer la journalisation.
− Les opérateurs se connectent avec leur PC opérateur à usage général et accèdent uniquement à
l’interface de messagerie ou de communication en utilisant une GUI basée sur un navigateur (par
exemple, Alliance Web Platform). Des mesures de sécurité spécifiques s’appliquent à cette
configuration:
o La GUI basée sur un navigateur est située dans la zone sécurisée et est séparée logiquement de
l’interface de messagerie et de communication.
o Une authentification multifactorielle est mise en place à l’endroit approprié (sur la GUI basée sur un
navigateur, l’interface de messagerie ou l’interface de communication).
o Cette configuration ne peut pas être utilisée pour les activités d’administration du système
d’exploitation.
• Les systèmes SWIFT qui se trouvent à l’intérieur de la zone sécurisée limitent l’accès des administrateurs
aux seuls ports, protocoles et IP sources prévus.
d.2 Accès des opérateurs distants (télétravail, « astreintes » ou administration à distance)
• L’accès à distance à la zone sécurisée depuis l’extérieur du réseau local de l’utilisateur nécessite d’abord
une authentification VPN (recommandée avec l’authentification multifacteur) au réseau local avant
d’accéder à la zone sécurisée via les mêmes canaux sécurisés que les opérateurs locaux.
• L’utilisateur réalise une évaluation des risques afin de déterminer les mesures de sécurité
supplémentaires à mettre en œuvre pour l’accès à distance, comme l’utilisation d’une infrastructure de
bureau virtuel, des canaux dédiés pour la connexion (par exemple, jump servers dédiés pour les
utilisateurs distants, lignes louées).
e) Dissociation des services informatiques et bureautiques généraux de l’entreprise

• Pour protéger la zone sécurisée contre le vol de justificatifs d’identité et/ou la corruption des services
d’authentification d’entreprise (LDAP, RADIUS, fournisseur d’identité, multifacteur), les systèmes de zone
sécurisée utilisent un système d’authentification distinct du service général d’authentification d’entreprise.
Par exemple, les systèmes de la zone sécurisée ne sont pas membres d’un service d’annuaire
d’entreprise, mais plutôt d’un service d’annuaire de zone sécurisée.
• L’infrastructure TI d’appui, comme la gestion des actifs, les bases de données, le stockage des données,
les services de sécurité (par exemple, les correctifs) et les services réseau (par exemple, DNS, NTP)
utilisés dans la zone sécurisée, est protégée de tout vol d’identifiants qui pourrait intervenir ailleurs dans
l’environnement de l’entreprise. Les établissements doivent analyser les systèmes de connexion pour
s’assurer qu’ils ne stockent pas d’authentificateurs (mots de passe, jetons, etc.) pour les systèmes et
comptes concernés, dans un quelconque format (haché, chiffré, texte brut) en dehors de la zone
sécurisée ou dans une autre zone sécurisée existante possédant des mesures similaires. En effet,
l’infrastructure TI d’appui n’a pas besoin d’être dédiée exclusivement aux systèmes SWIFT, et peut être
partagée au sein des zones sécurisées.
Mesures supplémentaires facultatives:

• Les systèmes de la zone sécurisée utilisent des listes blanches d’applications, lorsque cela est
techniquement possible. Ainsi, seules les applications fiables peuvent s’exécuter.
• Restreindre, par un cloisonnement supplémentaire, la communication entre les composantes de la zone
sécurisée envisagée:
− Les ACL réseau ou les pare-feu hébergés imitent le trafic hôte par hôte dans la zone sécurisée.
− Des pare-feu physiques ou réseau peuvent être utilisés entre les éléments de la zone sécurisée.
Points à considérer en cas de mise en œuvre alternative:
1er juillet 2020 29

A1→A3 A4 B
Les organisations qui ont un programme de sécurité mature peuvent envisager de mettre en œuvre des mesures
alternatives comme suggéré ci-dessous ou alternatives. Les solutions alternatives doivent être adaptées aux
risques de chaque environnement, et tenir compte des efforts nécessaires pour déployer, gérer et maintenir
efficacement cette solution.
• L’absence de séparation entre les systèmes d’authentification de la zone sécurisée et ceux de
l’entreprise dans son ensemble nécessitera la mise en œuvre d’un ensemble complet de mécanismes de
défense en profondeur, afin de détecter les intrusions dans la zone sécurisée et de s’en prémunir. Ces
mécanismes peuvent inclure: le repérage d’un service d’authentification dans une zone sécurisée
existante possédant des mesures identiques à celles applicables à la zone sécurisée SWIFT, la limitation
des relations de confiance entre l’environnement global de l’entreprise et la zone sécurisée (comme les
relations de confiance unilatérales), la restriction de l’accès des opérateurs et administrateurs, la mise en
place de mécanismes de contrôle d’accès privilégié solides, la mise en place d’un accès en lecture seule
si possible, l’activation de la journalisation détaillée, et la mise en place de capacités de détection et de
surveillance actives centralisées.
• Si les services TI généraux de l’entreprise (par exemple, analyse des vulnérabilités, gestion des pare-feu
aux entrées de la zone) sont partagés entre la zone sécurisée et d’autres environnements, les identifiants
utilisés à travers l’environnement doivent être contrôlés pour s’assurer qu’ils sont utilisés uniquement à
bon escient.
• Si un serveur général d’entreprise est initialement utilisé pour atteindre la zone sécurisée, ce serveur
n’est utilisé que pour filtrer l’accès légitime à la connectivité (constituant ainsi un concentrateur ou une
passerelle pour faciliter le filtrage de l’accès à la zone sécurisée). La gestion des identités et des accès
pour des éléments de la zone sécurisée et/ou le jump server repose encore sur des services
d’authentification résidant à l’intérieur de la zone sécurisée SWIFT ou une autre zone sécurisée existante
disposant de contrôles similaires.
• Si la zone sécurisée dépend de fonctions partagées par l’entreprise (par exemple, services d’annuaire,
serveurs ou réseaux) qui sont en dehors du périmètre, l’utilisateur doit s’assurer que si ces fonctions sont
compromises, elles ne compromettront pas la sécurité des éléments situés au sein du périmètre.
1er juillet 2020 30

1.2 Contrôle des comptes à privilèges dans le système

d’exploitation
A1→A3 A4 B
Type de contrôle: Obligatoire Applicable à l’architecture: ● ●
Objectif du contrôle: Restreindre et contrôler l’attribution et l’utilisation de comptes d’administrateur dans le

système d’exploitation.

• Zone sécurisée: comptes administrateur du système d’exploitation (sur des machines physiques ou
virtuelles)
• Plateforme de virtualisation locale ou distante (hébergée et/ou exploitée par un tiers) (également appelée
hyperviseur) hébergeant les VM relatives à SWIFT: comptes de niveau administrateur de la plateforme
• [Conseillé A1/A2/A3: Serveur middleware (tel que le serveur IBM® MQ ou équivalent) utilisé pour réaliser
des échanges avec les éléments relatifs à SWIFT]
• [Conseillé A4: Connecteur client]
Facteurs de risque:
• Suppression des journaux et des éléments de preuve
• Privilèges ou accès excessifs
• Manque de traçabilité
• Modifications non autorisées apportées au système
L’utilisation du compte administrateur dans le système d’exploitation est restreinte au maximum. L’utilisation est
contrôlée, surveillée, et autorisée uniquement pour des activités nécessaires comme l’installation et la
configuration d’un logiciel, les opérations de maintenance et les interventions d’urgence. Le reste du temps, un
compte avec moins de privilèges d’accès est utilisé.
Contrôler étroitement les comptes administrateur au niveau du système d’exploitation réduit le risque d’un
détournement des privilèges du compte par un cyber-pirate pour mener une attaque (par exemple, exécution de
commandes, suppression de traces).
appropriés. Ces principes peuvent constituer un bon point de départ pour une évaluation mais ne doivent
jamais être considérés comme une « grille d’audit », car les mises en œuvre peuvent varier d’un
• Les comptes administrateur sont:
− Windows: le compte administrateur intégré et les membres de groupes ayant des privilèges
d’administrateur (par exemple, comptes avec des privilèges de débogage ou sur le système de
fichiers). En général, les groupes Administrateurs de l’entreprise, Administrateurs de domaine et
Administrateur local.
− Linux/Unix: compte root (ID utilisateur = 0) et les membres du groupe root.
1er juillet 2020 31

A1→A3 A4 B
− Mainframe: administrateur système ou programmeur système.

• L’accès aux comptes administrateur du système d’exploitation est restreint au maximum, sauf pour
l’installation, la configuration, la maintenance et les interventions d’urgence. L’utilisation du compte
administrateur est limitée à la durée de l’activité (par exemple, fenêtres de maintenance).
• Il est interdit de se connecter avec un compte administrateur intégré sauf pour des activités pour
lesquelles ces comptes sont indispensables (par exemple, configuration du système) ou dans des
situations d’urgence (compte « urgence »). À la place, des comptes individuels avec privilèges
d’administrateur ou des comptes individuels permettant de passer en mode administrateur (comme
« sudo ») sont utilisés.
• L’accès avec un compte administrateur individuel et l’utilisation de ce compte sont journalisés afin que les
activités puissent être reconstituées, permettant ainsi la détermination de la cause profonde d’un incident.
• Les mots de passe des administrateurs sont étroitement contrôlés avec des mécanismes de contrôle
d’accès physiques lorsqu’ils sont enregistrés physiquement.

• Les systèmes sont configurés de manière à empêcher la connexion avec un compte administrateur
intégré, sauf en mode maintenance (par exemple, mode utilisateur unique ou mode sécurisé). Cela
bloque efficacement les connexions au compte en tant que service, traitement par lots, via des services
de bureau à distance, ou en accédant au privilège à partir d’un autre compte.
1er juillet 2020 32

1.3 Protection de la plateforme de virtualisation

A1→A3 A4 B
Objectif du contrôle: Sécuriser la plateforme de virtualisation et les machines virtuelles (VM) qui hébergent des
éléments relatifs à SWIFT au même niveau que les systèmes physiques.

hyperviseur) et VM utilisées pour héberger l’un des composants relatifs à SWIFT ci-dessous:
− Interface de messagerie
− Interface de communication
− GUI
− SWIFTNet Link
− Connecteur SWIFT
− Jump server
− PC opérateur dédiés et à usage général
− Pare-feu
− [Conseillé A1/A2/A3: Serveur middleware (tel que le serveur IBM® MQ ou équivalent) utilisé pour
réaliser des échanges avec les éléments relatifs à SWIFT]
− [Conseillé A4: Connecteur client]
Facteurs de risque:
• Prolifération incontrôlée de systèmes et de données
Sécuriser la plateforme de virtualisation, les machines virtualisées et l’infrastructure virtuelle d’appui (par
exemple, les pare-feu) au même niveau que les systèmes physiques.
Les mesures de sécurité qui s’appliquent aux systèmes non virtualisés (c’est-à-dire physiques) s’appliquent
également aux systèmes virtuels. La couche de virtualisation supplémentaire requiert une attention spéciale en
termes de sécurité. La prolifération incontrôlée des VM peut déboucher sur des machines non prises en charge
présentant le risque de systèmes non gérés, dépourvus de correctifs et exposés aux accès non autorisés aux
données.
À condition que des mesures appropriées aient été mises en œuvre au niveau de cette couche sous-jacente,
SWIFT ne limite pas l’utilisation de technologies de virtualisation pour un élément quelconque de l’infrastructure
SWIFT locale ou de l’infrastructure d’appui associée (par exemple, pare-feu virtuels).
Lorsqu’il s’appuie sur un tiers pour la plateforme de virtualisation sous-jacente, l’utilisateur doit s’engager avec le
tiers pour obtenir le confort raisonnable que l’objectif du contrôle est atteint.
1er juillet 2020 33

A1→A3 A4 B
• Les mêmes exigences de sécurité s’appliquent à la plateforme de virtualisation, aux machines virtuelles
et à l’infrastructure virtuelle d’appui qu’à tous les autres systèmes et éléments d’infrastructure. Ces
exigences de sécurité couvrant, par exemple, un site dans une zone sécurisée existante possédant des
mesures similaires à celles applicables à la zone sécurisée SWIFT, aux restrictions d’accès privilégié, à
la politique de connexion et de mot de passe, à l’installation de correctifs de sécurité et à la restriction de
l’accès à Internet. La plateforme de virtualisation est identifiée dans la section Éléments visés pour ces
mesures.
• Une analyse des vulnérabilités est effectuée sur les VM relatives à SWIFT et, lorsque cela est possible au
niveau technique, sur la plateforme de virtualisation.
• Les hôtes de la plateforme de virtualisation font l’objet d’une protection physique qui empêche les accès.
• L’isolement des VM est garanti sur la plateforme de virtualisation afin d’éviter a) tout déplacement latéral
en dehors d’une machine virtuelle afin d’accéder ou d’interagir avec d’autres VM ou avec l’hyperviseur
sous-jacent b) tout contournement des contrôles normaux du réseau qui filtrent et/ou inspectent les
connexions à l’environnement SWIFT.
o Le filtrage et l’inspection prévue des flux réseau qui atteignent les VM relatives à SWIFT sont de
préférence effectués en utilisant des ressources (telles que FW, des inspections des paquets ou un
filtrage des contenus) externes à la plateforme de virtualisation. Sinon, ils doivent être mis en
œuvre au niveau de l’hyperviseur.
o Si l’isolement est garanti sur la plateforme de virtualisation, les VM hébergées peuvent conserver
leur classification (sécurité) et être sécurisées individuellement en conséquence (ainsi elles
n’héritent pas de la classification des VM relatives à SWIFT et ne sont pas soumises à toutes les
mesures relatives à SWIFT ).
• Si une authentification multifactorielle est mise en œuvre pour l’accès interactif aux systèmes
d’exploitation des VM relatives à SWIFT , conformément à la mesure 4.2, en empêchant tout accès direct
à ces VM à partir de la couche de l’hyperviseur, l’authentification multifactorielle n’est pas obligatoire au
niveau gestion de la plateforme de virtualisation.
1er juillet 2020 34

1.4 Restriction de l’accès à Internet

A1→A3 A4 B
Type de contrôle: Obligatoire Applicable à l’architecture: ● ● ●
Objectif du contrôle: Contrôler/protéger l’accès à Internet à partir des PC opérateurs et autres systèmes se
trouvant dans la zone sécurisée

• PC opérateur dédiés et à usage général
• Jump server
• [Conseillé: Plateforme de virtualisation locale ou distante (hébergée et/ou exploitée par un tiers)
(également appelée hyperviseur) et ses PC de gestion]
• GUI
• SWIFTNet Link
Facteurs de risque:
• Exposition aux attaques sur Internet
Tous les PC opérateur dédiés et à usage général ainsi que les systèmes situés dans la zone sécurisée ont un
accès direct contrôlé à l’Internet, conformément à l’activité 19.
Un accès direct à Internet accroît l’exposition aux attaques sur Internet. Les risques sont encore plus élevés en
présence d’interactions humaines (navigation, emails ou autres activités autorisées sur les réseaux sociaux). Une
fois violés, ces systèmes peuvent devenir un point d’entrée laissant la voie à des mouvements latéraux et/ou à
l’intrusion d’éléments de commande et de contrôle.
La limitation et le contrôle des accès directs à Internet sont la priorité même si la réduction de la surface d’attaque
et des vulnérabilités de ces systèmes, conformément aux mesures pertinentes identifiées dans ce document,
sont également fondamentales.
En plus des PC opérateurs (à usage général) qui connectent les services ou applications relatifs à SWIFT offerts
par les prestataires de services (tels que SWIFT dans le cas de Lite2 ou Alliance Cloud, un Service Bureau, un
fournisseur L2BA), il convient de faire preuve de diligence pour sécuriser les PC opérateurs (à usage général)
utilisés pour accéder aux interfaces locales ou à l’interface graphique. Combiner de manière non sécurisée
l’accès à l’« environnement de production » à l’accès Internet pourrait donner lieu à des abus de la part de cyber
pirates.
19
L’objectif n’est pas d’interdire l’accès à l’Internet, mais de limiter/contrôler la connectivité lorsque cela est pertinent pour des
raisons commerciales (par exemple pour accéder aux ressources d’un prestataire de services externe).
1er juillet 2020 35

A1→A3 A4 B
a) Accès à Internet depuis la zone sécurisée
• La navigation sur Internet à des fins générales (y compris les activités Web Mail) provenant de systèmes
situés dans la zone sécurisée SWIFT n’est pas autorisée.
• L’accès à Internet à partir des systèmes situés dans la zone sécurisée (par exemple, PC opérateur
dédiés ou autres éléments relatifs à SWIFT ) est très limité et bloqué dans l’idéal.
− Si possible, les activités nécessitant l’utilisation d’Internet sont menées en dehors de la zone
sécurisée. Il peut s’agir, par exemple, d’opérations courantes effectuées sur swift.com ou du
téléchargement de correctifs de sécurité pour le transfert sécurisé de données dans la zone sécurisée.
− Si un accès à Internet est nécessaire à l’intérieur de la zone sécurisée, il peut être accordé uniquement
pour les URL de destination sur liste blanche via un proxy avec contrôle de contenu, en combinaison
avec une inspection du contenu et des contrôles de blocage/filtrage adéquats. Les connexions sont
autorisées uniquement si elles sont initiées vers l’extérieur.
• En tant que point d’entrée dans la zone sécurisée, le jump server, situé dans celle-ci ou dans une autre
zone sécurisée possédant des mesures équivalentes, ne possède pas d’accès à Internet.
b) Accès à Internet à partir des PC opérateur à usage général

• Contrôler l’accès à l’Internet fourni sur les PC opérateur à usage général utilisés pour
− se connecter à une application chez le prestataire de services (user-to-application) pour traiter les
transactions financières 20.
− accéder à une interface de messagerie ou de communication via une interface graphique basée sur
un navigateur (par exemple, Alliance Web Platform)
En utilisant l’une des options suivantes:
1. Accès à Internet en utilisant une solution de bureau à distance ou de machine virtuelle
2. Accès à Internet à partir du PC opérateur à usage général accordé uniquement pour les URL de
destination sur liste blanche via un proxy avec contrôle de contenu, en combinaison avec des dispositifs
de blocage/filtrage adaptés.
3. Accès à Internet à partir du PC opérateur à usage général par une passerelle Web (avec inspection du
contenu, en combinaison avec des contrôles de blocage/filtrage) utilisant des destinations URL
maintenues sur liste noire
• Même si SWIFT recommande vivement de contrôler l’accès à Internet, un autre moyen d’atteindre
l’Objectif du contrôle sur les PC accédant à l’infrastructure SWIFT locale consiste à imposer l’utilisation
d’un jump server ne disposant pas d’accès à Internet, combiné à une authentification multifactorielle,
conformément à la mesure 4.2, mise en œuvre sur les applications/systèmes individuels relatifs à SWIFT
ou sur le jump server.
c) Accès à Internet à partir d’autres composants (serveurs middleware ou plateforme de virtualisation -

Conseillé)
• L’accès à Internet à partir des systèmes middleware (tels que le serveur IBM® MQ) ou du système sous-
jacent de la plateforme de virtualisation (également connu sous le nom d’hyperviseur) est très limité et
bloqué dans l’idéal.
− Si possible, les activités nécessitant l’utilisation d’Internet sont menées en dehors d’autres systèmes.
Ces activités comprennent par exemple la conduite des affaires quotidiennes ou le téléchargement de
correctifs de sécurité pour un transfert sécurisé dans le système cible.
20
Comme l’affichage, la création, l’approbation ou la modification des transactions de messagerie ou la mise à jour des droits.
L’accès en lecture seule/en interrogation peut être supprimé si les droits en question ne peuvent pas être modifiés à partir des
ordinateurs de ces opérateurs.
1er juillet 2020 36

A1→A3 A4 B
• Si un accès à Internet est nécessaire à l’intérieur de la zone sécurisée, il peut être accordé uniquement
pour les URL de destination sur liste blanche via un proxy avec contrôle de contenu, en combinaison
avec des dispositifs de blocage/filtrage adaptés. Les connexions sont autorisées uniquement si elles sont
initiées vers l’extérieur.
1er juillet 2020 37

2 Réduire la surface d’attaque et les

vulnérabilités
2.1 Sécurité des flux de données internes
A1→A3 A4 B
Objectif du contrôle: Assurer la confidentialité, l’intégrité et l’authenticité des flux de données d’application
entre les applications locales relatives à SWIFT.

• Jump server, si utilisé
• Composants d’infrastructure locaux ou distants (hébergés et/ou exploités par une tierce partie) relatifs à
SWIFT
Facteurs de risque:
• Atteinte à la confidentialité de données sensibles
• Atteinte à l’intégrité de données sensibles.
• Trafic système authentifié
• Vol de mot de passe
Des mécanismes de confidentialité, d’intégrité et d’authentification sont mis en place pour protéger les flux de
données d’application à application relatifs à SWIFT et de jump server à application si utilisé.
La protection des flux de données internes permet de se prémunir contre toute divulgation accidentelle,
modification et tout accès des/aux données pendant leur transfert.

• Tous les flux de données entre applications relatives à SWIFT sont protégés par un mécanisme sécurisé
(par exemple, « authentification locale (LAU) en combinaison avec une protection de la confidentialité 21 »
ou « TLS bidirectionnel ») pour assurer la confidentialité, l’intégrité et l’authentification mutuelle des flux
de données. Cela inclut les flux de données suivants:
− de l’application RMA à l’interface de messagerie,
21
Comme le TLS unidirectionnel
1er juillet 2020 38

A1→A3 A4 B
− de la GUI à l’interface de messagerie,

− de la GUI à l’interface de communication,
− de l’interface de messagerie à l’interface de communication.
• La communication entre le jump server, si présent, et les applications relatives à SWIFT est protégée par
un mécanisme sécurisé (par exemple, TLS unidirectionnel) pour assurer la confidentialité et l’intégrité de
la connexion des utilisateurs vers les applications.
• Les protocoles sécurisés utilisent des algorithmes de cryptographie actuels répandus (par exemple,
AES 22, ECDHE 23), avec des longueurs de clé conformes aux bonnes pratiques actuelles. Pour en savoir
plus sur les algorithmes de cryptographie qui appuient les protocoles sécurisés, consultez la SWIFT
Knowledge Base TIP 5021566.
22
Advanced Encryption Standard
23
Elliptic Curve Diffie-Hellman Ephemeral
1er juillet 2020 39

2.2 Mises à jour de sécurité

A1→A3 A4 B
Objectif du contrôle: Minimiser l’apparition de vulnérabilités techniques connues sur les PC opérateurs et au
sein de l’infrastructure SWIFT locale en assurant le soutien des prestataires, en appliquant les mises à jour
logicielles obligatoires et en appliquant en temps utile des mises à jour de sécurité adaptées au risque évalué.

• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server: tout le matériel et les logiciels
hyperviseur) hébergeant les VM relatives à SWIFT et leurs PC de gestion
• Zone sécurisée: l’ensemble du matériel, y compris les périphériques réseau et les logiciels
Facteurs de risque:
• Exploitation de failles de sécurité connues
L’ensemble du matériel et des logiciels situés à l’intérieur de la zone sécurisée et sur les PC opérateur sont
couverts dans le cycle de maintenance du fournisseur, ont été mis à niveau avec les mises à jour logicielles
obligatoires, et les mises à jour de sécurité ont été appliquées en temps utile sur tous ces éléments.
La neutralisation des failles de sécurité connues permet de réduire efficacement les différents chemins d’accès
qu’un cyber-pirate peut emprunter. Un processus de mise à jour de sécurité global, reproductible et mis en œuvre
en temps utile est nécessaire pour pouvoir neutraliser continuellement ces failles connues lorsque des correctifs
de sécurité sont disponibles.

• Assistance du fournisseur
− L’ensemble des logiciels (y compris les systèmes d’exploitation) et du matériel (y compris les
périphériques réseau) est couvert par le cycle de vie produit du fournisseur et appuyé par une
assistance active (y compris une garantie étendue), s’il y a lieu.
− Des contrats de maintenance ou de licence sont mis en place pour l’accès aux mises à jour, mises à
niveau mineures et autres fonctions de maintenance critiques.
• Mises à jour logicielles obligatoires
− Les versions ou mises à jour obligatoires applicables à un élément de l’infrastructure SWIFT locale
sont installées dans le délai spécifié par le fournisseur.
1er juillet 2020 40

A1→A3 A4 B
• Application de mises à jour de sécurité

− Un processus d’évaluation des risques a été mis en place pour déterminer la manière la plus
appropriée de traiter les mises à jour/correctifs de sécurité du fournisseur. Lors de l’évaluation des
risques, les facteurs à considérer incluent notamment: la criticité du correctif indiquée par le
fournisseur, l’exposition et la vulnérabilité de l’utilisateur, les mesures d’atténuation et l’impact
opérationnel.
− Les délais de déploiement définis par l’utilisateur sont fixés pour l’application des correctifs en fonction
de la criticité, du type de système et des tests à réaliser sur les correctifs.
− En l’absence de processus et de délais définis en interne, SWIFT recommande l’utilisation du
Common Vulnerability Scoring System (CVSS) Version 3 comme outil pour l’évaluation de la criticité,
avec comme objectif de déploiement des correctifs:
o Critique (score 9,0): appliqué dans un délai d’un mois suivant sa sortie
o Élevé (score 7,0 – 8,9): appliqué dans un délai de 2 mois suivant sa sortie
o Bas / Moyen (score < 7,0): défini par l’utilisateur
− Remarque: Remarque: les mises à jour/correctifs de sécurité du système d’exploitation sont
généralement automatiquement installés et exécutés sur les PC opérateur juste après leur publication
par le fournisseur.
• Validation de la source et de l’intégrité des mises à jour de logiciel et de sécurité
• Avant d’appliquer les mises à jour de logiciel et de sécurité, leur source légitime est validée et des
contrôles d’intégrité (par exemple, validation de la somme de contrôle) sont effectués lorsque cela est
possible sur le plan technique.
1er juillet 2020 41

2.3 Sécurisation des systèmes

A1→A3 A4 B
Objectif du contrôle: Réduire la surface de cyber-attaque des éléments relatives à SWIFT en procédant à la
sécurisation des systèmes.

• Systèmes d’exploitation pour les PC opérateur dédiés et à usage général et, lorsqu’ils sont utilisés, les
jump servers
• Systèmes d’exploitation pour les applications relatives à SWIFT (y compris les VM)
• Les infrastructures d’appui dans la zone sécurisée (par exemple, pare-feu, routeurs)
Remarque: Les SWIFT HSM sont conformes à la norme FIPS 140-2 niveau 3 avec système d’exploitation sous-
jacent sécurisé, et ne sont pas visés par cette mesure.
Facteurs de risque:
• Surface d’attaque excessive
• Exploitation d’une configuration système non sécurisée
La sécurisation est appliquée et maintenue pour tous les éléments visés.
La sécurisation du système applique le concept de sécurité du « moindre privilège » à un système en désactivant
les fonctionnalités et les services qui ne sont pas nécessaires à l’exploitation normale du système. Ce processus
réduit les capacités du système, les fonctionnalités et les protocoles qu’une personne malintentionnée pourrait
utiliser lors d’une attaque.

• Tous les systèmes visés sont sécurisés selon une ou plusieurs des procédures suivantes:
− Guide de configuration de sécurité du fournisseur
− Guide de configuration de sécurité standard de l’industrie (par exemple, 24 CIS , DISA STIG, NIST),
24
Center for Internet Security; Defense Information Systems Agency - Secure Technical Implementation Guide; National Institute of
Standards and Technology
1er juillet 2020 42

A1→A3 A4 B
− Une configuration de sécurité ou un jeu de contrôles standard local ou d’une autorité de régulation
aussi rigoureuse que le guide du fournisseur ou la norme de l’industrie.
• Les configurations de sécurisation sélectionnées (jeu de règles) peuvent être remplacées par des
exigences de configuration spécifiques à une application pour assurer le bon fonctionnement des
systèmes liés à SWIFT.
• Le processus de sécurisation doit au minimum:
− Modifier les mots de passe par défaut
− Désactiver ou supprimer les comptes utilisateur inutiles
− Désactiver ou limiter les services, ports et protocoles inutiles
− Supprimer les logiciels inutiles
− limiter les ports physiques (par exemple USB) s’il y a lieu,
− définir, lorsque cela est possible sur le plan technique, des options de verrouillage automatique
(comme l’activation d’un économiseur d’écran sur les PC opérateur exigeant une nouvelle identification
de l’utilisateur après un certain temps d’inactivité ou après une mise en veille. Un délai d’inactivité de
15 minutes est recommandé)
− Modifier les configurations par défaut connues comme étant vulnérables
Les guides de configuration des fournisseurs et de l’industrie susmentionnés peuvent expliquer en détail
comment atteindre ces objectifs minimums.
• Les écarts par rapport à la configuration de sécurisation sélectionnée sont documentés en indiquant le
motif de l’écart et des atténuations potentielles sont appliquées.
• Les systèmes restent sécurisés:
− En vérifiant régulièrement, au moins deux fois par an, les systèmes par rapport aux paramètres
sécurisés identifiés conformément au guide précédent, afin de prendre des mesures correctives
pertinentes
− Ou en appliquant régulièrement les paramètres sécurisés identifiés aux systèmes.
1er juillet 2020 43

2.4A Sécurité du flux de données d’application métier

A1→A3 A4 B
Type de contrôle: Conseillé Applicable à l’architecture: ● ● ●
Objectif du contrôle: Assurer la confidentialité, l’intégrité et l’authenticité mutuelle des flux de données entre les
composants locaux ou distants de l’infrastructure SWIFT et le back-office auquel ils se connectent en premier
lieu.

• Couche d’échange de données: flux de transactions financières entre les composants locaux ou distants
(hébergés et/ou exploités par un tiers) relatifs à SWIFT (interfaces ou connecteurs) et le back-office; au
niveau applicatif, auxquels ils sont connectés (directement ou via un middleware)
Facteurs de risque:
• Trafic système authentifié
Des mécanismes de confidentialité, d’intégrité et d’authentification mutuelle ou au niveau des messages sont mis
en œuvre pour protéger les flux de données entre les composants de l’infrastructure SWIFT et les premiers
serveurs de back-office auxquels ils se connectent.
Protection des flux/connexions de données entre le premier bond du back-office, au niveau applicatif, vu depuis
la zone sécurisée de SWIFT, et les protections de l’infrastructure de SWIFT contre l’homme du milieu, la
divulgation involontaire, la modification et l’accès aux données pendant le transit.

Les principes de mise en œuvre sont des méthodes communes pour effectuer les contrôles appropriés.
Ces principes peuvent constituer un bon point de départ pour une évaluation, mais ne doivent jamais être
considérés comme une « grille d’audit », car les mises en œuvre varient d’un utilisateur à l’autre. Par
conséquent, dans les cas où certains éléments des principes de mise en œuvre ne sont pas présents ou
sont partiellement appliqués, les mesures d’atténuation, ainsi que les spécificités environnementales
particulières, doivent être prises en compte pour évaluer correctement le niveau global de conformité
(conformément aux principes directeurs suggérés ou à d’autres solutions).
• Les données circulant entre les composants locaux ou distants (hébergés et/ou exploités par un tiers)
relatifs à SWIFT et les systèmes de back-office (ou les systèmes de middleware) auxquels ils sont
directement connectés, sont protégées par un mécanisme sécurisé (par exemple, « LAU en combinaison
avec une protection de la confidentialité » ou une autre solution d’authentification basée sur des
messages, XML DSIG, AES GCM Authenticated Encryption, 2-way TLS) qui assure la confidentialité,
l’intégrité et l’authentification mutuelle des données en transit. Cela inclut le flux de données entre
− l’interface de messagerie et les premiers bonds du back-office (ou middleware) observés à partir de
l’interface,
− l’interface de communication et les premiers bonds du back-office (ou middleware) observés à partir de
l’interface,
− le connecteur et les premiers bonds du back-office (ou middleware) observés à partir du connecteur.
1er juillet 2020 44

A1→A3 A4 B
• Les protocoles sécurisés utilisent des algorithmes de cryptographie actuels répandus (par exemple,
AES 25, ECDHE 26), avec des longueurs de clé conformes aux bonnes pratiques actuelles. Pour en savoir
plus sur les algorithmes de cryptographie qui appuient les protocoles sécurisés, consultez la SWIFT
Knowledge Base TIP 5021566.
• Étant donné que cette mesure va progressivement devenir obligatoire dans une future version, les
principes suivants sont indiqués pour garantir la conformité:
− Posséder un inventaire des flux de données entre les éléments relatives à SWIFT et les premiers
bonds du back-office (ou du middleware)
− Élaborer un plan pour mettre en place/activer des mécanismes sécurisés pour les flux identifiés en
tenant compte des points suivants:
o La mise en œuvre de mécanismes sécurisés (voir la première puce ci-dessous) tels qu’exposés
par les interfaces, les connecteurs ou le serveur middleware
o La migration opportuniste des flux de données existants et moins standard vers les protocoles ou
les mécanismes sécurisés
o La restriction parallèle du risque d’usurpation de l’hôte du back-office ou d’intrusion de messages
par l’intermédiaire des dispositifs de connectivité au système ou au réseau.
• Lorsqu’un serveur middleware ou un connecteur client est utilisé, certaines exigences sont attendues des
hôtes de support; ces derniers sont en effet les gardiens des connexions entre le back-office et les
composants relatifs à SWIFT ou SWIFT même:
− Quel que soit l’endroit où les hôtes du serveur middleware ou du connecteur client sont situés et avec
quoi ces serveurs sont partagés, les mêmes exigences de sécurité s’appliquent à ces hôtes ; cela
couvre les serveurs MQ en série utilisés pour atteindre le premier back-office, tout comme les autres
composants ou systèmes d’infrastructure liés à SWIFT. Ces conditions de sécurité couvrent:
l’emplacement dans une autre zone sécurisée possédant des mesures équivalentes à celles qui
s’appliquent à la zone sécurisée SWIFT, restrictions d’accès avec privilèges, politique relative à la
procédure de connexion et aux mots de passe, installation de correctifs de sécurité, restriction de
l’accès à Internet. Ces contrôles ont le serveur middleware et/ou un connecteur client identifiés,
jusqu’à présent, comme « Conseillé » dans les « Éléments dans le périmètre » de leur définition de
contrôle.
− La protection des données sur les serveurs middleware (telles que les données présentes dans les
files d’attente des serveurs MQ utilisées pour atteindre les premiers back-office) ou sur le connecteur
client doit être assurée pour empêcher tout accès non autorisé. Cela peut se faire, par exemple, en
mettant en place un contrôle d’accès approfondi ou en cryptant de manière opportuniste les files
d’attente ou les données au repos)
− La protection des données relatives à SWIFT transitant entre les hôtes du serveur middleware (comme
entre plusieurs serveurs MQ en série) doit être garantie dans le cadre de la protection de
l’infrastructure middleware en utilisant des mécanismes sécurisés (voir le premier point des principes
de mise en œuvre ci-dessus)
− La définition et la gestion des règles de connectivité et des flux d’activité sur les serveurs middleware
doivent être sécurisées pour éviter tout flux non autorisé
• Pour les serveurs middleware (tels que IBM® MQ) connectant directement les composants de
l’infrastructure SWIFT, il est conseillé de mettre également en œuvre le même niveau de protection sur
les flux entre ce serveur middleware et les premiers back-offices, tel que vu du point de vue applicatif par
le composant lié à SWIFT. De même, il est également conseillé de mettre en œuvre le même niveau de
protection entre un connecteur client et les premiers bonds du back-office, le cas échéant, du point de
vue applicatif. Afin de garantir progressivement la conformité pour ces liens, les principes suivants sont
déjà fournis:
− Faire l’inventaire des flux de données relatifs à SWIFT (i) entre le serveur de middleware et les
premiers bonds du back-office vus à partir du composant lié à SWIFT et (ii) entre un connecteur client
et les premiers bonds du back-office vus à partir du connecteur client.
− Élaborer un plan pour activer des mécanismes sécurisés pour les flux identifiés en tenant compte des
points suivants:
25
26
1er juillet 2020 45

A1→A3 A4 B
o Mise en œuvre de mécanismes sécurisés (voir le premier point des principes de mise en œuvre ci-
dessus) tel qu’exposé par le serveur middleware, le connecteur client ou le système back-office
o Faire migrer de manière opportune les flux existants et moins standard vers les protocoles ou les
mécanismes sécurisés
o Garantir parallèlement l’authentification des sources de données et de l’autorisation des données
relatives à SWIFT au moyen (i) de fonctionnalités middleware natives ou (ii) de dispositifs de
connectivité systèmes ou réseau qui évitent tout risque d’usurpation de l’hôte.
Remarque: SWIFT s’attend à ce que ce contrôle devienne obligatoire dans une prochaine version de ce
document et échelonnera les attentes:
• En commençant par le connecteur client et les serveurs middleware, lorsqu’ils sont utilisés
• Ensuite, les flux entre les serveurs middleware et les composants relatifs à SWIFT et
• En clôturant avec les flux relatifs à SWIFT vers les systèmes de back-office atteints par les composants
relatifs à SWIFT ou le connecteur client, directement ou via le serveur middleware.
1er juillet 2020 46

2.5A Protection des données transmises en externe

A1→A3 A4 B
Type de contrôle: Conseillé Applicable à l’architecture: ● ●
Objectif du contrôle: Protéger la confidentialité des données relatives à SWIFT qui sont transférées ou
stockées en dehors de la zone sécurisée dans le cadre des processus opérationnels.

• Données sensibles de la zone sécurisée relatives à SWIFT (comme les sauvegardes, les informations
relatives aux transactions et les identifiants)
Facteurs de risque:
• Violation de données de sauvegarde fiables
Les données sensibles relatives à SWIFT qui sortent de la zone sécurisée à la suite de (i) sauvegardes des
applications/systèmes d’exploitation, d’une reproduction des données des transactions commerciales à des fins
d’archivage ou de reprise ou (ii) d’extraction pour le traitement hors ligne, sont protégées si elles sont stockées
en dehors d’une zone sécurisée et chiffrées lorsqu’elles sont en transit
Alors que le point 2.4A couvre les flux applicatifs (back-office) avec les composants liés à SWIFT, ce contrôle
couvre les données sous-jacentes relatives à SWIFT résidant dans le cloud ou exportées de la zone sécurisée et
manipulées dans le cadre d’activités opérationnelles (telles que les sauvegardes ou les extractions/copies
manuelles/automatiques de données).
Les sauvegardes des systèmes d’exploitation ou des applications et la reproduction des données des
transactions commerciales peuvent fournir des informations utiles pour préparer des transactions frauduleuses.
Leur transfert, leur manipulation et leur stockage en dehors des zones sécurisées (lorsqu’ils utilisent, par
exemple, la technologie SAN/NAS 27), doivent donc être sécurisés pour empêcher tout accès non autorisé. Le
chiffrement des flux ou des données constitue un moyen de protection courant de ce type de données pendant
leur transit.
Le chiffrement des sauvegardes, le chiffrement des données au repos ou la mise en place de contrôles de l’accès
ou d’autorisations appropriés sont des méthodes courantes de protection des données stockées.
Le traitement hors ligne couvre notamment le traitement effectué pour prendre en charge les activités, une
analyse supplémentaire ou des activités de veille économique.

27
Les technologies Storage Area Network/Network Attached Storage offrent des solutions de stockage réseau
1er juillet 2020 47

• Les données sensibles relatives à SWIFT reproduites ou extraites (données des transactions
commerciales dévoilant des informations comme les débiteurs, créanciers, comptes, montants,
informations commerciales), mots de passe et autres authentificateurs sont:
− Protégées contre tout accès non autorisé si elles sont stockées en dehors de la zone sécurisée SWIFT
ou de toute autre zone possédant des mesures identiques à celles de la zone sécurisée SWIFT. Cet
ensemble de données reproduites ou extraites est également idéalement chiffré lorsqu’il est stocké en
dehors d’une zone sécurisée (cela peut être effectué au niveau des données, du fichier, de
l’application ou du système),
− Chiffrées si elles sont en transit entre deux zones sécurisées (par exemple, entre deux centres de
données) ou transférées en dehors d’une zone sécurisée (SWIFT ou autre zone possédant des
mesures similaires). Le chiffrement peut être appliqué à la couche de données ou
réseau/communication/transport.
• En cas de recours à une plateforme de virtualisation à distance (hébergée et/ou exploitée par un tiers), il
est recommandé de veiller au cryptage des données. Ce cryptage peut se faire au niveau de
l’ »abonnement » au service ou au niveau du stockage et est censé être offert par le tiers pour protéger
l’accès aux données stockées.
• Les protocoles ou les mécanismes cryptographiques utilisent un algorithme de cryptographie actuel
répandu (par exemple, AES 28, ECDHE 29), avec des longueurs de clé conformes aux bonnes pratiques
actuelles. Pour en savoir plus sur les algorithmes de cryptographie qui appuient les protocoles sécurisés
actuels, consultez la SWIFT Knowledge Base TIP 5021566.
• Les mécanismes de cryptage sont conformes aux lois et règlements applicables 30.
• Si la cryptographie qui protège les données sensibles relatives à SWIFT a été compromise, un processus
doit être mis en place pour appliquer une nouvelle cryptographie et protéger ou détruire les copies
compromises des données.
Remarque: Les sauvegardes conservées pour la reprise des activités ou du système sont supposées être
conservées dans une zone sécurisée possédant les mêmes mesures que la zone sécurisée SWIFT.
28
29
30
Tels que ceux identifiés par Global Partner Digital (https://www.gp-digital.org/world-map-of-encryption/)
1er juillet 2020 48

2.6 Confidentialité et intégrité de la session opérateur

A1→A3 A4 B
Objectif du contrôle: Protéger la confidentialité et l’intégrité des sessions d’opérateurs interactifs se connectant
à l’infrastructure ou aux applications relatives à SWIFT locales ou distantes (exploitées par un prestataire de
services).

• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server: sessions vers le système
d’exploitation, les périphériques réseau ou vers la console de gestion de la plateforme de virtualisation
(également appelée gestionnaire d’hyperviseur)
• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server: sessions pour interfacer des
applications dans la zone sécurisée ou vers des applications chez le prestataire de services
• Zone sécurisée: session vers le HSM, les applications relatives à SWIFT, les dispositifs réseau et les
systèmes d’exploitation à partir de PC opérateurs dédiés
• [Conseillé A1/A2/A3: Sessions opérateur vers le serveur middleware (tel que le serveur IBM® MQ ou
similaire) utilisé pour échanger avec les composants liés à SWIFT]
• [Conseillé A4: Sessions opérateur vers le connecteur client]
Facteurs de risque:
• Atteinte à la confidentialité des opérations
• Atteinte à l’intégrité des opérations
La confidentialité et l’intégrité des sessions d’opérateurs interactifs se connectant aux applications relatives à
SWIFT (locales ou chez le prestataire de services) ou à la zone sécurisée sont sauvegardées.
Les sessions opérateur via le jump server, si utilisé dans l’infrastructure SWIFT locale ou externe, présentent un
risque particulier étant donné que les activités anormales ou non prévues sont plus difficiles à détecter pendant
les sessions interactives que dans les flux d’application à application. Par conséquent, il est important de protéger
l’intégrité et la confidentialité de ces sessions opérateur afin de limiter le risque d’utilisation abusive ou de vol de
mot de passe. S’il est utilisé, l’accès à la couche de virtualisation (gestionnaire de l’hyperviseur) doit disposer
d’une protection équivalente.

• Toutes les sessions interactives sont protégées par un protocole cryptographique (par exemple, ssh,
https avec TLS unidirectionnel).
1er juillet 2020 49

A1→A3 A4 B
• Les protocoles utilisent un algorithme de cryptographie actuel répandu (par exemple, AES 31, ECDHE 32),
avec des longueurs de clé conformes aux bonnes pratiques actuelles. Pour en savoir plus sur les
algorithmes de cryptographie qui appuient les protocoles sécurisés, consultez la SWIFT Knowledge Base
TIP 5021566.
• Les sessions opérateur et les autres types de session (par exemple, administration ou maintenance) ont
une fonctionnalité de verrouillage en cas d’inactivité qui limite la durée de la session au minimum
nécessaire pour accomplir des tâches habituelles.
• Si le verrouillage automatique n’est pas mis en place au niveau de la session, il doit être mis en place au
niveau du système d’exploitation de l’application, ou au niveau du jump server.
31
32
1er juillet 2020 50

2.7 Analyse des vulnérabilités

Type de contrôle: Obligatoire / Conseillé A1→A3 A4 B
pour B Applicable à l’architecture: ● ● ●
Objectif du contrôle: Identifiez les vulnérabilités connues dans l'environnement SWIFT local en mettant en
place un processus régulier d'analyse des vulnérabilités et en agissant en fonction des résultats.

• Jump server
• [Conseillé: PC opérateur à usage général comme décrit dans la section ‘Mesures supplémentaires
facultatives ‘
• Zone sécurisée: toutes les applications relatives à SWIFT et les systèmes d’exploitation sous-jacents, y
compris les PC opérateur dédiés
• [Conseillé: Plateforme de virtualisation locale ou distante (hébergée et/ou exploitée par un tiers)
(également appelée hyperviseur) hébergeant les VM relatives à SWIFT et leurs PC de gestion,
conformément à l’amélioration optionnelle]
Facteurs de risque:
La zone sécurisée et les PC opérateur dédiés sont analysés à la recherche de vulnérabilités, à l’aide d’un outil
d’analyse fiable et à jour, et les résultats sont pris en compte pour la prise de mesures de résolution appropriées.
La détection des vulnérabilités permet également d’analyser, de traiter et d’atténuer les vulnérabilités.
L’atténuation des vulnérabilités limite le nombre de chemins qu’une personne malintentionnée peut emprunter
pour mener une attaque. Un processus d’analyse des vulnérabilités complet, reproductible et exécuté en temps
utile est nécessaire pour pouvoir détecter en continu les vulnérabilités connues et prendre les mesures
nécessaires.

• L’analyse des vulnérabilités est effectuée au moins une fois par an ou après tout changement significatif
de l’environnement (par exemple, introduction de nouveaux serveurs ou composants et modification de la
conception du réseau, modification/augmentation de la gamme des composants entrant dans le champ
d’application).
− Les outils d’analyse des vulnérabilités proviennent de fournisseurs fiables et sont mis à jour avec des
profils d’analyse dans le mois précédant l’analyse.
1er juillet 2020 51

Type de contrôle: Obligatoire / Conseillé A1→A3 A4 B

pour B Applicable à l’architecture: ● ● ●
− Le type d’analyse des vulnérabilités le mieux adapté (notamment en utilisant des identifiants ou boîte
noire) est sélectionné pour l’environnement. Les éventuels identifiants administrateur utilisés pour
l’analyse sont correctement protégés.
− Des protections suffisantes, compte tenu du risque, sont mises en place pour limiter l’impact sur les
opérations (par exemple, exécuter des analyses en mode sécurisé, ou ignorer les systèmes pour
lesquels l’analyse pourrait être nuisible).
• Outre l’identification des vulnérabilités par le biais d’analyses, tous les tests d’intrusion ou les tests de
vulnérabilité effectifs effectués sur ou via des produits et services relatifs à SWIFT sont conformes à la
SWIFT Customer Testing Policy.
• Le résultat de l’analyse des vulnérabilités est documenté (avec accès restreint) et analysé afin que des
mesures correctives appropriées (comme l’application de mises à jour de sécurité conformément à la
mesure 2.2) puissent être prises.
• Une analyse par trimestre, par mois ou, dans l’idéal, en temps réel, est recommandée.

• L’analyse des vulnérabilités inclut les éléments du réseau (comme les routeurs et les switchs).
• L’analyse des vulnérabilités comprend les PC opérateurs à usage général utilisés pour se connecter à
l’infrastructure locale ou à celle du prestataire de services liée à SWIFT. Comme alternative, des mises à
jour de sécurité sont régulièrement appliquées sur les PC opérateur à usage général. Dans ce dernier
cas, seules les applications régulièrement corrigées et prises en charge sont déployées sur ces PC.
• L’analyse des vulnérabilités comprend éventuellement la plateforme de virtualisation locale ou distante
(hébergée et/ou exploitée par un tiers) qui héberge les VM relatives à SWIFT.
1er juillet 2020 52

2.8A Externalisation des activités critiques

A1→A3 A4 B
Objectif du contrôle: Assurer la protection de l’infrastructure SWIFT locale contre les risques inhérents à
l’externalisation d’activités critiques.

• Contrôle organisationnel applicable lors d’externalisation d’activités critiques relatives à SWIFT vers un
tiers ou un prestataire de services.
Remarque: Ce contrôle reste fortement recommandé même lorsque les activités externalisées ne sont pas
critiques.
Facteurs de risque:
• Exposition à des pratiques de sécurité défaillantes
Les activités critiques externalisées sont protégées avec au moins le même degré de soin que si ces activités
avaient été menées en interne.
Lorsque des activités critiques sont confiées à des sous-traitants (par exemple, un prestataire TI externe ou un
fournisseur de service cloud) ou des prestataires de services (comme un service bureau ou un fournisseur
d’applications Lite2), il est essentiel qu’au moins le même niveau de sécurité qu’en interne soit assuré (en plus du
respect du présent cadre de mesures de sécurité) afin d’empêcher l’introduction de nouvelles failles.
Remarque:
• SWIFT considère les opérations suivantes comme des opérations critiques:
− Gestion de la sécurité et gestion des changements du matériel et des logiciels (y compris les
applications, le système d’exploitation et la plateforme ou l’infrastructure virtualisée sous-jacente) qui
assurent le service SWIFT,
− Opérations en lien avec RMA,
− Accès aux données sensibles des utilisateurs (par exemple, contenu des messages),
− Suivi des événements contenant des données sensibles des utilisateurs,
− Gestion et configuration du réseau,
− Opérations en lien avec des transactions SWIFT (par exemple, création ou modification d’un message
concernant une transaction financière dans l’interface de messagerie).

1er juillet 2020 53

A1→A3 A4 B
• Lorsqu’il sous-traite son infrastructure liée à SWIFT ou une partie de celle-ci à un tiers (comme un
prestataire informatique externe ou un fournisseur de cloud computing comme quand elle sera disponible
la solution SWIFT de Digital Connectivity) agissant en son nom, l’utilisateur reste responsable du respect
des mesures de sécurité de ce cadre et doit demander à ce tiers de s’y conformer.
• Lorsque le tiers fournit des services partagés pour connecter des utilisateurs SWIFT non liés, il doit être
inscrit au programme d’infrastructure partagée (SIP) ou au programme Alliance Lite2 for Business
Applications (L2BA). L’utilisateur reste responsable de sa propre infrastructure, de son organisation et de
la mise en place de flux de données sécurisés vers le prestataire, conformément aux spécifications de ce
dernier. L’utilisateur est également responsable du contrôle de la conformité de son prestataire avec le
programme SIP ou L2BA concerné 33:
− Les Services bureaux enregistrés et conformes dans le cadre du Shared Infrastructure Programme
sont répertoriés dans le SWIFT Partner Programme Service Bureau Directory
− Les fournisseurs d’applications Lite2 professionnelles enregistrés et conformes dans le cadre du
programme sont répertoriés dans le Lite2 Business Applications Providers Directory
• Des accords de niveau de service (Service Level Agreement, SLA) et un accord de confidentialité (Non-
Disclosure Agreement, NDA) sont conclus avec chaque sous-traitant ou fournisseur de services auquel
des activités critiques sont transférées. Ces SLA définissent le niveau de soin à appliquer par le sous-
traitant ou le fournisseur de services pour exécuter ces opérations critiques.
• Une évaluation des risques est réalisée sur le sous-traitant au début de la relation contractuelle, puis
renouvelée régulièrement par la suite.
Remarque: SWIFT prévoit que ce contrôle deviendra obligatoire, dans une future version de ce document.
33
Un fournisseur reste sur la liste tant qu’il est conforme. S’il est radié de la liste, il y sera réinscrit dès que la conformité sera
rétablie.
1er juillet 2020 54

2.9A Contrôles opérationnels des transactions

A1→A3 A4 B
Objectif du contrôle: Restreindre l’activité des transactions sortantes dans les limites prévues d’une activité
normale.

• GUI
• Zone sécurisée: interface de messagerie
• Zone sécurisée: interface de communication
• Zone sécurisée: Connecteur SWIFT
• Connecteur client
Remarque: Les composants sont mentionnés comme le vecteur de contrôle des transactions sortantes
Facteurs de risque:
• Anomalies ou activités réseau suspectes non détectées
Mettre en œuvre des contrôles de détection, de prévention et de validation des transactions afin de limiter
l’activité des transactions sortantes dans les limites prévues de l’activité normale.
La mise en œuvre de contrôles commerciaux limitant autant que possible les transactions SWIFT réduit les
possibilités d’envoi (sortant) et, éventuellement, de réception (entrant) de transactions frauduleuses. Une analyse
de l’activité opérationnelle normale permet de définir au mieux ces restrictions. Des paramètres peuvent ensuite
être définis pour limiter les transactions à des seuils acceptables basés sur l’activité « normale ».

• Mettre en place des contrôles qui détecteront, empêcheront, ou valideront les flux de transactions par
rapport aux limites prévues de l’activité normale (service de contrôle des paiements). Les exemples de
mesures potentielles comprennent:
− A) La limitation du trafic sortant en dehors des heures de bureau:
o Les heures d’ouverture étant propres à chaque organisation et unité commerciale, il peut être
nécessaire de prendre en charge plusieurs heures de début et de fin (heures d’ouverture) ou de ne
pas définir de plage spécifique lorsque les systèmes sont utilisés 24 h/ 24.
1er juillet 2020 55

A1→A3 A4 B
o Envisager de restreindre la soumission et l’approbation des transactions SWIFT en dehors des

heures ouvrables habituelles 34. En cas de traitement SWIFT centralisé 24 h/24, limiter les
transactions ou les contrôler selon ce qu’il convient pour permettre l’exécution des tâches
habituelles: des messages suspects peuvent être présents dans le trafic légitime.
o Envisager d’activer les sessions actives de SWIFTNet FIN uniquement pendant les heures de
bureau (par exemple, les sessions de terminaux logiques automatisés se déconnectent à la fin de
la journée de travail). En cas de traitement SWIFT centralisé 24 h/24, limiter les transactions ou les
contrôler selon ce qu’il convient pour permettre l’exécution des tâches habituelles.
− B) Effectuer des validations de fin de journée et éventuellement intra-journalières:
o Mettre en place un processus pour émettre et vérifier les messages de confirmation (par exemple,
pour vérifier que les confirmations MT900 et MT910 correspondent aux transactions qui ont été
réalisées sur les comptes),
o Réconciliation des registres comptables de l’entité avec des messages de relevés de compte en fin
de journée (par exemple, MT 940 et MT 950),
o La réconciliation est faite chaque jour entre les messages qui sont envoyés au/du back-office et
au/du réseau SWIFT,
− C) Effectuer des contrôles centralisés sur les paiements afin de détecter d’éventuels comportements
anormaux:
o Les numéros de sessions dans l’interface de messagerie sont suivis pour s’assurer que la
numérotation séquentielle des sessions est intacte et ne contient aucun « trou » inattendu,
o Contrôler les transactions inhabituelles (par exemple, montants exceptionnellement élevés ou
montants cumulés, bénéficiaires, expéditeurs ou devises inhabituels).
• Sinon ou en plus, une réconciliation indépendante est effectuée avec les données de transaction des
utilisateurs obtenues de manière sécurisée à partir d’une source secondaire (interne ou externe comme
les rapports de validation quotidienne SWIFT) ou en vérifiant que la transaction est authentique auprès
de l’expéditeur et/ou du destinataire.

• Les comptes d’application et de système d’exploitation ne peuvent pas se connecter en dehors des
heures de travail normales du rôle concerné.
• Mettre en place des contrôles pour identifier une activité anormale des transactions entrantes.
34
La limitation ou le contrôle sommaire des sessions en dehors des flux commerciaux normaux peut introduire des retards
permettant d’intercepter/rappeler les transactions frauduleuses avant leur traitement immédiat potentiel et, finalement, leur
encaissement.
1er juillet 2020 56

2.10 Sécurisation des applications

A1→A3 A4 B
Objectif du contrôle: Réduire la surface de l’attaque des éléments relatifs à SWIFT en sécurisant les
applications sur les interfaces de messagerie et de communication compatibles SWIFT et les applications
connexes.

• GUI
• SWIFTNet Link
Facteurs de risque:
• Surface d’attaque excessive
• Exploitation d’une configuration des applications non sécurisée
Toutes les interfaces de messagerie et les produits d’interface de communication au sein de la zone sécurisée
sont compatibles SWIFT. La sécurisation des applications est appliquée et maintenue à tous les éléments visés.
La sécurisation des applications applique le concept de sécurité du « moindre privilège » à une application en
désactivant les fonctionnalités et les services qui ne sont pas nécessaires à l’exploitation normale. Ce processus
réduit les capacités, les fonctionnalités et les protocoles des applications qu’une personne malintentionnée
pourrait utiliser lors d’une attaque. Il permet également de changer de potentiels identifiants par défaut.
En outre, SWIFT exécute un programme de compatibilité des interfaces pour s’assurer que les interfaces sont
conformes aux pratiques actuelles et pour donner au client une assurance supplémentaire et des garanties, ainsi
qu’une meilleure visibilité par rapport aux capacités des différents produits. Après que l’autorité SWIFT chargée
des tests a validé les résultats des tests, l’interface est publiée dans le registre de compatibilité. Conformément
aux conditions générales de SWIFT, les clients doivent utiliser une interface compatible SWIFT.

• Garantir que les interfaces de messagerie et de communication sont compatibles SWIFT (la liste des
interfaces compatibles est publiée dans le registre de compatibilité sur www.swift.com).
− L’interface certifiée SWIFT doit répondre à toutes les exigences de conformité en matière de sécurité
(obligatoires et conseillées) définies dans le SWIFT Compatible Interface Programme.
o Si certaines exigences de conformité en matière de sécurité n’ont pas encore été satisfaites,
l’utilisateur doit passer à une interface certifiée appliquant au moins les exigences de conformité en
matière de sécurité obligatoires minimum.
1er juillet 2020 57

A1→A3 A4 B
o Le fournisseur de l’interface doit être contacté en cas de doute concernant la disponibilité de

certaines fonctionnalités de sécurité ou leur configuration et usage appropriés.
• Toutes les applications visées sont sécurisées selon une ou plusieurs des procédures suivantes:
− Guide de configuration ou d’exploitation de sécurité du fournisseur (tel que le SWIFT Alliance Security
Guidance),
− Une configuration ou un jeu de mesures de sécurité standard local ou d’une autorité de régulation
aussi rigoureux que le guide du fournisseur.
• Le processus de sécurisation des applications doit au minimum:
− Modifier les mots de passe par défaut existants,
− Désactiver ou supprimer les comptes utilisateur inutiles
− Désactiver ou limiter les composants, adaptateurs ou méthodes de connectivité inutiles,
− Configurer de manière sécurisée les adaptateurs, les méthodes de connectivité ou les connexions à
distance,
− Supprimer les progiciels inutiles,
− Modifier les configurations par défaut connues comme étant vulnérables
• Les écarts par rapport à la configuration de sécurisation sélectionnée (c’est-à-dire au jeu de règles) sont
documentés en indiquant le motif de l’écart.

Les applications supplémentaires installées sur les systèmes hébergeant des composants inclus dans le
périmètre d’application et traitant des données relatives à SWIFT sont également soumises à un durcissement
des applications conformément aux recommandations du prestataire.
1er juillet 2020 58

2.11A Mesures opérationnelles RMA

A1→A3 A4 B
Objectif du contrôle: Limiter les transactions aux contreparties validées et approuvées.

• GUI
• Connecteurs
Remarque: L’interface graphique, les connecteurs et l’interface de messagerie sont mentionnés comme le
vecteur potentiel pour l’échange et la notification RMA
Facteurs de risque:
Mettre en œuvre des mesures RMA afin de limiter les activités aux contreparties sûres.
La mise en place de mesures opérationnelles qui limitent les transactions SWIFT dans la mesure du possible
réduit le risque d’envoi et de réception de transactions frauduleuses. Ces restrictions sont mieux déterminées par
une analyse des relations commerciales efficaces où le RMA est un mécanisme permettant de prévenir le trafic
indésirable sur un service en contrôlant qui peut envoyer du trafic (et quel type de messages peut être échangé
par le biais de RMA Plus).

• Relationship Management Application (RMA)

− Des principes de connaissance des clients et de vérification appropriés sont mis en place pendant la
création et la gestion des relations RMA.
− Les relations RMA sont passées en revue au moins une fois par an pour garantir que les relations
obsolètes (inutilisées, inactives ou indésirées) sont analysées et éliminées/révoquées au moment
opportun.

• Application de gestion des relations plus (RMA+)
− Limiter les relations RMA valides aux types de messages spécifiques convenus avec la contrepartie.
Remarque: SWIFT s’attend à ce que cette mesure devienne obligatoire dans une prochaine version de ce
document.
1er juillet 2020 59

Présentation détaillée 3 Sécuriser physiquement l’environnement
3 Sécuriser physiquement l’environnement

3.1 Sécurité physique
A1→A3 A4 B
Objectif du contrôle: Empêcher l’accès physique non autorisé aux équipements sensibles, aux environnements
de travail, aux sites d’hébergement et au stockage

• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server, y compris les équipements
amovibles
• Zone sécurisée: l’ensemble du matériel informatique
• Matériel local ou distant (hébergé et/ou exploité par un tiers) prenant en charge la plateforme de
virtualisation (également appelé hyperviseur) et hébergeant les VM relatives à SWIFT
Remarque: Les boîtiers VPN Alliance Connect et leurs instances virtuelles (systèmes ou machines
d’hébergement) sont généralement exclus du champ d’application, mais doivent se trouver dans un
environnement doté de contrôles physiques appropriés, comme décrit ci-dessous.
Facteurs de risque:
• Accès physique non autorisé
Des dispositifs de sécurité physique sont mis en place pour protéger l’accès aux équipements sensibles, aux
sites d’hébergement et au stockage.
La mise en place de dispositifs de sécurité physique protège contre les menaces internes et externes, et réduit
les attaques opportunistes rendues possibles par l’accès aux systèmes physiques.

• Sécurité des périphériques amovibles

− Les périphériques amovibles sensibles (par exemple, « dispositif de saisie du code PIN » (PED), clés
PED, cartes à puce relatives à SWIFT , jetons USB, dispositifs TOTP) sont surveillés ou stockés en
lieu sûr lorsqu’ils ne sont pas utilisés.
1er juillet 2020 60

A1→A3 A4 B
− Les périphériques amovibles sensibles nécessaires pour les opérations continues normales (par
exemple, disques extractibles à chaud, dispositifs HSM) sont hébergés dans un centre de données ou
au moins dans un espace fermé à clé.
− Les supports de sauvegarde (par exemple, bandes) sont sécurisés physiquement.
• Sécurité de l’environnement de travail
− Les PC opérateur sont situés dans un environnement de travail sécurisé dont l’accès est contrôlé et
accordé uniquement aux employés et autres travailleurs et visiteurs autorisés. Une zone physique
séparée pour les PC opérateur qui accèdent aux systèmes SWIFT n’est pas nécessaire.
− Les imprimantes utilisées pour les transactions SWIFT se trouvent dans un environnement de travail
sécurisé et leur accès est restreint.
− Les points d’accès USB et autres points d’accès externes sur les PC opérateur sont désactivés dans la
plus large mesure possible, sans que cela n’entrave les opérations (par exemple, lorsque des jetons
sont nécessaires pour authentifier des utilisateurs ou des messages).
• Sécurité pour les travailleurs qui ont accès aux systèmes SWIFT (utilisation, maintenance ou
administration) distants (par exemple, télétravailleurs, personnel d’astreinte)
− Une politique de sécurité prévoyant les cas d’utilisation pour les travailleurs distants est mise en place.
Les aspects suivants sont pris en considération lors de l’élaboration de la politique:
o La sécurité physique de l’environnement de télétravail prévu,
o Les règles applicables aux équipements personnels utilisés à des fins professionnelles relatives à
SWIFT (par exemple, les PC personnels ne peuvent pas être utilisés pour accéder à l’infrastructure
SWIFT, mais les téléphones portables personnels peuvent être utilisés comme second facteur
d’authentification),
o Sécurité dans le cadre d’une utilisation dans des environnements publics,
o Sécurité dans les transports en commun et privatifs,
o Le stockage des équipements
o Accès non autorisé aux équipements (par exemple par la famille ou les amis),
o Contraintes pour l’accès à distance (VPN recommandé avec authentification multifactorielle)
o Protection des appareils mobiles utilisés pour l’authentification, comme OTP (activation du mot de
passe et du verrouillage automatique recommandée),
o Contrôles compensatoires (par exemple, bureau virtuel empêchant le stockage sur disque local ;
chiffrement du disque intégral),
o Signalement des incidents de sécurité (par exemple, vol) pour les personnes qui travaillent à
distance.
• Sécurité de l’environnement des serveurs
− Les serveurs sont hébergés dans un centre de données ou au moins dans un espace fermé à clé dont
l’accès est limité et contrôlé (par exemple à l’aide de badges d’accès ou de la biométrie).
o Dans l’idéal, les serveurs sont installés sur des racks. Une évaluation des risques est réalisée afin
de déterminer si un rack exclusivement dédié aux serveurs, ou si le verrouillage du rack, sont
nécessaires, en tenant compte des mécanismes de contrôle d’accès existants du centre de
données.
− L’environnement des serveurs est équipé de la vidéosurveillance avec des équipements de détection
des mouvements et d’enregistrement vidéo. La mise en place d’un système de vidéosurveillance qui
enregistre et conserve des images est conforme aux lois et règlements applicables 35. Dans l’idéal, les
images sont conservées pendant au moins trois mois.
− Aucune référence physique à SWIFT sur les serveurs (par exemple, étiquettes).
− Les ports externes (par exemple, USB, bus en série) sur les serveurs sont désactivés dans la plus
large mesure possible, sans que cela n’entrave les opérations.
• Journalisation et examen des accès physiques
− L’accès physique aux zones comportant des équipements sensibles (par exemple, centre de données,
espaces de stockage sécurisés) est journalisé.
35
Telles que les « Principes 3/2019 sur le traitement des données à caractère personnel au moyen de dispositifs vidéo », la
loi/code de pratique local sur la protection des données ou les lois relatives à la vidéosurveillance
1er juillet 2020 61

A1→A3 A4 B
− Les journaux d’accès physique sont mis à disposition pour les audits et enquêtes, et sont conservés
pendant 12 mois minimum et en conformité avec les lois et règlements applicables.
− L’accès physique est rapidement révoqué (ou modifié) lorsqu’un employé change de poste ou quitte
l’entreprise.
− Les listes de contrôle d’accès physique sont examinées au moins une fois par an.
1er juillet 2020 62

Présentation détaillée 4 Prévenir les vols d’identifiants
4 Prévenir les vols d’identifiants

4.1 Politique en matière de mots de passe
A1→A3 A4 B
Objectif du contrôle: S’assurer que les mots de passe sont suffisamment robustes pour résister aux attaques
courantes, en mettant en place et en appliquant une politique efficace en matière de mots de passe.

• Connexion à des PC opérateur dédiés et à usage général et, le cas échéant, au jump server
• Zone sécurisée: comptes d’applications et de systèmes d’exploitation, y compris les dispositifs de réseau
protégeant la zone sécurisée
• Jetons personnels et appareils mobiles personnels utilisés comme facteurs de possession pour
l’authentification multifactorielle (voir mesure 4.2)
Facteurs de risque:
• Compromission de mot de passe ou autre atteinte à la sécurité informatique
Tous les comptes d’application et de système d’exploitation nécessitent des mots de passe remplissant des
critères appropriés, comme la longueur, la complexité, la validité et le nombre maximum autorisé d’échecs de
tentatives de connexion. De manière similaire, les jetons personnels et les appareils mobiles nécessitent des
mots de passe ou des codes d’identification individuels (PIN) avec des paramètres appropriés.
La mise en place d’une politique en matière de mots de passe qui protège contre les attaques courantes visant
les mots de passe (par exemple, cassage, attaque par force brute) permet de protéger efficacement contre le
piratage de comptes. Les cyber-pirates utilisent souvent les privilèges d’un compte piraté pour se déplacer
latéralement au sein d’un environnement et étendre leur attaque. Un autre risque est le piratage des clés
d’authentification locale visant à violer l’intégrité des transactions.
Il faut toutefois garder à l’esprit que les mots de passe seuls ne sont généralement pas suffisants pour parer aux
cyber-attaques actuelles. Les utilisateurs doivent donc appréhender cette mesure en étroite relation avec
l’authentification multifactorielle requise.

1er juillet 2020 63

A1→A3 A4 B
• Une politique en matière de mots de passe couvrant aussi les paramètres PIN et conforme aux normes et
aux bonnes pratiques actuellement en vigueur dans l’industrie est mise en place, et définit les critères
suivants:
− Expiration des mots de passe
− Longueur, composition, complexité et autres restrictions pour les mots de passe
− Réutilisation des mots de passe
− Verrouillage après plusieurs échecs d’authentification, et récupération
− Les exigences concernant les mots de passe peuvent être modifiées si nécessaire pour des usages
particuliers:
o En combinaison avec un second facteur (par exemple, mot de passe à usage unique),
o Cible d’authentification (par exemple, système d’exploitation, application, appareil mobile, jeton),
o Type de compte (opérateur standard, opérateur privilégié, compte d’application à application ou
clés d’authentification locale).
D’autres recommandations pour les paramètres des mots de passe et des PIN sont fournies dans la
SWIFT Knowledge Base TIP 5021567 et 5022038.
• La politique en matière de mots de passe est élaborée en tenant compte des vulnérabilités connues liées
aux mots de passe dans l’environnement informatique. Par exemple, exiger un mot de passe de plus de
15 caractères pour les systèmes Windows empêche Windows de calculer l’empreinte de mot de passe
LM (LAN Manager) extrêmement vulnérable.
• La politique relative aux mots de passe est mise en application si possible par des moyens techniques
(par exemple, à travers une politique de groupe Active Directory, ou dans les paramètres de l’application).
• L’efficacité de la politique relative aux mots de passe est régulièrement évaluée (recommandée
annuellement).
• Les paramètres du système pour la gestion et le stockage des mots de passe sont conformes aux
bonnes pratiques de l’industrie et du fournisseur (par exemple, activation du paramètre de registre
« NoLMHash » dans Windows).
• Les mots de passe utilisés pour les systèmes de la zone sécurisée sont beaucoup plus vulnérables s’ils
sont stockés dans des systèmes d’authentification en dehors de la zone sécurisée (par exemple, dans un
Active Directory d’entreprise). Au lieu de cela, les mots de passe pour les systèmes de la zone sécurisée
sont, dans toute la mesure du possible, stockés uniquement à l’intérieur de la zone (par exemple, dans
un Active Directory pour les systèmes de production), comme expliqué dans le guide pour la conception
de la zone sécurisée ou une autre zone sécurisée existante possédant des mesures similaires.
Remarque: Il est important que les utilisateurs utilisent des mots de passe forts, et de préférence une
authentification forte, pour tous les systèmes utilisés tout au long de la chaîne de transaction, et pas seulement
pour l’infrastructure SWIFT.
1er juillet 2020 64

4.2 Authentification à facteurs multiples

A1→A3 A4 B
Objectif du contrôle: Empêcher que la violation d’un facteur d’authentification unique permette d’accéder aux
systèmes ou applications SWIFT, en mettant en place une authentification à facteurs multiples.

En fonction de la mise en œuvre:
• Connexion au PC opérateur dédié
• Accès de l’opérateur au jump server
• Processus de connexion de l’opérateur à l’interface de messagerie (y compris la base de données
hébergée), à l’interface de communication ou à l’application du prestataire de services relative à SWIFT
• Système d’exploitation hébergeant l’interface de messagerie (y compris la base de données hébergée) et
l’interface de communication
• Accès à l’infrastructure SWIFT à distance (hébergée et/ou exploitée par un tiers)
Facteurs de risque:
• Rejeu d’identifiants
• Compromission de mot de passe ou autre atteinte à la sécurité informatique
L’authentification multifactorielle est utilisée pour l’accès des utilisateurs interactifs aux applications relatives à
SWIFT et aux comptes du système d’exploitation.
L’authentification multifactorielle nécessite la fourniture de plusieurs (deux ou plus) des facteurs d’authentification
courants suivants:
• Facteur de connaissance (quelque chose que l’opérateur connaît), généralement un mot de passe.
• Facteur de possession (quelque chose que l’opérateur a), généralement:
− jetons connectés (par exemple, jetons USB, cartes à puce),
− jetons non connectés (par exemple, générateurs de mots de passe à usage unique utilisant le
téléphone portable de l’opérateur, jeton RSA ou Digipass).
• Facteur d’inhérence (quelque chose que l’opérateur est), généralement un facteur biométrique comme
une empreinte digitale, le balayage de la rétine ou la reconnaissance vocale.
La mise en œuvre de l’authentification multifactorielle offre un niveau de protection supplémentaire contre les
attaques d’authentification courantes (par exemple, l’espionnage par-dessus l’épaule, la réutilisation de mots de
passe ou les mots de passe faibles) et fournit une protection supplémentaire contre la compromission des
comptes pour le traitement de transactions malveillantes. Les cyber-pirates utilisent souvent les privilèges d’un
compte piraté pour se déplacer latéralement au sein d’un environnement et étendre leur attaque.

1er juillet 2020 65

• Lors de la mise en œuvre de l’authentification multifactorielle, les principes suivants s’appliquent:

− Lorsque l'authentification est basée sur un facteur de connaissance (généralement un mot de passe)
associé à un facteur de possession (un dispositif mobile), le dispositif utilisé pour le second facteur doit
être différent du dispositif utilisé pour entrer le premier facteur. Ainsi, utiliser une application pour
générer le second facteur sur le même appareil/PC utilisé pour entrer le premier facteur (mot de
passe) n’est pas considéré comme suffisant pour accéder aux systèmes SWIFT locaux.
o Les solutions de second facteur reposant sur un facteur de possession incluent (liste non
exhaustive): TOTP, RSA SecurID, Digipass, applications mobiles, tableaux de numéros
d’authentification de transaction (TAN), jetons USB personnels. La solution doit être sélectionnée
en fonction de la gestion du risque de l’utilisateur lui-même.
− Il est plus sûr de combiner un facteur d’inhérence avec un facteur de possession qu’avec un facteur de
connaissance.
• L’authentification multifactorielle est mise en œuvre au moins à une étape d’authentification à laquelle
l’administrateur du système ou l’utilisateur final est confronté lorsqu’il accède à une application SWIFT ou
à son système d’hébergement:
− Pour les administrateurs de systèmes d’exploitation lors de l’accès au système d’hébergement:
o À l’entrée de la zone sécurisée (jump server),
o Lors de la connexion au PC opérateur dédié (à l’intérieur de la zone sécurisée).
− Pour les utilisateurs finaux par ordre décroissant de robustesse de sécurité lors de l’accès à
l’application SWIFT:
o Sur les applications SWIFT individuelles (sur la GUI basée sur un navigateur, l’interface de
messagerie ou l’interface de communication),
o À l’entrée de la zone sécurisée (jump server),
o Lors de la connexion au PC opérateur dédié (c.-à-d. à l’intérieur de la zone sécurisée).
• L’authentification multifactorielle est mise en place pour l’accès des administrateurs à distance, en
général pour l’authentification VPN.
• Les systèmes d’authentification multifactorielle sont beaucoup plus exposés si les identifiants
d’authentification sont stockés en dehors de la zone sécurisée (par exemple, dans un Active Directory
d’entreprise). Si possible, le système d’authentification qui appuie la solution multifactorielle se trouve
dans la zone sécurisée.
• Les facteurs d’authentification fournis sont attribués individuellement et associés à une responsabilité
individuelle pour l’accès aux services, au système d’exploitation et aux applications.
• Si l’authentification unique (par exemple, SAML) est mise en place, un second facteur est quand même
exigé lors de l’authentification unique, ou à une étape ultérieure.
• L’AMF doit également être présentée lors de l’accès, au moins pour le traitement des transactions 36, à un
service, une application ou un composant relatif à SWIFT et exploité par un prestataire de services (tel
qu’un service bureau, un fournisseur L2BA ou un acteur intermédiaire).
Remarque: Toutes les interfaces de messagerie et de communication SWIFT et celles de fournisseurs tiers
compatibles SWIFT doivent prendre en charge ou intégrer l’authentification multifactorielle.
36
telles que l’affichage, la création, l’approbation ou la modification de transactions ou de droits d’utilisateur.
1er juillet 2020 66

Présentation détaillée 5 Gérer les identités et séparer les privilèges
5 Gérer les identités et séparer les privilèges

5.1 Contrôle d’accès logique
A1→A3 A4 B
Objectif du contrôle: Appliquer les principes de sécurité de l’accès basé sur le besoin d’en connaître, du
moindre privilège et de la séparation des tâches pour les comptes des opérateurs.

• Tous les comptes d’opérateurs (par exemple, sur la plateforme de virtualisation locale ou distante et leurs
PC de gestion, également appelés hyperviseur, hébergeant les VM relatives à SWIFT , les VM elles-
mêmes, le jump server, les PC dédiés aux opérateurs, les systèmes d’exploitation, les applications et le
HSM)
• [Conseillé: Tous les comptes d’opérateurs sur le connecteur client et le serveur middleware (tel que le
serveur IBM® MQ ou similaire) utilisés pour échanger avec les composants liés à SWIFT]
Facteurs de risque:
• Privilèges ou accès excessifs
• Non-respect de la séparation des tâches
Les comptes sont définis selon les principes de sécurité de l’accès basé sur le besoin d’en connaître, du moindre
privilège et de la séparation des tâches.
L’application des principes de sécurité du (1) besoin d’en connaître, (2) moindre privilège et de la (3) séparation
des tâches est essentielle pour limiter l’accès à l’infrastructure SWIFT locale. Une gestion efficace des comptes
d’opérateurs réduit le risque d’une utilisation de comptes par une personne malintentionnée dans le cadre d’une
attaque.

Une politique de contrôle d’accès logique est documentée et appliquée pour tenir compte des principes suivants:
• Besoin d’en connaître
− Seuls les opérateurs (utilisateurs finaux et administrateurs) qui ont constamment besoin d’accéder à la
zone sécurisée sont autorisés à avoir des comptes dans la zone sécurisée.
− Des privilèges sont accordés uniquement aux opérateurs ayant un besoin d’en connaître validés (par
exemple, la configuration système garantit que les opérateurs ont uniquement accès aux informations,
fichiers et ressources système dont ils ont besoin pour accomplir les tâches définies qui leur ont été
assignées). L’accès aux autres fonctions du système est désactivé.
• Moindre privilège
1er juillet 2020 67

A1→A3 A4 B
− La configuration système garantit le contrôle des privilèges des utilisateurs et administrateurs de

manière à ce que tous les privilèges soient adaptés aux besoins individuels.
− Seuls les privilèges nécessaires pour accomplir les tâches habituelles sont accordés aux comptes.
Des privilèges supplémentaires peuvent être uniquement accordés temporairement.
• Séparation des tâches et 4 yeux
− Les instructions pour la séparation des rôles figurent dans la documentation dédiée aux fournisseurs.
− Les fonctions sensibles sont séparées. Cela signifie que certains rôles ne peuvent pas être
représentés par le même individu, tels que:
o Soumission et approbation des transactions
o Rôles d’administrateur d’application et de responsable de la sécurité
o Administrateur réseau et administrateur du système d’exploitation.
− Les autorisations sensibles sont séparées afin d’empêcher le contournement du principe des 4 yeux.
Cette exigence s’applique au minimum aux opérations de contrôle d’accès et de configuration de la
sécurité sur les éléments suivants: Interface de messagerie et de communication, HSM, SWIFTNet
Online Operations Manager et Secure Channel.
• Examen et suppression des comptes:
− Les privilèges sont rapidement révoqués quand l’employé change de poste ou quitte l’entreprise.
− Les comptes sont examinés au moins une fois par an (ou plus fréquemment, dans l’idéal) et ajustés si
nécessaire pour appliquer les principes de sécurité de l’accès.
• Une procédure d’urgence pour l’accès aux comptes à privilèges est définie pour les cas dans lesquels les
personnes autorisées ne seraient pas disponibles en raison de circonstances imprévues:
− Toute utilisation opérationnelle de la procédure est journalisée.
− L’accès aux comptes à privilèges en urgence est contrôlé. L’utilisation est journalisée et le mot de
passe est modifié après l’utilisation en urgence.
1er juillet 2020 68

5.2 Gestion des jetons

A1→A3 A4 B
Objectif du contrôle: Assurer la bonne gestion, le suivi et l’utilisation de l’authentification du matériel connecté
ou des jetons personnels (lorsque des jetons sont utilisés).

• Authentification matérielle connectée ou jetons personnels utilisés pour les opérations SWIFT ou l’accès
à la zone sécurisée
• Dispositif de saisie du code PIN (PED) utilisé pour les opérations HSM
Facteurs de risque:
• Vol de jetons d’authentification
• Utilisation abusive de la gestion de HSM
Les jetons d’authentification matériels connectés ou personnels sont gérés correctement lors de leur attribution,
distribution, révocation, utilisation et stockage.
La protection de l’authentification matérielle ou des jetons personnels connectés est essentielle à la sauvegarde
du compte de l’opérateur ou du système concerné et renforce les bonnes pratiques de sécurité, en offrant un
niveau de protection supplémentaire contre les agresseurs.

• Un processus contrôlé est utilisé pour l’attribution et la distribution de matériel connecté ou de jetons
personnels utilisés pour les opérations SWIFT (par exemple jeton USB, jeton HSM, carte à puce).
• L’attribution des jetons est examinée au moins une fois par an (ou plus fréquemment, dans l’idéal).
• Les jetons matériels personnels sont révoqués lorsque la personne concernée n’a plus besoin d’accès, et
ils doivent être éventuellement rappelés (à des fins d’élimination ou de réaffectation, si approprié).
• Un registre des détenteurs de jetons matériels attribués est tenu.
• Les jetons matériels sont retirés physiquement du système et stockés en lieu sûr ou placés sous
surveillance lorsqu’ils ne sont pas utilisés.
• Lorsqu’un PED à distance est utilisé, les pratiques de sécurité suivantes s’appliquent:
− Les clés PED doivent être stockées et accessibles uniquement au personnel pertinent (les originaux et
les copies doivent être stockés dans un coffre-fort et l’accès est suivi)
− Même si les clés HSM PED ne sont pas personnellement assignées, l’utilisation doit être contrôlée,
suivie et surveillée. Si un code PIN est défini sur les clés PED et si une personne ayant accès à ces
clés et au code PIN quitte la société, les codes PIN devront être modifiés
− Les flux vers le HSM doivent être sécurisés conformément aux orientations de l’Alliance en matière de
sécurité, en tenant également compte de la CSP FAQ (SWIFT Knowledge Base TIP 5021823) pour
établir et gérer correctement la connexion.
1er juillet 2020 69

5.3A Processus Ressources humaines de validation du

personnel
A1→A3 A4 B
Objectif du contrôle: Garantir la fiabilité du personnel qui exploite l’environnement SWIFT local par un
processus de vérification du personnel conformément aux lois et réglementations locales en vigueur.

• Tout le personnel (tel que les employés, les agents, les consultants et les contractants) ayant un accès
opérationnel (maintenance ou administration) aux systèmes relatifs à SWIFT, aux serveurs de
connecteurs clients ou de middleware et à la plateforme de virtualisation locale ou distante hébergeant
les VM relatives à SWIFT , les VM de connecteurs clients ou les VM de middleware.
Facteurs de risque:
• Personnel ou opérateurs système non fiables
Le personnel qui exploite l’environnement SWIFT local est vérifié pour sa fiabilité avant d’être embauché pour la
première fois dans ce rôle, puis régulièrement par la suite.
Un processus de vérification de la fiabilité du personnel, habilitation interne ou externe, offre une garantie
supplémentaire des opérateurs ou des administrateurs de l’infrastructure SWIFT locale, et limite le risque de
menaces internes.

Dans les limites autorisées par les lois et réglementations en vigueur et dans la mesure où les informations sont
disponibles, les principes et vérifications spécifiées ci-dessous sont recommandés:
• Tout le personnel concerné est contrôlé au moins tous les 5 ans.
− Pour les personnes qui ont déjà un poste et qui n’ont pas encore fait l’objet d’une vérification, un
processus de mise à niveau est progressivement mis en place dans le cadre de la procédure de
vérification périodique (également parfois appelée revérification)
• La procédure de vérification appliquée lors de la première embauche inclut les vérifications suivantes (à
effectuer conformément aux lois et réglementations locales en vigueur 37):
− Vérification de l’identité,
37
En incluant, si approprié, une concertation sociale
1er juillet 2020 70

A1→A3 A4 B
− Vérification de toutes les informations sur les qualifications,

− Vérification des emplois précédents,
− Informations sur les éventuelles procédures civiles ou pénales passées ou en cours visant l’employé,
− Validation de toute participation à des activités externes pouvant occasionner un conflit d’intérêts,
− Vérification en matière de crédits financiers.
• La procédure de vérification périodique inclut les vérifications suivantes (à effectuer conformément aux
lois et réglementations locales en vigueur29):
− Informations sur les éventuelles procédures civiles ou pénales en cours visant l’employé,
− Validation de toute participation à des activités externes pouvant occasionner un conflit d’intérêts,
− Vérification en matière de crédits financiers.
1er juillet 2020 71

5.4 Stockage physique et logique des mots de passe

A1→A3 A4 B
Objectif du contrôle: Protéger physiquement et logiquement le référentiel des mots de passe enregistrés.
Comptes et mots de passe définis pour les éléments suivants:

• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server: pour l’accès au système
d’exploitation
• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server: session utilisateur interactive
• Zone sécurisée: l’ensemble des applications, systèmes d’exploitation, HSM et jetons liés, et composants
réseau
hyperviseur) hébergeant les VM relatives à SWIFT
• SWIFTNet Online Operations Manager et swift.com
Facteurs de risque:
Les mots de passe enregistrés sont stockés dans un endroit physique ou logique protégé, avec un accès limité
en fonction du « besoin d’en connaître ».
Le stockage sécurisé des mots de passe enregistrés (référentiel) empêche que les mots de passe ne soient
facilement accessibles à d’autres personnes, protégeant ainsi contre le vol de mots de passe. Les méthodes non
sécurisées courantes incluent notamment (liste non exhaustive): la saisie des mots de passe dans une feuille de
calcul ou un document texte enregistré sans chiffrement sur un ordinateur de bureau ou dans un répertoire
partagé ou sur un serveur, enregistrée sur un téléphone portable, la saisie manuelle ou l’impression des mots de
passe sur un post-it ou une feuille.
Cette mesure couvre le stockage de mots de passe de comptes « urgence », comptes à privilèges ou n’importe
quels autres comptes. Tous les comptes doivent être considérés parce (i) qu’une combinaison de comptes sans
privilèges violés peut être préjudiciable, comme le compte de l’instigateur d’une transaction et le compte d’un
approbateur (ii) que même l’opération de surveillance des comptes fournit des informations utiles pendant le délai
de reconnaissance.

• Les mots de passe inscrits sur des supports physiques sont protégés par les moyens suivants:
1er juillet 2020 72

− Stockage dans une enveloppe scellée avec témoin d’intégrité,

− Stockage dans un coffre-fort,
− Journalisation des accès au lieu de stockage et des mots de passe de compte concernés.
• Les mots de passe stockés logiquement (numériquement) sont protégés par les moyens suivants:
− Chiffrement de données au repos ou obfuscation (c’est-à-dire pas de stockage en texte brut),
− Accès authentifié au lieu de stockage, dans l’idéal avec journalisation de l’accès.
• Les mots de passe ne sont pas inscrits dans des manuels utilisateur ou autre document opérationnel sauf
s’ils sont stockés conformément aux instructions ci-dessus.
• Si, dans une situation d’urgence, un accès est accordé à un opérateur qui n’aurait pas eu d’accès en
temps normal, le mot de passe est modifié juste après et, facultativement, également la combinaison du
coffre-fort de stockage.
• Les mots de passe ne sont pas enregistrés dans des scripts ou d’autres codes logiciels.
Mesure supplémentaire facultative:

Le coffre-fort est certifié, par exemple, par l’Underwriters Laboratories (UL) Class TL ou par la certification
EN-1143-1.
1er juillet 2020 73

Présentation détaillée 6 Détecter les activités anormales dans les systèmes ou les
relevés d’opérations
6 Détecter les activités anormales dans les

systèmes ou les relevés d’opérations
6.1 Protection contre les logiciels malveillants
A1→A3 A4 B
Objectif du contrôle: Veiller à ce que l’infrastructure SWIFT locale soit protégée contre les logiciels malveillants
et agir en fonction des résultats.

• PC opérateur dédié et à usage général et, lorsqu’il est utilisé, jump server - Systèmes d’exploitation
Windows
• Gestion des PC de la Plateforme de virtualisation locale ou distante (hébergés et/ou exploités par un
tiers)
• Zone sécurisée: Serveurs pour SWIFT - Systèmes d’exploitation Windows
des échanges avec les éléments relatifs à SWIFT – Systèmes d’exploitation Windows]
Facteurs de risque:
• Exécution de codes malveillants
Un logiciel anti-malware provenant d’un fournisseur réputé est installé, maintenu à jour sur tous les systèmes et
les résultats sont pris en compte pour des actions de résolution appropriées.
« Logiciel malveillant » est un terme générique qui englobe de nombreux types de logiciels intrusifs et
indésirables, y compris des virus. La technologie anti-logiciels malveillants (terme plus large utilisé pour désigner
les antivirus) protège efficacement contre les codes malveillants ayant un profil numérique ou comportemental
connu.

sont partiellement appliqués, les mesures d’atténuation ainsi que les spécificités environnementales
particulières doivent être prises en compte pour évaluer correctement le niveau global de conformité
• Une analyse anti-logiciels malveillants à l’accès (également appelée analyse en temps réel ou en arrière-
plan) est effectuée sur tous les éléments visés. Une analyse complète à la demande est programmée au
moins une fois par semaine pour les PC opérateur (une fois par jour dans l’idéal). Une analyse complète
à la demande doit être programmée régulièrement pour les serveurs en fonction des contraintes
1er juillet 2020 74

commerciales et opérationnelles. Pour éviter une baisse de performance, les analyses complètes sont
effectuées à des périodes creuses et/ou en dehors des heures ouvrables.
• L’étendue de l’analyse doit inclure tous les fichiers des systèmes concernés. L’exclusion d’éléments ou
d’un annuaire de l’analyse est sujette à une évaluation des risques prenant en compte la configuration de
l’infrastructure de l’utilisateur, les politiques et les exigences en matière de sécurité interne, les capacités
des produits et les principes suivants:
− Les logiciels (par exemple, exe, librairies, scripts) et les données statiques (par exemple, fichiers de
configuration) doivent être analysés à l’accès ou à l’installation, puis régulièrement après cela,
lorsqu’ils sont complétés par un mécanisme d’intégrité durant l’exécution (conforme à la vérification de
l’intégrité des logiciels décrite dans la mesure 6.2) permettant l’identification des changements de
fichier ou des ajouts inattendus.
− Le contenu du serveur de la base de données (fichiers) peut être exclu de l’analyse lorsque les
données ont été vérifiées, validées et analysées au moins une fois avant leur stockage.
• Un programme anti-logiciels malveillants d’un fournisseur fiable est installé sur tous les systèmes
informatiques et mis à jour selon la fréquence d’analyse.
• Les systèmes qui ne mettent pas leurs profils à jour ou qui n’exécutent pas d’analyses programmées sont
détectés et réparés.
• La compatibilité du programme anti-logiciels malveillants avec l’environnement opérationnel est testée.
• Le programme anti-logiciels malveillants est testé en mode préventif si possible, après évaluation de
l’impact opérationnel. Il est recommandé de configurer le programme anti-logiciels malveillants pour
mettre en quarantaine les fichiers suspects et alerter le service de sécurité de l’utilisateur plutôt que de
les effacer immédiatement. Cela permet au service de sécurité de l’utilisateur d’enquêter sur l’alerte et de
prévenir d’éventuels « faux positifs » ultérieurs, tout en permettant la récupération des fichiers dans le cas
où ils auraient été confirmés comme étant légitimes.
• Les fichiers à envoyer doivent être scannés au moins une fois à n’importe quel stade/étape de leur
traitement interne et idéalement aussi près que possible de leur transfert dans le réseau SWIFT. Il s’agit
de s’assurer que ces fichiers ne contiennent pas de virus ou de logiciels malveillants susceptibles de
créer des risques pour l’expéditeur, pour SWIFT ou pour le destinataire.
• La solution EPP (Endpoint Protection Platform), combinée ou non avec la solution EDR (Endpoint
Detection and Response) offrant un contrôle similaire sur l’infrastructure peut être considérée comme une
mise en œuvre valable.

• Les systèmes anti-logiciels malveillants utilisent une combinaison de capacités basées sur la signature et
de capacités heuristiques.
• Les solutions anti-logiciels malveillants sont, lorsque cela est techniquement possible, déployées sur des
systèmes non-Windows.
• Une analyse complète à la demande est programmée au moins une fois par semaine pour les serveurs.
1er juillet 2020 75

6.2 Intégrité des logiciels

A1→A3 A4 B
Objectif du contrôle: Garantir l’intégrité des applications relatives à SWIFT et agir en fonction des résultats.

• Zone sécurisée: GUI à l’interface de messagerie et de communication
• Zone sécurisée: interface de communication
• Zone sécurisée: RMA
• Zone sécurisée: SNL
Facteurs de risque:
• Modifications non autorisées apportées au système
Une vérification de l’intégrité des logiciels est effectuée à intervalles réguliers sur l’interface de messagerie,
l’interface de communication et d’autres applications relatives à SWIFT et les résultats sont pris en compte pour
des actions de résolution appropriées.
Les vérifications de l’intégrité des logiciels permettent de détecter les modifications imprévues des logiciels
opérationnels.

• Les vérifications de l’intégrité des logiciels sont effectuées sur tous les éléments visés dès leur
lancement, puis au moins une fois par jour.
Options de mise en œuvre:
− Intégré dans le produit,
− Outil tiers de contrôle de l’intégrité des fichiers (FIM).
• L’intégrité des logiciels téléchargés est contrôlée en vérifiant la somme de contrôle au moment du
déploiement.

• Un contrôle d’intégrité est effectué en mémoire.
• Un contrôle d’intégrité est effectué au niveau du système d’exploitation.
• La surveillance de l’intégrité des fichiers englobe les produits dotés de mécanismes intégrés.
• Les systèmes qui se trouvent dans la zone sécurisée utilisent une liste blanche d’applications qui permet
de s’assurer que seules les applications connues et fiables sont exécutées.
1er juillet 2020 76

6.3 Intégrité des bases de données

A1→A3 A4 B
Objectif du contrôle: Assurer l’intégrité des enregistrements de la base de données pour l’interface de
messagerie SWIFT et agir en fonction des résultats.

• Bases de données utilisées par les interfaces de messagerie.
Remarque: cette exigence n’est pas pertinente pour l’architecture A3 et ne s’applique pas à l’architecture A1
lorsque l’infrastructure ne comprend pas d’interface de messagerie.
Facteurs de risque:
Une vérification de l’intégrité des bases de données est effectuée à intervalles réguliers sur celles qui enregistrent
les transactions SWIFT et les résultats sont pris en compte pour les actions de résolution appropriées.
Les vérifications de l’intégrité des bases de données permettent de détecter les modifications non prévues
apportées aux enregistrements des bases de données.

• La fonctionnalité de vérification de l’intégrité des bases de données est activée pour assurer l’intégrité au
niveau de l’enregistrement (contrôle de somme ou signature des enregistrements) et confirmer qu’il n’y a
aucun « trou » dans la numérotation séquentielle des transactions.
Options des mises en œuvre:
− Intégré à l’interface de messagerie,
− Intégré à la base de données.

• Une vérification complète de l’intégrité de la base de données est effectuée régulièrement, dans l’idéal
toutes les deux semaines.
• La vérification de l’intégrité consiste en une vérification complète des références de tous les
enregistrements (par exemple, pas d’enregistrements orphelins entre deux tables) et en une recherche
des enregistrements supprimés de manière inattendue.
• Une instance de base de données dédiée est utilisée pour SWIFT.
1er juillet 2020 77

6.4 Journalisation et surveillance

A1→A3 A4 B
Objectif du contrôle: Enregistrer les événements de sécurité et détecter les actions et opérations anormales
dans l’environnement SWIFT local.

• Couche échange de données: réseau
• PC opérateur dédié et à usage général ou, lorsqu’il est utilisé, jump server: système d’exploitation
• Zone sécurisée: GUI à l’interface de messagerie et de communication
• Zone sécurisée: l’ensemble des applications serveur et des systèmes d’exploitation
• Zone sécurisée: réseau et HSM
• Zone sécurisée: base de données
hyperviseur) hébergeant les VM relatives à SWIFT
Facteurs de risque:
Des capacités de détection des activités anormales sont mises en place, ainsi qu’un processus ou outil
permettant de stocker et de vérifier fréquemment les journaux.
La mise au point d’un programme de journalisation et de surveillance est fondamentale pour détecter
efficacement les comportements suspects et les attaques potentielles. L’environnement opérationnel étant de
plus en plus complexe, les capacités de journalisation et de surveillance nécessaires pour procéder aux
détections adéquates seront de plus en plus sophistiquées. Une simplification de l’environnement opérationnel
permettra une journalisation et une surveillance plus réduites.

• Objectifs principaux de la journalisation et de la surveillance:
1er juillet 2020 78

A1→A3 A4 B
− Mettre en place un plan pour la journalisation des activités en lien avec la sécurité, et configurer des
alertes pour les événements de sécurité suspects (si cela est pris en charge par l’application).
− Mettre en place un plan pour la surveillance des événements de sécurité et d’autres événements (par
exemple, la surveillance en temps réel des activités réalisées via la GUI), et pour le traitement des
alertes.
• Toutes les activités de journalisation et de surveillance sont conformes aux lois et règlements applicables,
ainsi qu’aux contrats de travail qui remplacent toute instruction de mise en œuvre.
• Journalisation:
− Des capacités de journalisation sont déployées pour détecter toute utilisation anormale dans la zone
sécurisée, ainsi que les actions visant à porter atteinte à l’effectivité des contrôles à l’intérieur de la
zone sécurisée.
− Les journaux offrent une traçabilité de l’utilisation du compte vers la personne concernée.
− Les journaux d’audit des interfaces de messagerie et de communication sont conservés pendant 12
mois minimum, et sont suffisamment protégés d’un danger au niveau administrateur (par exemple, les
fichiers du journal sont transférés vers un système distinct avec des identifiants d’administrateur
système différents).
− Les journaux d’audit des PC opérateur, pare-feu et bases de données sont conservés pendant 31
jours minimum.
− Au minimum, les journaux suivants sont conservés:
o Historique des lignes de commande pour les comptes à privilèges dans le système d’exploitation
sur les serveurs
o Journaux des interfaces de messagerie et de communication et du système d’exploitation, qui
détaillent les comportements anormaux dans le système (par exemple, activité en dehors des
heures ouvrables habituelles, multiples échecs de tentatives de connexion, erreurs
d’authentification, changements dans les groupes d’utilisateur),
o Journaux de pare-feu,
o Journaux de bases de données (si disponibles, et au moins pour les solutions de bases de
données hébergées).
• Surveillance:
− Des procédures sont mises en place pour identifier les connexions suspectes à un quelconque compte
à privilèges du système d’exploitation ou d’une application à l’intérieur de la zone sécurisée.
− Des processus de surveillance sont mis en place pour vérifier les données de surveillance du serveur,
des applications et des bases de données de la zone de sécurité soit quotidiennement via des
vérifications humaines ou soit via une surveillance automatique avec système d’alerte.
− Des processus de surveillance permettent de vérifier régulièrement les données de surveillance du
réseau.
− Toute activité anormale ou suspecte est signalée à l’équipe sécurité appropriée pour suivi.

• Un système de journalisation centralisé est mis en place, limitant le nombre d’emplacements de journaux
à surveiller.
• L’enregistrement des sessions est mis en place afin d’enregistrer toutes les activités faites par des
comptes à privilèges sur les serveurs de la zone sécurisée SWIFT.
1er juillet 2020 79

6.5A Détection des intrusions

A1→A3 A4 B
Type de contrôle: Conseillé Applicable à l’architecture: ● ●
Objectif du contrôle: Détecter et prévenir toute activité de réseau anormale dans l’environnement SWIFT local
ou distant.

• Réseau (couche échange de données atteignant les éléments relatifs à SWIFT et à l’intérieur de la zone
sécurisée)
• Plateforme de virtualisation à distance (hébergée et/ou exploitée par une tierce partie) prenant en charge
l’environnement SWIFT de l’utilisateur
Facteurs de risque:
La détection des intrusions est mise en place pour repérer les accès non autorisés au réseau et les activités
anormales.
Des systèmes de détection d’intrusions sont très souvent mis en place sur un réseau (NIDS) 38 - établissant une
base pour les opérations normales et l’envoi de notifications lorsque des activités anormales y sont détectées.
Étant donné qu’un réseau opérationnel est de plus en plus complexe (par exemple, systèmes qui communiquent
avec plusieurs destinations, accès à Internet), le système de détection des intrusions nécessaire pour procéder
aux détections adéquates sera également de plus en plus sophistiqué. Par conséquent, la simplification du
comportement du réseau permettra de mettre en place des solutions de détection des intrusions plus simples et
plus efficaces.
Les systèmes de détection des intrusions sur l’hôte (HIDS) sont destinés à protéger le système sur lequel ils sont
mis en place en plus de détecter les paquets réseau sur ses interfaces réseau, en fonctionnant comme un NIDS.
Les systèmes de détection d’intrusions (NIDS ou HIDS) combinent souvent des méthodes de basées sur les
signatures et basées sur les anomalies. Certains systèmes sont également capables de réagir à toute intrusion
détectée (par exemple, en coupant la connexion suspecte).
Le système de détection et réponse sur les points terminaux (EDR) est une technologie émergente qui répond au
besoin de surveillance et de réponse continues aux menaces avancées en détectant les activités suspectes et les
(traces d’) autres problèmes sur les hôtes/points terminaux. Cette technologie est plus fréquemment associée à
un système de plateforme de protection des terminaux (EPP) qui se concentre au niveau du dispositif.

• Le système de détection des intrusions est configuré de manière à détecter les activités anormales dans
la zone sécurisée et aux points d’entrée de la zone sécurisée. Cela peut être réalisé via un NIDS et/ou un
38
Système de détection des intrusions sur le réseau
1er juillet 2020 80

HIDS en fonction de la configuration du réseau (par exemple, les NIDS sont plus intéressants pour les
VLAN étendus ; les systèmes composés de plusieurs îlots séparés privilégieront la technologie HIDS sur
ces systèmes). La solution EDR peut également être envisagée.
• Les activités de réseau à suivre pour l’analyse de détection des intrusions peuvent inclure:
− Connexions entrantes et sortantes en dehors des heures ouvrables,
− Connexions non prévues de la zone sécurisée vers d’autres systèmes situés dans ou en dehors du
périmètre de la zone sécurisée SWIFT,
− Utilisation non prévue d’un port ou d’un protocole (par exemple, P2P).
• Le système actualise régulièrement les signatures d’intrusions connues.
• Si une intrusion est détectée, une alerte est envoyée et, si l’outil le permet, un mécanisme de défense est
déclenché manuellement ou automatiquement.
• Les intrusions détectées sont gérées sous le processus standard d’intervention en cas d’incident.

• Les systèmes de détection d’intrusions sont capables d’inspecter les flux chiffrés.
Points à considérer en cas de mise en œuvre alternative:

Les établissements disposant d’un niveau élevé de maturité de leur gestion des informations et des événements
de sécurité (SIEM) peuvent envisager d’étendre, conformément à la mesure 6.4, leur approche SIEM pour mener
une analyse en temps réel des intrusions sur les réseaux et dans les systèmes.
1er juillet 2020 81

Présentation détaillée Plan d’intervention en cas d’incident et partage d’informations
7 Plan d’intervention en cas d’incident et

partage d’informations
7.1 Planification de l’intervention en cas de cyber-
incident
A1→A3 A4 B
Objectif du contrôle: Garantir une approche cohérente et efficace de la gestion des cyber-incidents.

• Contrôle organisationnel
Facteurs de risque:
• Préjudice important dû à un manque de préparation pour faire face aux cyber-incidents
L’utilisateur a défini et testé un plan d’intervention en cas de cyber-incident.
La disponibilité et une bonne résilience sont essentielles pour les affaires. À cet égard, définir et tester un plan
d’intervention en cas de cyber-incident est un moyen extrêmement efficace de réduire l’impact et la durée d’un
cyber-incident réel. Étant donné que des enseignements sont tirés des tests effectués sur ce plan, ou des
incidents réels qui se sont produits, il est essentiel d’appliquer ces enseignements et d’améliorer le plan. En
outre, il est essentiel de planifier le partage des informations sur les menaces et les incidents afin d’aider la
communauté financière dans son ensemble à mettre en place des protections efficaces contre les cyber-
attaques.

sont partiellement appliqués, les mesures d’atténuation ainsi que les spécificités environnementales
particulières doivent être prises en compte pour évaluer correctement le niveau global de conformité
• L’utilisateur a élaboré un plan d’intervention en cas de cyber-incident qu’il actualise chaque année. Un
plan de sauvegarde et de reprise formel existe pour toutes les divisions critiques, afin d’appuyer les
interventions menées en cas d’incident.
− Le plan d’intervention en cas d’incident cybernétique comprend des coordonnées actualisées (internes
et externes en cas de recours à des tiers ou à des fournisseurs de services) et des délais d’escalade.
Un tel plan doit intégrer:
o La Cyber Security Incident - Recovery roadmap qui fournit une liste non exhaustive d’étapes ou
d’actions que doit suivre un client en cas de brèche de la cyber-sécurité, et qui renvoie à
l’assistance SWIFT. Les détails sont énoncés dans le bulletin du SWIFT-ISAC n° 10047.
o Les politiques de sécurité interne, lois et réglementations en vigueur dans le pays d’un utilisateur
doivent être observées et prises en considération lors de la planification de l’intervention en cas de
cyber-incident.
1er juillet 2020 82

A1→A3 A4 B
• Le plan est réexaminé au moins une fois par an, et testé au moins une fois tous les deux ans afin de
garantir la bonne reprise des opérations critiques avec une durée d’interruption minimum suite à un
cyber-incident.
• Le plan d’intervention en cas de cyber-incident inclut des mesures pour:
− notifier rapidement les parties prenantes internes appropriées et la direction,
− notifier rapidement les acteurs organisationnels externes pertinents (en général, le/les régulateur(s),
superviseur(s), les services répressifs),
− notifier rapidement le Centre de Support client SWIFT en passant par le canal par défaut, et se
conformer à d’autres obligations applicables pour les utilisateurs en cas d’incident touchant à la
sécurité, y compris l’obligation de coopérer et de fournir des matériaux destinés à la police scientifique,
comme peut l’exiger SWIFT,
− endiguer ou isoler rapidement le système affecté afin de limiter l’exposition de l’attaque tout en étant
capable d’identifier les activités illicites,
− impliquer des professionnels de la cyber-sécurité compétents pour identifier et s’occuper du cyber-
incident. Il est de la responsabilité de l’utilisateur de prendre des mesures correctives rapides pour
enquêter sur, nettoyer l’ensemble de l’infrastructure et reprendre les opérations sécurisées le plus tôt
possible,
− Revoir l’exactitude de l’/des attestation(s) actuelle(s) de l’utilisateur et, tel que le prévoit la politique des
mesures de sécurité de SWIFT, invalider cette/ces attestation(s) et effectuer une/des nouvelle(s)
attestation(s),
− faire une analyse de problème après l’incident afin d’identifier les vulnérabilités et d’y remédier,
− Documenter intégralement l’incident
• L’utilisateur a un plan documenté pour la transmission opportune d’informations sur les menaces aux
organisations qui diffusent les connaissances, à la police, à la justice et aux autorités de régulation
locales (en fonction des prescriptions légales applicables dans le pays de chaque utilisateur) et à SWIFT.
Le partage d’informations sur les menaces peut appuyer l’analyse des causes profondes et le partage
d’« indicateurs de compromission » (IOC) anonymisés avec la communauté.
• Les informations à partager sont d’abord évaluées pour veiller au respect des lois et règlements
applicables (par exemple, confidentialité des données à caractère personnel et des enquêtes) et prévenir
tout partage accidentel de données sensibles ou de données sans rapport avec l’incident.
• L’utilisateur peut utiliser les connaissances sur les menaces partagées par SWIFT, par exemple sous
forme d’IOC. L’utilisateur a mis en place des procédures pour:
− Garantir la distribution des informations aux contacts appropriés au sein de l’organisation,
− Bloquez le trafic entre les adresses IP/URL mentionnées dans les IOC.

• L’utilisateur peut intégrer la solution de flux automatisé d’alimentation SWIFT ISAC dans son
environnement.
1er juillet 2020 83

7.2 Formation et sensibilisation à la sécurité

A1→A3 A4 B
Objectif du contrôle: S’assurer que l’ensemble du personnel connaît et prend ses responsabilités en matière de
sécurité, en participant régulièrement à des activités de formation et de sensibilisation à la sécurité.

• L’ensemble du personnel (employés, agents, consultants et prestataires) qui a accès aux systèmes
SWIFT (utilisation, maintenance ou administration)
Facteurs de risque:
• sécurité engendrée par un personnel insuffisamment formé
Des sessions annuelles de sensibilisation à la sécurité sont dispensées pour tous les membres du personnel, y
compris une formation spécifique pour les rôles SWIFT qui ont un accès avec privilèges.
Un programme de formation et de sensibilisation à la sécurité encourage les employés et administrateurs à
adopter les bons comportements de sécurité et, de manière générale, renforce les bonnes pratiques de sécurité.
En outre, il est particulièrement important que les utilisateurs qui ont un accès privilégié aient les connaissances
et les compétences appropriées.

• Le personnel suit une session de formation et de sensibilisation à la sécurité chaque année. Les thèmes
abordés peuvent inclure:
− Formation sur les produits et services SWIFT (par exemple, via SWIFTSmart qui est accessible à tous
les utilisateurs),
− Sensibilisation aux cyber-menaces dans le secteur des services financiers, ou à celles qui concernent
plus spécifiquement le rôle et les responsabilités de l’employé,
− Risques liés à l’utilisation de l’Internet ou au déploiement dans le cloud
− Sécurité et gestion des mots de passe,
− Sécurité des périphériques
− Pratiques sûres (par exemple, identification des spams et du phishing, y compris le « spear
phishing 39 », téléchargement de fichiers, pratiques de navigation),
− Signalement des événements et activités suspects,
39
Le Spear phishing est une fraude qui cible les courriels ou les communications électroniques et qui concerne une personne, une
organisation ou une activité spécifique.
1er juillet 2020 84

− Détection des cyber-incidents et réaction, conformément au plan d’intervention de l’organisation.

− Programme interne ou externe qui autorise en option le personnel à obtenir et à maintenir les
certifications.
• La formation est dispensée sous la forme la mieux adaptée, y compris la formation en ligne, la formation
en salle de classe et les webinaires.
• Les personnes qui ont accès aux applications, données, certificats, réseaux, etc. SWIFT ont une
connaissance suffisante, et sont bien informées des cyber-risques qui les concernent (par exemple, par le
biais d’IOC publiés par SWIFT), des bonnes pratiques, des bons comportements et des processus.
• Des tests d’ingénierie sociale, y compris des campagnes de phishing avec de faux courriels, sont
exécutés pour mettre au défi et améliorer la sensibilisation à la sécurité.
1er juillet 2020 85

7.3A Tests d’intrusion

A1→A3 A4 B
Objectif du contrôle: Valider la configuration de sécurité opérationnelle et identifier les failles de sécurité en
effectuant des tests d’intrusion.

• PC opérateur dédié et à usage général ou, lorsqu’il est utilisé, jump server: tout le matériel, les logiciels et
le réseau
• Couche d’échange de données (les points d’entrée dans la zone sécurisée ou les flux établis vers les
composants de la zone sécurisée doivent être pris en compte)
• Connecteur client
• Zone sécurisée: l’ensemble du matériel, des logiciels et des éléments du réseau (conformément à la
SWIFT Customer Testing Policy, les applications propres à SWIFT et les services centraux pour SWIFT
tels que SWIFTNet InterAct, FileAct FIN, SWIFTNet Instant ou WebAccess ne sont pas concernés)
• Plateforme de virtualisation à distance (exploitée par un tiers) (également appelée hyperviseur)
hébergeant les VM relatives à SWIFT et leurs PC de gestion
Facteurs de risque:
• Failles de sécurité inconnues ou mauvaises configurations de sécurité
Des tests d’intrusion au niveau de l’application, de l’hôte et du réseau sont effectués vers la zone sécurisée et les
PC opérateur ou le jump server, si utilisé.
Les tests d’intrusion sont basés sur des attaques simulées qui utilisent des technologies similaires à celles
déployées lors d’attaques réelles. Ils servent à déterminer les chemins que les cyber-pirates peuvent emprunter,
ainsi que le degré d’intrusion potentiel dans l’environnement ciblé. Ces simulations sont un moyen efficace
d’identifier les faiblesses dans l’environnement, qui pourraient nécessiter des mesures correctives, d’amélioration
ou supplémentaires.

• L’organisation utilise une approche basée sur les risques pour déterminer le périmètre cible (par exemple,
zone sécurisée ou serveur spécifique, y compris d’autres services potentiels servant de soutien à la zone
sécurisée), la méthode (par exemple, test boîte blanche, test boîte noire) et l’origine de l’attaque (par
exemple, attaque interne, provenant de l’intérieur ou de l’extérieur de la zone sécurisée, ou attaque
externe) pour le test.
• Les tests de pénétration sont effectués au moins tous les deux ans, et idéalement aussi après des
modifications importantes de l’environnement (par exemple, introduction de serveurs nouveaux/modifiés,
1er juillet 2020 86

de nouveaux systèmes d’exploitation, de technologies telles que la virtualisation ou de nouvelles

technologies de périphériques réseau, modification de la conception du réseau).
• Les tests d’intrusion sont soigneusement planifiés et exécutés afin d’éviter tout impact sur la disponibilité
ou l’intégrité.
• Des tests d’intrusion sont effectués par des experts qui sont indépendants de l’équipe chargée de
l’infrastructure SWIFT ( « red team » interne ou ressources externes).
• Les tests d’intrusion sur les composants réseau et l’hôte (par exemple, bases et configurations de règles)
sont effectués dans l’environnement de production du service ou dans l’environnement de préproduction
reproduisant l’environnement réel.
• Des protections suffisantes sont mises en place pour limiter au minimum tout impact des tests d’intrusion
sur les opérations.
• Le résultat des tests d’intrusion est documenté (avec accès restreint) et sert à alimenter le processus de
mise à jour de sécurité.
Remarque: Le CSP FAQ (SWIFT Knowledge Base TIP 5021823) fournit des informations supplémentaires sur
l’étendue et les scénarios à prendre en compte.

Des tests d’intrusion sont effectués sur les applications propres à SWIFT, en conformité avec la SWIFT Customer
Testing Policy. Ces tests d’intrusion sur les applications propres à SWIFT sont effectués dans l’environnement de
recette afin d’éviter tout impact potentiel sur la disponibilité ou l’intégrité.
1er juillet 2020 87

7.4A Évaluation des risques fondée sur des scénarios

A1→A3 A4 B
Objectif du contrôle: Évaluer les risques et le niveau de préparation de l’organisation sur la base de scénarios
de cyber-attaque plausibles.

• Le contrôle organisationnel (personnes, processus et infrastructure) doit également être assuré par un
tiers exploitant une plateforme de virtualisation à distance (également appelée hyperviseur) qui héberge
les VM relatives à SWIFT
Facteurs de risque:
• Préjudice important dû à un manque de préparation pour faire face aux cyber-incidents
• Vulnérabilité non identifiée aux cyber-risques
Des évaluations de risque basées sur des scénarios, sont effectuées régulièrement afin d’améliorer la
préparation à la réponse aux incidents et d’accroître la maturité du programme de sécurité de l’organisation.
Les évaluations des risques basées sur des scénarios, y compris les jeux de cyber-guerres, testent diverses
attaques réalisées par tous les types de personnes non autorisées sur les systèmes et les processus existants
ciblant l’infrastructure hébergée liée à SWIFT. Les évaluations des risques basées sur des scénarios allient des
exercices techniques et commerciaux effectués dans le cadre de la procédure de gestion des risques de l’entité.
Ces évaluations prennent en compte les menaces non exhaustives suivantes: usurpation de l’identité de
l’utilisateur final, falsification des messages, interception des messages, faiblesses des logiciels tiers, systèmes
compromettants ou attaques par déni de service (DoS) affectant la disponibilité du service. Les résultats de
l’évaluation et des atténuations existantes aident à identifier les zones à risque qui pourraient nécessiter une
action future, une atténuation des risques ou une mise à jour du plan d’intervention en cas de cyber-incident.
Les actions, atténuations ou mises à jour identifiées doivent être signalées et examinées en vue d’une
neutralisation, selon leur criticité conformément au processus de gestion des risques en sécurité de l’information
(ISRM).
Il existe plusieurs cadres ISRM qui peuvent être consultés (par exemple, sur des sites NIST, ENISA, COBRA ou
ISO, ou à partir d’une norme ou de mesures locales ou d’une autorité de régulation aussi rigoureuses que le
guide de l’industrie) pour définir la bonne ISRM et les bonnes ressources de l’utilisateur (par exemple, mesures
de sécurité critiques du CIS). Ces cadres peuvent être utilisés pour commencer à mettre en œuvre un processus
de gestion des risques de base qui sera ensuite renforcé pour gérer les risques spécifiques de l’utilisateur.

• Une activité d’évaluation et de planification de risque basée sur des scénarios est menée pour:
− identifier les méthodes qui pourraient être utilisées par des personnes malintentionnées pour accéder
sans autorisation à l’infrastructure SWIFT locale, sur la base des techniques déjà observées ou des
techniques plausibles déduites des motivations et capacités des cyber-pirates,
1er juillet 2020 88

− analyser l’efficacité des mécanismes de prévention et de détection existants pour contrecarrer les
techniques utilisées par des cyber-pirates pour accéder sans autorisation à l’environnement,
− analyser la probabilité et l’impact des vecteurs d’attaque significatifs et plausibles au vu des
mécanismes existants,
− analyser l’efficacité des mesures d’intervention existantes à limiter l’impact des vecteurs d’attaque
significatifs et plausibles au vu des mécanismes existants,
− identifier la nécessité de mécanismes de prévention et de détection supplémentaires.
• L’évaluation et la planification sont effectuées au moins une fois par an, et actualisées dans le cadre des
activités de gestion continue des risques, en cas de changement important de la technologie, ou lorsque
les renseignements sur les menaces indiquent un changement important dans les capacités ou
motivations des cyber-pirates.
• Les renseignements actuels sur les menaces ainsi que les attaques observées/probables (vecteurs,
techniques, acteurs, etc.) servent de base à des scénarios réalistes.
• Chaque catégorie d’actifs (périphériques de l’utilisateur final, serveurs, périphériques réseau) est évaluée
régulièrement par rapport aux menaces existantes, et lorsque des modifications sont apportées ou que
de nouvelles menaces sont identifiées.
1er juillet 2020 89

Présentation détaillée Tableau récapitulatif des facteurs de risque
Tableau récapitulatif des facteurs de risque

Le tableau ci-dessous fait la synthèse de tous les facteurs de risque mentionnés dans le présent document, en mettant chaque mesure de sécurité
en correspondance avec les risques documentés qu’elle doit contribuer à atténuer.
Mesures de
sécurité SWIFT 1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7 2.8A 2.9A 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1 6.2 6.3 6.4 6.5A 7.1 7.2 7.3A 7.4A
Facteurs de risque
Vol de jetons X
d’authentification
Transactions réalisées X X
avec des contreparties
non autorisées
Piratage du système X
d’authentification de
l’entreprise
Violation de données de X
sauvegarde fiables
Vol d’identifiants X
utilisateur
Rejeu d’identifiants X X
Suppression des journaux X

et des éléments de
preuve
Surface d’attaque X X
excessive
Préjudice important dû à X X
un manque de
préparation pour faire
face aux cyber-incidents
Privilèges ou accès X X
excessifs
Exécution de codes X
malveillants
1er juillet 2020 90

Mesures de
Facteurs de risque
Exploitation d’une X X
configuration système non
sécurisée
Exploitation de failles de X X X
sécurité connues
Exposition aux attaques X X
sur Internet
Exposition à des X
pratiques de sécurité
défaillantes
sécurité engendrée par un X
personnel insuffisamment
formé
Manque de traçabilité X X X X
Atteinte à la confidentialité X
des opérations
Atteinte à l’intégrité des X
opérations
Atteinte à la confidentialité X X X
de données sensibles
Atteinte à l’intégrité de X X X
données sensibles.
Compromission de mot de X X
passe ou autre atteinte à
la sécurité informatique
Vol de mot de passe X X X X
Non-respect de la X
séparation des tâches
Accès non autorisé à X X X X
l’hyperviseur et à ses
modules de configuration
1er juillet 2020 91

Mesures de
Facteurs de risque
Accès physique non X
autorisé
Modifications non X X
autorisées apportées au
système
Trafic système authentifié X X
Prolifération incontrôlée X
de systèmes et de
données
Anomalies ou activités X X X
réseau suspectes non
détectées
Vulnérabilité non X
identifiée aux cyber-
risques
Failles de sécurité X
inconnues ou mauvaises
configurations de sécurité
Personnel ou opérateurs X
système non fiables
1er juillet 2020 92

Présentation détaillée Architectures de référence de la zone sécurisée
Architectures de référence de la zone

sécurisée
Les schémas ci-dessous sont uniquement indicatifs, et présentent quelques-unes des
nombreuses manières de concevoir les zones sécurisées pour chaque architecture (A1, A2,
A3, A4, B).
Figure 10a: Exemple de zones sécurisées pour l’architecture A1 - Interfaces dans

l’environnement de l’utilisateur (dans les locaux ou dans le Cloud)
Figure 10b: Exemple de zones sécurisées pour l’architecture A1 -

Interface de communication uniquement dans l’environnement de l’utilisateur (locale ou dans
le Cloud)
1er juillet 2020 93

Figure 11: Exemple de zone sécurisée pour l’architecture A2 - Interface de messagerie

uniquement dans l’environnement de l’utilisateur (locale ou dans le Cloud)
Figure 12a: Exemple de zone sécurisée pour l’architecture A3 – Connecteur SWIFT
Figure 12b: Exemple de zone sécurisée pour l’architecture A4 – Middleware en tant que
connecteur
1er juillet 2020 94

Figure 13a: Architecture B - Aucune empreinte chez l’utilisateur
Figure 13b: Architecture B – Aucune empreinte locale avec le client middleware
1er juillet 2020 95

Présentation détaillée Exemples de scénarios de menaces
Exemples de scénarios de menaces
Les scénarios suivants sont des exemples destinés à aider les utilisateurs à comprendre les
types de cyber-menaces que chaque mesure de sécurité doit aider à atténuer. Ces
scénarios ne sont pas exhaustifs et sont fournis uniquement à des fins contextuelles et
pédagogiques. La probabilité et l’impact de chaque scénario peuvent varier
considérablement en fonction des variables de l’environnement de l’utilisateur.
1.1 Protection de l’environnement SWIFT

• Des cyber-pirates volent les identifiants/mots de passe de l’administrateur système de
l’Active Directory de l’entreprise, ce qui leur permet d’accéder à tous les identifiants de
connexion stockés dans l’annuaire.
• Des cyber-pirates s’introduisent dans l’infrastructure TI d’appui (par exemple, serveur
d’analyse, serveur de correctif), située dans l’environnement TI général, pour voler les
identifiants système et ensuite accéder à l’infrastructure SWIFT locale.
• Des cyber-pirates obtiennent un accès administrateur à un PC opérateur, ce qui leur
permet d’accéder à la base de données locale des comptes et de réutiliser les
empreintes pour accéder à d’autres systèmes.
• Un opérateur clique sur un lien malveillant dans un courriel, et télécharge sans le
savoir un logiciel malveillant qui compromet la sécurité du PC local.
1.2 Contrôle des comptes à privilèges dans le système d’exploitation

• Un administrateur système utilisant le compte root dans Linux exécute des actions non
autorisées (par exemple, changement des configurations de sécurité, plantage
intentionnel du système), qui ne peuvent pas être imputées à un opérateur individuel.
• Un opérateur avec des privilèges administrateur excessifs supprime des journaux et
d’autres éléments de preuve pour dissimuler des actions non autorisées.
1.3 Protection de la plateforme de virtualisation (également connue sous le nom

d’hyperviseur)
• Un cyber-pirate qui a accès à l’hyperviseur pourrait compromettre la confidentialité,
l’intégrité et la disponibilité des machines virtuelles qui hébergent des services SWIFT.
• Un cyber-pirate qui a accès à l’hyperviseur ou à la fonction d’approvisionnement de la
machine virtuelle pourrait créer de nouvelles machines virtuelles pour renforcer son
attaque, par exemple en créant de faux services d’application afin d’amener les
utilisateurs à divulguer des informations sensibles ou à télécharger des logiciels
malveillants.
• Des failles et/ou une configuration non sécurisée dans la plateforme de virtualisation
pourraient permettre aux cyber-pirates de faire une brèche dans le cloisonnement entre
les domaines des machines virtuelles.
1.4 Restriction de l’accès à Internet

• Des cyber-pirates s’introduisent dans l’infrastructure TI d’appui (par exemple, serveur
middleware ou serveur de la plateforme de virtualisation) pour voler les identifiants
système et ensuite accéder à l’infrastructure SWIFT locale.
• Des cyber-pirates obtiennent un accès administrateur à un PC opérateur, ce qui leur
permet d’accéder à la base de données locale des comptes et de réutiliser les
empreintes pour accéder à d’autres systèmes.
1er juillet 2020 96

• Un opérateur clique sur un lien malveillant dans un courriel ou une page Web, et
télécharge sans le savoir un logiciel malveillant qui compromet la sécurité du PC ou du
serveur local.
2.1 Sécurité des flux de données internes

• Un cyber-pirate ayant accès à la zone sécurisée par un réseau compromet l’intégrité
des transactions en transit entre l’interface de messagerie et l’interface de
communication.
• Un cyber-pirate ayant accès à la zone sécurisée par un réseau peut observer le trafic
de données non chiffrées entre les éléments SWIFT locaux, et enregistrer des
transactions confidentielles.
2.2 Mises à jour de sécurité

• Un cyber-pirate exploite une vulnérabilité connue et non corrigée pour accéder à un
serveur qui héberge une application relative à SWIFT.
• Le système d’exploitation a dépassé la durée du cycle de maintenance du fournisseur,
ce qui engendre des vulnérabilités persistantes, sans résolution possible par le
fournisseur.
2.3 Sécurisation des systèmes

• Un cyber-pirate utilise le nom d’utilisateur et le mot de passe par défaut pour accéder à
l’interface d’administration d’un pare-feu du réseau.
• Un cyber-pirate exploite une faille dans un protocole de réseau non utilisé (par
exemple, telnet) pour accéder à un serveur SWIFT.
2.4A Sécurité du flux de données d’application métier

• Un cyber-pirate positionné sur le serveur middleware utilisé ou entre le back-office et
l’interface de messagerie introduit des transactions non autorisées.
• Un cyber-pirate lance une attaque de l’homme du milieu pour modifier les comptes
bénéficiaires de transactions SWIFT valables.
• Un cyber-pirate positionné sur le serveur middleware utilisé ou entre le back-office et
l’interface de messagerie peut suivre le trafic de données non chiffrées et enregistrer
les transactions confidentielles.
2.5A Protection des données transmises en externe

• Un emplacement de sauvegarde des données est compromis, et des sauvegardes
SWIFT non chiffrées ainsi que des empreintes d’identifiants sont dérobées, le cyber-
pirate se retrouvant en possession d’informations précieuses concernant les
opérateurs SWIFT et les activités courantes dans l’environnement local.
• Des sauvegardes non chiffrées des serveurs SWIFT sont transmises via un réseau non
sécurisé, ce qui permet à des cyber-pirates d’obtenir un accès en lecture seule à tous
les messages récemment échangés.
2.6 Confidentialité et intégrité de la session opérateur

• Un opérateur quitte son bureau sans qu’une extinction automatique de l’écran ne soit
programmée, ce qui permet à une personne non autorisée d’accéder au compte de
l’opérateur et à l’interface de messagerie SWIFT.
1er juillet 2020 97

• Un cyber-pirate peut surveiller une session opérateur chiffrée, et exploite des

informations non chiffrées pour planifier une future attaque.
• Un cyber-pirate peut surveiller une session opérateur chiffrée, et vole des identifiants
pour créer une transaction SWIFT frauduleuse.
• Un cyber-pirate intercepte une transaction envoyée entre le navigateur et l’application
Web, modifie son contenu et le transfère vers l’application Web.
• Un cyber-pirate peut détourner une session ouverte ou contourner un dispositif
d’authentification du fait de paramètres peu sûrs, afin de capturer ou de créer une
transaction SWIFT frauduleuse.
2.7 Analyse des vulnérabilités

• Une vulnérabilité manifeste n’est pas identifiée ni traitée, ce qui permet à un cyber-
pirate de l’exploiter pour accéder à un serveur relatif à SWIFT.
2.8A Externalisation des activités critiques

• Un sous-traitant ne sépare pas correctement les systèmes SWIFT d’autres systèmes
peu sécurisés, entraînant la propagation d’un virus dans plusieurs environnements et
une atteinte à l’intégrité des systèmes SWIFT.
• Le fournisseur sous-traitant n’applique pas correctement le contrôle d’accès, ce qui fait
qu’un employé non autorisé accède à l’interface de messagerie SWIFT ou à d’autres
composants ou systèmes relatifs à SWIFT.
2.9A Contrôles opérationnels des transactions

• La réconciliation quotidienne n’est pas effectuée, empêchant la détection d’une
transaction frauduleuse avant la date de règlement.
• Les transactions ne sont pas limitées aux heures ouvrables normales, empêchant la
détection d’une transaction frauduleuse.
2.10 Sécurisation des applications

• Les cyber-pirates peuvent utiliser des comptes ou des mots de passe par défaut pour
obtenir un accès non autorisé à l’application.
• Les privilèges excessifs accordés à des utilisateurs de l’application peuvent être utilisés
de manière abusive par les cyber-pirates pour effectuer des actions non autorisées sur
l’application.
• Un cyber-pirate exploite une faille dans un protocole de réseau non utilisé (par
exemple, telnet) ou dans une fonctionnalité fournie par des progiciels inutiles pour
accéder à un serveur SWIFT.
2.11A Mesures opérationnelles RMA

• Les relations RMA ne sont pas correctement gérées, ce qui conduit au traitement d’une
transaction d’une contrepartie non vérifiée ou inactive.
3.1 Sécurité physique

• La non-conservation des journaux empêche d’enquêter en profondeur sur le personnel
qui a eu accès physiquement au coffre-fort, après la découverte de la disparition d’un
ensemble de jetons SWIFT HSM.
• Un contrôle d’accès défaillant au centre de données offre au personnel non autorisé un
accès physique aux serveurs SWIFT lui permettant de mener des attaques physiques.
1er juillet 2020 98

4.1 Politique en matière de mots de passe

• Une politique est mise en place pour les mots de passe, mais n’est pas appliquée, ce
qui engendre l’utilisation par les opérateurs de mots de passe faibles facilement
cassables lors d’une cyber-attaque.
• Un mot de passe d’une longueur insuffisante permet de calculer son empreinte, qu’un
cyber-pirate extrait de la mémoire du PC et qui lui permet de retrouver le mot de passe
d’origine.
• Les mêmes mots de passe sont utilisés par un administrateur pour des systèmes
situés à l’intérieur et à l’extérieur de la zone sécurisée, ce qui permet à un cyber-pirate
de dérober le mot de passe le plus exposé et de le réutiliser pour accéder à la zone
sécurisée.
4.2 Authentification à facteurs multiples

• L’authentification multifactorielle n’est pas mise en place pour l’accès aux applications,
ce qui permet à un cyber-pirate d’utiliser un mot de passe volé pour accéder à
l’intégralité de l’interface de messagerie SWIFT.
• L’authentification multifactorielle n’est pas mise en place pour l’accès au système
d’exploitation de l’interface de messagerie, ce qui permet à un cyber-pirate d’utiliser un
mot de passe volé pour obtenir un accès administrateur au système.
5.1 Contrôle d’accès logique

• Les principes du moindre privilège ne sont pas appliqués, ce qui permet à un opérateur
qui n’a besoin que d’un accès en lecture seule de créer et d’envoyer des transactions
SWIFT.
• Les principes de séparation des tâches ne sont pas appliqués, ce qui permet à un
même opérateur de créer et d’approuver une transaction SWIFT, en infraction avec la
politique d’approbation des transactions de l’utilisateur.
• L’accès aux comptes n’est pas révoqué rapidement, ce qui permet à un employé muté
récemment d’utiliser son ancien accès pour modifier des fichiers sur l’interface de
messagerie SWIFT.
5.2 Gestion des jetons

• Une mauvaise tenue des registres d’attribution des jetons matériels connectés ou
personnels empêche la révocation des jetons lorsque des employés quittent
l’entreprise, conduisant à des accès résiduels inconnus et non contrôlés.
• Un jeton est laissé inséré dans le PC d’un utilisateur qui n’est plus utilisé, ce qui permet
à un cyber-pirate d’utiliser le jeton comme identifiant d’authentification dans le cadre
d’une attaque.
5.3A Processus Ressources humaines de validation du personnel

• Un nouvel employé avec un casier judiciaire contenant des condamnations pour fraude
financière n’est pas vérifié avant qu’un accès opérateur ne lui soit accordé, conduisant
ainsi à l’attribution d’un rôle de confiance à une personne qui n’est pas fiable.
• Les employés actuels ne sont pas contrôlés, et de ce fait l’organisation n’a pas
connaissance du fait que l’un d’entre eux a pris un emploi à temps partiel dans un autre
établissement financier, et a maintenant un conflit d’intérêts important.
5.4 Stockage physique et logique des mots de passe
1er juillet 2020 99

• Un opérateur SWIFT inscrit son mot de passe sur un morceau de papier conservé
dans sa zone de travail, ce qui permet à tout le personnel qui a un accès physique à la
zone de voir le mot de passe.
• Un administrateur d’application SWIFT conserve ses mots de passe administrateur
dans un fichier en texte brut sur son PC, permettant ainsi à tout administrateur système
du PC d’accéder aux mots de passe.
6.1 Protection contre les logiciels malveillants

• Aucun programme anti-logiciels malveillants n’est installé sur le PC opérateur, et un
logiciel malveillant exécutable courant parvient ainsi à compromettre le PC après un
clic dans un courriel de phishing.
• Le programme anti-logiciels malveillants installé sur les serveurs SWIFT n’est pas mis
à jour régulièrement, ce qui permet à un logiciel malveillant exécutable qui aurait pu
être détecté d’endommager les serveurs.
6.2 Intégrité des logiciels

• Un cyber-pirate expérimenté modifie l’exécutable de l’interface de messagerie et n’est
pas détecté, car le contrôle de l’intégrité des logiciels n’a pas été mis en œuvre.
• Une mise à jour logicielle contenant un logiciel malveillant est installée du fait de
l’absence de vérification de la somme de contrôle au moment du téléchargement.
6.3 Intégrité des bases de données

• L’absence de contrôle de l’intégrité des bases de données permet à des logiciels
malveillants cibles de supprimer des enregistrements de bases de données tout en
réalisant des transactions non autorisées.
• L’absence de contrôle de l’intégrité des bases de données permet à un cyber-pirate de
modifier des enregistrements de bases de données afin de dissimuler des preuves.
• L’absence de contrôle de l’intégrité des bases de données ne permet pas de détecter
un « trou » dans la numérotation séquentielle des enregistrements.
6.4 Journalisation et surveillance

• Une journalisation défaillante empêche de remonter jusqu’à une personne spécifique
en se basant sur des commandes à privilèges malicieuses dans le cadre d’une
enquête sur un cyber-incident
• Les journaux sont enregistrés, mais ne sont pas contrôlés, ce qui ne permet pas de
détecter les activités anormales avant que des dommages financiers importants ne
soient occasionnés.
6.5A Détection des intrusions

• L’absence de capacités de détection des intrusions empêche la détection du trafic
inhabituel en dehors des heures ouvrables normales.
• L’absence de capacités de détection des intrusions empêche la détection d’un trafic
inhabituel pour un protocole sur un port donné.
• Le système de détection des intrusions n’est pas correctement configuré ou contrôlé,
ce qui empêche d’identifier des intrusions visibles qui sont noyées dans une multitude
de fausses alertes.
7.1 Plan d’intervention en cas de cyber-incident
1er juillet 2020 100

• Un plan d’intervention en cas de cyber-incident qui n’est pas testé conduit à une
mauvaise réaction et à une absence de coordination face à une cyber-intrusion grave,
occasionnant des dommages financiers importants qui auraient pu être évités.
• Le non-signalement d’un cyber-incident à SWIFT entraîne un partage d’informations
incomplet, conduisant à des cyber-incidents similaires dans d’autres établissements qui
auraient pu être évités.
• L’incapacité à agir sur la base des renseignements sur les cyber-menaces conduit à
des cyber-intrusions utilisant des méthodes connues, qui auraient pu être évitées.
7.2 Formation et sensibilisation à la sécurité

• Les opérateurs SWIFT ne sont pas formés aux bonnes pratiques de sécurité, ce qui
conduit certains membres du personnel à cliquer sur des liens dans des courriels de
phishing.
• Les administrateurs système SWIFT ne sont pas sensibilisés à la sécurité en lien avec
leur rôle et, par conséquent, ne détectent ni ne signalent les activités suspectes sur les
systèmes SWIFT.
• Les responsables de la sécurité SWIFT n’ont pas les connaissances nécessaires en
lien avec leur rôle et de ce fait n’attribuent pas correctement les privilèges aux
opérateurs, ce qui permet le contournement du principe de séparation des tâches.
7.3 Tests d’intrusion

• Aucun test d’intrusion n’est effectué dans l’environnement SWIFT, empêchant la
détection et la correction de règles de pare-feu excessivement permissives.
• Les tests d’intrusion sont effectués par du personnel non qualifié et incapable de
simuler une attaque classique dans le secteur financier, ce qui engendre un faux
sentiment de sécurité et un faible engagement en faveur des améliorations nécessaires
sur le plan de la sécurité.
7.4A Évaluation des risques fondée sur des scénarios

• Des scénarios de risque réalistes ne sont pas testés dans l’organisation, ce qui
engendre une mauvaise estimation de la probabilité, de l’impact et du cyber-risque
global.
• Des scénarios de risque sont testés sans que les divisions et les cadres concernés
soient impliqués, ce qui rend l’activité globalement peu utile et conduit à un faible
engagement en faveur des améliorations nécessaires sur le plan de la sécurité.

Présentation détaillée Glossaire
Glossaire
Terme Définition
Principe des 4 yeux Principe de sécurité selon lequel deux personnes

doivent approuver une action avant qu’elle ne puisse
être exécutée.
Ce principe est également appelé « règle des deux
hommes » ou « intégrité par deux personnes ».
Administrateur Peut désigner:
Administrateurs d’application – responsables de la
configuration, de la maintenance et de la conduite
d’activités nécessitant des droits applicatifs particuliers
pour des opérations effectuées à l’aide de l’interface
applicative.
Administrateurs système - Responsables de la
configuration, de la maintenance et de la conduite
d’autres activités soumises à des privilèges via des
systèmes d’exploitation ou autre accès direct (non front-
end)
Compte d’application Les comptes d’application sont les identifiants désignés
pour une application. Ils ne sont pas destinés à être
utilisés par un accès humain ou GUI. Les comptes
d’application ont un mot de passe qui est stocké,
récupéré et utilisé automatiquement par l’application.
Un compte d’application est généralement utilisé à des
fins d’intégration (par exemple, appel de l’API) ou à
l’appui du STP (Straight-Through-Processing/traitement
des opérations au fil de l’eau).
Catégorie d’actifs Catégorie d’actifs informatiques (par exemple, bases de
données, serveurs, applications).
Application métier Systèmes qui prennent en charge la logique métier, la
génération de transactions et d’autres activités
intervenant avant la transmission dans l’infrastructure
SWIFT locale.
Connecteur Les connecteurs sont des logiciels locaux destinés à
faciliter la communication avec une interface de
messagerie ou de communication, les deux ou à un
prestataire de services. Lorsqu’on utilise un connecteur,
les composants d’interface sont généralement proposés
par un prestataire de services (par exemple, par un
service bureau, une infrastructure de concentrateurs ou
SWIFT).
Alliance Lite2 AutoClient, Direct Link, MicroGateway et
produits équivalents sont considérés comme des
solutions de connexion SWIFT.
Les solutions de transfert de fichiers ou les serveurs
middleware (tels que les serveurs IBM® MQ) sont
considérés comme des connecteurs clients.
À l’avenir, une application intégrant toutes les
fonctionnalités permettant de se connecter directement
et indépendamment à la passerelle API de SWIFT pour
traiter les transactions sera également considérée
comme un connecteur client (API maison).

Terme Définition
Connecteur client Les solutions de transfert de fichiers ou les serveurs

middleware (tels que les serveurs IBM® MQ) sont
considérés comme des connecteurs clients, par
opposition aux produits compatibles SWIFT (tels que
les interfaces ou connecteurs de communication et de
messagerie) fournis par SWIFT ou des fournisseurs
tiers.
À l’avenir, une application intégrant toutes les
fonctionnalités permettant de se connecter directement
et indépendamment à la passerelle API de SWIFT pour
traiter les transactions sera également considérée
comme un connecteur client (API maison).
CVSS - Common Vulnerability Scoring CVSS est une norme ouverte de l’industrie qui sert à
System évaluer la criticité des vulnérabilités en attribuant des
scores de criticité à ces vulnérabilités, ce qui permet de
hiérarchiser les réponses et les ressources en fonction
de la menace.
Interface de communication Logiciel de communication qui fait la liaison entre le
réseau SWIFTNet et l’interface de messagerie. Les
interfaces de communication permettent une intégration
centralisée, automatique et rapide avec différentes
applications financières internes et interfaces propres
aux services. Les interfaces de communication sont
fournies par SWIFT (par exemple, Alliance Gateway ou
Alliance Gateway Instant). Les interfaces de
communication dotées d’un label compatible avec
SWIFT peuvent également être fournies par des
vendeurs tiers.
Cyber-incident Tout acte malveillant ou événement suspect qui
compromet ou tente de compromettre un
environnement informatique.
Couche d’échange de données Le transport des données entre les composants relatifs
à SWIFT (dans l’infrastructure SWIFT locale ou chez un
prestataire de services) et le premier back-office
utilisateur, au niveau applicatif, comme on l’observe à
partir des composants relatifs à SWIFT.
PC opérateur dédié Poste de travail opérateur situé à l’intérieur de la zone
sécurisée et destiné exclusivement à interagir avec les
autres éléments de la zone sécurisée
Détection et réponse sur les points La détection et la réaction sur les points terminaux sont
terminaux (EDR) une technologie émergente qui répond au besoin de
surveillance et de réaction continues face aux menaces
avancées en détectant les activités suspectes et les
(traces d’) autres problèmes sur les hôtes/points
terminaux.
Plateforme de protection des points Solution émergente de prévention des attaques.
terminaux (PPE) S’associe plus fréquemment à l’EDR.
Utilisateur final Personne nécessitant un accès interactif à l’application
(par exemple, pour des transactions commerciales, la
surveillance et le contrôle d’accès). Cela inclut les
responsables de la sécurité et les administrateurs
d’application chargés de la configuration et de la
maintenance de l’application.
Environnement informatique et L’infrastructure TI générale utilisée pour appuyer
bureautique général (entreprise) l’organisation dans son ensemble. Cela comprend les
services TI généraux et les PC opérateur à usage
général.

Terme Définition
Services informatiques et bureautiques Infrastructure TI d’appui, comme les services

généraux d’authentification, la gestion des actifs, les bases de
données, le stockage des données, les dispositifs de
sécurité (par exemple, les correctifs) et les services
réseau (par exemple, DNS, NTP).
Postes de travail opérateur à usage Poste de travail opérateur dans l’environnement général
général de l’entreprise et utilisé pour des tâches courantes
Interface graphique utilisateur (GUI) Logiciel qui produit l’interface graphique pour un
utilisateur
(c.-à-d. Alliance Web Platform et produits équivalents).
Jeton matériel Jeton USB, carte à puce ou dispositif similaire.
Connexion/session interactive Modèle de session qui indique un échange de données
(par exemple, lorsqu’un utilisateur saisit des données
ou une commande et que le système renvoie des
données).
Indicateurs de compromission (IOC) Indices qui peuvent être observés sur un réseau ou un
système d’exploitation et qui peuvent signaler une
compromission du système.
Services informatiques et bureautiques Ensemble d’éléments qui appuient les processus métier
à l’intérieur de la zone sécurisée, comme une
plateforme de déploiement des versions et correctifs,
Active Directory.
Jump server Serveur utilisé pour accorder l’accès à la zone
sécurisée depuis le réseau de l’entreprise de l’utilisateur
(par exemple, Citrix ou Remote Desktop)
Authentification locale (LAU) L’authentification locale, ou LAU (« Local
Authentication »), garantit l’intégrité et l’authentification
des fichiers échangés entre applications.
L’authentification locale nécessite que l’entité
expéditrice et l’entité réceptrice utilisent la même clé
pour la signature d’un fichier d’authentification locale.
Infrastructure SWIFT locale L’ensemble des éléments SWIFT qui se trouvent dans
l’environnement de production de l’utilisateur, y compris
les systèmes, les applications, le matériel associé, les
jetons et d’autres authentificateurs. Également connue
sous le nom de zone sécurisée SWIFT.
Interface de messagerie Logiciel de messagerie prenant en charge les services
de messagerie SWIFT (FIN, InterAct et FileAct). Le
logiciel permet aux utilisateurs de connecter des
applications métier aux services de messagerie SWIFT,
et est généralement connecté directement à l’interface
de communication. Les interfaces de messagerie sont
fournies par SWIFT (par exemple, Alliance Access ou
Alliance Messaging Hub). Les interfaces de messagerie
portant un label compatible avec SWIFT peuvent
également être fournies par des fournisseurs tiers.
Middleware Logiciel qui permet à deux programmes distincts
d’interagir et/ou d’échanger des données l’un avec
l’autre (par exemple, IBM® MQ, BizTalk,
ConnectDirect).Généralement composé d’un serveur et
de clients exécutés sur différents systèmes
interconnectés (modèle client-serveur). Dans le cas
d’un modèle peer-to-peer sans serveur central, la
connectivité peut être considérée comme étant directe
entre les systèmes (elle ne passe donc pas par un
middleware).

Terme Définition
Serveur middleware Les implémentations de systèmes middleware locaux,

tels que le serveur IBM® MQ (y compris le gestionnaire
de files d’attente MQ, l’appliance MQ ou les deux),
utilisés pour l’échange de données entre les
composants relatifs à SWIFT (dans l’infrastructure
SWIFT locale ou chez un prestataire de services) et un
back-office d’utilisateur, vu depuis les composants liés à
SWIFT.
Authentification à facteurs multiples L’authentification multifactorielle est une méthode
d’authentification des utilisateurs avec laquelle au
moins deux éléments différents sont nécessaires pour
authentifier un utilisateur. Les facteurs d’authentification
suivants peuvent être sélectionnés:
• Facteur de connaissance (quelque chose que
l’utilisateur connaît), par exemple un PIN ou un
mot de passe.
• Facteur de possession (quelque chose que
l’utilisateur a), par exemple un jeton HSM, un
Digipass, un téléphone portable, ou un
générateur de mots de passe à usage unique
RSA
• Facteur humain (quelque chose que l’utilisateur
est), par exemple une empreinte digitale ou
autre facteur biométrique
Liste de contrôle d’accès réseau (ACL) Une liste de contrôle d’accès réseau est une liste de
règles appliquées aux numéros de port ou aux
adresses IP pour le contrôle du trafic entrant et sortant.
Ces listes sont disponibles sur un périphérique réseau.
Périphériques réseau Éléments utilisés pour la gestion, le routage et la
sécurité du réseau (par exemple, routeurs, switchs,
pare-feu).
Empreinte non-SWIFT Composant déployé dans un environnement utilisateur
pour se connecter aux services de messagerie SWIFT,
à la plateforme de transactions SWIFT ou à un
prestataire de services et qui n’est pas une interface de
messagerie, une interface de communication ou un
connecteur fourni par SWIFT ou par un fournisseur
tiers.
Les solutions de serveurs de fichiers, les serveurs
middleware/MQ ou les connecteurs clients (API maison)
sont des exemples d’empreinte non-SWIFT.
Comptes de système d’exploitation (SE) Comptes utilisateur sur un serveur ou PC qui sont
utilisés pour accéder directement au système
d’exploitation.
Opérateur Désigne collectivement les personnes suivantes:
Utilisateurs finaux – personnes nécessitant un accès
interactif à l’application (par exemple, pour des
transactions commerciales, la surveillance et le contrôle
d’accès). Cela inclut les responsables de la sécurité et
les administrateurs d’application chargés de la
configuration et de la maintenance de l’application.
Administrateurs du système d’exploitation –
responsables de la configuration, de la maintenance et
de la conduite d’autres activités soumises à des
privilèges sur les systèmes d’exploitation hébergeant
l’infrastructure SWIFT locale.
PC opérateur PC utilisé par les opérateurs pour remplir leurs
fonctions.

Terme Définition
PIN Code d’identification individuel - Un code secret qui fait

office de mot de passe, empêchant d’autres personnes
d’avoir un accès non autorisé ou d’utiliser un jeton, un
appareil mobile ou une carte.
Compte à privilèges Compte sur un système d’exploitation ou une
application qui donne un accès plus étendu par rapport
à celui d’un utilisateur standard. Inclut les comptes
administrateur sur les systèmes d’exploitation, et les
comptes des responsables de la sécurité et des
responsables d’application sur les applications.
Confort raisonnable Un niveau de confort que la direction peut obtenir de la
part d’experts en la matière (Petites et moyennes
entreprises, PME) internes ou externes lorsque:
- Un niveau approprié d’indépendance et
d’objectivité de la PME est garanti ;
- Une validation équitable par la PME de la
conception et de la mise en œuvre du contrôle,
confirmant l’atténuation des risques conformément
à l’objectif du contrôle ; et
- Les écarts constatés n’ont pas d’impact significatif
sur la capacité du contrôle à atténuer le risque, ou
des contrôles alternatifs compensent les écarts
constatés.
Les évaluations et certifications externes (par exemple
par rapport au SOC ou aux normes du secteur
identifiées à l’annexe E) qui couvrent les contrôles de la
CSCF, peuvent donner à la direction un confort
raisonnable quant à la pertinence des contrôles ainsi
qu’à leur efficacité opérationnelle. L’étendue et
l’approche utilisées pour l’évaluation du contrôle dans le
cadre de ces évaluations ou certifications externes
doivent être comprises avant de s’y fier, en partie ou en
totalité.
Relationship Management Application Filtre qui permet à l’utilisateur de limiter les
(RMA) correspondants desquels des messages peuvent être
reçus, ainsi que le type de messages qui peut être reçu.
L’utilisation du mécanisme Relationship Management
Application est obligatoire pour le service FIN. Il est
disponible, mais facultatif pour SCORE FileAct et
Generic FileAct.
Accès à distance Accès à un ordinateur depuis l’extérieur du réseau
local. Par exemple, depuis le domicile ou depuis le
réseau d’une autre organisation.
Connexion à distance Connexion à un système initiée via une connexion à un
réseau plutôt que directement depuis le PC local.
Zone sécurisée Zone délimitée sur le site de l’utilisateur, séparée de
l’environnement général de l’entreprise. La zone
sécurisée comprend les systèmes relatifs à SWIFT (par
exemple, interface de messagerie, interface de
communication), et éventuellement d’autres systèmes
protégés.
Environnement des serveurs Centre de données ou autres serveurs d’hébergement
physiques sécurisés.

Terme Définition
Un service bureau est une organisation utilisatrice ou
Service bureau
non utilisatrice SWIFT qui fournit des services pour
connecter les utilisateurs SWIFT.
Les services proposés par un service bureau incluent
généralement le partage, l’hébergement, ou
l’exploitation des éléments de connectivité SWIFT, la
connexion, ou la gestion des sessions ou de la sécurité
pour le compte des utilisateurs SWIFT.
Les services bureaux sont soumis au Shared
Infrastructure Programme.
Prestataire de services Entreprise qui fournit des services aux utilisateurs
SWIFT en lien avec l’utilisation quotidienne de leur
connexion SWIFT. Les services proposés incluent
généralement le partage ou l’exploitation des éléments
de connectivité SWIFT, la connexion, ou la gestion des
sessions ou de la sécurité pour les utilisateurs de
SWIFT. Ces organisations comprennent des
fournisseurs d’infrastructures partagées (par exemple,
service bureau, fournisseurs de connectivité partagée,
SWIFT, hub de groupe).
Mode utilisateur unique ou mode sécurisé Mode d’exploitation protégé qui limite les privilèges de
l’utilisateur.
SOAP Simple Object Access Protocol (SOAP)
Jeton logiciel Jeton d’authentification sous forme logique (logicielle).
Personnel Ensemble du personnel (employés, agents, consultants
et prestataires).
Connecteur SWIFT Un connecteur fourni par SWIFT (par exemple, SIL/
DirectLink, Alliance Lite2 AutoClient ou MicroGateway).
Un connecteur doté d’un label compatible avec SWIFT
fourni par un fournisseur tiers.
Empreinte SWIFT Produits d’interface de messagerie, d’interface de
communication ou de connecteurs fournis par SWIFT
ou dotés d’un label compatible avec SWIFT et fournis
par un fournisseur tiers.
Client lourd Logiciel installé et exécuté sur le PC opérateur local
plutôt que via une interface de navigateur.
Tiers Entité indépendante de l’utilisateur SWIFT ou du
fournisseur de connexion SWIFT de l’utilisateur. Par
exemple, un prestataire informatique externalisé ou
externe ou un fournisseur de cloud computing.
Par défaut, le service bureau et le fournisseur L2BA
sont considérés comme des prestataires de services et
non comme des tiers, sauf si l’utilisateur s’engage
spécifiquement avec eux pour héberger et/ou exploiter
en tout ou en partie l’infrastructure SWIFT locale de
l’utilisateur (toujours détenue par l’utilisateur).
Numéro d’authentification de transaction - Un type de mot de passe à usage unique généralement
Transaction Authentication Number utilisé en combinaison avec un identifiant standard et un
(TAN) mot de passe. Initialement présenté dans une liste
(tableau).
Plateforme de transaction (SWIFT) La future plateforme sera déployée de manière
centralisée par SWIFT pour offrir une gestion complète
des transactions conformément à la stratégie
approuvée par le conseil d’administration en mars 2020.
Transport Layer Security (TLS) Protocole cryptographique qui assure la confidentialité
et l’intégrité sur le réseau et protège contre les attaques
par rejeu.

Terme Définition
Utilisateur Organisation que SWIFT a acceptée en vertu des

Règles applicables aux sociétés en tant qu’utilisateur
dûment autorisé de produits et services SWIFT. Les
critères à remplir pour être accepté en tant qu’utilisateur
de SWIFT sont énoncés dans les Règles applicables
aux sociétés.
Comptes d’application utilisateur Comptes utilisateur créés au niveau de la couche
application pour accorder un accès et des autorisations
pour l’application (c’est-à-dire pas des comptes de
système d’exploitation).

Présentation détaillée Mise en correspondance des normes de l’industrie
Mise en correspondance des normes de

l’industrie
Le tableau ci-dessous met en correspondance les mesures de sécurité SWIFT et les trois cadres de
normes de sécurité internationales:
• Le National Institute of Standards and Technology (NIST) est une agence fédérale
américaine non réglementaire rattachée au département du Commerce des États-Unis
qui a mis au point un « Cadre de cyber-sécurité » pour aider les entreprises à gérer les
cyber-risques.
• ISO 27002 ISO/IEC 27002 est une norme de sécurité de l’information publiée par
l’organisation internationale de normalisation (ISO) et la Commission électrotechnique
internationale (IEC).
• La norme de sécurité de l’industrie des cartes de paiement (Payment Card Industry
Data Security Standard, PCI DSS) est une norme de sécurité des informations
protégées pour les entreprises qui fournissent des cartes de paiement.
Le tableau de correspondance ci-dessous montre également le lien entre les mesures de sécurité
SWIFT et des mesures similaires prévues par ces normes de l’industrie. Si des utilisateurs sont certifiés
par rapport à ces normes, et à condition que leur infrastructure SWIFT soit comprise dans le champ de
cette certification, le tableau montre le rapport entre les mesures prévues par ces normes et les mesures
de sécurité SWIFT
Pour d’autres normes, SWIFT suggère d’utiliser les références informatives fournies par NIST dans
l’Annexe A: Cœur du Cadre de gestion de la cyber-sécurité v1.1 pour vous orienter à partir du tableau
suivant.
Remarque importante:
Le respect des exigences de ces normes de l’industrie ne signifie pas automatiquement que la mesure
de sécurité SWIFT correspondante est pleinement appliquée. Certains aspects de la mesure pourraient
ne pas être couverts par la norme. Il appartient à l’utilisateur d’évaluer si, et dans quelle mesure, sa
conformité avec l’une de ces normes de l’industrie permet d’évaluer son application des mesures de
sécurité SWIFT.
Cadre de gestion de la
Objectif de la mesure SWIFT cybersécurité du NIST v1.1 ISO 27002 (2013) PCI DSS 3.2.1
1.1 Protection de Contrôle d’accès (PR.AC) Gestion de la Condition 1:

l’environnement SWIFT sécurité des réseaux Installer et maintenir à
PR.AC-5: L’intégrité du réseau
(13.1) jour une configuration
Protéger l’infrastructure SWIFT est protégée en mettant en
pare-feu pour protéger
locale de l’utilisateur contre des place un cloisonnement du 13.1.3: Cloisonnement
les données des
éléments potentiellement réseau si nécessaire des réseaux
titulaires de cartes
compromis de l’environnement
informatique et bureautique Article(s)
général ainsi que de applicable(s):1.3
l’environnement externe.
1.2 Contrôle des comptes à Contrôle d’accès (PR.AC) Gestion de l’accès Condition 8:
privilèges dans le système utilisateur (9.2) Identifier et authentifier
PR.AC-4: Les droits d’accès
d’exploitation l’accès aux
sont gérés, en appliquant les 9.2.3: Gestion des
composants du
Restreindre et contrôler principes du moindre privilège privilèges
système
l’attribution et l’utilisation de et de la séparation des tâches
comptes d’administrateur dans Article(s)
le système d’exploitation. applicable(s): 8.1, 8.5

1.3 Protection de la Contrôle d’accès (PR.AC) 9 Contrôle d’accès Condition 2:

plateforme de virtualisation Ne pas utiliser les
Sécurité des données (PR.DS) 10 Cryptographie
mots de passe
Sécuriser la plateforme de
Processus et procédures de 11 Sécurité physique système et autres
virtualisation (également
protection de l’information et environnementale paramètres de sécurité
connue sous le nom
(PR.IP) par défaut définis par
d’hyperviseur) et les machines 12 Sécurité liée à
le fournisseur
virtuelles (VM) en tant que Maintenance (PR.MA) l’exploitation
serveurs physiques. Sous-section(s)
Technologie de protection 13 Sécurité des
applicable(s): 2.1 à
(PR.PT) communications
2.6
Toutes les sous-catégories 14 Acquisition,
développement et
maintenance des
systèmes d’information
1.4 Restriction de l’accès à Contrôle d’accès (PR.AC) Gestion de la Condition 1:

Internet sécurité des réseaux Installer et maintenir à
PR.AC-5: L’intégrité du réseau
(13.1) jour une configuration
Limiter l’accès à Internet à est protégée en mettant en
pare-feu pour protéger
partir des PC opérateur et des place un cloisonnement du 13.1.3: Cloisonnement
les données des
autres systèmes situés dans la réseau si nécessaire des réseaux
titulaires de cartes
zone sécurisée.
Article(s)
applicable(s):1.3
2.1 Sécurité des flux de Sécurité des données Transfert de Condition 4:

données internes (PR.DS) l’information (13.2) Crypter la transmission
des données du
Assurer la confidentialité,
PR.DS-2: Les données en 13.2.1: Politiques et titulaire sur les réseaux
l’intégrité et l’authenticité des
transit sont protégées procédures de publics ouverts
flux de données entre les
transfert de
applications locales relatives à
l’information
SWIFT et leur liaison jusqu’au Article(s)
poste de travail de l’opérateur. applicable(s): 4.1
2.2 Mises à jour de sécurité Processus et procédures de Gestion des Condition 6:

protection de l’information vulnérabilités Développer et gérer
Limiter l’apparition de
(PR.IP) techniques (12.6) des systèmes et des
vulnérabilités techniques
applications sécurisés
connues dans l’infrastructure PR.IP-12: Un plan de gestion 12.6.1: Gestion des
SWIFT locale en apportant une des vulnérabilités est défini et vulnérabilités Article(s)
assistance, en installant les appliqué techniques applicable(s):6.2
mises à jour logicielles
RS.AN-5: Des processus sont
obligatoires, et en installant en
établis pour recevoir, analyser
temps utile les mises à jour de
et réagir aux vulnérabilités
sécurité nécessaires compte
révélées à l’organisation par
tenu du risque évalué.
des sources internes et
externes (par exemple, tests
internes, bulletins de sécurité,
ou chercheurs dans le
domaine de la sécurité)

2.3 Sécurisation des Processus et procédures de Exigences de Condition 2:

systèmes protection de l’information sécurité applicables Ne pas utiliser les
(PR.IP) aux systèmes mots de passe
Réduire la surface de cyber-
d’information (14.1) système et autres
attaque des éléments relatives PR.IP-1: Une configuration de
paramètres de sécurité
à SWIFT en procédant à la base des systèmes de 14.1.1: Analyse et
par défaut définis par
sécurisation des systèmes. technologie de spécification des
le fournisseur
l’information/contrôle industriel exigences de sécurité
est créée et tenue à jour Article(s)
applicable(s): 2.2, 2.5
2.4A Sécurité du flux de Sécurité des données Transfert de Condition 4:

données d’application métier (PR.DS) l’information (13.2) Crypter la transmission
des données du
Assurer la confidentialité, PR.DS-2: Les données en 13.2.1: Politiques et
titulaire sur les réseaux
l’intégrité et l’authenticité transit sont protégées procédures de
publics ouverts
mutuelle des flux de données transfert de
entre les applications back- l’information Article(s)
office (ou middleware) et les applicable(s): 4.1
éléments de connexion de
l’infrastructure SWIFT.
2.5A Protection des données Sécurité des données Transfert de Condition 3:

transmises en externe (PR.DS) l’information (13.2) Protéger les données
de titulaires de cartes
Protéger la confidentialité des PR.DS-2: Les données en 13.2.1: Politiques et
stockées
données relatives à SWIFT qui transit sont protégées procédures de
sont transférées et stockées en transfert de Article(s)
dehors de la zone sécurisée. l’information applicable(s): 3.4
2.6 Confidentialité et intégrité Sécurité des données Contrôle de l’accès Condition 8:

de la session opérateur (PR.DS) au système et à Identifier et authentifier
l’application (9.4) l’accès aux
Protégez la confidentialité et PR.DS-2: Les données en
composants du
l'intégrité des sessions transit sont protégées 9.4.2: Sécuriser les
système
d'opérateur interactives se procédures de
connectant à l'infrastructure connexion Article(s)
SWIFT locale. applicable(s): 8.1

2.7 Analyse des Surveillance continue Gestion des Condition 11:

vulnérabilités (DE.CM) vulnérabilités Tester régulièrement
techniques (12.6) les processus et les
Identifier les vulnérabilités DE.CM-8: Des analyses des
systèmes de sécurité
connues dans l’environnement vulnérabilités sont effectuées
12.6.1: Gestion des
SWIFT local en procédant Article(s)
Évaluation des risques vulnérabilités
régulièrement à l’analyse des applicable(s): 11.2
(ID.RA) techniques
vulnérabilités.
ID.RA-1: Les vulnérabilités des
actifs sont identifiées et
documentées.
2.8A Externalisation des Environnement opérationnel Sécurité de Condition 12:

activités critiques (ID.BE) l’information dans Maintenir une politique
les relations avec les de sécurité de
Assurer la protection de ID.BE-5: Des critères de
fournisseurs (15.1) l’information pour
l’infrastructure SWIFT locale résilience pour appuyer la
l’ensemble du
contre les risques inhérents à fourniture de services critiques 15.1.1: Politique de
personnel
l’externalisation d’activités sont établis sécurité de
critiques. l’information dans les Article(s)
Gouvernance (ID.GV)
relations avec les applicable(s): 12.8
ID.GV-2: Les rôles et fournisseurs
responsabilités en matière de
sécurité de l’information sont
coordonnés et alignés avec les
rôles internes et partenaires
externes
Gestion des risques de la
chaîne d’approvisionnement
(ID.SC)
ID.SC1 à ID.SC5
2.9A Contrôles opérationnels Contrôle d’accès (PR.AC) Transfert de Condition 7:

des transactions l’information (13.2) Restreindre l’accès
aux données du
Limiter les transactions aux sont gérés, en appliquant les 13.2.2: Accords en
titulaire aux seules
limites prévues de l’activité principes du moindre privilège matière de transfert
personnes ayant
normale. et de la séparation des tâches. d’information
besoin de les
connaître à des fins
professionnelles
Article(s)
applicable(s): 7.1.4

2.10 Sécurisation des Processus et procédures de Exigences de Condition 2:

applications protection de l’information sécurité applicables Ne pas utiliser les
(PR.IP) aux systèmes mots de passe
Réduire la surface de l’attaque
d’information (14.1) système et autres
des éléments relatives à PR.IP-1: Une configuration de
SWIFT en utilisant des base des systèmes de 14.1.1: Analyse et
interfaces de messagerie et de technologie de spécification des
le fournisseur
communication certifiées l’information/contrôle industriel exigences de sécurité
SWIFT et en sécurisant les est créée et tenue à jour Sous-section(s)
applications. applicable(s): 2.1 à
2.5
Condition 6:
Développer et gérer
des systèmes et des
applications sécurisés
Article(s)
applicable(s): 6.2,
6.3, 6.4, 6.5, 6.7
2.11A Mesures Contrôle d’accès (PR.AC) Transfert de Condition 7:

opérationnelles RMA l’information (13.2) Restreindre l’accès
aux données du
Limiter les transactions aux sont gérés, en appliquant les 13.2.2: Accords en
contreparties validées et principes du moindre privilège matière de transfert
personnes ayant
approuvées. et de la séparation des tâches. d’information
besoin de les
professionnelles
Article(s)
3.1 Sécurité physique Contrôle d’accès (PR.AC) Zones sécurisées Condition 9:

(11.1) Restreindre l’accès
Empêcher l’accès physique PR.AC-2: L’accès physique
physique aux données
non autorisé aux équipements aux actifs est géré et protégé. 11.1.1: Périmètre de
du titulaire
sensibles, aux sites sécurité physique
d’hébergement et au stockage. Article(s)
11.1.2: Contrôles
applicable(s): 9.1,
physiques des accès
9.3, 9.5
11.1.3: Sécurisation
des bureaux, des
salles et des
équipements
11.1.4: Protection
contre les menaces
extérieures et
environnementales
11.1.5: Travail dans
les zones sécurisées

4.1 Politique en matière de Contrôle d’accès (PR.AC) Contrôle de l’accès Condition 2:

mots de passe au système et à Ne pas utiliser les
PR.AC-1: Les identités et les
l’application (9.4) mots de passe
S’assurer que les mots de identifiants sont gérés pour les
système et autres
passe sont suffisamment périphériques et utilisateurs 9.4.3: Système de
robustes pour résister aux autorisés gestion des mots de
attaques courantes, en mettant passe
le fournisseur
en place et en appliquant une
politique efficace en matière de Article(s)
mots de passe. applicable(s): 2.1
Condition 8: Identifier
et authentifier l’accès
aux composants du
système
Article(s)
applicable(s):8.2
4.2 Authentification à Contrôle d’accès (PR.AC) Contrôle de l’accès Condition 8: Identifier

facteurs multiples au système et à et authentifier l’accès
PR.AC-1: Les identités et les l’application (9.4) aux composants du
Empêcher que la violation d’un
identifiants sont gérés pour les système
facteur d’authentification
périphériques et utilisateurs 9.4.2: Sécuriser les
unique ne permette d’accéder
autorisés procédures de
aux systèmes SWIFT, en Article(s)
connexion
mettant en place une PR.AC-6:Les identités sont applicable(s):8.2, 8.3
authentification à facteurs confirmées, liées à des
multiples. identifiants et affirmées dans
les interactions
PR.AC-7: Les utilisateurs,
appareils et autres actifs sont
authentifiés (par exemple,
facteur unique, multifacteur) en
fonction du risque de la
transaction (par exemple,
risques pour la sécurité et la
vie privée des individus, et
autres risques
organisationnels)
5.1 Contrôle d’accès logique Contrôle d’accès (PR.AC) Exigences métier en Condition 7:
matière de contrôle Restreindre l’accès
Appliquer les principes de PR.AC-4: Les droits d’accès
d’accès (9.1) aux données du
sécurité de l’accès basé sur le sont gérés, en appliquant les
besoin d’en connaître, du principes du moindre privilège 9.1.1: Politique de
personnes ayant
moindre privilège et de la et de la séparation des tâches contrôle d’accès
besoin de les
séparation des tâches pour les
comptes des opérateurs.
professionnelles
Article(s)
5.2 Gestion des jetons Contrôle d’accès (PR.AC) Responsabilités Condition 12:
relatives aux actifs Maintenir une politique
Assurer la bonne gestion, le PR.AC-1: Les identités et les
(8.1) de sécurité de
suivi et l’utilisation de identifiants sont gérés pour les
l’information pour
l’authentification du matériel périphériques et utilisateurs 8.1.2: Propriété des
l’ensemble du
connecté ou des jetons autorisés actifs
personnel
personnels (si des jetons sont
utilisés). Article(s)
applicable(s): 12.3

5.3A Processus Ressources Processus et procédures de Avant l’embauche Condition 12:

humaines de validation du protection de l’information (7.1) Maintenir une politique
personnel (PR.IP) de sécurité de
7.1.1: Screening
Garantir la fiabilité du PR.IP-11: La cyber-sécurité
l’ensemble du
personnel qui exploite est intégrée aux pratiques des
personnel
l’environnement SWIFT local ressources humaines (par
par un processus de exemple, DE provisioning, Article(s)
vérification du personnel. sélection du personnel) applicable(s):12.7
5.4 Stockage physique et Contrôle d’accès (PR.AC) Contrôle de l’accès Condition 8:

logique des mots de passe au système et à Identifier et authentifier
PR.AC-1: Les identités et les
l’application (9.4) l’accès aux
Protégez les mots de passe identifiants sont gérés pour les
composants du
enregistrés physiquement et périphériques et utilisateurs 9.4.3: Système de
système
logiquement. autorisés gestion des mots de
passe Article(s)
Sécurité des données
(PR.DS)
PR.DS-1: Les données au
repos sont protégées
6.1 Protection contre les Surveillance continue de la Protection contre les Condition 5:
logiciels malveillants sécurité (DE.CM) logiciels malveillants Protéger tous les
(12.2) systèmes contre les
Assurer la protection contre les DE.CM-4: Les codes
logiciels malveillants et
logiciels malveillants de malveillants sont détectés 12.2.1: Mesures contre
mettre à jour
l’infrastructure SWIFT locale. les logiciels
régulièrement les
malveillants
logiciels antivirus ou
programmes
Article(s)
6.2 Intégrité des logiciels Sécurité des données Maîtrise des logiciels Condition 11:
(PR.DS) d’exploitation (12.5) Tester régulièrement
Garantir l’intégrité des
les processus et les
applications relatives à SWIFT. PR.DS-6: Des mécanismes de 12.5.1: Installation de
contrôle de l’intégrité sont logiciels sur des
utilisés pour vérifier l’intégrité systèmes Article(s)
des logiciels, des firmwares et d’exploitation applicable(s): 11.5
des informations
Sécurité des
processus de
développement et
d’assistance
technique (14.2)
14.2.4: Restrictions
relatives aux
changements apportés
aux progiciels

6.3 Intégrité des bases de Sécurité des données Maîtrise des logiciels Condition 11:
données (PR.DS) d’exploitation (12.5) Tester régulièrement
les processus et les
Garantir l’intégrité des PR.DS-6:Des mécanismes de 12.5.1: Installation de
enregistrements des bases de contrôle de l’intégrité sont logiciels sur des
données de l’interface de utilisés pour vérifier l’intégrité systèmes Article(s)
messagerie SWIFT. des logiciels, des firmwares et d’exploitation applicable(s): 11.5
des informations
Sécurité des
processus de
développement et
d’assistance
technique (14.2)
14.2.4: Restrictions
relatives aux
changements apportés
aux progiciels
6.4 Journalisation et Technologie de protection Journalisation et Condition 10:

surveillance (PR.PT) surveillance (12.4) Effectuer le suivi et
surveiller tous les
Enregistrer les événements de PR.PT-1: Les registres 12.4.1: Journalisation
accès aux ressources
sécurité et détecter les actions d’audit/enregistrements de des événements
réseau et aux données
et opérations anormales dans journaux sont déterminés,
du titulaire
l’environnement SWIFT local. documentés, mis en œuvre et
examinés conformément à la Article(s)
politique applicable(s): 10.2,
10.6
Anomalies et événements
(DE.AE)
DE.AE-2: Les événements
détectés sont analysés afin de
comprendre les cibles et
méthodes d’attaque
6.5A Détection des Surveillance continue de la Gestion de la Condition 11:

intrusions sécurité (DE.CM) sécurité des réseaux Tester régulièrement
(13.1) les processus et les
Détecter et prévenir les DE.CM-1: Le réseau est
activités de réseau anormales surveillé afin de détecter les 13.1.1: Contrôle des
dans l’environnement SWIFT cyber-incidents potentiels réseaux Article(s)
local. applicable(s): 11.4
7.1 Planification de Processus et procédures de Gestion des Condition 12:

l’intervention en cas de protection de l’information incidents liés à la Maintenir une politique
cyber-incident (PR.IP) sécurité de de sécurité de
l’information et l’information pour
Garantir une approche PR.IP-9: Des plans
améliorations (16.1) l’ensemble du
cohérente et efficace de la d’intervention (intervention en
personnel
gestion des cyber-incidents. cas d’incident et continuité des 16.1.1:
activités) et des plans de Responsabilités et Article(s)
reprise (reprise après incident procédures applicable(s): 12.10
et reprise après sinistre) sont
mis en place et gérés
7.2 Formation et Sensibilisation et formation Pendant la durée du Condition 12:

sensibilisation à la sécurité (PR.AT) contrat (7.2) Maintenir une politique
de sécurité de
S’assurer que l’ensemble du PR.AT-1: Tous les utilisateurs 7.2.2: Sensibilisation,
personnel connaît et prend ses sont informés et formés apprentissage et
l’ensemble du
responsabilités en matière de formation à la sécurité
personnel
sécurité, en participant de l’information
régulièrement à des activités Article(s)
de formation et de applicable(s): 12.6
sensibilisation à la sécurité.

7.3A Tests d’intrusion Processus et procédures de Revue de la sécurité Condition 11:

protection de l’information de l’information Tester régulièrement
Valider la configuration de
(PR.IP) (18.2) les processus et les
sécurité opérationnelle et
identifier les failles de sécurité PR.IP-12: Un plan de gestion 18.2.3: Examen de la
en effectuant des tests des vulnérabilités est défini et conformité technique Article(s)
d’intrusion. appliqué applicable(s): 11.3
Évaluation des risques
(ID.RA)
ID.RA-1: Les vulnérabilités des
actifs sont identifiées et
documentées.
7.4A Évaluation des risques Évaluation des risques ISO 27001 article 8.2 Condition 12:
fondée sur des scénarios (ID.RA) Maintenir une politique
de sécurité de
Évaluer les risques et le niveau ID.RA-1: Les vulnérabilités des
de préparation de l’organisation actifs sont identifiées et
l’ensemble du
sur la base de scénarios de documentées.
personnel
cyber-attaque plausibles.
ID.RA-3: Les menaces
Article(s)
internes et externes sont
applicable(s): 12.2
identifiées et documentées
ID.RA-4: Les répercussions
potentielles sur l’activité et les
probabilités sont identifiées
ID.RA-5: Les menaces,
vulnérabilités, probabilités et
impacts sont utilisés pour
déterminer le risque
ID.RA-6: Les réactions face
aux risques sont identifiées et
hiérarchisées

Présentation détaillée Services et composants dans le champ d’application par type
d’architecture
Services et composants dans le champ

d’application par type d’architecture
Pour aider les utilisateurs à identifier les éléments les plus importants, le tableau ci-dessous (version
2021_1.0) présente les services et composants prévus dans le champ d’application et leur type
d’architecture connexe habituel. Il présente également à titre d’information les éléments habituels qui
n’entrent pas dans le champ d’application
Remarque: ce tableau sera continuellement mis à jour tout au long de l’année et il est recommandé de
toujours utiliser la dernière version qui se trouve dans la base de connaissances SWIFT TIP 5024040.
Les éléments suivants doivent être pris en compte lors de son utilisation:
• Si plusieurs composants appartiennent à un utilisateur et que ces composants ont des types d’architecture
différents, l’utilisateur doit attester dans KYC-SA du type d’architecture le plus complet en utilisant l’arbre de
décision si nécessaire.
• Une composante co-hébergée avec une composante dans le champ d’application est considérée comme
faisant partie du champ d’application.
• Tous les composants situés dans une zone sécurisée doivent être sécurisés au même niveau
• <CTRL F> représente le moyen le plus pratique de localiser un produit
• Composants et classés par ordre alphabétique dans chaque catégorie
• <date d’entrée en vigueur> désigne la date à partir de laquelle une composante nouvellement introduite doit
être prise en compte pour l’évaluation du PSC. Si elle est vide, cela signifie qu’elle doit déjà être prise en
compte.
• A, B - Désigne le fait que le type d’architecture peut être n’importe quel « A » ou « B ».
• N/A - Non applicable
• SWIFT recommande toujours de protéger les composants qui sont hors du champ d’application comme s’ils
en faisaient partie.

d’architecture
Dans le
Type(s)
champ/hors Nom du composant Date
probable(s)
du champ Catégorie (par ordre alphabétique dans chaque Description/Remarque d’entrée
d’architecture
d’application catégorie) en vigueur
de CSP
du CSP
Liste des interfaces de communication compatibles:
Interfaces et https://www.swift.com/about-us/partner-programme/swift-certified-
Interface de communication (par exemple, SAG,
applications interface-programme-0?AKredir=true A1
AGI)
connexes Comprend également une fonctionnalité de connectivité API basée sur
l’AGI ou le SAG
Interface utilisateur graphique (GUI), par SWIFT ne garantit pas la compatibilité de l’interface utilisateur graphique
A
exemple AWP, CREST GUI, gpi GUI fournie par les fournisseurs
IPLA - Plateforme d’intégration Alliance Access Construit sur la base de l’ASA A1/A2
IPLA - Connecteur pour le filtrage des sanctions
Le connecteur CFS est un composant IPLA sur SAA A1/A2
(CFS)
Le connecteur gpi sur IPLA est une solution verticale fonctionnant comme
IPLA - Connecteur gpi un ensemble de composants à l’intérieur de l’infrastructure SAA-IPLA A1/A2
(fonctionne au sein de la SAA)
IPLA - Connecteur cible 2 (T2) Le connecteur T2 est un composant IPLA sur SAA A1/A2
IPLA - Connecteur Target 2 for Securities (T2S) Le connecteur T2S est un composant IPLA sur SAA A1/A2
Liste des interfaces de messagerie compatibles.
Interface de messagerie (par exemple SAA,
Certains back-offices peuvent être considérés comme des interfaces de A1/A2
AMH)
messagerie (voir TIP 5021823)
Le back-office utilisant la MQHA en mode « Souple » et « Strict » est
La MQHA en mode souple/strict A1/A2
considéré comme une interface de messagerie
Le back-office utilisant le RAHA en mode « Souple » et « Strict » est
RAHA en mode souple/strict A1/A2
considéré comme une interface de messagerie
Peut être autonome ou intégré à l’accès à Alliance ou à l’AMH ou au
Relationship Management Application (RMA) produit du fournisseur - https://www.swift.com/about-us/partner- A1/A2
programme/swift-certified-interface-programme/document-centre
Le connecteur gpi sur AMH est un service d’AMH fonctionnant au sein de
SWAP Proxy (connecteur gpi) sur AMH A1/A2
l’infrastructure d’AMH (fonctionne au sein d’AMH)
Ce composant est utilisé pour le transfert de fichiers et est installé dans
Gestionnaire SWFA - SWIFT FileAct A1/A2
l’interface de messagerie
Accès Alliance SWIFT utilisé pour se connecter à Il s’agit d’une solution SAA hébergée chez le client et accédant à la
A2
l’ARG (Alliance Remote Gateway) solution Alliance Cloud de SWIFT
Peut être inclus dans l’interface de communication ou fonctionner de
SWIFTNet Link (SNL) A1
manière autonome
lorsqu’il est embarqué (c’est-à-dire intégré dans l’interface de
Traducteur SWIFT (intégré) messagerie) ; en dehors du champ d’application lorsqu’il est A1/A2
autonome
Ce terme désigne la solution File base qui s’interface avec les serveurs
Lite 2 Autoclient A3
SWIFT Lite
Connecteur Ce terme désigne la solution SWIFT New Lite qui remplace la solution
SIL - Alliance Cloud A3
SWIFT Autoclient basée sur le lien direct
SIL - CFS ( Connecteur pour le contrôle des
Le connecteur CFS est un composant autonome A3
sanctions)

d’architecture
Dans le
Type(s)
probable(s)
d’architecture
de CSP
du CSP
Le connecteur gpi sur SIL est une solution verticale fonctionnant comme
SIL - Connecteur gpi (alias Connecteur gpi
un ensemble de composants à l’intérieur de SIL qui est un logiciel A3
autonome)
autonome (par exemple Gsrp ou Gcase)
Connecteur API SWIFT comprend des produits tels que DirectLink/SIL ou SWIFT Microgateway A3
SWIFT Microgateway Fournit une fonctionnalité de connectivité API A3
Connecteur client API fait maison comprenant une fonctionnalité de

Connecteur API client A4
connectivité API, basée sur le SDK/spéc. SWIFT API
Solutions de transfert de fichiers utilisées pour faciliter la communication
Solutions FTP (serveurs) avec les composants relatifs à SWIFT offerts par un prestataire de A4
Connecteur services
client
conseillé dans le champ d’application en 2020, Mise en œuvre de
systèmes middleware locaux, tels que le serveur IBM® MQ, utilisé pour
[Conseillé] Serveur Middleware/MQ l’échange de données entre les composants relatifs à SWIFT (dans A4
l’infrastructure SWIFT locale ou chez un prestataire de services) et le
back-office des utilisateurs
Boîtiers VPN Alliance Connect ou leurs instances
virtuelles (systèmes ou machines Seule la mesure 3.1 du CSP (sécurité physique) s’applique A, B
d’hébergement)
Authentification matérielle connectée ou jetons personnels utilisés pour les
opérations SWIFT ou l’accès à une zone sécurisée et dispositif de saisie
du code PIN (PED) utilisé pour les opérations HSM. Comprend les jetons
Authentification matérielle connectée ou jetons
personnels 3Skey lorsqu’ils sont utilisés pour les services SWIFT A, B
Composants personnels
(tels que FIN, InterAct, FileAct en direct ou via Alliance Cloud, Lite2
matériels et, à l’avenir, un service de messagerie ou la plateforme de
transaction qui sera exposée par SWIFT)
HSM - Hardware Security Module Généralement combiné avec le BNL A1
Dispositifs de réseau protégeant la (les) zone(s)
Comprend les pare-feu et les routeurs A
sécurisée(s)
Couche sous-jacente sur prem ou avec les fournisseurs de cloud
Plateforme de virtualisation (hyperviseur) A, B
computing hébergeant des VM relatives à SWIFT
Poste de travail opérateur situé à l’intérieur de la zone sécurisée et destiné
PC opérateur dédié A
exclusivement à interagir avec les autres éléments de la zone sécurisée
PC opérateur à usage général accédant à
Poste de travail opérateur dans l’environnement général de l’entreprise et
l’infrastructure swift locale ou distante et à ses A, B
PC utilisé pour des tâches courantes
opérateurs
opérateur et
opérateurs PC opérateur à usage général utilisé pour accéder aux services de
PC opérateur à usage général utilisé pour
messagerie SWIFT hébergés et exploités chez un prestataire de services
accéder aux services de messagerie SWIFT
(tel qu’un bureau de service, un fournisseur L2BA, un acteur intermédiaire B
hébergés et exploités chez un prestataire de
ou SWIFT) et lorsque ces PC sont utilisés pour soumettre ou affecter des
services
transactions commerciales

d’architecture
Dans le
Type(s)
probable(s)
d’architecture
de CSP
du CSP
PC opérateur à usage général utilisé par les
Les utilisateurs de l’interface graphique uniquement n’ont pas de
utilisateurs de l’interface graphique Alliance B
connecteur
Cloud ou Lite 2
PC opérateur à usage général utilisé par les Ce terme recouvre les PC qui se connectent à distance à une application
B
utilisateurs de l’interface graphique L2BA frontale exploitée par un fournisseur L2BA
PC opérateur à usage général utilisé par les Ce terme désigne les PC qui se connectent à l’application ESMIG
B
utilisateurs de l’ESMIG U2A (European Single Market Infrastructure Gateway) via le réseau SWIFT
Filtrage des sanctions (SS) à l’aide du service de copie FIN Y, la solution
PC opérateur à usage général se connectant à la est utilisée pour examiner les paiements bloqués dans le SS, qui peuvent A, B
solution cloud Sanctions Screening ensuite être annulés ou débloqués.
PC opérateur à usage général se connectant aux
Utilisation de la plateforme Web/SAG/SNL - En plus du MV-SIPN A1
services d’accès au Web
" Utilisation du navigateur/des jetons - En plus du MV-SIPN B
" Utilisation du navigateur/des jetons - Sur l’Internet B

PC opérateur à usage général accédant au
Utilisation de la plateforme Web/SAG/SNL - En plus du MV-SIPN A1
traqueur gpi
" Utilisation du navigateur/des jetons - En plus du MV-SIPN B
" Utilisation du navigateur/des jetons - Sur l’Internet B

Le composant CRNet fournit à l’utilisateur un certain nombre de contrôles
sur la connexion réseau entre l’alliance SWIFT et l’application hôte du
CRNet dans le SAA A2
CRNet. Il contient les processus sous-jacents nécessaires au transfert de
fichiers et aux services interactifs
Connecteur client Euclid (ECC) - Pour le trafic
livré par SWIFT aux utilisateurs d’Euclid et utilisé pour le trafic SWIFT A1
SWIFT
n’affecte pas
Hôte du connecteur Euclide (ECH) livré à Euro Clear par SWIFT - Uniquement dans les locaux d’EuroClear l’architecture
Empreinte
de l’utilisateur
des produits
MI utilisés Market Infrastructure (MI) Channel est un canal de messagerie conçu pour
pour un permettre aux clients d’accéder aux grandes infrastructures de marché de
service manière efficace. MI Channel s’appuie sur la plateforme de stockage et de
SWIFT transmission SWIFTNet et optimise l’échange de grandes quantités de
MI Channel pour CLS A1
spécifique données entre l’infrastructure du marché et ses participants, tout en offrant
un mode de fonctionnement simplifié et en facilitant l’intégration. La
fonctionnalité du canal MI est intégrée dans l’interface de communication
existante: Passerelle de liaison et d’alliance SWIFTNet
Logiciel de gestion pour l’ensemble de la chaîne de communication pour la
Canal MI pour T2S A1
connexion à la passerelle T2S dans l’OPC SWIFT spécifique à EuroClear
Cette solution est proposée en deux versions: (i) intégrée dans le SNL ou
Empreinte minimale (MFP) (ii) autonome, remplaçant le SAA-SAG/SNL - dans les deux cas, elles A1
relèvent du champ d’application de la DSP

d’architecture
Dans le
Type(s)
probable(s)
d’architecture
de CSP
du CSP
Le Transaction Delivery Agent est une application, fonctionnant en amont
d’Alliance Gateway, qui permet le transfert de messages entre institutions.
Ce mode de transfert offre une seule et unique garantie de livraison des
TDA - Agent de livraison des transactions messages. L’interface du Transaction Delivery Agent utilisée pour A1
communiquer avec les applications des institutions est basée sur le
middleware de messagerie standard IBM WebSphere MQ
Transport de données entre des éléments relatives à SWIFT (dans
l’infrastructure SWIFT locale ou chez un prestataire de services) et le
Couche d’échange de données A, B
premier bond du back-office de l’utilisateur tel qu’observé à partir des
éléments relatifs à SWIFT. Contrôles applicables: 2.4A, 6.4, 6.5A, 7.3A
Autres Jump server donnant accès à la (aux) zone(s) Serveur utilisé pour accorder l’accès à la zone sécurisée depuis le réseau
A
sécurisée(s) de l’entreprise de l’utilisateur (par exemple, Citrix ou Remote Desktop)
SOAP/API pour se connecter d’un back-office à La méthode de connexion SOAP permet l’échange de messages MT, XML
l’interface de messagerie d’un prestataire de B
et FileAct entre Alliance Access et les applications de back-office.
services
Une solution d’identité personnelle SWIFT basée sur la technologie PKI.3.
Les jetons clés peuvent être utilisés avec toutes les banques pour signer
et approuver les transactions. 3SKey peut être utilisé sur n’importe quel
canal bancaire électronique, y compris les systèmes internes de gestion
de la trésorerie ou des liquidités, la banque en ligne, les réseaux locaux et
3Skey Sans objet
propriétaires et SWIFT. Vous pouvez l’utiliser pour signer des instructions
bancaires électroniques ou vous connecter de manière sécurisée à votre
application bancaire. Notez que les jetons personnels 3Skey utilisés
Hors du champ d’application
pour les services SWIFT entrent dans le champ d’application (voir la

catégorie Composants matériels ci-dessus)
Utilisateurs de l’AU-NPP et du GLI Ne sont pas considérés comme des utilisateurs de SWIFT Sans objet
Systèmes qui prennent en charge la logique métier, la génération de
transactions et d’autres activités intervenant avant la transmission dans
Application métier Sans objet
l’infrastructure SWIFT locale. Par exemple, les applications back-office
comme SAP et General Ledger ne sont pas concernées.
Bien que globalement hors de portée, SWIFT recommande que les
systèmes de BI définis comme destination des données sensibles
Sans objet
Systèmes de Business Intelligence (BI) (par transmises soient pris en compte dans la mesure de contrôle « 2.5A
exemple, SWIFT Scope Protection de données pour transmission externe ».
Celle-ci comprend (i) la connexion aux 4 fournisseurs SWIFT (BT Global
Connexions au réseau SWIFT fournies par les
Services, Orange Business Services, AT&T et Colt) derrière les boîtes Sans objet
partenaires du réseau SWIFT
VPN et (ii) les connexions Internet
Connecteur client Euclid (ECC) - Pas pour le Livré par Internet. SWIFT fournit le connecteur, mais BT Radianz assure la
Sans objet
trafic SWIFT connectivité du réseau
PC Euclid livré par EuroClear à ses clients Sans objet

d’architecture
Dans le
Type(s)
probable(s)
d’architecture
de CSP
du CSP
Serveur Euclid livré par EuroClear Sans objet
L’infrastructure TI globale utilisée pour appuyer l’organisation dans son
Environnement informatique et bureautique
ensemble (par exemple, PC opérateur à usage général, serveur de Sans objet
général de l’entreprise
messagerie, services d’annuaire, etc.).
Lors de l’utilisation de SWIFT.com, les comptes sont uniquement utilisés
PC opérateur à usage général accédant au pour les fonctionnalités de suivi de base, ce qui signifie qu’ils ne sont pas Sans objet
système de suivi de base gpi utilisés pour l’arrêt et le rappel
Ce composant logiciel permet à une application fonctionnant sur un
système d’émettre des appels vers un gestionnaire de file d’attente (MQ
Sans objet
Server) fonctionnant sur un autre système. Le résultat de l’appel est
Client MQ sur back-office renvoyé au client MQ, qui le transmet à l’application
Les back-offices utilisant la MQHA en mode de base sont considérés
MQHA en mode de base Sans objet
comme des back-offices
Les back-offices utilisant le RAHA en mode de base sont considérés
RAHA en mode de base Sans objet
comme des back-offices
PAG/DMC pour l’AU-NPP Ne sont pas considérés comme des utilisateurs de SWIFT Sans objet
Une solution utilisée pour identifier et prévenir les instructions de paiement

Payment Controls Service (PCS – Service de frauduleuses ou non conformes à la politique pour les paiements envoyés.
Sans objet
contrôle des paiements) SWIFT recommande que les jetons associés à ce service soient
couverts dans la mesure 5.2 Gestion des jetons
La prévalidation gpi détecte les problèmes de paiement avant l’envoi des

paiements pour exécution. Il n’y a donc pas de risque spécifique en termes
de CSP.
La prévalidation gpi utilise la passerelle API de SWIFT. Cette
Prévalidation pour SWIFT gpi authentification devra se faire à l’aide de la plateforme SWIFT API, Sans objet
laquelle peut être facilitée par l’utilisation d’une technologie spécialisée,
telle que le connecteur pour SWIFT gpi. Il peut fonctionner sur la base
d’un SDK, d’un SDK + connecteur gpi autonome, ou en utilisant des
interfaces et un connecteur gpi intégré
Utilisé uniquement pour les requêtes et n’affectant pas l’intégrité des
Sans objet
Serveur Web gpi de prévalidation transactions
Cette solution est utilisée pour examiner les paiements bloqués dans SS,
ils peuvent ensuite être annulés ou débloqués. Par conséquent, les
utilisateurs finaux n’initient pas ou ne modifient pas les paiements en SS.
Sanctions Screening (SS) en utilisant FIN Y Si un paiement est débloqué, cela signifie qu’il a passé tous les contrôles
Sans objet
Copy service - Solution cloud de transaction dans l’interface de messagerie (par exemple, méthode des
4 yeux, méthode des 6 yeux) et il s’agit juste d’un contrôle supplémentaire
à des fins de conformité avec ces listes des Nations unies, des États, des
PPP, etc. Les utilisateurs finaux utilisent l’interface graphique pour accéder

d’architecture
Dans le
Type(s)
probable(s)
d’architecture
de CSP
du CSP
au SS du Cloud. SWIFT recommande que les jetons associés à ce
service soient couverts dans la mesure 5.2 Gestion des jetons
Une solution d’intelligence économique offrant une visibilité complète et
Champ d’application de SWIFT immédiate sur les déclarations de trésorerie quotidiennes d’une Sans objet
organisation
Ne s’applique pas lorsque la connexion aux services de
SWIFT SDK sur back-office ( en utilisant messagerie/transaction SWIFT repose sur d’autres
Sans objet
l’empreinte SWIFT ou le connecteur client) applications/composants relatifs à SWIFT (utilisant une interface de
communication ou un connecteur SWIFT (API) comme empreinte SWIFT)
Hors-champ d’application lorsqu’il est autonome ; dans le champ
Traducteur SWIFT (autonome) Sans objet
d’application lorsqu’il est intégré dans l’interface de messagerie
Un serveur hébergé chez un prestataire de services et assurant un service
Sans objet
Serveurs d’accès au Web côté fournisseur basé sur le Web

Présentation détaillée Responsabilités partagées dans un modèle de Cloud IaaS
Responsabilités partagées dans un

modèle de Cloud IaaS
Les utilisateurs collaborant avec des tiers (comme un prestataire informatique externe ou un fournisseur
de cloud computing) ou des prestataires de services (comme un service bureau ou un fournisseur
d’applications Lite2 professionnelles) pour héberger ou exploiter tout ou partie de leur propre
infrastructure SWIFT doivent obtenir de ces tiers ou prestataires de services un confort raisonnable que
les activités connexes sont protégées conformément aux mesures de sécurité du CSCF. En effet,
l’utilisateur reste responsable et redevable de l’attestation qu’il doit remplir en tenant compte des
contrôles qu’il a déployés et de ceux déployés par ses tiers et prestataires de services.
Il n’est bien sûr pas possible de couvrir tous les modèles d’externalisation. Par conséquent, pour illustrer
et déclencher la motivation des utilisateurs lorsqu’ils envisagent leur modèle d’externalisation, le tableau
ci-dessous présente le partage type des responsabilités au moment de la sélection d’un modèle IaaS
(Infrastructure as a Service) dans le cloud, similaire à celui de Digital Connectivity*, lorsqu’elle est
disponible.
* Dans Digital Connectivity, l’utilisateur souscrit à un environnement virtualisé mis en place par des
fournisseurs de cloud computing (CP) sélectionnés sur leur infrastructure. L’utilisateur reste responsable
du déploiement, de la gestion des différentes piles (systèmes et applications) de son abonnement et
donc des contrôles y afférant. Le HSM et le VPN peuvent être physiquement hébergés, ou plus tard
virtualisés, dans l’infrastructure du fournisseur de cloud computing. Si la majorité des systèmes ou
composants d’une architecture A1 sont hébergés chez le fournisseur de cloud computing, l’utilisateur
dispose néanmoins de certains équipements, au minimum les PC opérateur, qu’il doit protéger.

Présentation détaillée Mentions légales
Mentions légales
Copyright
SWIFT © 2020. Tous droits réservés.
Diffusion restreinte
Il vous est interdit de diffuser la présente publication en dehors de votre organisation, à moins que
votre abonnement ou ordre ne vous confère expressément ce droit, auquel cas vous devez respecter
toute autre condition applicable.
Avis de non-responsabilité
Les informations figurant dans la présente publication sont susceptibles d’être modifiées à tout
moment. Vous devez toujours consulter la dernière version disponible.
Traductions
La version anglaise de la documentation SWIFT est la seule version officielle et contraignante.
Marques
SWIFT est le nom commercial de S.W.I.F.T. SCRL. Les éléments ci-après sont des marques
déposées de SWIFT: 3SKey, Innotribe, MyStandards, Sibos, SWIFT, SWIFTNet, SWIFT Institute, le
logo Standards Forum, le logo SWIFT et UETR. Les autres noms de produit, de service ou
d’entreprise figurant dans cette publication sont des noms commerciaux, des marques commerciales
ou des marques déposées de leurs propriétaires respectifs.

CSCF v2021 01072020 FR-FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CSCF v2021 01072020 FR-FR

Transféré par

Droits d'auteur :

Formats disponibles

SWIFT Customer Security Controls Framework

1er juillet 2020

Table des matières

1er juillet 2020 2

1er juillet 2020 3

1er juillet 2020 4

1er juillet 2020 5

Aperçu des changements

Le tableau suivant résume les principaux changements apportés au contenu du présent

Mesure ou section Changement

Confirmer la scission des mesures de contrôle existantes dans un souci

1er juillet 2020 6

Mesure ou section Changement

Clarifications sur les définitions du champ d’application et la nouvelle

1er juillet 2020 7

Mesure ou section Changement

1.1 Protection de l’environnement Ajout d’un accès temporaire comme

1er juillet 2020 8

Mesure ou section Changement

6.5A Détection des intrusions Référence à l’utilisation de la solution EDR

1er juillet 2020 9

Objectifs et principes du cadre

Figure 1: Objectifs et principes du cadre

Les 31 mesures de sécurité (22 mesures obligatoires et 9 mesures conseillées) détaillées

1er juillet 2020 10

• L’atteinte à la confidentialité (des données commerciales, des systèmes informatiques,

Intégration avec la gestion de la sécurité et des risques

1er juillet 2020 11

Périmètre des mesures de sécurité

Figure 2: Périmètre des mesures de sécurité

Les mesures de sécurité s’appliquent aux éléments visés suivants:

1er juillet 2020 12

1er juillet 2020 13

Le terme PC opérateur seul désigne à la fois les PC à usage général et les PC

Les éléments suivants ne sont pas visés par les mesures:

1er juillet 2020 14

1er juillet 2020 15

Figure 3a: Architecture A1 - Interfaces dans l’environnement de l’utilisateur

Figure 3b: Architecture A1 - Interface de communication uniquement dans l’environnement de

Ce type d’architecture A1 inclut également des solutions hébergées où l’utilisateur

1er juillet 2020 16

• Architecture A2 – Utilisateur détient l’interface de messagerie, mais pas l’interface de

Figure 4: Architecture A2 - Interface de messagerie uniquement dans l’environnement de

Ce type d’architecture comprend également les solutions hébergées où l’utilisateur

• Architecture A3 – Connecteur SWIFT

1er juillet 2020 17

Figure 5: Architecture A3 – Connecteur SWIFT

• Architecture A4 – Connecteur client

Figure 6a: Architecture A4 – Middleware/Transfert de fichiers comme connecteur

Cette architecture spécifique nécessitera que certains utilisateurs adoptent

En préparation du futur, cette architecture de type A4 comprend également des

1er juillet 2020 18

futur service de messagerie 11 ou une Plateforme de transaction 12 exposée par SWIFT).

Figure 6b: Architecture A4 - Connecteur client (API maison)

• Architecture B - Aucune empreinte chez l’utilisateur

1er juillet 2020 19

Figure 7: Architecture B - Aucune empreinte d’utilisateur se connectant à un prestataire de

Les mesures de sécurité applicables aux architectures A1, A2 et A3 sont identiques 15

1er juillet 2020 20

Structure des mesures de sécurité

1er juillet 2020 21

Conformité des contrôles de sécurité

1er juillet 2020 22