Ssi e 007

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université des Sciences et de la Technologie Houari Boumediene
Faculté d’Informatique
Département des Systèmes Informatiques
Mémoire de Master
Filière : Informatique
Spécialité :
Sécurité des Systèmes Informatiques
Thème
Conception et implémentation d’un scénario de supervision et
détection des attaques ciblant le contournement de la logique de
fonctionnement métier des applications bancaires SWIFT
Sujet Proposé par :

Mr BENDELHOUM Soheib – Intervalle Technologies
Soutenu le : 29/06/2022
Présenté par :
BENMIMOUN Manel
KEDIDAH Racha
Devant le jury composé de :
Mr ABDELLI Abdelkrim Président (e)

Mme ALIOUANE Lynda Membre
Binôme N° : SSI-E-007 / 2022

Remerciements
Nous tenons tout d’abord à remercier Dieu le tout puissant et
miséricordieux de nous avoir accordé la force, la patience et la volonté
de mener à bien ce travail.
Nous aimerions d’abord exprimer nos infinis remerciements et nos

respectueuses reconnaissances à l’équipe d’Intervalle Technologies
de nous avoir ouvert ses portes, et à notre promoteur Mr
BENDELHOUM.S pour accepter de nous confier ce projet, pour ses
directives précieuses et pour son suivi, sa rigueur, sa patience et sa
disponibilité durant toute la période de ce projet.
Nous souhaitons également remercier Mme ALIOUANE.L de nous

avoir aidé à travers les conseils et les remarques qu’elle nous a
prodigué.
Nous désirons aussi remercier les membres du jury pour l’intérêt qu’ils
ont porté à notre effort en acceptant d’examiner notre modeste travail
et en l’enrichissant par leurs propositions.
Nous n’oserions oublier de remercier tous les professeurs de la faculté

d’informatique et du département des Systèmes Informatiques de
l’USTHB pour la qualité d’enseignement qu’ils nous ont prodigué au
cours de ces années d’études, pour nous avoir procuré les conditions
les plus favorables pour le bon déroulement de notre parcours. Merci
pour votre générosité et votre patience, et pour tout ce que vous nous
avez appris.
Enfin, nous voudrions témoigner nos profondes gratitudes à tous ceux

qui ont contribué de près ou de loin à la réalisation de ce projet qui est
l’aboutissement d’un dur labeur et de beaucoup de sacrifices.
Dédicaces
La première personne à qui je dédicace ce travail, ma chère maman
qui me considère comme sa plus grande réussite et que moi je
considère comme mon plus grand modèle dans la vie.
À mes chères petits frères et sœurs Yasmine et Yanis et Ines, qui sont
ma plus grande source d’inspiration et de motivation et pour qui
j’espère avoir été un bon exemple.
À mes grands-parents, puisse dieu vous préserve votre santé et votre

bonheur et vous garde pour nous.
À mon cher père, qui m’a encouragé et qui a toujours eu confiance en

moi et en mes capacités tout au long de mon cursus.
À ma meilleure amie Hiba, qui m’a été d’un grand soutien moral durant
toutes mes années de collège, lycée et d’université.
Manel.
Dédicaces
Je tiens à dédier ce travail à la personne qui a consacré toute sa vie
pour me voir réussir, qui m’a accompagné par ses prières, à ma très
chère mère, aucune dédicace ne saurait exprimer mon sentiment de
gratitude envers toi. Je te dois ce que je suis aujourd’hui et ce que je
serai demain et je ferai toujours de mon mieux pour rester ta fierté et
ne jamais te décevoir.
À mon père Mohamed, mes chers frères Walid et Wacim, avec tous
mes sentiments de respect et de reconnaissance pour leur patience,
leur accompagnement, leur présence et leur soutien.
À une personne très précieuse dans ma vie, qui n’a jamais quitté mon
côté, tes mots d’encouragement sonnent toujours à mes oreilles,
merci Feriel.
À tous mes enseignants, qui ont assuré ma formation depuis le

primaire à ce jour, je vous exprime toute ma gratitude.
À toute personne qui m’a apporté la moindre aide, merci.
Racha.
Résumé
Durant cette lutte contre la fraude que les instituts financiers mènent
désormais contre les cybers attaquants, plusieurs mesures de
sécurité ont dû être mises en place aux seins de ces organisations
pour empêcher et prévenir les attaques qui menacent leurs
applications. On compte parmi les applications les plus ciblées par ces
menaces, les applications du réseau interbancaire SWIFT.
Parmi les mesures de sécurité qui assurent la détection et la

prévention des menaces sur les systèmes, le Centre Opérationnel de
Sécurité (SOC). Composé de plusieurs types de technologies, le SOC
assure la détection des anomalies sur un système, l’investigation et
assure en cas d’incidents la réponse à ces derniers.
Dans le cadre de notre travail, nous nous sommes intéressés à

l’amélioration du processus de détection des anomalies qui menacent
les transactions SWIFT dans un SOC, et le développement des cas
d’utilisation adéquats sur le SIEM pour le signalement en cas
d’altération dans la logique de fonctionnement dans les applications
et les transactions SWIFT.
Sommaire
INTRODUCTION GÉNÉRALE ............................................................................................ 1
1. LES APPLICATIONS SWIFT ......................................................................................... 3
1.1. INTRODUCTION :............................................................................................................... 3

1.2. DÉFINITION DE SWIFT : .................................................................................................. 3
1.3. DÉFINITION DU RÉSEAU SWIFTNET : ............................................................................. 4
1.4. MÉTHODES D’ACCÈS DES UTILISATEURS AU RÉSEAU SWIFTNET : ............................... 4
1.4.1. CONNEXION DIRECTE : .................................................................................................... 4
1.4.2. SERVICE BUREAU : .......................................................................................................... 5
1.4.3. INTERFACE WEB ALLIANCE LITE :................................................................................... 5
1.5. LES SERVICES DE MESSAGERIE SWIFTNET : ................................................................. 5
1.5.1. FIN : ............................................................................................................................... 5
1.5.2. FILEACT : ........................................................................................................................ 6
1.5.3. INTERACT : ..................................................................................................................... 6
1.5.4. BROWSE : ........................................................................................................................ 6
1.6. STANDARDISATION : ......................................................................................................... 7
1.6.1. TYPES ET STRUCTURE DES MESSAGES SWIFT MT : ........................................................ 7
1.6.2. TYPES ET STRUCTURE DES MESSAGES SWIFT MX : ....................................................... 9
1.7. CONCLUSION : ................................................................................................................ 10
2. LA SÉCURITÉ AUTOUR DES APPLICATIONS SWIFT ........................................ 12
2.1. INTRODUCTION :............................................................................................................. 12

2.2. SÉCURITÉ DE LA MESSAGERIE SWIFT : ........................................................................ 12
2.2.1. CONFIDENTIALITÉ : ....................................................................................................... 13
2.2.2. INTÉGRITÉ : ................................................................................................................... 13
2.2.3. DISPONIBILITÉ : ............................................................................................................. 13
2.2.4. RÉSILIENCE : ................................................................................................................. 13
2.3. SWIFT FACE AUX MENACES :........................................................................................ 14
I
2.3.1. BANQUE DEL AUSTROZ EN ÉQUATEUR : ........................................................................ 14
2.3.2. BANQUE DE CHILE EN CHILI :........................................................................................ 14
2.3.3. THIEN PONG BANK AU VIETNAM : ................................................................................ 14
2.3.4. THE BANK OF BANGLADESH : ....................................................................................... 15
2.3.5. FACTEURS DE COMPROMISSION : ................................................................................... 15
2.4. LE PROGRAMME CSP SWIFT : ..................................................................................... 15
2.4.1. DÉFINITION DU CSP : .................................................................................................... 15
2.4.2. CONTRÔLES CSP SWIFT : ............................................................................................ 16
2.4.3. TYPES D’ARCHITECTURES :............................................................................................ 17
2.4.3.1. Architecture A1 : ....................................................................................................... 17
2.4.3.2. Architecture A2 : ....................................................................................................... 18
2.4.3.3. Architecture A3 : ....................................................................................................... 18
2.4.3.4. Architecture B : ......................................................................................................... 18
2.5. CONCLUSION : ................................................................................................................ 19
3. LE CENTRE OPÉRATIONNEL DE SÉCURITÉ (SOC) ........................................... 20
3.1. INTRODUCTION :............................................................................................................. 20

3.2. DÉFINITION DU SOC : .................................................................................................... 20
3.3. MISSIONS DU SOC :........................................................................................................ 21
3.4. PROCESSUS D’UN SOC : ................................................................................................. 21
3.4.1. LA SURVEILLANCE ET LA DÉTECTION : .......................................................................... 21
3.4.2. RÉPONSE AUX INCIDENTS : ............................................................................................ 22
3.4.3. LES RENSEIGNEMENTS SUR LES MENACES : ................................................................... 24
3.5. LES RÔLES ET LES RESPONSABILITÉS DU SOC :............................................................ 24
3.6. TECHNOLOGIES DU SOC : ............................................................................................. 25
3.6.1. LE SIEM : ..................................................................................................................... 26
3.6.1.1. Les cas d’utilisation : ................................................................................................. 26
3.6.1.2. Les cas d’utilisation par défaut sur un SIEM : .......................................................... 27
3.6.1.3. Formalisation d’un cas d’utilisation : ........................................................................ 27
3.6.1.4. Création d’un cas d’utilisation personnalisé : ........................................................... 28
3.6.2. LA SOLUTION UEBA : ................................................................................................... 29
3.6.3. LES SOLUTIONS DE DÉCOUVERTE D’ACTIFS : ................................................................. 30
3.6.4. LES SOLUTIONS D’ÉVALUATION DE VULNÉRABILITÉ : ................................................... 30
II
3.6.5. LES SOLUTIONS DE DÉTECTION D’INTRUSION : .............................................................. 30
3.7. MODÈLES ET STRATÉGIES D’UN SOC :.......................................................................... 30
3.8. CONCLUSION : ................................................................................................................ 31
4. CONCEPTION ................................................................................................................ 32
4.1. INTRODUCTION :............................................................................................................. 32

4.2. ÉTUDE THÉORIQUE DE LA LOGIQUE DE FONCTIONNEMENT DES APPLICATIONS SWIFT
:………………......................................................................................................................... 32
4.2.1. CRÉATION DES MESSAGES : ........................................................................................... 33
4.2.2. VÉRIFICATION DES MESSAGES : ..................................................................................... 33
4.2.3. AUTORISATION DES MESSAGES : ................................................................................... 33
4.3. ÉTUDE DES CONTRÔLES OPÉRATIONNELS DES TRANSACTIONS DU CSP : .................... 33
4.3.1. CONTRÔLE DE LA VALEUR LA TRANSACTION :............................................................... 34
4.3.2. LES HEURES D’ACTIVITÉS NORMALES :.......................................................................... 34
4.3.3. SÉPARATION DES TÂCHES : ............................................................................................ 34
4.4. COLLECTE DES JOURNAUX D’AUDIT DE L’APPLICATION SWIFT ALLIANCE : ............ 34
4.5. ÉTUDE ET ANALYSE DES LOGS D’UNE TRANSACTION NORMALE : ................................. 35
4.5.1. CRÉATION DU MESSAGE : .............................................................................................. 35
4.5.2. VÉRIFICATION DES MESSAGES : ..................................................................................... 36
4.5.3. AUTORISATION DES MESSAGES : ................................................................................... 36
4.5.4. LE TRAITEMENT (HANDLING) ET L’ENVOI DES MESSAGES :............................................ 37
4.6. RÉCAPITULATIFS DES MENACES ET LES ALERTES : ....................................................... 37
4.7. NORMALISATION ET MAPPAGE DES CHAMPS DES JOURNAUX REÇUS PAR LE SIEM : .. 38
4.8. IDENTIFICATION DES SCÉNARIOS DE MENACE ET DES CAS D’UTILISATION : ................ 40
4.8.1. SCÉNARIO 1 : VÉRIFICATION DES MESSAGES : ............................................................... 40
4.8.2. SCÉNARIO 2 - AUTORISATION DES MESSAGES : ............................................................. 40
4.8.3. SCÉNARIO 3 - LIBÉRATION DU MESSAGE : ..................................................................... 41
4.8.4. SCÉNARIO 4 - MONTANT EXCEPTIONNEL : ..................................................................... 41
4.8.5. SCÉNARIO 5 - LES HEURES D’ACTIVITÉS NORMALES : ................................................... 42
4.8.6. SCÉNARIO 6 - SÉPARATION DES TÂCHES : ...................................................................... 42
4.8.7. SCÉNARIO 7 – MESSAGE EXPIRÉ : .................................................................................. 43
4.9. CONCLUSION : ................................................................................................................ 43
III
5. RÉALISATION ET TESTS............................................................................................ 44
5.1. INTRODUCTION :............................................................................................................. 44

5.2. ENVIRONNEMENT DE TRAVAIL : .................................................................................... 44
5.2.1. WINDOWS 10 :............................................................................................................... 44
5.2.2. SWIFT ALLIANCE ACCESS : ......................................................................................... 44
5.2.3. IBM QRADAR : ............................................................................................................. 45
5.2.4. WINCOLLECT : .............................................................................................................. 45
5.3. IMPLÉMENTATION DES RÈGLES DE CORRÉLATION : ..................................................... 45
5.3.1. ANALYSE D’UNE TRANSACTION NORMALE : .................................................................. 46
5.3.2. CONFIGURATION DE LA SOURCE DES JOURNAUX (LOG SOURCE) : ................................. 50
5.3.3. TRAITEMENT DES LOGS : ............................................................................................... 50
5.3.3.1. L’analyse (le « Parsing ») : ........................................................................................ 51
5.3.3.2. Le mappage : ............................................................................................................. 52
5.3.4. CRÉATION DES RÈGLES DE CORRÉLATION ...................................................................... 54
5.3.4.1. Scénario 1 – contourner la vérification : ................................................................... 56
5.3.4.2. Scénario 2 – contourner l’autorisation : .................................................................... 57
5.3.4.3. Scénario 3 – contournement du routage : .................................................................. 57
5.3.4.4. Scénario 4 – valeur de transaction relativement élevée : .......................................... 59
5.3.4.5. Scénario 5 – opération en dehors des heures normales de service : .......................... 60
5.3.4.6. Scénario 6 – problème de séparation des tâches : ..................................................... 61
5.3.4.7. Scénario 7 – message expiré : ................................................................................... 63
5.3.5. TESTS DES RÈGLES (LA DÉTECTION) : ............................................................................ 64
5.3.5.1. Contournement de la vérification, de l’autorisation et de routage : .......................... 64
5.3.5.2. Détection d’une valeur de transaction élevée : .......................................................... 66
5.3.5.3. Une opération en dehors des heures d’activité normales : ........................................ 67
5.3.5.4. Un problème de séparation des tâches : .................................................................... 68
5.3.5.5. Un message expiré :................................................................................................... 68
5.4. CONCLUSION : ................................................................................................................ 69
CONCLUSION GÉNÉRALE ............................................................................................... 70
ANNEXE A – CONTRÔLES DU PROGRAMME CSP .................................................... 71
IV
Liste des Figures
Figure 1.1 : Structure d'un message MT. _________________________________________ 8
Figure 2.1 : Type des architectures proposées par CSP (v2020). _____________________ 17
Figure 3.1 : Exemple d'une règle de corrélation de haut niveau. ______________________ 29
Figure 4.1 : Journalisation d’une transaction normale. _____________________________ 35

Figure 4.2 : Schéma récapitulatif des cas d'utilisation. _____________________________ 37
Figure 5.1 : l’interface graphique « Log Activity » de QRadar. ______________________ 45

Figure 5.2 : Exemple d’un évènement « Message Sent ». ____________________________ 46
Figure 5.3 : Un évènement "Message Received". __________________________________ 47
Figure 5.4 : Un évènement "Validation Error". ___________________________________ 47
Figure 5.5 : Un évènement "Message Routed" - 1er routage. ________________________ 48
Figure 5.6 : Un évènement "Message Routed" - 2em routage. ________________________ 48
Figure 5.7 : Un évènement "Message Routed" - 3em routage. ________________________ 48
Figure 5.8 : Un évènement "FOFS Information". _________________________________ 48
Figure 5.9 : Un évènement "Message Handling". _________________________________ 49
Figure 5.10 : Un évènement "Message Sent". _____________________________________ 49
Figure 5.11: La réception des Logs par QRadar. __________________________________ 49
Figure 5.12 : La création du "Log Source". ______________________________________ 50
Figure 5.13 : Le "Parsing" de la date et l'heure d'un évènement dans DSM Editor. _______ 51
Figure 5.14 : Le "Parsing" du "UUMID" d'un évènement dans DSM Editor. ___________ 52
Figure 5.15 : L’enregistrement de l’évènement "Message Handling".__________________ 53
Figure 5.16 : L'affectation d'un QID au message "Message Handling". ________________ 54
Figure 5.17 : La réception des évènements mappés dans Log Activity. _________________ 54
Figure 5.18 : Création d'une liste "ReferenceSet" des UUMID. ______________________ 55
Figure 5.19 : L'ajout des UUMID dans la liste "UUMID". __________________________ 55
Figure 5.20 : La suppression d'un UUMID. ______________________________________ 56
I
Figure 5.21 : Règle 1 - contournement de la vérification. ___________________________ 56
Figure 5.22 : Règle 2 - contournement de l'autorisation. ____________________________ 57
Figure 5.23 : Création de la règle de détection de contournement de routage. ___________ 58
Figure 5.24 : Règle 3 - contournement du routage. ________________________________ 59
Figure 5.25 : Règle 4 - valeur de transaction relativement élevée. ____________________ 60
Figure 5.26 : Règle 5.1 - opération en dehors des heures normales de service (soumission). 61
Figure 5.27 : Règle 5.2 - opération en dehors des heures normales de service (approbation).
_________________________________________________________________________ 61
Figure 5.28 : Remplissage de la liste "SWIFT Messages Creators". ___________________ 62
Figure 5.29 : Règle 6 – problème de séparation des tâches. _________________________ 63
Figure 5.30 : Règle 7 – message expiré. _________________________________________ 64
Figure 5.31 : Détection d’une tentative de contournement de vérification. ______________ 64
Figure 5.32 : Détails de l'alerte : vérification contournée. __________________________ 65
Figure 5.33 : Détection d’une tentative de contournement d'autorisation. ______________ 65
Figure 5.34 : Détails de l'alerte : autorisation contournée. __________________________ 65
Figure 5.35 : Exemple d'une transaction à haute valeur. ____________________________ 66
Figure 5.36 : Détection d’une transaction à haute valeur. ___________________________ 66
Figure 5.37 : Détails de l'alerte : montant élevé. __________________________________ 67
Figure 5.38 : Détection d’une opération dans un temps suspect. ______________________ 67
Figure 5.39 : Détection d’une incompatibilité dans la séparation des tâches. ___________ 68
Figure 5.40 : Détails de l'alerte : problème de séparation des tâches. _________________ 68
Figure 5.41: Configuration de la durée de vie des UUMID. _________________________ 69
Figure 5.42 : Notification de l'expiration d'un UUMID. ____________________________ 69
II
Liste des Tableaux
Tableau 2.1 : Objectifs, principes et contrôles du CSP. _____________________________ 17
Tableau 4.1 : Normalisation des évènements._____________________________________ 38

Tableau 4.2 : "Parsing" des champs. ___________________________________________ 39
Tableau 4.3 : Affectation des QID aux évènements. ________________________________ 40
III
Table des acronymes
APT Advanced Persistent Threat
C&C Command-and-Control
CSCF Customer Security Controls Framework
CSP Customer Security Program
DDoS Distributed Denial of Service
DoS Denial of Service
DSM Device Support Module
GUI Graphical User Interface
IDS Intrusion Detection System
IoA Indicators of Attack
IoC Indicators of Compromise
KPI Key Performance Indicator
MPF Message Processing Function
MT Message Type
MTTD Mean Time to Detect/Discover
MTTR Mean Time to Respond
OWASP The Open Web Application Security Project
SA Situation Assessment
SAA SWIFT Alliance Access
SAG SWIFT Alliance Gateway
SIEM Security Information & Event Management
SLA Service Level Agreement
SNL SWIFTNet Link
SOC Security Operations Center
SWIFT Society for Worldwide Interbank Financial
Telecommunication
SWIFTNet SWIFT Network
TTP Tactics, Techniques, and Procedures
UEBA User and Entity Behavior Analytics
IV
Introduction générale
La lutte contre la fraude constitue l’un des défis majeurs que doit relever
l’écosystème financier de nos jours, particulièrement en temps de crise. En cette
période d’instabilité et de changements rapides, les cybercriminels sont en embuscade
et cherchent à tirer parti de cette incertitude en tentant d’identifier les déficiences des
dispositifs de sécurité, pourtant généralement bien affûtés. La fraude aux paiements
institutionnels, largement répandue, constitue aujourd’hui un véritable casse-tête. Les
cybercriminels cherchent en effet à obtenir un accès illicite aux systèmes d’un
établissement, afin de voler des montants conséquents sans être démasqués.
Les fraudeurs ont très vite exploité les possibilités offertes par les nouvelles
conditions de travail suite à la pandémie COVID-19. Au début de l’année 2020, les
Autorités monétaires et les Agences de cybersécurité de différents pays ont fait part
de déclarations selon lesquelles des groupes de cybercriminels et des attaques de
type menace persistante avancée (APT) ciblaient les particuliers et les organisations
de toutes tailles dans le cadre d’escroqueries associées à la pandémie COVID-19. Ces
escroqueries faisaient notamment usage d’emails de phishing.
Les données montrent que les dommages causés à la communauté financière

ne diminuent pas. La fraude institutionnelle implique des attaques commises par des
parties externes à l’infrastructure de l’établissement financier, qui installent des
logiciels malveillants à distance ou par le biais du personnel de l’établissement. Les
paiements institutionnels constituent en effet un véhicule attrayant pour les criminels
en raison de la rapidité et du caractère définitif des règlements. Et une fois le paiement
effectué, il est très difficile de récupérer les pertes éventuelles. Bien que la fréquence
mondiale de la fraude aux paiements institutionnels soit plus faible, l’impact est
important, tant sur le plan du montant des fonds à risque que du préjudice
potentiellement causé à la réputation de l’institution attaquée. La mise en place de
stratégies et de contrôles internes les plus efficaces et opportuns
Les utilisateurs du réseau SWIFT -fournisseur mondiale de messagerie

financière- font partie de ce vaste écosystème et n’échappent, donc, pas à la tendance.
Et malgré la mise en place de mesures de sécurité robustes, les attaquants répondent
de façon toujours plus sophistiquée, de sorte que les institutions doivent bien
1
reconnaître qu’elles sont susceptibles de faire l’objet de cyberattaques. SWIFT a défini

dès 2017 un programme de sécurité, le programme de sécurité client. Il repose sur un
référentiel de contrôles, le « Customer Security Controls Framework ». Ce référentiel
est évolutif, s’impose aux membres et sa mise en œuvre doit faire l’objet depuis 2021
d’une évaluation indépendante annuelle qui sert de base à l’attestation de sécurité qui
leur est demandée. Chaque membre SWIFT se doit donc de déployer les mesures de
sécurité préconisées et d’être à même d’en rendre compte en vue de renforcer la
protection du réseau SWIFT auquel il est connecté et de ses membres.
L’une des exigences du Framework (exigence 6) consiste à mettre en place des

contrôles permettant de détecter les activités anormales dans les systèmes ou les
relevés d’opérations, d’où la recommandation de mettre en place un Centre
Opérationnel de Sécurité (SOC). L’objectif du SOC étant de détecter, analyser et
intervenir en cas d’incidents lié à la cybersécurité. Pour cela, il utilise une combinaison
de dispositifs technologiques ainsi qu’un ensemble de processus pour détecter et
remonter le moindre incident afin que les équipes de sécurité puissent réagir
rapidement.
Dans le cadre de notre travail, nous nous sommes intéressés à l’amélioration

du processus de détection des anomalies qui menacent les transactions SWIFT via un
SOC, et le développement de cas d’utilisation adéquats pour le signalement en cas
d’altération dans la logique de fonctionnement des applications et transactions SWIFT.
À cet effet, la première étape de notre travail consistait à déterminer les

scénarios de menaces qui doivent être détectés. Pour cela, à travers des journaux
générés par l’application, nous avons étudié le processus de fonctionnement d’une
application SWIFT lors de l’envoie d’une transaction, et avons déduit les différentes
étapes et phases par lesquelles passe une transaction d’être transmise. L’étape
suivante consistait à procéder à la normalisation de ces journaux au niveau du SIEM
et à l’implémentation des cas d’utilisation adéquats. Et finalement, afin de tester le bon
fonctionnement de ces cas d’utilisation implémentées au niveau du SIEM, nous avons
simulé des scénarios d’attaques.
2
Chapitre 1 Les applications SWIFT
1. Les applications SWIFT

1.1. Introduction :
Face aux différents types de dangers qui menacent la sécurité de l’information,

les systèmes d’informations du secteur financier demeurent la cible principale pour un
attaquant potentiel.
Dans ce premier chapitre nous allons présenter le réseau SWIFT et les

différents services de messagerie fournis par ses applications ainsi que les types de
messages échangés entre ces derniers.
1.2. Définition de SWIFT :
SWIFT (Society for Worldwide Interbank Financial Telecommunication) est une

communauté d’utilisateurs, dont la forme juridique est celle d’une société coopérative
de droit belge détenue par des institutions financières. Sa mission est d’offrir aux
acteurs du monde de la finance des services sécurisés de messagerie sur un réseau
privé (SWIFTNet) et utilisant les technologies avancées du monde de l’internet.
SWIFT a été créée en 1973 par 239 banques de 15 pays qui souhaitaient «
automatiser le télex ». Au 1er janvier 2011, SWIFT interconnectait près de 10 000
utilisateurs dans 210 pays. Au cœur des échanges entre les banques et leurs
correspondants, SWIFT s’est imposé au fil du temps comme l’organisme de
standardisation de l’industrie financière.
Les utilisateurs de SWIFT sont essentiellement les membres actionnaires de la

coopérative, leurs filiales ou implantations qui représentent près de 60% de ses
utilisateurs. Seules les banques, les courtiers et les gestionnaires de fonds
d’investissement peuvent devenir actionnaires de SWIFT. Le nombre d’actions qu’ils
détiennent est revu tous les deux ans en fonction de l’utilisation que ces membres font
du réseau et de ses services [1].
3
1.3. Définition du réseau SWIFTNet :
Le réseau SWIFTNet est un réseau de télécommunication TCP/IP sécurisé

développé par la coopérative SWIFT à travers lequel sont proposés des services et
des solutions, comme la messagerie FIN ou le transfert de fichier FileAct.
Le réseau est muni de points d’accès que les utilisateurs atteignent en recourant
aux services de l’un des quatre partenaires choisis par SWIFT pour mettre en œuvre
et assurer la connexion jusqu’aux utilisateurs finaux. La sécurité de bout-en-bout est
assurée par la mise en place de tunnels chiffrés qui permettent de constituer entre
l’utilisateur et SWIFT un réseau privé virtuel (VPN) [1].
La connexion au réseau peut se faire de différentes manières, mais toutes

nécessitent des logiciels, matériels et systèmes de sécurité fournis par SWIFT. Dans
le vocabulaire propre à SWIFT, les logiciels de messagerie spécifiques au réseau sont
appelés des interfaces.
Pour toutes les interfaces externes, les applications commerciales utilisent l'API
SWIFTNet Link (SNL) pour accéder aux services SWIFTNet. Ses processus d'arrière-
plan prennent en charge les fonctions de messagerie, de sécurité et de gestion des
services. Il est intégré à SWIFTAlliance WebStation et SWIFTAlliance Gateway (SAG),
SAG permet aux applications professionnelles sur des plateformes informatiques
disparates de transmettre des messages via SWIFTNet, les messages sont reçus via
des adaptateurs hôtes, y compris un adaptateur hôte WebSphere MQ.
1.4. Méthodes d’accès des utilisateurs au réseau SWIFTNet :
Pour accéder au réseau, les utilisateurs ont le choix entre trois grandes familles
de solution [1] :
1.4.1. Connexion directe :

Pour une connexion directe, les utilisateurs installent dans leurs locaux les
éléments logiciels et matériels nécessaires à la connexion.
4
1.4.2. Service Bureau :

Un Service Bureau est un fournisseur de connexion indirect. Les utilisateurs
passent par un service bureau afin d’utiliser une connexion partagée et mutualisée, la
connexion étant alors-dite indirecte.
La principale raison qui conduit à externaliser cette partie de la solution, quand

ce n’est pas la solution de gestion de trésorerie entière, ne réside pas tant dans le coût
moindre que dans la relative complexité dont on s’affranchit. Les Service Bureau
proposent l’hébergement de cette mutualisation, en y associant parfois des services
directement liés tels que des convertisseurs de formats ou des outils de rapport.
1.4.3. Interface Web Alliance lite :

Les utilisateurs passent par une interface web accessible via l’internet et un
serveur web situé chez SWIFT : cette dernière solution s’appelle Alliance Lite.
Alliance Lite est destinée à des utilisateurs ayant des volumes limités, une
organisation et des problématiques d’intégration simples. La majorité des nouveaux
utilisateurs de SWIFT ont opté pour cette solution, cette part de marché se retrouvant
plus ou moins chez les entreprises, ce qui confirme le besoin d’une solution simple,
accessible via l’internet, surtout dans les pays où il n’y a pas de Service Bureau.
1.5. Les services de messagerie SWIFTNet :
Les organisations de services financiers ont des besoins de messagerie de plus

en plus complexes et divers, qu'il s'agisse de communiquer avec les infrastructures de
marché, avec les correspondants ou avec les clients commerciaux. Pour cela SWIFT
Propose plusieurs services de messagerie [2].
1.5.1. FIN :
FIN est le service de messagerie le plus ancien. Il permet l'échange de
messages formatés avec les standards MT SWIFT traditionnels. Ces standards
couvrent une large variété de domaines d'activité et sont largement utilisés et acceptés
par la communauté financière.
5
FIN permet l'échange de messages sur la base d'un message à la fois et prend
en charge l'échange de formats internes entre les infrastructures de marché et leurs
clients. Il fonctionne également en mode différé et offre des fonctionnalités étendues,
comme la copie des messages, les transmissions à des groupes d'autres utilisateurs
et la récupération en ligne des messages échangés auparavant [2].
1.5.2. FileAct :
FileAct permet le transfert de fichiers. Il est généralement utilisé pour transférer
des lots importants de messages, comme des fichiers de paiements en gros, de très
gros rapports ou des données opérationnelles [2].
1.5.3. InterAct :
Comme FIN, InterAct permet l'échange de messages sur la base d'un message
à la fois et prend en charge l'échange de formats internes entre les infrastructures de
marché et leurs clients. En outre, InterAct offre plus de flexibilité, notamment la
messagerie en mode différé, la messagerie en temps réel et des options de requête et
de réponse en temps réel. Le service InterAct permet d'échanger les types de
messages MX, qui sont exprimés dans la syntaxe flexible XML et développés
conformément à la méthodologie du standard ISO 20022, beaucoup d'entre eux ayant
déjà été publiés comme définitions du standard ISO 20022 [2].
1.5.4. Browse :
Browse est un service de navigation sur le réseau SWIFTNet permettant aux
utilisateurs de naviguer sur les portails financiers en ligne mis à disposition par les
institutions financières et les infrastructures de marché sur SWIFTNet. Il combine la
convivialité de la technologie Web avec les fonctionnalités de sécurité offertes par
SWIFTNet (il permet aux banques de porter leurs applications web dans un
environnement sécurisé et fiable).
SWIFT propose WebAccess comme solution avec laquelle les utilisateurs

peuvent naviguer de façon sécurisée sur les sites Web financiers disponibles sur
SWIFTNet utilisant des technologies et des protocoles Internet standards [3].
6
1.6. Standardisation :
Étant donné que SWIFT joue un rôle important et sensible par rapport la
communauté financière aujourd’hui, la création des messages doit être donc soumise
à un ensemble de règles, pour cela, SWIFT a créé SWIFT Standards qui définit des
règles et des conseils sur les meilleures pratiques sur la façon dont les normes doivent
être déployées pour répondre aux besoins d’échanges ou pour se conformer à la
réglementation.
SWIFT a utilisé dès le début sa syntaxe propriétaire FIN qui est les messages
MT (ISO 15022), ensuite elle a adopté la modélisation UML, et la syntaxe XML adaptée
aux échanges inter-applications. Les standards XML concernent les paiements entre
banques et entre les entreprises et les banques, dans le deuxième cas, outre des
banques, des trésoriers des entreprises et des éditeurs de logiciels ont validé ce
standard [2].
1.6.1. Types et structure des messages SWIFT MT :

Parmi les normes de message importantes gérées par SWIFT Standards, la
norme SWIFT MT est utilisée pour les paiements internationaux, la gestion de
trésorerie, le financement du commerce et les activités de trésorerie. Il existe trois
types de messages SWIFT MT [4] : un « User-to-User Message », un « System
Message » ou un « Service Message », les messages de type « User-to-User » sont
utilisés entre deux institutions financières pour effectuer des transactions financières
et sont classés en 9 catégories numérotés de 1 à 9. Un « System Message » est
envoyé par un système SWIFT à un utilisateur ou vice versa, les messages système
sont classé dans la catégorie 0. Les « Service Messages », (appelés aussi « Control
Messages »), se rapportent soit à des commandes système telles que LOGIN,
SELECT, QUIT, ou à l’accusé de réception du message. SWIFT Standards gère aussi
le processus de maintenance annuel pour MT, qui garantit que la norme évolue pour
répondre aux besoins changeants du marché.
Un message SWIFT contient au maximum 5 blocs dont deux sont optionnels

sous le format suivant [5] :
{{1: BASIC HEADER BLOCK} {2: APPLICATION HEADER BLOCK} {3: USER
HEADER BLOCK} {4: TEXT BLOCK} {5: TRAILER BLOCK}}
7
Figure 1.1 : Structure d'un message MT.
• Basic Header Block : ce bloc contient des informations sur la source du

message (l’adresse logique du terminal de la source du message), ainsi que le
numéro de session et un numéro séquentiel.
• Application Header Block : contient des informations sur le type du message, la
destination (l’adresse logique du terminal de la destination du message), le
numéro de session, un numéro séquentiel, la date et l’heure de la transaction.
• User Header Block : ce champ est optionnel, il contient des sous-blocs avec
des instructions de traitement optionnelles.
• Text Block : ou le corps du message, il contient le message texte sous forme
de champs ou de sous-champs, il fait référence au message MT (Message
Type).
• Trailer Block : ou « Message Terminator », il se compose de sous-blocs et peut
contenir une « Checksum » ou un « Message Authentication Code » pour
assurer l’intégrité du message, ce bloc est optionnel à savoir le type du
message ou l’application avec laquelle le message a été envoyé/reçu, les
informations contenues dans ce block étaient d’une valeur considérable à
l’époque du Telex pour marquer la fin de la transmission du message et ainsi
rassurer le récepteur qu’il a reçu l’instruction complète.
8
• Le réseau SWIFT peut joindre un autre champ supplémentaire « ‘S’ - System

Trailerblock »
Le message MT se trouvant dans le bloc 4 précise l’objet et la structure du

message, il s’écrit sous la forme « MTxxx » où le premier chiffre spécifie la catégorie,
le deuxième spécifie le groupe, et le dernier spécifie le type du message. On distingue
9 différentes catégories en fonction du métier pour lequel ils sont utilisés [8]:
• Catégorie 1 (MT1xx) : paiements pour le compte de donneurs d’ordres ou

bénéficiaires non bancaires et messages connexes.
• Catégorie 2 (MT2xx) : paiements entre établissements bancaires et messages
connexes.
• Catégorie 3 (MT3xx) : marchés de change, de taux et monétaires et messages
connexes.
• Catégorie 3 (MT3xx) : marchés de change, de taux et monétaires et messages
connexes.
• Catégorie 4 (MT4xx) : encaissements, lettres de crédit et messages connexes.
• Catégorie 5 (MT5xx) : opérations sur titres et messages connexes.
• Catégorie 6 (MT6xx) : matières premières, syndication et messages connexes.
• Catégorie 7 (MT7xx) : crédits documentaires, garanties et messages connexes.
• Catégorie 8 (MT8xx) : chèques de voyage et messages connexes.
• Catégorie 9 (MT9xx) : information sur les comptes et messages connexes.
Les messages SWIFT MT pertinents pour les transactions de paiement sont

MT1xx, MT2xx et MT9xx.
1.6.2. Types et structure des messages SWIFT MX :

En 2018, la communauté financière mondiale s’est mis d’accord pour la
migration du standard FIN (MT) vers la norme ISO 20022 avec le format XML dans les
messages MX. Sous contrat avec ISO, SWIFT Standards maintient la norme de
messagerie ouverte ISO 20022 qui s'applique à tous les processus du secteur
financier. La ISO 20022 est une méthodologie pour la création de normes de
messagerie financière et d'un corps de contenu connexe, elle définit les termes
industriels courants et les messages traitant d'un éventail croissant de domaines
d'activité : les paiements, le Cash Management, la trésorerie, les cartes et les titres [6].
9
Ce format est plus simple à traiter pour un système informatique vu qu’il est
basé sur les messages structurés XML. La ISO 20022 a classé les messages sous
plusieurs types notamment [7] :
• Initiation des paiements (Payment initiation - PAIN).

• Compensation et règlement des paiements (Payment Clearing and
Settlement - PACS).
• Avis de versement de paiements (Payments Remittance Advice - REMT).
• Gestion de trésorerie (Cash management - CAMT).
• Gestion de compte (Account management - ACMT).
• Trésorerie (Treasury - TERA).
• Suivi des transactions commerciales (Tracking Business Transactions -
TRCK).
Les messages relatifs aux opérations de paiement sont PACS, PAIN et CAMT.
Un identifiant de message MX s’écrit sous la forme TYPE.XXX.YYY.ZZ et est

composé de quatre parties : le type du message (ou le domaine : PAIN, CAMT, ACMT
etc.), XXX étant le numéro du message dans le domaine (Message
Identifier/functionnality), YYY est la variante du message (l’identification d’un sous-
ensemble d’un message défini pour un usage particulier), et ZZ est le numéro de
version [8].
L'adoption du format MX sera progressive et dépendra des pays ou des régions.

Dans l'Union européenne, les paiements de grande valeur dans les régions entrant
dans le réseau SWIFT, Target2 (système de paiement à règlement brut en temps réel
en Euro) et quelques autres dans le champ d'application seront d'abord transférés en
novembre 2022. La Réserve fédérale américaine effectuera la transition en novembre
2023. Les deux formats coexistent jusqu'en 2025 (date limite fixée par SWIFT), et la
plupart des messages MT ne seront alors plus autorisés [9].
1.7. Conclusion :
Dans ce premier chapitre nous avons pu définir le réseau SWIFTNet et les

applications communiquant dans ce réseau tout en mettant en avant les messages
échangés entre ces applications durant une transaction.
10
Dans le prochain chapitre nous aborderons l’aspect sécurité par rapport à ces
systèmes ainsi que les mesures mises en place par SWIFT pour assurer une sécurité
robuste.
11
Chapitre 2 La sécurité autour des applications SWIFT
2. La sécurité autour des

applications SWIFT
2.1. Introduction :
Considérant les différentes menaces auxquelles fait face le secteur financier, le

réseau SWIFT est sans doute l’une des principales cibles. Le danger auquel fait face
ce réseau est illustré par de multiples attaques médiatisées résultant de colossales
pertes financières.
Dans ce chapitre nous allons visionner l’importance accordée à la sécurité des

transactions SWIFT par les utilisateurs et SWIFT elle-même afin de détecter et
prévenir les menaces auxquelles ce réseau a fait face ces dernières années.
2.2. Sécurité de la messagerie SWIFT :
Les services de messagerie de SWIFT sont fournis au sein de l'environnement

SWIFT, qui inclut tous les locaux, l'infrastructure, les logiciels, les produits et les
services détenus et exploités directement (et contrôlés) par SWIFT et son personnel.
L'environnement SWIFT applique des protections strictes de sécurité, de
confidentialité et d'intégrité aux messages des clients.
Des contrôles et des procédures ont été mis en place pour protéger les données
des messages contre toute divulgation non autorisée, pour garantir l'origine des
messages, pour protéger les messages contre toute modification non autorisée et pour
détecter toute altération des messages ; des fonctionnalités de validation des
messages peuvent en outre être utilisées pour garantir que seuls les messages validés
sont traités et remis dans l'ordre pertinent au destinataire prévu [10].
12
2.2.1. Confidentialité :
Afin de protéger la confidentialité des données des clients, l’accès à ces
derniers est protégé par des mesures de sécurité physique et logique adapté à la
criticité de l’information protégée. Ajoutons à cela que ces données sont cryptées
lorsqu’elles sont stockées sur les systèmes SWIFT ou lors de leur transfert.
2.2.2. Intégrité :
Des clés publiques spécifiques à SWIFT, des certificats numériques et des
signatures numériques sont utilisés à la fois pour authentifier les expéditeurs et pour
valider l'intégrité des messages envoyés. SWIFT vérifie les signatures pour confirmer
l'intégrité des messages et valide les certificats pour authentifier les expéditeurs [10].
SWIFT s'assure que les messages sont remis au destinataire prévu dans l'ordre
approprié et fournit une sécurité de bout en bout, permettant aux expéditeurs
d'appliquer des signatures pour leurs destinataires, et aux destinataires de vérifier
l'intégrité des messages et d'authentifier les expéditeurs [10].
2.2.3. Disponibilité :
Plusieurs centres d’exploitations sont gérés par SWIFT, éliminant tous points
de défaillance et assurant une redondance des sites et une disponibilité des services
de messagerie 24 heures sur 24 et 365 jours par an.
En 2014, le centre d'exploitation de pointe de SWIFT en Suisse est devenu

entièrement opérationnel. Cette nouvelle installation informatique a la capacité de
prendre en charge un flux de messagerie global. SWIFT a la possibilité ultime de
restaurer la messagerie dans le cas improbable et extrême où toutes les autres
mesures de résilience et sauvegardes seraient inadéquates [10].
2.2.4. Résilience :
Les Infrastructure SWIFT sont conçues, développées et testées afin d’assurer
une disponibilité continue même en cas de perturbation, problème de fonctionnement
ou actes malveillants, ayant comme objectif d’assurer un court temps de récupération.
Même si selon SWIFT, une panne prolongée de ses services de messagerie

est improbable, cette dernière est bien préparée pour le rare cas où ses services soient
13
affectés par un incident. Des tests de continuité d’activités sont effectué régulièrement
couvrant différents scénarios. De plus, des audits internes et externes sont organisés
régulièrement afin d’assurer une résilience des services de la messagerie SWIFT [10].
2.3. SWIFT face aux menaces :
Les attaques contre les systèmes SWIFT ont été très médiatisées au cours de
ces dernières années. Chaque attaque est particulière (malware, vol d’identifiants…)
mais toutes ont entraîné des pertes financières importantes. Parmi les attaques qui
ont fait objet de beaucoup de pertes on compte :
2.3.1. Banque del Austroz en Équateur :

La banque Del Austroz a été victime d’une attaque sur leurs messagerie SWIFT
durant laquelle l’attaquant a pris possession des informations d’identification de la
messagerie d’un opérateur et les a utilisées pour annuler, créer et modifier les
demandes de transfert pour finalement effectuer des virements à partir de plusieurs
comptes totalisant 12 millions de dollars [11].
2.3.2. Banque de Chile en Chili :

Un logiciel malveillant destructeur a été diffusé à la Banque de Chile en mai
2018. Il a semé le chaos, distrayant les défenseurs d'une autre attaque contre les
joyaux de la couronne. Alors que tous les systèmes étaient en panne, des messages
frauduleux ont été envoyés pour 10 000 000 $ [12].
2.3.3. Thien Pong Bank au Vietnam :

En décembre 2015, des attaquants ont utilisé des logiciels malveillants pour
tenter de voler 1 130 000 $ à la Thien Pong Bank. Le logiciel malveillant affectait le
lecteur PDF de Foxit et lui permettait de modifier les déclarations en convertissant le
PDF en XML. Les employés de la banque ont stoppé l'attaque en temps opportun en
raison de l'identification de messages SWIFT suspects [12].
14
2.3.4. The Bank of Bangladesh :

La cyberattaque contre la Bank of Bangladesh (février 2016) a été l'un des
braquages les plus importants et des attaques les plus calculées et les plus
sophistiquées contre les systèmes SWIFT à ce jour. Les enquêtes ont révélé que
l'attaque avait été patiemment exécutée sur une période de près d'une année
complète.
Les attaquants ont eu accès aux systèmes internes de la banque et ont déployé
un logiciel Windows de confiance pour surveiller l'activité des employés. Grâce à cette
prise de position initiale, les attaquants ont pu se déplacer latéralement sur le réseau
interne de la banque à la recherche de systèmes connectés à SWIFT.
Une fois l'accès aux systèmes SWIFT obtenu, les attaquants surveillent le
comportement des employés, volent les informations d'identification des utilisateurs et
déploient des logiciels malveillants spécialement conçus. Le logiciel malveillant ciblait
l'application SWIFT Alliance Access, contournait ses contrôles de sécurité et
supprimait les preuves des messages SWIFT imprimés [13].
2.3.5. Facteurs de compromission :

Après examen de ces attaques très médiatisées, on constate que le principal
facteur de compromission est l’être humain et que la majorité des attaques qui ont
ciblés la plateforme SWIFT proviennent de l’intérieur de la banque. Un autre facteur
important est que la majorité de ces attaques ont été causées par le déploiement d’un
logiciel malveillant sur les systèmes internes de la banque.
2.4. Le programme CSP SWIFT :
En guise de contre-mesure aux cyber menaces dont elle est cible, SWIFT a
introduit le programme de sécurité client (CSP) afin d’aider les clients SWIFT à
sécuriser leur infrastructure SWIFT locale.
2.4.1. Définition du CSP :

Le programme de sécurité client (CSP) est un programme conçu pour aider les
institutions financières à améliorer leur posture de sécurité : il détecte et vise à prévenir
15
les activités frauduleuses grâce à un ensemble de contrôles de sécurité obligatoires,

des initiatives de partage d'informations à l'échelle de la communauté et des fonctions
de sécurité améliorées sur les produits SWIFT. Tous les membres de SWIFT doivent
soumettre une auto-attestation annuelle de conformité aux contrôles décrits dans le
cadre des contrôles de sécurité client (CSCF). SWIFT effectue des inspections
aléatoires de ses membres pour s'assurer qu'ils ont mis en place des contrôles de
sécurité appropriés et signale toute organisation non conforme aux régulateurs du
secteur.
La mise en œuvre de tous les contrôles obligatoires (et consultatifs) spécifiés

par CSP améliorera considérablement la sécurité de l’infrastructure SWIFT locale et
garantira également que tous les clients SWIFT disposent d'une norme de base pour
leur sécurité. Cependant, cela ne doit pas être considéré comme une solution parfaite
pour empêcher de nouvelles attaques.
Dans le document CSP lui-même, il est indiqué que le CSP ne doit pas être
considéré comme une approche exhaustive de la sécurité et qu'il ne remplace pas un
cadre de sécurité et de risque bien structuré. De par sa conception, son objectif est de
fournir une norme de base pour la sécurité de tous les systèmes SWIFT locaux
uniquement. En tant que telles, les méthodologies d'attaque générales peuvent
toujours être appliquées aux systèmes critiques les plus sécurisés [14].
2.4.2. Contrôles CSP SWIFT :

Le CSCF comprend des contrôles de sécurité obligatoires et consultatifs pour
les utilisateurs de SWIFT. Les contrôles évoluent au fil du temps pour lutter contre les
nouvelles menaces et pour mettre en œuvre de nouveaux développements en matière
de cybersécurité. Le CSCF comporte 31 contrôles au total adressent principalement 3
thèmes qui s'appuient sur huit principes de sécurité. Au sein de chaque objectif, les
principes associés couvrent les domaines d'intervention les plus importants [15].
Le tableau 2.1 suivant présente les objectifs et les principes de CSCF pour aider
les utilisateurs à sécuriser leurs systèmes :
16
La sécurisation de 1. Restreindre l'accès à Internet.

l’environnement 2. Séparer les systèmes critiques de l'environnement
informatique informatique général.
3. Réduire la surface d'attaque et les vulnérabilités.
4. Sécuriser physiquement l'environnement.
Connaître et limiter 5. Empêcher la compromission des informations
l’accès d'identification.
6. Gérer les identités et séparer les privilèges.
Détecter et réagir 7. Détecter les activités anormales dans les enregistrements
système/transaction.
8. Planifier la réponse aux incidents.
Tableau 2.1 : Objectifs, principes et contrôles du CSP.
2.4.3. Types d’architectures :

Les membres de SWIFT doivent attester de leur niveau de conformité aux
contrôles obligatoires applicables à leur type d'architecture comme spécifié dans le
CSCF.
Chaque utilisateur doit déterminer lequel des types d’architecture de référence

ressemble le plus à son propre déploiement d’architecture pour déterminer quels
composants sont visés. Selon le type d’architecture, certains contrôles de sécurité
peuvent ou non s’appliquer. CSCFv2020 propose 4 architectures (A1, A2, A3 et B), la
nouvelle version CSCFv2021 a introduit un nouveau type d'architecture (A4) [15].
Figure 2.1 : Type des architectures proposées par CSP (v2020).
2.4.3.1. Architecture A1 :
Ce type d’architecture inclut également des solutions hébergées quand

l’utilisateur est propriétaire (détient la licence) de l’interface de communication qu’il
utilise ou qui est utilisée pour lui ou pour un autre/d’autre utilisateur(s). L’interface de
17
communication est la propriété et se trouve à l’intérieur de l’environnement de

l’utilisateur. Dans le cas où les utilisateurs n’utilisent pas ou ne détiennent pas
d’interface de messagerie mais une interface de communication, on les considère tout
de même comme une architecture A1 [15].
L’interface de messagerie se trouve dans l’environnement de l’utilisateur, mais

c’est un fournisseur de services (par exemple, un service bureau, SWIFT Alliance
Remote Gateway ou un hub de groupe) qui détient la licence pour l’interface de
communication et qui la gère. Ce type d’architecture inclut également les solutions
hébergées de l’interface de messagerie lorsque l’utilisateur détient une licence pour
l’interface de messagerie [15].
Un logiciel (par exemple, Alliance Lite2 AutoClient, Direct Link ou une solution
de transfert de fichiers) est utilisé dans l’environnement de l’utilisateur pour faciliter la
communication entre les applications avec une interface fournie par un fournisseur de
services (par exemple, un service bureau, Alliance Lite2, un hub de groupe).
Éventuellement, cette configuration peut être utilisée en combinaison avec une
solution GUI (d’utilisateur à application) [15].
2.4.3.4. Architecture B :
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 [15]:
• Les utilisateurs accèdent aux services SWIFT exclusivement via une

application GUI fournie par le fournisseur de services (d’utilisateur à
application). Le PC ou l’appareil utilisé par ces utilisateurs doit être considéré
comme un PC opérateur (à usage général) et protégé en conséquence.
• Les applications métier des utilisateurs communiquent directement avec le
fournisseur de services (d’application à application) en utilisant un produit
middleware (par exemple, IBM MQ ou similaire) ou des API fournies par le
fournisseur de services. La classification de cette configuration comme une
architecture de type B coïncide avec le périmètre des mesures de sécurité
18
dont sont exclues les applications back office et middleware. Toutefois,

SWIFT recommande vivement l’application des mesures pour l’architecture
de type A3 sur ces applications middleware et API.
2.5. Conclusion :
Dans ce chapitre nous avons pu comprendre l’importance des pertes

engendrées par les attaques subies par le réseau SWIFT ces dernières années. Ainsi,
nous avons pu mettre en avant les mesures mises en place par l’organisation SWIFT
pour prévenir de ces menaces.
Dans le prochain chapitre nous allons découvrir une des mesures les plus
essentielles pour la détection des comportement anormaux sur différents types de
systèmes.
19
Chapitre 3 Le centre opérationnel de sécurité
3. Le centre opérationnel de
sécurité (SOC)
3.1. Introduction :
La sécurité des systèmes d’information dans une organisation repose

essentiellement sur l’effort fourni par le management pour la mise en œuvre des
ressources nécessaires afin d’assurer une surveillance opérationnelle de ces
systèmes. De ce fait, la mise en place d’un SOC au sein d’une organisation prouve la
maturité de cette dernière et l’importance accordée à l’aspect sécurité de ses
systèmes.
Dans ce chapitre nous allons définir le Centre Opérationnelle de Sécurité,

illustrer ces différents composants et sa structure et mettre en avant son rôle dans le
maintien d’une sécurité opérationnelle au sein d’une entreprise.
3.2. Définition du SOC :
Un centre opérationnel de sécurité (SOC) est une fonction centralisée de cyber

activités de défense au sein d'un organisme, c’est une collaboration d’un ensemble de
ressources humaines, de solutions (technologies) et de processus visant à surveiller
l’état d’un système, prévenir, détecter, évaluer et qualifier les évènements de sécurité.
Cette entité organisée assure le pilotage des réponses appropriées aux incidents de
sécurité et aux cybers-menaces et garantit la conformité des SI par rapport aux
normes, standards et règlementations [16].
Compte tenu de toutes ses responsabilités, le SOC doit offrir un moyen qui
signale les incidents suspects, fournir de l’aide pour traiter ces incidents et avoir les
compétences et les ressources nécessaires pour effectuer des investigations
approfondies et détaillées sur les systèmes compromis pour déterminer la nature de
l’incident.
20
Un bon SOC est celui qui intervient contre toute action visant à influer sur la
disponibilité, la confidentialité et l’intégrité des atouts de l’entreprise, il rend les
systèmes plus résilients aux impacts, et détecte et élimine les capacités adverses.
3.3. Missions du SOC :
• La surveillance, la détection, et l’analyse des intrusions potentielles en temps

réel.
• La prévention des incidents de sécurité grâce à une approche proactive :
l’analyse continue des menaces, le scan des réseaux et des vulnérabilités, la
mise en place des politiques de sécurité etc.
• La fourniture des prises de conscience de la situation (SA) et des rapports sur
l’état de la cybersécurité, les incidents et les tendances en matière de
comportement d’adversaire à l’équipage approprié.
• L’exploitation des technologies de défense telles que les IDS et les systèmes
d’analyse de données [17].
3.4. Processus d’un SOC :
Selon le « SOC Framework » de l’OWASP, les processus d’un SOC peuvent

être classés dans plusieurs catégories en fonction de la tâche effectuée [18] :
3.4.1. La surveillance et la détection :

Cette phase est divisée en 6 sous-étapes : l’identification, la corrélation,
l’agrégation, la rétention, le scan et la surveillance, elle inclut l’analyse des Logs,
l’analyse du le trafic réseau, l’analyse des utilisateurs identifiés…, pour pouvoir extraire
des informations indiquant la présence probable d’une activité suspecte sur son
système.
1. L’identification : en collectant les journaux des évènements de tous les actifs et

les applications (bases de données, programmes et applications, systèmes
d’exploitation, pares-feux, les Points et les EndPoints etc.).
21
2. La corrélation : l’objectif de cette étape est de suivre l’incident et extraire les

différents motifs comportementaux comme l’horodatage de l’incident et la
synchronisation entre les différents actifs.
3. L’agrégation : consiste à limiter les données à traiter et à les normaliser, tout en
préservant l’intégrité des données.
4. La rétention des données à analyser, et les archiver pour effectuer des
investigations afin de les comparer aux exigences de la conformité.
5. Le scan du réseau et des vulnérabilités, la reconnaissance passive, suivi par la
corrélation les événements relatifs aux services vulnérables.
6. La surveillance en temps réel des flux réseaux, du périmètre, de la configuration,
la surveillance des changements touchant les fichiers critiques, l’utilisation des
privilèges, les IDS et les IPS etc.
3.4.2. Réponse aux incidents :

1. Les alertes : en cas d’incident, il est nécessaire que l’équipe de défense agisse
rapidement afin de réduire l’impact de cet incident et le contourner.
2. La gestion des incidents : le processus de gestion des incidents ne peut pas être
improvisée, il est donc nécessaire de mettre en place un plan de gestion des
incidents structuré afin de concilier efficacité et rapidité, tout en conservant une
démarche d’amélioration continue :
• La détection : la détection vise à identifier quel évènement suspect a été
généré et quand, les outils de gestion des logs, le SIEM, les IDS/IPS ou les
antivirus aident le personnel de sécurité d’en savoir plus sur ces intrusions de
différentes manières, à savoir la reconnaissance de signature ou la détection
d’anomalies. Une intrusion possible est une traduction d’un ensemble de :
 Indicateurs de compromission (IoC) : sont des indices ou des preuves d’un
objet ou d’une activité identifiée sur le réseau ou sur un hôte, qui
fournissent des informations précieuses sur les systèmes compromis, par
exemple un trafic réseau inhabituel qui pourrait être une attaque DDoS ou
une connexion à serveur C&C, ou des activités irrégulières par des
comptes d'utilisateurs privilégiés sur des données sensibles, ou des
modifications des valeurs des clés de registre [19].
22
 Indicateurs d’attaque (IoA) : est toute preuve numérique ou physique

qu'une cyberattaque est susceptible de se produire, contrairement aux
indicateurs de compromission qui sont preuves qu'un incident s'est produit.
Les méthodes de détection IoA visent à détecter l’activité malicieuse au fur
et à mesure qu'un attaquant progresse dans le cycle de vie de l’attaque,
en d'autres termes, les IoA sont détectés avant les violations de données.
 Tactiques, Techniques et Procédures (TTPs) : MITRE a implémenté une
base de connaissances sur les tactiques et les techniques de l'adversaire,
basée sur des observations du monde réel, la tactique est le but ou l'objectif
de l'adversaire, la technique est la façon dont l'adversaire atteint le but ou
l'objectif, et la procédure est la façon dont la technique est exécutée [20].
• L’analyse : l’analyse est soumise à une contrainte temporelle, car son but est
de recommander une action à mener afin de limiter l’impact de l’attaque et
restaurer le fonctionnement correct du système.
• La priorisation : selon les impacts sur le système compromis, les incidents
seront classés par ordre de priorité, par exemple, les incidents de niveau 1
causent des impacts graves et sont jugés critiques.
• La réponse : sert à effectuer des actions selon l’analyse précédente et la
priorité affectée à cet incident.
• Le confinement : dès qu'un risque potentiellement grave est mis en évidence,
l’isolation de l’incident doit être la 1ère action à faire afin qu’il ne se propage pas
et cause d’autres dommages suivant des stratégies de confinement à court
terme ou à long terme.
• L’éradication : c’est l’élimination de la cause principale de l’incident, si le
système est infecté par un malware par exemple, l’action corrective est donc
la suppression de ce malware.
• La reprise : est de restaurer une version fonctionnelle du système à partir d’une
sauvegarde précédente et sûre, tout en soulignant la nécessité de préserver
les preuves de l’incident.
• Les investigations : ce processus permet de découvrir la vérité d’un incident et
la chronologie des évènements, de collecter, prendre une copie et stocker les
preuves, le résultat d’une analyse forensique peut être utilisé pour des
poursuites judiciaires en cas de besoin.
23
3. Les métriques : sont les indicateurs clés de performance (KPIs), les accords de
niveau de service (SLA), le temps moyen de détection (MTTD) ou le temps moyen
de résolution (MTTR), ces statistiques peuvent être obtenues à partir du temps
de réponse, ou le nombre des incidents ou des faux positifs.
3.4.3. Les renseignements sur les menaces :

1. La chasse aux menaces : c’est une approche proactive permettant d'identifier
les menaces inconnues, ou des menaces déjà présentes dans le réseau d'une
organisation, ça consiste à rechercher de manière itérative dans les réseaux
pour détecter des indicateurs de compromission, les TTPs, et des menaces
telles que les APT qui échappent au système de sécurité existant [21].
Les activités de chasse aux menaces comprennent :
• La chasse aux menaces internes ou aux attaquants externes.
• La recherche proactive des adversaires connus.
• La recherche de menaces cachées pour empêcher l'attaque de se produire.
• L’exécution du plan d'intervention en cas d'incident.
2. La collection des renseignements et la gestion des vulnérabilités : elles aident à
prendre des décisions sur la manière de répondre à ces menaces et sur les
mesures de protection à prendre après avoir acquéri une connaissance détaillée
des menaces.
3.5. Les rôles et les responsabilités du SOC :
Même si le SOC s'appuie fortement sur la technologie automatisée, l'élément

humain reste un élément crucial. Dans une organisation, un bon nombre de rôles
peuvent appartenir à d'autres équipes en dehors du SOC, le SOC peut tirer parti de
ces ressources. L’affectation des rôles se résume aux services et aux niveaux de
service que le SOC fournira.
Les analystes de sécurité : les analystes sont généralement au cœur de tout

SOC et peuvent fournir une variété de services tel que la surveillance des événements
de sécurité, l'enquête sur les rapports d'incident, traitement, renseignements sur les
menaces, renseignements sur les vulnérabilités et la génération des rapports. Dans la
plupart des SOC, ces derniers sont organisés en niveaux avec des niveaux d’analystes
24
juniors fournissant une analyse initiale ou un tri et des niveaux supérieurs offrant des
capacités plus avancées, telles que l’investigation et l’analyse des malwares [17].
Le responsable du SOC (SOC Manager) : il directeurs ou les chefs d'équipe

assurent la direction des équipes au sein du SOC, normalement alignées sur des
ensembles de services communs. C’est un cadre de haut niveau qui dirige les équipes
SOC, et gère les ressources, les priorités et les projets de sécurité de l'entreprise [22].
Les rôles d’ingénieurs : sont généralement responsables des tests, de la mise

en scène et du déploiement des nouvelles plates-formes technologiques ou les
versions/mises à jour majeures de ces plates-formes. Ils ont tendance à être plus axés
sur les projets que les autres rôles au sein du SOC et ont tendance à développer des
compétences approfondies dans des plates-formes technologiques particulières [23].
Les rôles opérationnels : alors que les ingénieurs SOC ont tendance à se
concentrer sur de nouveaux projets, les opérateurs SOC passent leur temps à
maintenir et exploiter les plates-formes SOC actuellement déployées. Contrairement
aux ingénieurs SOC, les opérateurs SOC se concentrent sur le maintien de la
disponibilité et de la stabilité des plates-formes existantes, et fournissent généralement
une couverture correspondant aux niveaux de service attendus au sein du SOC [23].
Autres rôles de support : la plupart des SOC ont un grand nombre d'autres
rôles de support, dont : Les chefs de projet, coordination et soutien de la planification
de la continuité des activités / de la reprise après sinistre, support de conformité et
d’audit, gestionnaires d'incidents et de problèmes, développeurs de
processus/procédure, spécialistes de la formation, spécialistes en communication,
gestion des fournisseurs et des contrats [23].
3.6. Technologies du SOC :
Le SOC utilise plusieurs technologies afin de satisfaire ses besoins, il n’y a pas
d’outil unique qui « fera tout », chaque outil a ses points forts, mais chacun a aussi ses
limites. Les outils SIEM, les IDS ou les IPS sont de bons exemples de ces outils.
25
3.6.1. Le SIEM :
Une solution de gestion de l'information et des événements de sécurité (ou
SIEM) est un logiciel qui améliore la détection des menaces, la conformité et la gestion
des incidents de sécurité grâce à la collecte, l’agrégation, le filtrage, le stockage, le tri,
la corrélation et l'analyse de données et de sources d'événements de sécurité
historiques et en temps réel.
Un SIEM collecte et combine des données provenant de différentes sources

d'événements à travers un Framework de sécurité d'une organisation, y compris les
systèmes hôtes, les réseaux, les pare-feux, les antivirus… Il effectue une analyse des
données collectées sur les actifs des terminaux, du réseau et du cloud par rapport aux
règles de sécurité et aux analyses avancées pour identifier les problèmes de sécurité
potentiels au sein d'une entreprise [24].
En tirant parti d’une architecture et d’un ensemble de fonctionnalités robustes

et évolutives, le SIEM prend en charge un certain nombre de cas d’utilisation
convaincants.
3.6.1.1. Les cas d’utilisation :
La corrélation des événements de sécurité est la forme d'analyse de données

la plus connue et la plus utilisée, elle fait référence à la tâche de créer un contexte
dans lequel révéler des relations entre des événements disparates reçues de diverses
sources dans le but d'identifier et de signaler les menaces. Un contexte peut être lié
par le temps, l'heuristique et la valeur des actifs [25].
Afin de détecter les menaces avancées ainsi que les infractions de conformité,
les solutions SIEM offrent un outil très performant, il s’agit des règles de corrélation,
une règle de corrélation est un ensemble de tests utilisé pour établir des liens entre
plusieurs évènements et/ou flux constatés sur le réseau, plusieurs exemples de type
de liens peuvent être cités à ce niveau comme par exemple la fréquence « un ou
plusieurs évènements spécifiques qui se répètent dans le temps » ou le séquencement
des évènements « Une authentification réussie après plusieurs tentatives
d’authentifications échouées ».
Chaque règle de corrélation présente en réalité un ou une partie d’un cas

d’utilisation, ce dernier illustre un scénario de détection d’une menace, une infraction
26
de la politique de l’entreprise, une tâche opérationnelle de sécurité répétitive …, les

entreprises doivent toujours établir les cas d’utilisations relatifs à leurs contexte, mettre
à jour régulièrement ces cas d’utilisation afin de s’adapter avec les changements et
l’évolution des menaces et exigences de conformité, et enfin, il faut qu’elles cherchent
d’une façon continue le développement des nouveaux cas d’utilisation afin de détecter
d’autres scénarios non couvert actuellement par le SIEM.
Les règles de corrélation sont packagées dans les outils SIEM. Les fournisseurs
offrent généralement la possibilité d'effectuer des mises à jour régulières des
ensembles de règles dans le cadre d'un service d'assistance payant. Ces règles
peuvent être ajustées ou créées selon le besoin ; cependant, il est important de
connaître d'abord les cas d'utilisation que l’entreprise cherche à aborder.
3.6.1.2. Les cas d’utilisation par défaut sur un SIEM :
La plupart des règles de corrélation proposées par les fournisseurs SIEM sont
basées sur l'expérience qu'ils acquièrent de leurs bases d'installation et de leurs
équipes de recherche internes, ce qui signifie qu'ils ont très probablement développé
des règles pour les besoins de l’entreprise. Des exemples de règles de corrélation
prêtes à l'emploi incluent le signalement des échecs de connexion excessifs, des
infections par des logiciels malveillants, des connexions sortantes non autorisées et
des tentatives DoS. Il est recommandé de demander au fournisseur SIEM d'analyser
vos scénarios d'entreprise lors d'une preuve de concept afin de valider ses capacités
de corrélation et de création de rapports [25]. Il est des bonnes pratiques d'ajuster les
règles prêtes à l'emploi ou de créer ses propres règles qui répondent aux besoins
d’une entreprise.
3.6.1.3. Formalisation d’un cas d’utilisation :
Les règles de corrélation sont destinées à détecter et à signaler les scénarios

de menace, également appelés cas d'utilisation. Avant de formaliser un cas
d'utilisation, vous souhaitez répondre aux questions suivantes :
• Quelle méthodologie devez-vous utiliser pour élaborer un cas d'utilisation ?
• Pour un cas d'utilisation, quels messages de journalisation devez-vous

collecter et à partir de quels appareils ?
27
• Pouvez-vous répondre aux exigences d'un cas d'utilisation en utilisant les

contrôles de sécurité existants ?
• Quelle est la complexité de la tâche de création ou de réglage des règles de

corrélation ?
• Comment associez-vous les cas d'utilisation à votre programme d'évaluation

des risques ?
• Quelle est la complexité du cas d'utilisation et quel impact aura-t-il sur les
performances de votre outil SIEM ?
• La règle créée pour un cas d'utilisation entraînera-t-elle une augmentation

des faux positifs ?
Le cas d'utilisation exact et votre choix d'outils ont un impact sur la complexité
associée à la création ou à la personnalisation des règles de corrélation. Par exemple,
la création d'une règle qui alerte sur la détection de l'utilisation d'un protocole de
gestion en texte clair tel que Telnet pourrait être simple par rapport à des règles plus
complexes qui impliquent plusieurs sources, messages et périodes. En outre, il est
important de prendre en compte l'impact des performances sur le SIEM à mesure que
vos règles augmentent en taille et en complexité, ainsi que la gestion des fonctions
personnalisées [25].
3.6.1.4. Création d’un cas d’utilisation personnalisé :
Regardons l'exemple de cas d'utilisation pour créer une règle de corrélation qui
déclenche une alerte lorsque le même compte a été utilisé pour se connecter à plus
de dix serveurs de centre de données, suivi par un ou plusieurs de ces serveurs
établissant une ou plusieurs connexions TCP sortantes vers des Adresses IP dans les
5 minutes après les dix tentatives de connexion. L'idée d'utiliser cet exemple est de
démontrer à quel point la création de règles de corrélation peut être complexe pour
des cas d'utilisation qui peuvent sembler simples. Vous pouvez exprimer ce cas
d'utilisation sous la forme d'une instruction imbriquée composée d'une combinaison
d'événements (contenu) et d'opérateurs tels que AND, OR, NOT et FOLLOWED BY
(contexte avec état). Dans ce cas d'utilisation, un contexte n'est rien d'autre qu'un
ensemble arbitraire de paramètres décrivant un événement particulier ou une
séquence d'événements. Cette instruction imbriquée pour répondre à ce cas
d'utilisation est illustrée à la figure 3.1 suivante :
28
Figure 3.1 : Exemple d'une règle de corrélation de haut niveau.
Une fois qu'une instruction personnalisée a été créée, l'étape suivante consiste
à convertir l'instruction en règle en suivant la syntaxe utilisée par l'outil SIEM de votre
choix. Les outils SIEM commerciaux fournissent une interface graphique pour vous
permettre d'accomplir cette tâche. Une alternative consiste à confier la création de
règles à un consultant tiers ou aux services professionnels du fournisseur SIEM. Nous
vous recommandons de vérifier d'abord auprès du fournisseur SIEM qu'il n'existe pas
de règle ou de règles existantes qui répondent à vos besoins avant d'investir du temps
et de l'argent dans la création de règles de corrélation personnalisées.
Malgré le fait qu'un cas d'utilisation puisse sembler simple, le convertir en règle
peut ne pas l'être aussi facilement. Même si vous deviez convertir l'exemple précédent
en une règle de corrélation, qu'en est-il des plus compliquées ? De plus, dans quelle
mesure pouvez-vous développer votre base de règles et quel impact cela aurait-il sur
les performances de votre outil ? Examinons quelques alternatives à la création de
règles basées sur la corrélation [25].
3.6.2. La solution UEBA :

L'analyse du comportement des utilisateurs et des entités (UEBA) est une
technologie de cybersécurité innovante qui utilise des algorithmes d’apprentissage
automatique afin de créer une base de référence concernant les comportements
normaux des utilisateurs au sein de votre réseau. En termes plus simples, il observe
les comportements de chacun.
La capacité UEBA, généralement ajoutée dans un deuxième temps à la

plateforme SIEM, aide les équipes de sécurité à créer des points de référence en
29
appliquant la modélisation du comportement ainsi que l’apprentissage automatique

afin de faire émerger les risques de sécurité [26].
3.6.3. Les solutions de découverte d’actifs :

La découverte d’actifs, aussi appelée répertoire d’actifs, aide à mieux
comprendre quels systèmes et outils sont en cours d’exécution dans l’environnement.
Il permet de déterminer quels sont les systèmes critiques de l’entreprise et comment
prioriser les contrôles de sécurité [17].
3.6.4. Les solutions d’évaluation de vulnérabilité :

Détecter les failles qu’un attaquant peut utiliser pour pénétrer au sein de vos
systèmes est essentiel pour protéger votre environnement. Les équipes de sécurité
doivent rechercher les vulnérabilités des systèmes pour repérer les potentielles
brèches et agir en conséquence. Certaines certifications et réglementations exigent
également des évaluations périodiques de la vulnérabilité pour permettre de valider la
conformité [17].
3.6.5. Les solutions de détection d’intrusion :

Les systèmes de détection d’intrusion (IDS) sont des outils incontournables
permettant aux SOC de détecter les attaques dès les premiers stades. Ils fonctionnent
généralement en identifiant les schémas d’attaque connus à l’aide de signatures
d’intrusion [17].
3.7. Modèles et stratégies d’un SOC :
Selon les exigences de sécurité et le budget, il existe plusieurs modèles à suivre

lors du déploiement d’un SOC [18] :
Le SOC interne : dans ce cas, l’entreprise construit sa propre équipe de

cybersécurité, la création d'un SOC interne minimise le risque de perte de données
critiques de l'organisation. La mise en place d'un SOC interne, robuste et capable de
gérer les menaces, aide l'organisation à développer des capacités et des compétences
qui lui donnent un contrôle total sur la sécurité. Les entreprises qui envisagent d'établir
un SOC interne doivent disposer d'un budget pour assurer la continuité.
30
Le SOC externe : pour de nombreuses organisations, opter pour un SOC

externalisé est une solution beaucoup plus lucrative et efficace. Alors que la création
d'un SOC interne est à forte intensité de capital et nécessite le recrutement et le
renforcement d'une expertise interne substantielle, un SOC externalisé permet à
l'entreprise d'accéder immédiatement aux avantages d'un service mis en œuvre par
des professionnels en tirant parti de l'infrastructure, de l'expérience et des capacités
complètes que le fournisseur de services apporte à la relation.
Le SOC virtuel : l'équipe de sécurité ne dispose pas de ses propres

installations physiques et travaille souvent à distance dans différents endroits.
Le SOC cogéré : le SOC cogéré se compose de personnel SOC interne

travaillant avec un fournisseur de services de sécurité gérés externe.
3.8. Conclusion :
Dans ce chapitre nous avons pu présenter la structure d’un SOC et ses

composants tout en soulignant le rôle des cas d’utilisation et les règles de corrélation
dans le respect des exigences et des objectifs métier de sécurité et de conformité
d’une organisation.
Dans le prochain chapitre de conception nous allons étudier la logique de

fonctionnement de l’application SWIFT selon les journaux collectés au niveau de cette
dernière et identifier par la suite les scénarios de cas d’utilisation dans les cas de
comportements anormaux relatifs à la logique de fonctionnement.
31
Chapitre 4 Conception
4. Conception
4.1. Introduction :
Dans le SOC, La détection des menaces, des infractions de la politique de

l’entreprise ou autres comportements anormaux est assurée par les scénarios de cas
d’utilisation mis en œuvre. Afin de déterminer les scénarios de cas d’utilisation
adéquats pour la détection de ces comportements susceptibles de menacer la sécurité
des transactions SWIFT, nous allons étudier dans ce chapitre les journaux collectés
au niveau d’une application SWIFT et en déduire sa logique de fonctionnement.
4.2. Étude théorique de la logique de fonctionnement des

applications SWIFT :
La préparation des messages passe par plusieurs étapes, le passage du

message d’un état à l’état suivant se fait en fonction du résultat obtenu par certaines
vérifications qui déterminent le prochain traitement du message.
Le traitement se fait selon une fonction de traitement des messages (MPF) qui
sert à :
• Retirer un message de la liste d’entrée.

• Ajouter un message dans une file sortante.
• Traiter un message en fonction d’un objectif fonctionnel.
• Retourner le résultat du traitement au logiciel du routage.
Un événement est enregistré dans le journal des événements chaque fois qu’un
message sera acheminé, supprimé ou déplacé. Cet événement décrit la file d'attente
d'où provient le message, la file d'attente dans laquelle se trouve le message, et quel
opérateur a acheminé le message.
32
4.2.1. Création des messages :

Les utilisateurs créent des messages SWIFT sur l’application de création de
message. Le traitement des messages se fait selon le type, le format, ainsi que
l'autorisation et le routage définis par l'établissement financier pour chaque message.
Un nouveau message créé (lorsqu'il est valide) est mis en file d'attente lorsqu'un
opérateur appelle l'une des commandes pour déplacer ou acheminer le message. Si
l'opérateur utilise la commande "Route", alors le MPF invoque les services du logiciel
de routage pour router le message vers la file d'attente suivante. Si l'opérateur n'utilise
pas la commande "Route", alors le MPF lui-même déplace le message directement
dans la file d'attente sélectionnée par l'opérateur.
4.2.2. Vérification des messages :

L'application Vérification des messages vérifie les champs clés des messages
SWIFT FIN, tels que les dates de valeur, les devises et les montants. Dans la plupart
des cas, un créateur de message ne le vérifie pas. Au lieu de cela, le vérificateur entre
à nouveau les champs clés, qui sont affichés sous forme de blancs. Les ensembles
de champs doivent correspondre pour que le message soit vérifié.
4.2.3. Autorisation des messages :

Les messages SWIFT FIN et système vérifiés sont autorisés à être diffusés par
l'application d'approbation de message, au cours de laquelle une vérification visuelle
est effectuée
4.3. Étude des contrôles opérationnels des transactions du CSP :
Le standard CSP SWIFT expose plusieurs exigences de détection auxquelles

doivent se conformer les utilisateurs. Il a été tiré, à partir des contrôles de ce standard,
des exigences métiers qui seront possiblement détectables par le SOC. Parmi ces
exigences on compte :
33
4.3.1. Contrôle de la valeur la transaction :

Le contrôle 2.9A du référentiel CSP SWIFT concerne le contrôle des
transactions. Une des exigences de ce contrôle est la suivante : “Contrôler les
transactions inhabituelles (par exemple, montants exceptionnellement élevés,
bénéficiaires ou devises inhabituelles)". Selon ce contrôle, les transactions échangées
ne devraient pas dépasser une certaine limite de montant. Le plafond diffère d’une
organisation à une autre, et d’un correspondant à un autre.
Après une étude des besoins des clients d’Intervalle Technologies, le seuil de
transactions sera limité à 5 millions de dollars.
4.3.2. Les heures d’activités normales :

Une autre exigence du contrôle 2.9A : « La soumission et l’approbation des
transactions SWIFT ne sont pas possibles en dehors des activités normales de
l’entreprise ». Les heures de travail diffèrent d’une organisation à une autre tout
comme le weekend.
Après une étude des besoins des clients d’Intervalle Technologies les heures
d’activités normales ont été arrêtées : de 8h à 18h et le weekend le vendredi et samedi.
4.3.3. Séparation des tâches :

Le contrôle 5.1 du référentiel CSP SWIFT souligne l’exigence de s’assurer que
la séparation des tâches est effective « 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 la soumission et approbation des transactions ».
Selon le concept de la séparation des tâches, l’opérateur qui crée la transaction

ne peut pas être celui qui la vérifie, ni celui qui l’autorise.
4.4. Collecte des journaux d’audit de l’application SWIFT

Alliance :
À partir de l’application SWIFT Alliance d’une entreprise financière cliente

d’Intervalle Technologies, les fichiers journaux d’audits ont été extraits et étudiés afin
de pouvoir comprendre le processus de fonctionnement et les différentes étapes
34
parcourues ainsi que les files d’attentes par lesquelles passe un message de
transaction. Ce suivi des messages a été effectué selon un identificateur nommé
« UUMID ».
L’objectif principale de la compréhension de ce processus c’est d’effectuer une

comparaison avec les objectifs métier et les exigences du standard CSP SWIFT vue
précédemment et finalement déterminer les scénarios de comportements anormaux
susceptible de représenter une menace de fraude des transactions SWIFT et
d’implémenter les mesures nécessaires pour la détection de ces scénarios.
4.5. Étude et analyse des logs d’une transaction normale :
Selon les constats émis lors de l’étude des journaux collectés, le processus
déduit est montré dans le schéma suivant :
Figure 4.1 : Journalisation d’une transaction normale.
4.5.1. Création du message :

Par défaut, un message financier SWIFT créé avec succès est acheminé vers
la file d'attente de vérification _MP_verification en produisant un Log de type Message
35
Received, pour continuer le routage du message, ce dernier doit être vérifié et autorisé,
un message en attente de routage génère un log de type Validation Error. Pour ce fait,
la règle qui sera créée sur le SIEM devra produire une alerte lorsqu’un message est
reçu par la file _MP_authorisation à partir d’une autre file que MP_verification.
Lorsqu’un message qui nécessite une modification de données, ou ayant une

ou plusieurs erreurs syntaxiques, il sera enfilé dans _MP_mod_text.
4.5.2. Vérification des messages :

Les messages FIN créés par un opérateur via l'application de création de
messages ou les messages corrigés manuellement via l’application de modification
seront en attente de vérification et sont conservés dans la file d'attente de vérification
des messages (_MP_verification) et génèrent un Log de premier routage de type
Message Routed avec une destination _MP_verification.
Cette file contient également les messages SWIFT reçus de l'interface

d'application, si le partenaire de message n'a pas l'autorisation de bypasser la
vérification.
Par défaut, si le message a été traité (vérifié) avec succès et est valide, il sera
acheminé vers la file _MP_authorisation et produit un Log de deuxième routage de
type Message Routed ayant comme source _MP_verification et comme destination
_MP_authorisation.
Lorsqu’un contenu de message erroné est identifié pendant la vérification, il

sera enfilé dans _MP_mod_text en générant un Message Routed.
4.5.3. Autorisation des messages :

La file _MP_authorisation se compose de messages vérifiés par l'application
« Message Approval » , un message en attente d’autorisation est routé de la file de
vérification, il génère un Log de deuxième routage de type Message Routed ayant
comme source _MP_verification et comme destination _MP_authorisation.
Si l’autorisation est exécutée avec succès, le message sera défilé de

_MP_authorisation et routé (3èm routage) vers la file EMBS_IN, un journal Message
Routed ayant comme source _MP_authorisation et comme destination EMBS_IN est
enregistré aux journaux d’évènements.
36
4.5.4. Le traitement (handling) et l’envoi des messages :

Un message valide et routé avec succès passe à la phase « Handling », la file
EMBS_IN génère un événement de type FOFS Information pour indiquer la fin de la
phase de routage, le traitement du message est journalisé comme Message Handling,
à la fin le message sera envoyé en produisant un Message Sent.
4.6. Récapitulatifs des menaces et les alertes :
Le schéma 4.2 ci-dessous représente un récapitulatif des scénarios de

menaces identifiées précédemment ainsi que les cas d’alerte qui seront générés par
le SIEM en cas de détections de ces anomalies :
Figure 4.2 : Schéma récapitulatif des cas d'utilisation.
37
4.7. Normalisation et mappage des champs des journaux reçus

par le SIEM :
Les journaux d’audits générés par l’application SWIFT Alliance auront besoin
d’être normalisés et mappés afin que le SIEM puisse les reconnaître et identifier les
différents paramètres, ce qui serait très utile lors de la réalisation de la corrélation.
La normalisation se feras selon le tableau suivant :
Nom Description Catégorie Mappage

des
gravités
Start A session was started HL: Access Error= 7
Session LL: Session Opened Warning= 5
Info= 1,2,3
Message A message was HL: Application
Sent successfully sent LL: Content delivery
Record not A record can’t be found HL: Audit

found LL: Read Activity Failed
Validation A validation error was HL: System

error (from) occurred LL: Error
FOFS FOFS Information HL: Audit

Information LL: Start Activity Succeeded
Message A message was received HL: Application

Received LL: Content delivery
Message A message was routed HL: Application

Routed LL: Content delivery
Message The message is in HL: Audit

handling processing phase LL: General Audit Event
Tableau 4.1 : Normalisation des évènements.
La normalisation se feras à partir du mappage des champs des journaux reçus

selon le tableau suivant :
38
Champ du Champ de l’événement Expression régulière

journal sur QRadar
Date-time Log Source Time Date-time\s*=\s{1}(\d{2}\/\d{2}\/\d{4}
\s\d{2}:\d{2}:\d{2})\s
Name Event ID \sName\s+=\s(.*)\s+Class\s+=
Class Event Category Class\s*=\s(\S*)\s*Number
Application Application Application\s*=\s([\d\w\s\.]*)\sFunction
UUMID UUMID UUMID\s*[:\s]*([\w\d]*)
Operator Username Operator\s*=\s(\S+)\s
Hostname Source Hostname Hostname\s*=\s(\S*)\s*
Filename File Path Filename\s:\s([\S]*)\s
Montant Tranfert_Montant USD([^\s]*,[^\s]*)
EUR([^\s]*,[^\s]*)
Source Queue SWIFT Source Queue routed\sfrom\squeue\s([^\s]*)
Destination SWIFT Destination to\squeue\s([^\s]*)

Queue Queue Target\srouting\spoint\s:\s([^\s]*)
Tableau 4.2 : "Parsing" des champs.
Suite au mappage de ces journaux, un QID seras attribué à chaque type de

journal afin de faciliter l’identification et la création des cas d’utilisation, le tableau 4.3
suivant représente les QID affectés aux différents évènements :
Nom QID
Start Session 1,003,000,002
Message Sent 1,003,000,009
Record not found 1,003,000,012
Validation error (from) 1,003,000,008
Automatic Session Not Started 1,003,000,016
FOFS Information 1,003,000,014
Message Received 1,003,000,015
39
Message Routed 1,003,000,006

Message handling 1,003,000,010
Tableau 4.3 : Affectation des QID aux évènements.
4.8. Identification des scénarios de menace et des cas

d’utilisation :
Suite à l’étude effectuée dans les étapes précédentes, les scénarios de

comportement anormal ainsi que les règles adéquates pour les détecter sont les
suivants :
4.8.1. Scénario 1 : Vérification des messages :

Les messages reçus par la file _MP_authorisation doivent obligatoirement
provenir de la file _MP_verification afin de s'assurer que les messages qui sont prêts
à être autorisés ont été vérifiés et tout autre scénario est suspect.
Pour ce fait, la règle qui serait créée sur le SIEM devrait produire une alerte
lorsqu’un message est reçu par la file _MP_authorisation à partir d’une autre file que
MP_verification.
Règle 1 :
Apply - SWIFT Suspicious Activity-Message not received from Verification Queue on

events which are detected by the Local system
and when the event matches QID is 1,003,000,006, Swift Destination Queue (custom)
is any of _MP_authorisation, Swift Source Queue (custom) is not any of
_MP_verification_
and when any of UUMID (custom) are contained in any of UUMID – AlphaNumeric
4.8.2. Scénario 2 - Autorisation des messages :

Les messages reçus par la file EMBS_IN doivent obligatoirement provenir de la
file _MP_authorisation afin de s'assurer que les messages qui sont prêts à être
envoyés ont été vérifiés et autorisés pour l’envoi et tout autre scénario est suspect.
Pour ce fait, la règle qui serait créée sur le SIEM devra produire une alerte
lorsqu’un message est reçu par la file EMBS_IN à partir d’une autre file que
_MP_authorisation.
40
Règle 2 :
Apply - SWIFT Suspicious Activity-Message not received from Authorisation Queue on

and when the event matches Swift Destination Queue (custom) is any of EMBS_IN,
Swift Source Queue (custom) is not any of _MP_authorisation
and when the event QID is one of the following (1003000006) Message Routed
4.8.3. Scénario 3 - Libération du message :

Les messages FOFS qui sont prêts à être envoyés doivent obligatoirement
provenir de la file EMBS_IN et tout autre scénario est suspect.
Pour ce fait, la règle qui serait créée sur le SIEM devrait produire une alerte
lorsqu’un message FOFS provient d’une autre file que EMBS_IN.
Règle 3 :
Apply - SWIFT Suspicious Activity-Message not received from EMBS on events which
are detected by the Local system
and when the event QID is one of the following (1003000010) Message handling
and when the event matches Payload Matches Regular Expression is not (EMBS\s-
\sMessage\swith\sUUMID\s[^,]*)
4.8.4. Scénario 4 - Montant exceptionnel :

Selon les exigences du contrôle 2.9 du référentiel CSP SWIFT, une transaction
ne doit pas dépasser un certain montant défini comme une limite par l’organisation.
Pour détecter une infraction de cette exigence, une règle de corrélation serait créée
sur le SIEM pour produire une alerte lorsqu’une transaction crée dépasse un montant
considéré comme exceptionnel par l’institut financier.
Règle 4 :
Apply - SWIFT Suspicious Activity- High-Value Transaction on events which are

detected by the Local system
and when the event QID is one of the following (1003000008) Validation error (from)
and when the event matches Transfert_amount (custom) is greater than 5,000,000
41
4.8.5. Scénario 5 - Les heures d’activités normales :

Une autre exigence du contrôle 2.9 du référentiel CSP SWIFT stipule que la
soumission et l’approbation des transactions SWIFT ne sont pas possibles en dehors
des activités normales de l’entreprise, ce qui mènera à la création d’une règle qui
déclencheras une alerte lorsqu’un message seras créé ou autorisé entre avant 8h du
matin et après 18h ou pendant le weekend.
Règle 5 :
Apply - SWIFT Suspicious Activity- Submision Compliance Error CSP SWIFT on

and when the event QID is one of the following (1003000015) Message Received
and when the event matches (DATEFORMAT(devicetime,'H') IN
(0,1,2,3,4,5,6,7,18,19,20, 21,22, 23)) or (DATEFORMAT(devicetime,'EE') IN
('Fri','Sat')) AQL filter query
4.8.6. Scénario 6 - Séparation des tâches :

Le contrôle 5.1 du référentiel CSP SWIFT souligne l’exigence de s’assurer que
la séparation des tâches est effective. Cela signifie que certains rôles ne peuvent pas
être représentés par le même individu, tels que la soumission et l’approbation des
transactions.
Pour cela une règle de corrélation serait créée sur la SIEM pour alerter lorsque
l’opérateur qui a créé le message est le même à vérifier ou à l’autoriser.
Pour réaliser ce contrôle nous assurons la récupération du créateur du message

(operator) dans une liste (SWIFT Messages Creators) à l’occrence d’un évènement
MessageReceived (QID=1,003,000,015) :
Apply - New SWIFT Message Creator Appears on events which are detected by the
Local system
and when the event matches QID is 1,003,000,015
Et la règle suivante sera appliquée à la réception de Message Routed :
42
Règle 6 :
Apply - SWIFT Suspicious Activity- Segregation of Duties Complience Error on events

which are detected by the Local system
and when any of Username are contained in any of Swift Message Creators -
AlphaNumeric
4.8.7. Scénario 7 – Message expiré :

Si une transaction reste dans une file d’attente pour plus d’une quinzène de
jours, une alerte devras être émise du SIEM pour alerter les administrateurs de la
necessité de supprimer ou valider cette dernière. La règle qui correspond à ce cas est
la suivante :
Règle 7 :
Apply - SWIFT Message Expired Alert on events which are detected by the Local
system
and when the event(s) were detected by one or more of System Notification-2 :: poc
and when the event QID is one of the following (38750148) Reference Data Expiry
and when the Event Payload contains from collection : UUMID
4.9. Conclusion :
Dans ce chapitre nous avons effectué une étude sur les journaux de
l’applications SWIFT Alliance pour déterminer la logique de fonctionnement et le
scénario de comportement normal d’un traitement de transaction SWIFT pour
finalement en déduire les scénarios de comportement anormaux à partir desquelles
seront implémentés sur le SIEM, dans le prochain chapitre, les règles de corrélation
adéquates pour la détection de ces scénarios constituant des cas d’utilisation pour
l’organisation du SOC.
43
Chapitre 5 Réalisation et Tests
5. Réalisation et Tests
5.1. Introduction :
Plusieurs scénarios de comportements suspicieux représentant des anomalies

ou des infractions de conformité susceptibles de menacer la sécurité des transactions
SWIFT ont été déduits lors de l’étude effectuée dans le chapitre précédent. Afin de
prévenir ces menaces, il est nécessaire de mettre en place sur le SOC les mesures
de détection de ces menaces, pour cela, nous allons mettre en œuvre, dans ce dernier
chapitre, les cas d’utilisations et les règles de corrélations adéquates sur le SIEM et
les tester avec une simulation de ces scénarios.
5.2. Environnement de travail :
5.2.1. Windows 10 :
Windows 10 est un système d'exploitation propriétaire de la famille Windows
NT développé par Microsoft lancé au public en 2015 [27].
Nos cas d’utilisation implémentés sont indépendants du système d’exploitation

installé sur la machine cliente ou la machine de détection
5.2.2. SWIFT Alliance Access :

Alliance Access est une interface multiplateforme de messagerie SWIFT qui
permet aux banques et aux infrastructures de marché de se connecter à SWIFT. Elle
fournit un guichet unique aux services de messagerie incluant la création des
messages SWIFT FIN, InterAct et FileAct, la vérification, l'autorisation, la modification
et autres [28].
SWIFT Alliance Access 7.0 est utilisée pour générer le fichier « .log », nous
avons récupéré ces journaux d’évènements après avoir effectué un virement pour les
analyser et extraire les différentes informations nécessaires pour le traitement.
44
5.2.3. IBM QRadar :

IBM Security QRadar est une solution créée par « Q1 Labs » au début de ce
siècle comme un moteur de détection d'anomalies de comportement réseau, et
achetée par IBM vers la fin de 2011, IBM l’a transformé en SIEM en ajoutant davantage
de capacités de détection des menaces avec des renseignements sur les menaces,
des capacités d'analyse historiques et en temps réel, des analyses UEBA [29].
L’imprime écran suivant représente la réception des évènements en temps réel

dans le « Log Activity » :
Figure 5.1 : l’interface graphique « Log Activity » de QRadar.
5.2.4. WinCollect :
WinCollect est l’une des nombreuses solutions de collecte d'événements
Windows (DSM), c’est un redirecteur d'événements Syslog utilisé pour transférer les
journaux d’événements à partir de Windows vers QRadar [30].
5.3. Implémentation des règles de corrélation :
Avant de créer les règles de corrélation, nous avons récupéré un échantillon de

logs générés par la machine cliente dans laquelle une application SWIFT Alliance
Access est installée, les évènements sont cités dans le tableau 4.1, l’illustration
suivante est un exemple de journal d’évènement Message Sent :
45
Figure 5.2 : Exemple d’un évènement « Message Sent ».
Les différents types de messages reçus contient les champs communs

suivants :
- Date-time : la date et l’heure de cette journalisation.

- Name : le nom de l’évènement.
- Class : la classe de l’évènement, nous avons noté les classes suivantes :
Backup/Restore, Communication, Data, Message, Network, Operator,
Restart/Stop, Security, Software et System.
- Severity : la gravité indique le niveau de menace.
- Operator : représente l’utilisateur de SWIFT.
- Hostname : le nom de l’hôte.
- Journal text : contient des informations sur le message générant ce journal
d’évènement comme le UUMID qui est l’identifiant unique du message.
5.3.1. Analyse d’une transaction normale :

Un message FIN passe par plusieurs étapes au niveau système avant d’être
envoyé suivant le schéma 4.2 : la création, la validation, le routage, le traitement (ou
le handling), et enfin l’envoi.
L’ensemble des journaux d’évènements générés de l’arrivé jusqu’à l’envoi du

message est illustré dans les figures suivantes :
46
Figure 5.3 : Un évènement "Message Received".
Figure 5.4 : Un évènement "Validation Error".
47
Figure 5.5 : Un évènement "Message Routed" - 1er routage.
Figure 5.6 : Un évènement "Message Routed" - 2em routage.
Figure 5.7 : Un évènement "Message Routed" - 3em routage.
Figure 5.8 : Un évènement "FOFS Information".
48
Figure 5.9 : Un évènement "Message Handling".
Figure 5.10 : Un évènement "Message Sent".
« WinCollect » envoie tous ces journaux à QRadar, ce dernier les affiche

comme des évènements inconnus vu que les évènements de ce type ne sont pas
traités au préalable par QRadar.
Figure 5.11: La réception des Logs par QRadar.
49
Pour permettre au SIEM de classer nos journaux d’évènements, nous devons

spécifier la façon dont ils seront catégorisés, nous affectons à chaque champ de
l’évènement dans QRadar, une partie du Log ou une information déterministe.
5.3.2. Configuration de la source des journaux (Log Source) :

Une source de Logs est une source de données qui crée des journaux
d’événements, nous avons configuré QRadar pour accepter les journaux
d'événements provenant de la source « SWIFT-LOG-SOURCE » qui se trouve sur
notre réseau à l'aide de l'application « QRadar Log Source Management », la
configuration utilisera « WinCollect File Forwarder » comme protocole pour recevoir
les journaux d’événements.
Figure 5.12 : La création du "Log Source".
5.3.3. Traitement des Logs :

Le traitement des Logs garantit que les données des fichiers journaux analysés
seront automatiquement triées en différentes catégories et champs, ce qui permet
50
d'explorer plus facilement les données des journaux. Afin de passer de « Unknown »
à un nom d’évènement précis, nous devons d’abord analyser « parser » les
évènements ensuite les mapper. À la fin de cette opération, QRadar affecte à chaque
évènement un identifiant (QID) qui permet de classer l’évènement et l’utiliser par la
suite pour créer des règles de corrélation.
5.3.3.1. L’analyse (le « Parsing ») :
L’outil « DSM Editor » de QRadar offre la possibilité de remplir les différents

champs d’un évènement à partir du contenu du Log, et de créer d’autres champs si
nécessaire. L’analyse des Logs convertit les journaux textuels en données structurées
pour une meilleure analyse et visualisation. Le « parsing » des Logs se fait dans la
partie « Proprieties » du « DSM Editor », pour chaque champ nous définissons une
expression régulière qui permet de reconnaître la donnée associée au champ choisi.
Par exemple, pour avoir le temps exact d’un l’évènement, nous le récupérons à
partir du champ « Date-time » du Log en utilisant l’expression régulière suivante (tout
en respectant le format dans le Log) :
Date-time\s*=\s{1}(\d{2}\/\d{2}\/\d{4}\s\d{2}:\d{2}:\d{2})\s
La figure suivante montre la donnée récupérée par l’expression régulière, à la

fin de cette étape le statut du Log sera « analysé non mappé » (ou « Parsed but not
Mapped ») :
Figure 5.13 : Le "Parsing" de la date et l'heure d'un évènement dans DSM Editor.
51
De la même manière, il est possible de remplir tous les autres champs tels que
la file source, la file destination, l’identifiant (l’UUMID), l’application, l’hote source etc.
L’imprime écran suivant montre le remplissage du champ « UUMID » :
Figure 5.14 : Le "Parsing" du "UUMID" d'un évènement dans DSM Editor.
Il est à noter que jusqu’à présent aucun QID n’est attribué aux évènements,
ces derniers ne peuvent être utilisés dans aucune règle (ils ne sont pas encore
indexés), ils figurent touours comme des évènements inconnus pour QRadar.
5.3.3.2. Le mappage :
Le mappage des Logs est le processus qui indique la façon de création d’un
enregistrement à partir des messages. Le mappage des Logs se fait dans la partie
« Event Mappings » du « DSM Editor », un enregistrement contient le nom, la
description, les catégories (High Level HL et Low Level LL), la source et la gravité de
l’évènement.
52
L’imprime écran suivant est l’enregistrement de l’évènement Message

Handling :
Figure 5.15 : L’enregistrement de l’évènement "Message Handling".
À la fin de la configuration, chaque évènement possède son propre QID, il

pourrait apparaître dans les résultats de recherche par QID et peut être utilisé à la
création des règles comme illustré sur la figure 5.16 :
53
Figure 5.16 : L'affectation d'un QID au message "Message Handling".
Après l’analyse et le mappage de tous les évènements, nous les avons

récupérés (en appliquant un filtre sur la source des Logs), QRadar a reconnu les
différents noms et les catégories des évènements :
Figure 5.17 : La réception des évènements mappés dans Log Activity.
5.3.4. Création des règles de corrélation

Dans l'intention de localiser les messages, l’UUMID de chaque nouveau
message sera enfilé dans une liste à l’arrivée, et défilé vers la fin du traitement.
54
Pour collecter les UUMID des messages en cours de traitement, nous avons
créé une nouvelle collection « ReferenceSet » appelée « UUMID » :
Figure 5.18 : Création d'une liste "ReferenceSet" des UUMID.
Pour remplir cette liste, nous avons créé la règle suivante qui permet d’effectuer
cette tâche à l’occurrence de chaque évènement de type Message Received (QID =
1,003,000,015) :
Apply - New UUMID Appears on events which are detected by the Local system and
when the event matches QID is 1,003,000,015
Figure 5.19 : L'ajout des UUMID dans la liste "UUMID".
L’UUMID d’un message traité et envoyé sera supprimé de la liste précédente

à l’occurrence d’un évènement Message Sent (QID = 1,003,000,009) du même
message avec la règle suivante :
55
Apply - Message Sent successfully on events which are detected by the Local system
Figure 5.20 : La suppression d'un UUMID.
5.3.4.1. Scénario 1 – contourner la vérification :
La vérification d’un message est exécutée dans la phase de routage à l’arrivée

d’un message Message Routed (1er routage – QID=1,003,000,006) de la file de
modification _MP_mod_text et allant vers _MP_verification, les messages suspects
sont alors ceux qui arrivent à la phase d’autorisation (« destination queue » est
_MP_authorisation) et provenant d’une source autre que la file de vérification, cette
information est indiquée dans le champ « Journal text » (voir la figure 5.6), la règle
permettant de surveiller ce routage est la suivante :
Apply - SWIFT Suspicious Activity-Message not received from Verification Queue on

and when the event matches QID is 1,003,000,006, Swift Destination Queue (custom)
is any of _MP_authorisation, Swift Source Queue (custom) is not any of
_MP_verification_
Figure 5.21 : Règle 1 - contournement de la vérification.
56
5.3.4.2. Scénario 2 – contourner l’autorisation :
L’autorisation d’un message est le 2em routage dans la phase de routage, elle
est exécutée à la réception d’un message Message Routed (QID=1,003,000,006) de
la file de vérification, à la fin de l’autorisation le message est routé vers EMBS_IN,
nous allons vérifier donc les messages ayant comme destination la file EMBS_IN, et
une destination et provenant d’une source autre que la file _MP_authorisation, cette
information est indiquée dans le champ « Journal text » du journal d’évènement (voir
la figure 5.6), nous avons créé la règle suivante pour suivre cet acheminement.
Apply - SWIFT Suspicious Activity-Message not received from Authorisation Queue on

and when the event matches Swift Destination Queue (custom) is any of EMBS_IN,
Swift Source Queue (custom) is not any of _MP_authorisation
Figure 5.22 : Règle 2 - contournement de l'autorisation.
5.3.4.3. Scénario 3 – contournement du routage :
À la fin du routage d’une message, la file EMBS_IN génère un message FOFS

Information pour informer que le message est prêt à traiter (passer à la phase du
handling), le champ « Journal text » dans Message Handling contient une information
sur la source du message (EMBS dans le cas normal), nous avons créé la règle
suivante pour déclencher une alerte pour tout évènement suspect de type Message
Handling provenant d’une autre file que EMBS :
Apply - SWIFT Suspicious Activity-Message not received from EMBS on events which
are detected by the Local system
and when the event QID is one of the following (1003000010) Message handling
57
and when the event matches Payload Matches Regular Expression is not (EMBS\s-
\sMessage\swith\sUUMID\s[^,]*)
La figure suivante montre la création de cette règle à l’aide de l’outil de création

et modification des règles « Rule Wizard » :
Figure 5.23 : Création de la règle de détection de contournement de routage.
Après la création de la règle, nous visons à assurer l’indexation des alertes à

chaque fois qu’une alerte s’est déclenchée comme montré dans la figure suivante :
58
Figure 5.24 : Règle 3 - contournement du routage.
5.3.4.4. Scénario 4 – valeur de transaction relativement élevée :
Ce contrôle a été tiré à partir du programme CSP, parmi les directives

d'application citées dans le point 2.9A qui spécifie des contrôles opérationnels des
transactions. La valeur d’une transaction est indiquée dans le champ 4 « Text block »
d’un message FIN (plus précisément dans le champ :32:), le « Journal Test » du
Message Validation Error (QID=1,003,000,008) contient le corps du message FIN et
donc la valeur de la transaction.
Pour signaler toute valeur qui semble élevée, nous définissons un seuil maximal
qu’une transaction ne doit pas dépasser (5,000,000.00USD ou 5,000,000.00EUR dans
notre cas). Ce contrôle est réalisé à l’aide de la règle suivante :
Apply - SWIFT Suspicious Activity- High-Value Transaction on events which are

detected by the Local system
and when the event QID is one of the following (1003000008) Validation error (from)
and when the event matches Transfert_amount (custom) is greater than 5,000,000
59
Figure 5.25 : Règle 4 - valeur de transaction relativement élevée.
5.3.4.5. Scénario 5 – opération en dehors des heures normales de

service :
Les directives d'application citées dans le point 2.9A exigent que la soumission
et l’approbation des transactions SWIFT soient restreintes en dehors des activités
normales. Chaque institution financière définit son temps de service pour signaler les
opérations effectuées en dehors de ces heures. Nous allons extraire l’heure et la date
des journaux de Message Received (QID=1,003,000,015) pour contrôler la
soumission, et Message Routed (QID=1,003,000,006) pour contrôler l’approbation,
afin de déclencher une alerte en cas de transaction en dehors des heures de services
(les soirs ou bien les weekends).
À la réception de Message Received nous appliquons la règle suivante :
Apply - SWIFT Suspicious Activity- Submision Compliance Error CSP SWIFT on

and when the event QID is one of the following (1003000015) Message Received
(0,1,2,3,4,5,6,7,18,19,20, 21,22, 23)) or (DATEFORMAT(devicetime,'EE') IN
60
Figure 5.26 : Règle 5.1 - opération en dehors des heures normales de service (soumission).
Et la règle suivante sera appliquée à la réception de Message Routed :
Apply - SWIFT Suspicious Activity- Approval Compliance Error CSP SWIFT on events
and when the event matches Swift Source Queue (custom) is any of
_MP_authorisation, Swift Destination Queue (custom) is any of EMBS_IN
(0,1,2,3,4,5,6,7,18,19,20, 21,22,23)) or (DATEFORMAT(devicetime,'EE') IN
Figure 5.27 : Règle 5.2 - opération en dehors des heures normales de service (approbation).
5.3.4.6. Scénario 6 – problème de séparation des tâches :
Le cinquième principe du CSP spécifie les contrôles de gestion des identités et

séparation des privilèges, parmi les directives de mise en œuvre de son 1er contrôle
(contrôle d’accès logique) nous avons noté que les tâches délicates doivent être
séparées, certains rôles ne peuvent pas être représentés par la même personne
comme le créateur et le vérificateur/autorisateur d’une transaction.
61
Pour réaliser ce contrôle nous assurons la récupération du créateur du message

(operator) dans une liste (SWIFT Messages Creators) à l’occrence d’un évènement
Message Received (QID=1,003,000,015) :
Apply - New SWIFT Message Creator Appears on events which are detected by the
Local system
Figure 5.28 : Remplissage de la liste "SWIFT Messages Creators".
Ensuite nous avons créé une règle qui permet de signaler les vérificateurs et
les autorisateurs ayant le même utilisateur (Operator) que les créateurs des
messages :
Apply - SWIFT Suspicious Activity- Segregation of Duties Complience Error on events

and when any of Username are contained in any of Swift Message Creators -
AlphaNumeric
62
Figure 5.29 : Règle 6 – problème de séparation des tâches.
5.3.4.7. Scénario 7 – message expiré :
Certaines institutions financières définissent une durée de vie des transactions,

après l’expiration de la transaction elle sera classée comme suspecte.
À la création d’une nouvelle liste « ReferenceSet », nous sommes invités à

définir un TTL (voir la figure 5.18 page XX), chaque élément qui dépasse ce TTL sera
supprimé automatiquement et nous seront notifiés que cet élément, la source de
journaux « System Notification ::2 poc » est chargée de signaler ce type d’évènements
(Reference Data Expiry – QID=38750148) :
Apply - SWIFT Message Expired Alert on events which are detected by the Local
system
and when the event(s) were detected by one or more of System Notification-2 :: poc
and when the event QID is one of the following (38750148) Reference Data Expiry
and when the Event Payload contains from collection : UUMID
63
Figure 5.30 : Règle 7 – message expiré.
5.3.5. Tests des règles (la détection) :

Pour donner un aperçu du fonctionnement de nos règles de corrélation, nous
allons transmettre des journaux d’évènements de test et analyser la raison de
déclenchement de chaque alerte.
5.3.5.1. Contournement de la vérification, de l’autorisation et de

routage :
Figure 5.31 : Détection d’une tentative de contournement de vérification.
La figure ci-dessus montre l’alerte d’un message reçu non vérifié, l’utilisateur
souhaite autoriser un message sans le vérifier, dans un autre cas similaire, il tente de
router son message sans l’autoriser, une alerte doit être déclenchée quand un
message demande d’être autorisé sans avoir été vérifié, la figure ci-dessous affiche
les évènements et l’alerte de contournement de la vérification associés à ce scénario :
L’évènement « SWIFT Suspicious Activity – Message not received from

Verification Queue » est généré suite à une tentative de routage vers l’autorisation
sans vérification.
64
Les différents détails de l’alerte comme la règle qui a déclenché l’alerte,

l’utilisateur, la source et la destination du message sont affichés dans « Event
Information » comme montré dans la figure suivante :
Figure 5.32 : Détails de l'alerte : vérification contournée.
Dans le cas où un utilisateur tente de router un message sans l’autoriser, une

alerte « SWIFT Suspicious Activity – Message not received from Authorisation
Queue » est générée :
Figure 5.33 : Détection d’une tentative de contournement d'autorisation.
Les détails de l’alerte affirment que le message reçu n’a pas été autorisé (il a
été routé d’une file autre que « _MP_Authorisation » :
Figure 5.34 : Détails de l'alerte : autorisation contournée.
65
5.3.5.2. Détection d’une valeur de transaction élevée :
À l’arrivée d’un évènement Validation Error ayant un montant élevé, une alerte
de type « SWIFT Suspicious Activity- High-Value Transaction » sera déclenchée :
En dessous est un exemple du journal d’évènement Validation Error avec une

valeur de transaction supérieure à 5.000.000,00 USD (7.547.710,27 USD).
Figure 5.35 : Exemple d'une transaction à haute valeur.
Le traitement de cet évènement par le SIEM déclenche l’alerte citée précédemment :
Figure 5.36 : Détection d’une transaction à haute valeur.
66
Figure 5.37 : Détails de l'alerte : montant élevé.
5.3.5.3. Une opération en dehors des heures d’activité normales :
Dans ce cas, la règle implémentée signale toute réception ou autorisation

effectuée dans un temps suspect, ce paramètre varie selon l’entreprise en fonction de
ses heures des activités normales.
Figure 5.38 : Détection d’une opération dans un temps suspect.
Cette règle ne vérifie pas la date et l’heure de réception du journal, elle vérifie
le temps de création de ce dernier (20:45:50).
67
5.3.5.4. Un problème de séparation des tâches :
Cette alerte est levée lorsque l’utilisateur créateur du message tente de router
son propre message (le valider ou l’autoriser).
Figure 5.39 : Détection d’une incompatibilité dans la séparation des tâches.
Les détails de l’alerte dans la figure suivante affirme que l’autorisateur du

message est le même utilisateur créateur du message :
Figure 5.40 : Détails de l'alerte : problème de séparation des tâches.
5.3.5.5. Un message expiré :
Chaque message créé ont une durée de vie déterminée dans les paramètres
de la liste des identifiants des messages, en raison de faire le test nous allons définir
la durée de vie des éléments du « ReferenceSet » UUMID à 2 minutes après l’insertion
(l’apparition) de chaque UUMID. Dans le cas normal, chaque client spécifie sa durée
souhaitée.
Les UUMID des messages dépassant la durée de vie seront automatiquement

supprimés de la liste des UUMID, les informations d’évènement « Reference Data
Expiry » contient l’UUMID du message expiré.
68
La figure 5.43 suivante représente les paramètres associés à la liste

« UUMID » :
Figure 5.41: Configuration de la durée de vie des UUMID.
A la suppression d’un élément, nous serons notifiés de la part de « System

Notification » que l’identifiant du message ne figure plus dans la liste.
Figure 5.42 : Notification de l'expiration d'un UUMID.
5.4. Conclusion :
Dans ce dernier chapitre, nous avons étudié, normalisé et mappé les journaux
reçus par le SIEM à partir de l’application SWIFT Alliance. Par la suite, nous avons pu
programmer les règles de corrélations adéquates aux scénarios sélectionnés dans le
chapitre précédent.
Enfin, nous avons testé les règles créées en simulant les scénarios d’attaques
afin de confirmer la détection en cas d’anomalie.
69
Conclusion générale
Conclusion générale
Mondialement, le secteur financier demeure la première cible potentielle d’une
cyberattaque. Cela s’est représenté à travers l’attaque sur le système bancaire
mondial SWIFT qui n’a pas épargné la banque centrale de Bangladesh. Cette attaque
a engendré d’une part le braquage d’une somme phénoménale, mais a permis d’une
autre part de sensibiliser et assurer la prise de conscience de la sévérité des dangers
qui menacent constamment les systèmes d’information de ces organisations.
Suite à cet événement marquant, le challenge que s’étaient fixé les instituts
financiers était de se forger une maturité et une évolution en termes de sécurité de
l’information afin de pouvoir prévenir ce type d’attaques. L’organisation SWIFT a aussi
veillé à mettre en place un référentiel qui servirait de guide au maintien de la
confidentialité, l’intégrité et la disponibilité dans le réseau SWIFT.
Nous avons élaboré dans le cadre de notre PFE un travail structuré selon
plusieurs étapes afin d’atteindre l’objectif d’assurer la bonne détection des scénarios
d’anomalies qui menacent le réseau SWIFT grâce au SOC. Ces étapes consistaient à
étudier la logique de fonctionnement des messages SWIFT et en déduire les scénarios
de menaces qui devraient être détectés pour finalement les implémenter sur le SIEM
et tester l’efficacité de ces derniers.
Le travail que nous avons effectué nous a permis de découvrir la structure des
fichiers journaux d’audit des applications et spécialement de comprendre la logique de
fonctionnement de l’application bancaire mondiale SWIFT. De plus nous avons
découvert les différents composants qui structurent le SOC et nous familiariser avec
le système de gestion de l’information et des événements de sécurité (SIEM) et
l’approche adoptée par cette solution de sécurité pour le traitement des évènements
et la détection des anomalies.
En perspective, il serait intéressant d’étudier la logique de fonctionnement des

sessions sur les applications SWIFT et étudier les objectifs métier et de sécurité et de
conformité selon le référentiel CSP SWIFT afin de pouvoir établir de nouveaux
scénarios qui concernent la compromission de compte et de session et en déduire les
règles qui permettent la détection de ces scénarios.
70
Annexe A – Contrôles du programme CSP
Annexe A – Contrôles du
programme CSP
Les contrôles SWIFT CSCF 2020 sont organisés en trois objectifs principaux,
soutenus par huit principes et 31 contrôles [15].
Contrôles de sécurité obligatoires et consultatifs Type d’Architecture
A B
1. Restreindre l’accès à Internet et protéger les systèmes critiques de
l’environnement informatique général
1.1. Protection de l’environnement SWIFT X
1.2. Contrôle des comptes privilégiés du système X
d’exploitation
1.3. Protection de la plateforme de virtualisation X
1.4. A. Restriction de l’accès à Internet X X
2. Réduire la surface d’attaque et les vulnérabilités
2.1. Sécurité du flux de données interne X

2.2. Mises à jour de sécurité X X
2.3. Durcissement du système X X
2.4. A. Sécurité du flux de données du back-office X X
2.5. A. Protection des données de transmission X
externe
2.6. A. Confidentialité et intégrité de la session de X X
l’opérateur
2.7. Scan des vulnérabilités X X
2.8. A. Externalisation des activités critiques X X
2.9. A. Contrôles opérationnels des transactions X X
2.10 Durcissement de l’application X
2.11.A. Contrôles opérationnels du RMA X X
3. Protéger physiquement l’environnement
Annexe A – Contrôles du programme CSP
3.1. Sécurité physique X X

4. Prévenir la compromission des identifiants
4.1. Politique de mots de passe X X

4.2. Authentification multi-facteur X X
5. Gérer les identités et séparer les privilèges
5.1. Contrôle d’accès logique X X

5.2. Gestion des jetons X X
5.3.A. Processus de vérification du personnel X X
5.4. Stockage physique et logique des mots de passe X X
6. Détecter les activités anormales dans les systèmes ou les records des
transactions
6.1. Protection contre les Malwares X X
6.2. Intégrité des logiciels X
6.3. Intégrité des bases de données X
6.4. Journalisation et Monitoring X X
6.5. A. Détection des intrusions X
7. Plan de réponse aux incidents et d’échange de renseignements
7.1. Planification des réponses aux cyber incidents X X

7.2. Formation et sensibilisation à la sécurité X X
7.3. Tests de pénétration X X
7.4. Évaluation des risques liés aux scénarios X X
Références
Bibliographie
[1] UTSIT : « SWIFT POUR LES ENTREPRISES VADE MECUM », édition 2011.
[2] Messagerie et standards, consulté le 14/03/2022 - https://www.swift.com/fr/about-

us/discover-swift/messagerie-et-standards
[3] SWIFT WebAccess, consulté le 14/03/2022 - https://swift.com/our-solutions/global-

financial-messaging/swift-webaccess
[4] SWIFT : « Standards MT November 2020 », publié le 16 April 2020
[5] Susan V. Scott et Markos Zachariadis : « The Society for Worldwide Interbank
Financial Telecommunication (SWIFT) », publié en 2014.
[6] Discover SWIFT, consulté le 14/03/2022 - https://www.swift.com/about-

us/discover-swift/messaging-and-standards
[7] SWIFT Message Types, consulté le 15/03/2022 https://www.sepaforcorporates.

com/swift-for-corporates/swift-message-types-know-mts-mxs/
[8] SWIFT : « ISO 20022 Programme Quality data, quality payments », publié le 19
décembre 2018.
[9] ISO 20022 adoption programme, consulté le 19/03/2022 - https://www.swift.com/fr

/node/301056
[10] Découvrir SWIFT, consulté le 19/03/2022 - https://www.swift.com/fr/about-

us/discover-swift/securite-de-linformation
[11] Banque de l’Equateur piratée, 12 millions de dollars dérobés via SWIFT, consulté
le 21/03/2022 https://www.undernews.fr/banque-cartes-bancaires/banque-de-
lequateur-piratee-12-millions-de-dollars-derobes-via-la-faille-swift.html
[12] Deloitte et Touche LLAC : « SWIFT Systems and the SWIFT Customer Security
Program », publié en 2021.
[13] F-secure : « Threat Analysis, SWIFT Systems and the SWIFT Customer Security
Program »,
Références
[14] “Customer Security Programme (CSP)”, consulté le 22/03/2022

https://www.swift.com/fr/node/300751
[15] SWIFT : « SWIFT Customer Security Controls Framework v2020 Customer

Security Programme Detailed Description », publié le 04 juillet 2019.
[16] SANS Institute : « Analyst Program. The Definition of SOC-cess? SANS 2018
Security Operations Center Survey », publié en août 2018.
[17] Carson Zimmerman et The MITRE Corporation : « MITRE Ten Strategies of a

World-Class Cybersecurity Operations Center », publié en 2014.
[18] OWASP : “Security Operations Center (SOC) Framework Project Presentation”.
[19] NIST : ”Security and Privacy Controls for Information Systems and Organizations,
(24) SYSTEM MONITORING | INDICATORS OF COMPROMISE », Revision 5, publié
en septembre 2020.
[20] MITRE ATT&CK Definition, consulté le 18/03/2022 - attack.mitre.org
[21] IBM What is threat hunting?, consulté le 20/03/2022 - ibm.com/topics/threat-

hunting
[22] Alissa Torres de SANS Institute : « Building a World-Class Security Operations

Center a Roadmap », publié en mai 2015.
[23] Joseph Muniz, Gary McIntyre et Nadhem AlFardan : « Security Operation Center:
Building, Operating, and Maintaining Your SOC », publié en 2016.
[24] What Is Security Information and Event Management (SIEM)?, consulté le

14/04/2022 https://www.trellix.com/en-us/security-awareness/operations/what-is-
siem.html
[25] CISCO : « Security Operation Center: Building, Operating, and Maintaining Your
SOC », publié en 2016.
[26] The SOC, SIEM, and Other Essential SOC Tools, consulté le 15/04/2022 -
https://www.exabeam.com/explainers/siem/the-soc-secops-and-siem/
[27] Windows 10, consulté le 13/05/2022 - https://fr.wikipedia.org/wiki/Windows_10
[28] Alliance Access: features and functionalities, consulté le 24/05/2022

https://www.swift.com/fr/node/9006
Références
[29] QRadar SIEM Review & Alternatives, consulté le 24/05/2022

https://www.comparitech.com/net-admin/qradar siem-review-alternatives/
[30] WinCollect overview, consulté le 25/05/2022 https://www.ibm.com/docs/en/

qradar-on-cloud?topic=7-wincollect-overview
Résumé
Durant cette lutte contre la fraude que les instituts financiers mènent
désormais contre les cybers attaquants, plusieurs mesures de sécurité ont
dû être mises en place aux seins de ces organisations pour empêcher et
prévenir les attaques qui menacent leurs applications. On compte parmi
les applications les plus ciblées par ces menaces, les applications du
réseau interbancaire SWIFT.
Parmi les mesures de sécurité qui assurent la détection et la
prévention des menaces sur les systèmes, le Centre Opérationnel de
Sécurité (SOC). Composé de plusieurs types de technologies, le SOC
assure la détection des anomalies sur un système, l’investigation et
assure en cas d’incidents la réponse à ces derniers.
Dans le cadre de notre travail, nous nous sommes intéressés à
l’amélioration du processus de détection des anomalies qui menacent les
transactions SWIFT dans un SOC, et le développement des cas
d’utilisation adéquats sur le SIEM pour le signalement en cas d’altération
dans la logique de fonctionnement dans les applications et les
transactions SWIFT.
Mots clés : SOC, SIEM, SWIFT, cas d’utilisation, fraude, sécurité,

détection.

Ssi e 007

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

Ssi e 007

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université des Sciences et de la Technologie Houari Boumediene

Sujet Proposé par :

Devant le jury composé de :

Mr ABDELLI Abdelkrim Président (e)

Binôme N° : SSI-E-007 / 2022

Nous aimerions d’abord exprimer nos infinis remerciements et nos

Nous souhaitons également remercier Mme ALIOUANE.L de nous

Nous n’oserions oublier de remercier tous les professeurs de la faculté

Enfin, nous voudrions témoigner nos profondes gratitudes à tous ceux

À mes grands-parents, puisse dieu vous préserve votre santé et votre

À mon cher père, qui m’a encouragé et qui a toujours eu confiance en

À tous mes enseignants, qui ont assuré ma formation depuis le

À toute personne qui m’a apporté la moindre aide, merci.

Parmi les mesures de sécurité qui assurent la détection et la

Dans le cadre de notre travail, nous nous sommes intéressés à

1. LES APPLICATIONS SWIFT ......................................................................................... 3

1.1. INTRODUCTION :............................................................................................................... 3

2. LA SÉCURITÉ AUTOUR DES APPLICATIONS SWIFT ........................................ 12

2.1. INTRODUCTION :............................................................................................................. 12

3. LE CENTRE OPÉRATIONNEL DE SÉCURITÉ (SOC) ........................................... 20

3.1. INTRODUCTION :............................................................................................................. 20

4.1. INTRODUCTION :............................................................................................................. 32

5.1. INTRODUCTION :............................................................................................................. 44

CONCLUSION GÉNÉRALE ............................................................................................... 70

ANNEXE A – CONTRÔLES DU PROGRAMME CSP .................................................... 71

Figure 3.1 : Exemple d'une règle de corrélation de haut niveau. ______________________ 29

Figure 4.1 : Journalisation d’une transaction normale. _____________________________ 35

Figure 5.1 : l’interface graphique « Log Activity » de QRadar. ______________________ 45

Tableau 4.1 : Normalisation des évènements._____________________________________ 38

Les données montrent que les dommages causés à la communauté financière

Les utilisateurs du réseau SWIFT -fournisseur mondiale de messagerie

reconnaître qu’elles sont susceptibles de faire l’objet de cyberattaques. SWIFT a défini

L’une des exigences du Framework (exigence 6) consiste à mettre en place des

Dans le cadre de notre travail, nous nous sommes intéressés à l’amélioration

À cet effet, la première étape de notre travail consistait à déterminer les

1. Les applications SWIFT

Face aux différents types de dangers qui menacent la sécurité de l’information,

Dans ce premier chapitre nous allons présenter le réseau SWIFT et les

1.2. Définition de SWIFT :

SWIFT (Society for Worldwide Interbank Financial Telecommunication) est une

Les utilisateurs de SWIFT sont essentiellement les membres actionnaires de la

1.3. Définition du réseau SWIFTNet :

Le réseau SWIFTNet est un réseau de télécommunication TCP/IP sécurisé

La connexion au réseau peut se faire de différentes manières, mais toutes

1.4. Méthodes d’accès des utilisateurs au réseau SWIFTNet :

1.4.1. Connexion directe :

1.4.2. Service Bureau :

La principale raison qui conduit à externaliser cette partie de la solution, quand

1.4.3. Interface Web Alliance lite :

1.5. Les services de messagerie SWIFTNet :

Les organisations de services financiers ont des besoins de messagerie de plus

SWIFT propose WebAccess comme solution avec laquelle les utilisateurs

1.6.1. Types et structure des messages SWIFT MT :

Un message SWIFT contient au maximum 5 blocs dont deux sont optionnels

Figure 1.1 : Structure d'un message MT.

• Basic Header Block : ce bloc contient des informations sur la source du

• Le réseau SWIFT peut joindre un autre champ supplémentaire « ‘S’ - System

Le message MT se trouvant dans le bloc 4 précise l’objet et la structure du

• Catégorie 1 (MT1xx) : paiements pour le compte de donneurs d’ordres ou

Les messages SWIFT MT pertinents pour les transactions de paiement sont

1.6.2. Types et structure des messages SWIFT MX :