Audit et definition de la politique de sécurité du

réseau informatique de la first bank

UNIVERSITE DE YAOUNDE I AFRILAND FIRST BANK

FACULTÉ DE SCIENCES AGENCE SIEGE - YAOUNDÉ

DÉPARTEMENT D'INFORMATIQUE DIRECTION DES SYSTÈMES

D'INFORMATIONS

AUDIT ET DEFINITION DE LA POLITIQUE DE SECURITE DU RESEAU

INFORMATIQUE DE LA FIRST BANK

Rapport de stage présenté et soutenu publiquement en vue de l'obtention du diplôme de :

MASTER 2 «RÉSEAUX ET APPLICATIONS MULTIMÉDIA»

Par :

KOUALOROH Gustave

Titulaire d'une Maîtrise en Informatique

Sous la direction de :

M. François DAGORN M. Jean Jacques MATJEI MATJEI Enseignant à l'Université de

Rennes I Administrateur du réseau informatique

Encadreur académique Encadreur professionnel

Année académique 2006/2007

DEDICACES
A mes parents
 A mon petit bébé KOUALOROH KEYAMPI Gustave Junior

REMERCIEMENTS
F Notre reconnaissance va tout d'abord à M. François DAGORN qui a bien voulu nous
encadrer. Grâce à sa totale disponibilité et à sa volonté, nous avons pu surmonter certains
obstacles.

F Nos remerciements vont également aux enseignants du département d'informatique de

l'Université de Yaoundé I pour leurs précieux enseignements. Nous tenons à remercier
particulièrement le chef de département M. Emmanuel KAMGNIA et le Coordonnateur
du «MASTER 2 RESEAUX ET APPLICATIONS MULTIMEDIA» M. Gilbert TINDO
pour leurs précieux conseils et leur dévouement pour le bon déroulement de notre
formation.

F Ce travail étant le fruit d'un stage de quatre mois au sein de l'entreprise AFRILAND
FIRST BANK sous la supervision de Mr. Guy Laurent FONDJO et de Mr. Jean Jacques
MATJEI MATJEI, nous tenons à leur exprimer notre profonde gratitude pour leur
disponibilité et leurs conseils permanents. Nous remercions également la Direction
Générale de la banque qui a bien voulu nous accorder ce stage.

F Nous remercions tous les étudiants de la première promotion du « MASTER 2

RESEAUX ET APPLICATIONS » pour leur esprit de fraternité et de partage tout au long
de cette formation.

F Nous adressons aussi nos remerciements à M. KENNE Mathurin, M. NDEZO Joseph,

M. KUETE Jules, Mme MAGUITO Eveline, Mme TCHOUPOU Véronique, Mme
KOGUIO Antoinette, M. KUETE Jules, M. DETEMBOU Moïse, M. FOPA Jean Pierre ;
aux familles DOUMTSOP et TIFFA pour leur soutien financier et moral tout au long de
nos études.

F Nous sommes reconnaissants envers nos camarades KENNE Sidoine, KENNE

SONKOUE Darius, TATSILONG Henri, DOHOLA Beaudelaire, DOUYEM Etienne
Robert, TCHOFOUO Eric, KEMBOU Jules, DOUANLA Hermann, KENNE Flore,
DOUWE Vincent. Que ce travail soit pour eux source de motivation et d'encouragement.

F Nous remercions tout le personnel du Cabinet GIFEX pour son appui.

Gustave KOUALOROH

AVANT-PROPOS
Dans le cadre de la professionnalisation des enseignements, la Faculté des Sciences de
l'Université de Yaoundé I à travers le département d'Informatique a introduit dans ses
programmes pour le compte de l'année académique 2006/2007 un cycle de « Master 2
Réseaux et Applications Multimédia ». Cette formation professionnelle a pour objectif de
mettre sur le marché de l'emploi des diplômés capables de :

§ concevoir et mettre en oeuvre des réseaux locaux et métropolitains,

§ administrer des réseaux et répondre de manière sécurisée aux exigences des utilisateurs,

§ développer des applications complexes basées sur la technologie WEB,

§ tirer partie de la convergence entre l'informatique et les télécommunications pour

développer des services à forte valeur ajoutée,

§ intégrer des services qui manipulent sons, paroles et images dans le cadre d'applications
multimédia.

Au terme de la formation, l'étudiant est tenu d'effectuer un stage académique d'une durée
d'au moins quatre mois en entreprise sanctionné par un mémoire dont la note porte sur le
travail réalisé, le rapport de stage et la présentation orale effectuée : chaque rubrique
comptant pour un tiers de la note finale du module.

Le présent rapport fait suite au stage que nous avons effectué dans les locaux de
l'entreprise AFRILAND FIRST BANK, agence siège à Yaoundé sis Hôtel de ville, du 07
avril au 30 juillet 2008 sous le thème « Audit et Définition de la politique de sécurité du
réseau informatique de la First Bank ».

LISTE DES SIGLES ET

ABREVIATIONS
: Advance Encryption Standard - Algorithme de cryptographie symétrique
AES
ANTIC : Agence Nationale des Technologies de l'Information et de la
Communication
ACID : Analysis Console for Intrusion Databases
CERTA : Centre d'Expertise Gouvernemental de Réponse et de Traitement des
Attaques informatiques
CERT/CC : CERT Coordination Center
CLUSIF : Club de Sécurité de l'Information Français
CEI : Commission Electrotechnique Internationale
CERT : Computer Emergency Response Team
DES : Data Encryption Standard
DMZ : DeMillitarized Zone ou Zone démilitarisée
DECB : Direction des Etudes et du Commercial Banking
DSIG : Direction des Systèmes d'Informations du Groupe
DFC : Direction Financière et Comptable
EBIOS : Expression des Besoins et Identification des Objectifs de Sécurité
FAI : Fournisseur d'Accès à Internet
ISO : International Standard Organisation
IPSec : Internet Protocol Security
PIX : Private Internet EXchange est un boîtier pare-feu actuellement conçu
vendu par le groupe Cisco Systems
PKI : Public Key Infrastructure ou Infrastructure à clés publiques
RSSI : Responsable de Sécurité de Systèmes d'Informations
RSA : Rivest Shamir Adleman - Algorithme de cryptographie à clefs publiques
SQL : Structured Query Language
SI : Système d'Informations
SMSI : Système de Management de la Sécurité de l'Information
URL : Universal Ressource Localisator

S0MMAIRE
DEDICACES I

REMERCIEMENTS II

AVANT-PROPOS III

LISTE DES SIGLES ET ABREVIATIONS IV

S0MMAIRE V

INTRODUCTION 1

PREMIERE PARTIE: AUDIT DE SECURITE DU RESEAU INFORMATIQUE

DE LA FIRST BANK 4

1. ARCHITECTURE DU RESEAU INFORMATIQUE DU SIEGE DE LA FIRST

BANK 4
2. LES MENACES SUR LE RESEAU INFORMATIQUE DE LA FIRST BANK 7

2.1. Menaces relevant des problèmes non spécifiques à l'informatique 7

2.2. Les pannes et erreurs (non intentionnelles) 7

2.3. Les menaces intentionnelles 8

3. SCAN DES PORTS AVEC NMAP 11

3.1. Description de Nmap 11

3.2. Différents types de scan 11

3.3. Différents états des ports 12

4. SCAN DES VULNERABILITES AVEC NESSUS 14

5. TESTS D'INTRUSIONS DIVERS ET VARIES 20

5.1. Résumé des étapes du hacker 20

5.2. Test d'intrusions sur le réseau de la First bank 20

6. DETECTION D'INTRUSIONS AVEC « SNORT » 23

6.1. Les prérequis pour l'installation de snort 24

6.2. Installation de l'outil snort 24

6.3. Test de Fonctionnement : 25

6.4. Liaison des logs de snort avec mysql : 25

6.5. Création de nouvelles règles 25

6.6. Mise en place d'ACID : 26

7. RECOMMANDATIONS 27

DEUXIEME PARTIE : DEFINITION DE LA POLITIQUE DE SECURITE DU

RESEAU INFORMATIQUE DE LA FIRST BANK 32

1. OBJECTIF D'UNE POLITIQUE DE SECURITE RESEAU 32

1.1. Définir une analyse de risque 33

1.2. Principes génériques d'une politique de sécurité réseau 33

1.3. Niveaux d'une politique de sécurité réseau 37

1.4. Les différents types de politiques de sécurité 38

2. STRATEGIE DE SECURITE RESEAU 38

2.1. Méthodologie pour élaborer une stratégie de sécurité réseau 38

2.2. Propositions de stratégie de sécurité réseau 42

3. LES MODELES DE SECURITE 46

3.1. Le modèle I-BAC (Identity Based Control Access) 46

3.2. Le modèle R-BAC (Role Based Access Control) 46

3.3. Le modèle T-BAC (Task Based Access Control) 47

3.4. Le modèle V-BAC (View Based Access Control) 47

3.5. Le modèle T-MAC (Team Based Access Control) 48

3.6. Le modèle Or-BAC (Organization Based Access Control) 48

4. APPLICATION DU MODELE OR-BAC A LA DEFINITION DE LA

POLITIQUE DE SECURITE RESEAU : CAS DU LAN DE PRODUCTION DU
SIEGE DE LA FIRST BANK 56

4.1. Les organisations 56

4.2. Les sujets et rôles 57

4.4. Services offerts par le réseau local de l'Organisation et hiérarchisation :

actions/activités 58

4.4. Définition des vues et hiérarchisation 59

4.5. Quelques Org_FB_Permissions 59

4.6. Dérivation des permissions 60

CONCLUSION 61

BIBLIOGRAPHIE I
ANNEXES : CAHIER DE CHARGES II

INTRODUCTION
L'informatique est devenue un outil incontournable de gestion, d'organisation, de
production et de communication. Le réseau informatique de l'entreprise met en oeuvre des
données sensibles, les stocke, les partage en interne, les communique parfois à d'autres
entreprises ou personnes ou les importe à partir d'autres sites. Cette ouverture vers
l'extérieur conditionne des gains de productivité et de compétitivité.

Il est donc impossible de renoncer aux bénéfices de l'informatisation, d'isoler le réseau de

l'extérieur, de retirer aux données leur caractère électronique et confidentiel. Les données
sensibles du système d'information de l'entreprise sont donc exposées aux actes de
malveillance dont la nature et la méthode d'intrusion sont sans cesse changeantes. Les
prédateurs et voleurs s'attaquent aux ordinateurs surtout par le biais d'accès aux réseaux
qui relient l'entreprise à l'extérieur.

La sécurité du système d'information d'une entreprise est un requis important pour la

poursuite de ses activités. Qu'il s'agisse de la dégradation de son image de marque, du vol
de ses secrets de fabrication ou de la perte de ses données clients ; une
catastrophe informatique a toujours des conséquences fâcheuses pouvant aller jusqu'au
dépôt de bilan. On doit réfléchir à la mise en place d'une politique de sécurité avant même
la création du réseau. Cependant, la sécurité des SI est souvent oubliée ou établie à
postériori.

En ce qui concerne les normes de sécurité des SI, la famille de normes ISO 27000
constitue un véritable espoir pour les RSSI dans la mesure où elle apporte une aide
indéniable dans la définition, la construction et la déclinaison d'un SMSI efficace à travers
une série de normes dédiées à la sécurité de l'information :

§ ISO/CEI 27001 : système de Gestion de la Sécurité de l'Information (ISMS) -

Exigences ;

§ ISO/CEI 27002 : code de bonnes pratiques pour la gestion de la sécurité de

l'information (anciennement ISO/CEI 17799) ;

§ ISO/CEI 27003 : système de Gestion de la Sécurité de l'Information (ISMS) - Guide

d'implémentation ;

§ ISO/CEI 27004 : mesure de la gestion de la sécurité de l'information ;

§ ISO/CEI 27005 : gestion du risque en sécurité de l'information ;

§ ISO/CEI 27006 : exigences pour les organismes réalisant l'audit et la certification de

Systèmes de Gestion de la Sécurité de l'Information (ISMS) ;

§ ISO/CEI 27007 : guide pour l'audit de Systèmes de Gestion de la Sécurité de

l'Information (ISMS).

Il existe également plusieurs méthodes d'analyse de risques selon les zones

géographiques. Parmi ces dernières, nous pouvons citer :

§ EBIOS (Expression de Besoins et Identification des Objectifs de Sécurité) : méthode

d'analyse des risques créée DCSSI (Direction Centrale de la Sécurité des Systèmes
d'Information) du ministère français de la défense. Elle est destinée avant tout aux
entreprises françaises et à l'administration ;

§ MELISA (Méthode d'évaluation de la vulnérabilité résiduelle des systèmes

d'information) : méthode inventée par Albert Harari au sein de la Direction Générale de
l'Armement (DGA) en France. Elle a été abandonnée au profit de MEHARI ;

§ MARION (Méthodologie d'Analyse de Risques Informatiques Orientée par Niveaux) :

elle a été développée par le CLUSIF dans les années 1980 mais a été abandonnée en 1998
au profit de la méthode MEHARI ;

§ MEHARI (MEthode Harmonisée d'Analyse de RIsques) : développée par le CLUSIF

depuis 1995, suite à la fusion de deux anciennes méthodes MARION et MELISA ;

§ OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) a été créé
par l'université de Carnegie Mellon (Etats-Unis) en 1999. Elle a pour but de permettre à
une entreprise de réaliser par elle-même l'analyse des risques de leur SI, sans aide
extérieure (consultants) ;

§ CRAMM (CCTA Risk Analysis and Management Method) a été inventée par
Siemens en Angleterre et est soutenue par l'état.

A côté de tous ces standards de sécurité et méthodes d'analyse de risques, certains pays
ont développé un arsenal juridique pour réglementer le secteur de la sécurité informatique.
Bien plus des entreprises ont souvent été créées pour veiller à l'application des politiques
gouvernementales en la matière.

En France par exemple, la Direction Centrale de la Sécurité des Systèmes d'Information

(DCSSI) a été créée et placée sous l'autorité de Secrétaire général de la défense nationale.
Cette structure chargée entre autres de coordonner l'action gouvernementale en matière de
la sécurité des SI, d'évaluer les menaces pesant sur les systèmes d'information, donner
l'alerte, développer les capacités à les contrer et à les prévenir à travers les CERTA.

Au Cameroun, L'ANTIC, créée par Décret n° 2002/092 du 8 Avril 2002, a pour mission
de promouvoir et de suivre l'action gouvernementale dans le domaine des technologies de
l'information et de la communication.

Notre travail dans le cadre du présent mémoire a débuté par la rédaction d'un cahier de
charges, questions de se fixer les idées sur ce qui convient de faire ou non pour répondre
aux questions qui se cachent derrière le thème énoncé plus haut dans ce document. Le
contenu de ce cahier de charge peut être consulté en annexe de ce document. Par la suite,
nous avons suivi un plan de travail structuré en deux parties :

§ l'audit de sécurité du réseau informatique de la First Bank : ici nous commençons par
faire un aperçu des menaces sur le réseau informatique de la First Bank, nous effectuons
par la suite des tests de vulnérabilités et des tests d'intrusions, enfin nous faisons des
recommandations pour une amélioration future de la sécurité de ce réseau informatique ;

§ la deuxième partie est consacrée à la définition d'un politique de sécurité du système

d'information de la First Bank. Nous avons commencé cette partie par un état des lieux
des méthodes des différents modèles de sécurité puis nous avons appliqué un de ces
modèles de sécurité, Or-BAC en l'occurrence, dans le cadre de la définition de la politique
de sécurité du LAN de production de la First Bank.

NB : pour des raisons de sécurité liées à la confidentialité des informations internes à la

banque, les travaux effectués dans le cadre de ce travail n'ont pas été entièrement exposés
dans le présent rapport. Un rapport plus complet notamment en ce qui concerne la
première partie sur l'audit de sécurité est la propriété de l'entreprise Afriland First Bank.

PREMIERE PARTIE: AUDIT DE

SECURITE DU RESEAU
INFORMATIQUE DE LA FIRST
BANK
L'audit sécurité d'un réseau informatique est un état des lieux de la sécurité du réseau
informatique actuel avec des propositions permettant de résoudre les problèmes potentiels
une fois l'audit sécurité effectué et les conclusions présentées par la partie effectuant cet
audit.

Le présent audit a pour but d'évaluer les failles de sécurité du réseau et proposer des
solutions aptes à corriger les vulnérabilités afin que le hacker ne puisse s'en servir. Nous
commencerons tout d'abord par une présentation des menaces auxquelles l'entreprise fait
face, ensuite nous effectuerons les tests de vulnérabilités et d'intrusions sur le réseau et
nous terminerons par les recommandations portant sur d'éventuelles améliorations à
apporter au réseau.

1. ARCHITECTURE DU RESEAU INFORMATIQUE

DU SIEGE DE LA FIRST BANK

Afriland First Bank est une institution bancaire camerounaise à capitaux majoritairement
africains dont le siège est situé à Yaoundé (quartier Hyppodrome). Elle est implantée dans
plusieurs pays du continent noir ainsi qu'en France et en Chine. Au Cameroun, on
dénombre quinze agences implantées dans les villes de Yaoundé (3 agences), Douala (4
agences), Bafoussam, Bamenda, Nkongsamba, Limbé, Ngaoundéré, Maroua, Garoua et
Kousséri. Son réseau informatique au Cameroun est constitué de deux MAN dont un à
Douala et l'autre à Yaoundé, puis d'un LAN dans chacune des autres agences ; le tout
interconnecté formant ainsi une topologie en étoile étendue. Le réseau informatique du
siège à Yaoundé, placé sous le contrôle de la DSIG comprend deux réseaux filaires de
classe C. L'architecture actuelle a subi des modifications à la suite d'un audit du système
d'informations avec à la clef des recommandations. Elle se présente comme suit :
Comme nous pouvons observer sur la figure ci-dessus, c'est un réseau modulaire qui
comporte les blocs de distribution, d'administration et d'interconnexion.

Les blocs de distribution, situés à tous les niveaux de l'immeuble siège et des bâtiments
annexes (DECB et DFC), sont constitués de armoires contenant :

§ des panneaux de brassage qui sont des équipements permettant de relier la source à
plusieurs switchs.

§ des switchs permettant de connecter divers postes de travail aux réseaux.

Les blocks d'administration sont constitués des postes de travail permettant d'administrer
les réseaux et les services réseaux contenues dans les différents serveurs (Serveur
Middleware, Gacha, Delta, As Millenium, Antivirus, web/mail).

Les blocks d'interconnections contiennent des équipements de réception des signaux et

d'interconnexion avec les autres agences.

Le coeur du réseau est en fibre optique avec des câbles de redondance (Câble FTP de
catégorie 6) pour palier aux éventuelles pannes de la fibre optique.

2. LES MENACES SUR LE

RESEAU INFORMATIQUE DE LA FIRST BANK

Une menace1(*) est un événement, d'origine accidentelle ou délibérée, capable s'il se réalise
de causer un dommage au sujet étudié. Le réseau informatique de la First Bank comme
tout autre réseau informatique est en proie à des menaces de toutes sortes qu'il convient de
recenser.

2.1. MENACES RELEVANT DES PROBLÈMES NON

SPÉCIFIQUES À L'INFORMATIQUE

Certaines menaces aux réseaux informatiques ne sont pas spécifiques à ce secteur. Parmi
elles, nous pouvons citer :

§ les risques accidentels : incendie, explosion, inondation, tempête, foudre. Ici les
techniques de prévention sont assez bien maîtrisées ;

§ les vols et sabotages de matériels : vols d'équipements matériels, destruction

d'équipements, destruction des supports de sauvegarde ;

§ autres risques : départ du personnel stratégique, grèves, etc.

2.2. LES PANNES ET ERREURS (NON INTENTIONNELLES)

Ce sont :

§ pannes/dysfonctionnement du matériel ;

§ pannes/dysfonctionnement du logiciel de base ;

§ erreurs d'exploitation :
o oubli de sauvegardes,

o écrasement de fichiers ;

§ erreurs de manipulation des informations :

o erreurs de saisie,

o erreurs de transmission,

o erreurs d'utilisation ;

§ erreurs de conception des applications.

2.3. LES MENACES INTENTIONNELLES

C'est l'ensemble des actions malveillantes qui constituent la plus grosse partie du risque.
Elles font l'objet principal des mesures de protection. Parmi elles, on compte les menaces
passives et les menaces actives.

Les menaces passives sont :

§ les détournements des données (l'écoute sur le réseau à l'aide des sniffeurs2(*), les
indiscrétions) : c'est le cas le cas de l'espionnage industriel, l'espionnage commercial, les
violations déontologiques ;

§ les détournements de logiciels : les copies illicites par exemple.

Quant aux menaces actives, nous pouvons citer :

§ les modifications des informations : le fraude financière informatique ;

§ le sabotage des informations ;

§ les modifications des logiciels :

o le virus : c'est un programme qui se reproduit en s'insérant partiellement dans d'autres

fichiers ;

o le ver : un ver (en anglais worm) est un programme qui se propage d'ordinateur à
ordinateur via un réseau comme l'Internet. Ainsi, contrairement à un virus, le ver n'a pas
besoin d'un programme hôte pour assurer sa reproduction. Son poids est très léger, ce qui
lui permet de se propager à une vitesse impressionnante sur un réseau, et pouvant donc
saturer ce dernier ;

o le spyware : ce logiciel espion est un logiciel nuisible qui transmet à des tiers des
informations contenues dans votre ordinateur ;
o le hijacker : c'est un pirate de navigateur qui utilise les failles de sécurité d'Internet
Explorer pour s'installer sur votre ordinateur. Ce genre de programme s'installe donc juste
en surfant sur le net, souvent sur des sites de piratage, de jeux, de cracking, ou encore
sites à caractère pornographique ;

o le troyen : un troyen (en anglais trojan horse) tire son nom du mythe du cheval de Troie.
Ce programme a une apparence saine, souvent même attirante, mais lorsqu'il est exécuté,
il effectue, discrètement ou pas, des actions supplémentaires. Ces actions peuvent être de
toutes formes, comme l'installation d'une backdoor3(*) par exemple.

o la bombe logique : une bombe logique est un troyen qui, une fois exécutée, produira ses
effets à un moment précis. Par exemple, la bombe logique Tchernobyl s'est activée le 26
avril 1999 (jour du 13ème anniversaire de la catastrophe nucléaire en Ukraine), mais la
bombe peut également attendre une combinaison de touches bien précise de la part de
l'utilisateur pour se déclencher ou attendre qu'un fichier s'exécute ;

o le hoax : un hoax (canular) est un courrier électronique contenant une fausse

information. Si certains sont inoffensifs, d'autres peuvent être dangereux ;

o le spam : le spamming consiste à envoyer des messages appelés "spam" à une ou

plusieurs personnes. Ces spams sont souvent d'ordre publicitaire ;

o le mailbombing : le mailbombing s'apparente un peu au spamming puisqu'il a pour but

de provoquer une gêne pour la victime. Mais cette fois, le but n'est pas le même, il s'agit
de saturer la boîte aux lettres électronique de la victime en envoyant plusieurs mails, des
milliers par exemple ;

o le pishing : le phishing est très à la mode aujourd'hui et consiste à soutirer des

informations confidentielles (comme les codes bancaires, ...) auprès des clients par
usurpation d'identité ;

o le ransomware : le ransomware est un logiciel malveillant qui chiffre les données, les «
prend en otage » et ne donne le mot de passe que lorsque la rançon a été versée. Des
variantes plus agressives menacent d'effacer définitivement un fichier toutes les 30
minutes, jusqu'à ce que la rançon ait été versée. Le paiement d'une rançon est
habituellement demandé via e-Gold ou Western Union afin de ne pas dévoiler à
l'utilisateur la véritable identité du pirate. Cette technique d'abord utilisée en Russie s'est
maintenant étendue au monde entier. Le ver Arhiveus et le cheval de Troie Zippo sont
deux exemples de ransomware ayant sévi en 2006 ;

o le scareware : c'est un logiciel conçu pour faire croire aux utilisateurs d'Internet que leur
PC est infecté ou qu'il est touché par un autre problème de sécurité et les encourager à
acquérir une version « totalement opérationnelle » d'un logiciel qui désinfectera leur poste
de travail.

Pour parvenir à leurs fins, les pirates ont recours à un certain nombre de stratagèmes pour
maximiser le taux d'infections. Nous pouvons citer parmi les stratagèmes utilisés les
suivants :
1. Accroissement de la portée des infections grâce au détournement de réputation : 83
pour cent des pages Web infectées par des malwares4(*) se trouvent sur des sites Web
parfaitement légitimes5(*). Pour les auteurs de malwares, la manière la plus efficace et la
moins coûteuse d'infecter des ordinateurs par l'intermédiaire du Web consiste à héberger
leurs malwares à l'endroit où le plus grand nombre de personnes les verront. C'est
précisément ce qu'ils font quand ils détournent la réputation de sites Web existants en
attirant des utilisateurs qui se méfient d'autant moins qu'ils font confiance à la popularité
et à la crédibilité de ces URL qui semblent sûres.

2. Dissimulation de l'attaque derrière un téléchargeur : au lieu de placer directement leur

code malveillant sur une page Web, de nombreux cybercriminels insèrent des
«téléchargeurs». Ces chevaux de Troie sont conçus pour éviter la plupart des mécanismes
de défense. Ils contiennent très peu de code et ne contiennent pas par eux-mêmes de
charge malveillante. Ce n'est qu'une fois installés sur un ordinateur qu'ils téléchargent
cette charge à partir d'un autre site Web, souvent via un port différent.

3. Infection silencieuse par téléchargement passif : Pour que ce type d'infection se

produise, il suffit qu'un utilisateur navigue sur le Web et visite une page infectée à l'aide
d'un navigateur auquel aucun correctif n'a été appliqué. L'utilisateur n'a même pas besoin
de cliquer sur des liens particuliers, ni d'ouvrir des fichiers précis. Son ordinateur devient
infecté simplement parce qu'il a visité un site sur lequel les vulnérabilités connues du
navigateur sont exploitées par l'auteur d'un malware.

4. Exploitation des noms de domaine résultant de fautes de frappe : Les pirates ont eu
l'idée de créer des noms de domaine ressemblant à des sites parfaitement légitimes (par
exemple, « Goggle » au lieu de « Google », ou un « .tv » à la fin au lieu de « .com »), ce
qui leur permet d'utiliser des fautes de frappe courantes pour faire atterrir très simplement
des utilisateurs sur leurs pages Web. Ces pages sont en quelque sorte des pièges, qui
n'attendent que des proies à capturer et à infecter. Comme ces sites ressemblent
généralement au site initialement souhaité, il est très facile d'obtenir du visiteur qu'il ouvre
ou télécharge du contenu, d'autant que ce contenu semble sûr.

5. Utilisation d'attaques de spam à flux rapide pour envoyer des malwares : Alors qu'ils
envoyaient souvent les malwares sous forme de pièces jointes aux messages
électroniques, les pirates tendent aujourd'hui à envoyer des messages électroniques
contenant des liens qui conduisent à des pages Web infectées. Derrière ces liens se
cachent des armées d'ordinateurs infectés, appelés « botnets », qui font office d'hôtes
Web. Les auteurs de malwares alternent constamment entre ces différents ordinateurs
pour fournir une page d'accueil infectée toujours différente aux personnes qui suivent un
lien. Cette opération consistant à modifier rapidement l'adresse IP de l'ordinateur qui
héberge le malware est appelée « flux rapide ». Elle complique la tâche aux filtres en
charge de détecter et de bloquer les attaques de spam correspondantes.

6. Toujours avoir une longueur d'avance sur les systèmes de défense de sécurité :
Contrairement aux virus et aux vers véhiculés par messagerie, qui cessent d'être
dangereux une fois qu'ils ont été éradiqués, les menaces Web modernes ne cessent d'être
adaptées et modifiées afin d'esquiver les systèmes de défense. En présentant
continuellement les menaces sous une forme différente, les pirates peuvent créer de
nombreuses variantes mineures, dont certaines ne sont pas reconnues par les solutions de
sécurité. Ce processus peut même être automatisé, ce qui permet aux criminels de générer
plusieurs variantes d'un même malware le même jour.

La liste des menaces et stratagèmes que nous venons donner est loin d'être exhaustive.
Nous avons surtout énuméré ici les menaces et stratagèmes les plus connues.

3. SCAN DES PORTS AVEC NMAP

Nmap est un outil d'exploration réseau et scanneur de ports/sécurité dont la syntaxe est la
suivante : nmap [types de scans ...] [options] {spécifications des cibles}. Nmap existe
aussi en mode graphique sous le nom « Zenmap GUI ».

Nmap permet d'éviter certaines attaques et aussi de connaître quels services tournent sur
une machine. Une installation faite un peu trop vite peut laisser des services en écoute
(donc des ports ouverts sans que cela ne soit nécessaire) et donc vulnérables à une attaque.
Nmap est un logiciel très complet et très évolutif, et il est une référence dans le domaine
du scanning.

3.1. DESCRIPTION DE NMAP

Nmap a été conçu pour rapidement scanner de grands réseaux, mais il fonctionne aussi
très bien sur une cible unique. Nmap innove en utilisant des paquets IP bruts (raw
packets) pour déterminer quels sont les hôtes actifs sur le réseau, quels services (y
compris le nom de l' application et la version) ces hôtes offrent, quels systèmes
d'exploitation (et leurs versions) ils utilisent, quels types de dispositifs de filtrage/pare-
feux sont utilisés, ainsi que des douzaines d'autres caractéristiques. Nmap est
généralement utilisé pour les audits de sécurité mais de nombreux gestionnaires des
systèmes et de réseau l'apprécient pour des tâches de routine comme les inventaires de
réseau, la gestion des mises à jour planifiées ou la surveillance des hôtes et des services
actifs.

Le rapport de sortie de Nmap est une liste des cibles scannées ainsi que des informations
complémentaires en fonction des options utilisées.

3.2. DIFFÉRENTS TYPES DE SCAN

Nmap permet d'effectuer des scans en utilisant différentes techniques issues de l'étude du
comportement des machines respectant le RFC 7932 (TCP). Parmi la douzaine de
techniques de scan connues, on peut citer les suivantes :

§ Scan TCP SYN: Le scan SYN est celui par défaut et le plus populaire pour de bonnes
raisons. Il peut être exécuté rapidement et scanner des milliers de ports par seconde sur un
réseau rapide lorsqu'il n'est pas entravé par des pare-feux. Le scan SYN est relativement
discret et furtif, vu qu'il ne termine jamais les connexions TCP. Nmap émet un paquet sur
le port ciblé et attend la réponse qui peut être :
o un paquet SYN/ACK qui indique que le port est ouvert ;

o un paquet RST qui indique que le port est fermé ;

o pas de réponse si le port est filtré.

Faire ce type de scan requiert l'option -sS.

§ Scan TCP connect : c'est le type de scan par défaut quand le SYN n'est pas utilisable.
Tel est le cas lorsque l'utilisateur n'a pas les privilèges pour les paquets bruts (raw
packets) ou lors d'un scan de réseaux IPv6. Son exécution est plus lente que le premier et
requiert l'option -sT.

§ Scan UDP : même si les services les plus connus d'Internet son basés sur le protocole
TCP, les services UDP sont aussi largement utilisés. DNS, SNMP ou DHCP (ports 53,
161/162 et 67/68) sont les trois exemples les plus courants. Comme le scan UDP est
généralement plus lent et plus difficile que TCP, certains auditeurs de sécurité les
ignorent. C'est une erreur, car les services UDP exploitables sont courants et les attaquants
eux ne les ignoreront pas. Le scan UDP est activé avec l'option -sU. Il peut être combiné
avec un scan TCP, comme le scan SYN (-sS), pour vérifier les deux protocoles lors de la
même exécution de Nmap.

3.3. DIFFÉRENTS ÉTATS DES PORTS

Nmap retourne les résultats des scans sous forme d'états de ports scannés. Les six états
des ports reconnus par Nmap sont :

§ ouvert : une application accepte des connexions TCP ou des paquets UDP sur ce port.

§ fermé : le port fermé est accessible (il reçoit et répond aux paquets émis par Nmap),
mais il n'y a pas d'application en écoute.

§ filtré : Nmap ne peut pas toujours déterminer si un port est ouvert car les dispositifs de
filtrage des paquets empêchent les paquets de tests (probes) d'atteindre leur port cible.

§ non-filtré : l'état non-filtré signifie qu'un port est accessible, mais que Nmap est
incapable de déterminer s'il est ouvert ou fermé.

§ ouvert|filtré : Nmap met dans cet état les ports dont il est incapable de déterminer l'état
entre ouvert et filtré.

§ fermé|filtré : cet état est utilisé quand Nmap est incapable de déterminer si un port est
fermé ou filtré. Cet état est seulement utilisé par le scan Idle basé sur les identifiants de
paquets IP.

Scan TCP Stealth SYN du serveur DNS

Nous avons présenté dans cette section l'outil Nmap puis nous l'avons utilisé pour scanner
tour à tour les réseaux internes du siège de la First Bank, les adresses VPN des routeurs de
différentes agences, les serveurs web et DNS ainsi que les adresses des PIX de quelques
fournisseurs d'accès à Internet (Gonago, Saconets et Creolinks).

Le scan des ports des adresses VPN de différentes agences nous a révélé un certain
nombre d'informations (les ports ouverts et les services à l'écoute sur ces ports, les ports
fermés, les ports filtrés et les services à l'écoute sur ces ports, les systèmes d'exploitation,
le type de matériel, ...).

Le scan des serveurs web et DNS nous a révélé entre autres informations les noms d'hôte
des ces différents serveurs.

Le scan des adresses des PIX de certains fournisseurs d'accès nous a permis d'avoir un état
des sorties du réseau WAN de la First Bank.

Les différentes informations révélées dans cette section à travers les scans peuvent
permettre aux administrateurs et responsables de sécurité du réseau de désactiver certains
services installés et non-utilisés. Elles peuvent aussi permettre aux attaquants potentiels
d'avoir plus d'amples informations sur le réseau qui représente leur proie.

La suite de nos travaux sera consacrée au scan de vulnérabilités du réseau avec l'outil
Nessus.

4. SCAN DES VULNERABILITES AVEC NESSUS

Nessus est un outil de test de vulnérabilité. Il fonctionne en mode client/serveur, avec une
interface graphique. Une fois installé, le serveur « Nessusd », éventuellement sur une
machine distante, effectue les tests et les envoie au client « Nessus » qui fonctionne sur
une interface graphique.

Nessus est un produit commercial diffusé par la société TENABLE Network Security. Il
peut toutefois être utilisé gratuitement avec une base des vulnérabilités dont la mise à jour
est décalée d'une semaine.

Les résultats peuvent être enregistrés sous divers formats : NBE, NSR et html.

Notre but dans cette partie est surtout de présenter les résultats des scans de vulnérabilités
effectués sur le réseau informatique de la First Bank. Nous avons scanné les
vulnérabilités connues de Nessus sur le serveur web, le serveur DNS, les routeurs du VPN
ainsi que les PIX des fournisseurs d'accès à Internet.

Scan des vulnérabilités du serveur DNS

Vulnérabilités de niveau moyen

DNS Cache Snooping

Synopsis:

Remote DNS server is vulnerable to cache snooping attacks.

Description:

The remote DNS server answers to queries for third-party domains which do not have the
recursion bit set.

This may allow a remote attacker to determine which domains have recently been
resolved via this name server, and therefore which hosts have been recently visited.

For instance, if an attacker was interested in whether your company utilizes the online
services of a particular financial institution, they would be able to use this attack to build
a statistical model regarding company usage of aforementioned financial institution. Of
course, the attack can also be used to find B2B partners, web-surfing patterns, external
mail servers, and more...

See also :

For a much more detailed discussion of the potential risks of allowing DNS cache
information to be queried anonymously, please see:

http://www.nessus.org/u?0f22a4a4

Risk factor :

Medium / CVSS Base Score : 5.0

(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)

Nessus ID : 12217
Usable remote name server

Synopsis:

The remote name server allows recursive queries to be performed by the host running
nessusd.

Description:

It is possible to query the remote name server for third party names.

If this is your internal nameserver, then forget this warning.

If you are probing a remote nameserver, then it allows anyone to use it to resolve third
parties names (such as www.nessus.org). This allows hackers to do cache poisoning
attacks against this nameserver.

If the host allows these recursive queries via UDP, then the host can be used to 'bounce'
Denial of service attacks against another network or system.

See also:

http://www.cert.org/advisories/CA-1997-22.html

Solution:

Restrict recursive queries to the hosts that should use this nameserver (such as those of
the LAN connected to it).

If you are using bind 8, you can do this by using the instruction 'allow-recursion' in the
'options' section of your named.conf

If you are using bind 9, you can define a grouping of internal addresses using the 'acl'
command
Then, within the options block, you can explicitly state: 'allow-recursion
{ hosts_defined_in_acl }'

For more info on Bind 9 administration (to include recursion), see:

http://www.nominum.com/content/documents/bind9arm.pdf

If you are using another name server, consult its documentation.

Weak Supported SSL Ciphers Suites

Synopsis:

The remote service supports the use of weak SSL ciphers.

Description:

The remote host supports the use of SSL ciphers that offer either weak encryption or no
encryption at all.

See also:

http://www.openssl.org/docs/apps/ciphers.html

Solution:

Reconfigure the affected application if possible to avoid use of weak ciphers.

Risk factor :

Medium / CVSS Base Score : 5.0

(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)

Plugin output :

Here is the list of weak SSL ciphers supported by the remote server :

Low Strength Ciphers (< 56-bit key)

SSLv2
EXP-R-CBC-MD5 Kx=RSA(512) Au=RSA Enc=R(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
SSLv3
EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1
export
EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-R-CBC-MD5 Kx=RSA(512) Au=RSA Enc=R(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
TLSv1
EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-R-CBC-MD5 Kx=RSA(512) Au=RSA Enc=R(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

The fields above are :

{OpenSSL ciphername}
Kx={key exchange}
Au={authentication}
Enc={symmetric encryption method}
Mac={message authentication code}
{export flag}

Nessus ID : 26928
SSL Certificate Expiry
The SSL certificate of the remote service expired Jul 18 11:58:05 2005 GMT!

Nessus ID : 15901
Deprecated SSL Protocol Usage

Synopsis:

The remote service encrypts traffic using a protocol with known weaknesses.

Description:

The remote service accepts connections encrypted using SSL 2.0, which reportedly
suffers from several cryptographic flaws and has been deprecated for several years. An
attacker may be able to exploit these issues to conduct man-in-the-middle attacks or
decrypt communications between the affected service and clients.

See also:

http://www.schneier.com/paper-ssl.pdf

Solution:

Consult the application's documentation to disable SSL 2.0 and use SSL 3.0 or TLS 1.0
instead.

Risk factor :

Medium / CVSS Base Score : 5.0

(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)

Nessus ID : 20007
PHP Mail Function Header Spoofing Vulnerability

The remote host is running a version of PHP <= 4.2.2.

The mail() function does not properly sanitize user input. This allows users to forge email
to make it look like it is coming from a different source other than the server.

Users can exploit this even if SAFE_MODE is enabled.

Solution: Contact your vendor for the latest PHP release.

Risk factor : Medium

CVE : CVE-2002-0985, CVE-2002-0986

BID : 5562
Other references : OSVDB:2111

Nessus ID : 11444
PHP Multiple Unspecified Vulnerabilities

The remote host is running a version of PHP which is older than 5.0.3 or 4.3.11

The remote version of this software is vulnerable to a set of vulnerabilities in the EXIF
module which have been fixed by the PHP Group.

See also : http://www.php.net/ChangeLog-5.php#5.0.4

http://www.php.net/ChangeLog-4.php#4.3.11

Solution : Upgrade to PHP 5.0.3 or 4.3.11

Risk factor : Medium
BID : 13143, 13163, 13164

Nessus ID : 18033
Apache Remote Username Enumeration Vulnerability

Synopsis:

The remote Apache server can be used to guess the presence of a given user name on the
remote host.

Description:

When configured with the 'UserDir' option, requests to URLs containing a tilde followed
by a username will redirect the user to a given subdirectory in the user home.

For instance, by default, requesting /~root/ displays the HTML contents from
/root/public_html/.

If the username requested does not exist, then Apache will reply with a different error
code. Therefore, an attacker may exploit this vulnerability to guess the presence of a
given user name on the remote host.

Solution:

In httpd.conf, set the 'UserDir' to 'disabled'.

Risk factor :

Medium / CVSS Base Score : 5.0

(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)
CVE : CVE-2001-1013
BID : 3335
Other references : OSVDB:637

Nessus ID : 10766
HTTP TRACE / TRACK Methods

Synopsis:

Debugging functions are enabled on the remote web server.

Description:

The remote webserver supports the TRACE and/or TRACK methods. TRACE and
TRACK are HTTP methods which are used to debug web server connections.

In addition, it has been shown that servers supporting the TRACE method are subject to
cross-site scripting attacks, dubbed XST for "Cross-Site Tracing", when used in
conjunction with various eaknesses in browsers. An attacker may use this flaw to trick
your legitimate web users to give him their credentials.

See also:

http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
http://www.apacheweek.com/issues/03-01-24
http://www.kb.cert.org/vuls/id/867593

Solution:

Disable these methods.

Risk factor :

Medium / CVSS Base Score : 5.0

(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)
Solution :

Add the following lines for each virtual host in your configuration file :
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Alternatively, note that Apache versions 1.3.34, 2.0.55, and 2.2 support disabling the
TRACE method natively via the 'TraceEnable' directive.

Plugin output :

The server response from a TRACE request is :

TRACE /Nessus2324.html HTTP/1.1

Vulnérabilités de niveau élevé

BIND 9 overflow

The remote BIND 9 DNS server, according to its version number, is vulnerable to a
buffer overflow which may allow an attacker to gain a shell on this host or to disable this
server.

Solution: upgrade to bind 9.2.2 or downgrade to the 8.x series

See also: http://www.isc.org/products/BIND/bind9.html

http://cert.uni-stuttgart.de/archive/bugtraq/2003/03/msg00075.html
http://www.cert.org/advisories/CA-2002-19.html
Risk factor: High
CVE : CVE-2002-0684
Other references : IAVA:2003-B-0001

Nessus ID : 11318
php PHP_Variables Memory Disclosure

The remote host is running a version of PHP which is older than 5.0.2 or
4.39.

The remote version of this software is vulnerable to a memory disclosure vulnerability in

PHP_Variables. An attacker may exploit this flaw to remotely read portions of the
memory of the httpd process on the remote host.

See also: http://www.php.net/ChangeLog-5.php#5.0.2

Solution: Upgrade to PHP 5.0.2 or 4.3.9

Risk factor: High

BID : 11334

Nessus ID : 15436
php4/5 Vulnerabilities

The remote host is running a version of PHP which is older than 5.0.3 or 4.3.10.

The remote version of this software is vulnerable to various security issues which may,
under certain circumstances, to execute arbitrary code on the remote host, provided that
we can pass arbitrary data to some functions, or to bypass safe_mode.

See also : http://www.php.net/ChangeLog-5.php#5.0.3

Solution : Upgrade to PHP 5.0.3 or 4.3.10

Risk factor : High

CVE : CVE-2004-1018, CVE-2004-1019, CVE-2004-1020, CVE-2004-1063, CVE-

2004-1064, CVE-2004-1065
BID : 11964, 11981, 11992, 12045
Other references : OSVDB:12410

Nessus ID : 15973
Nous avons également effectué le scan des vulnérabilités sur les VPN de Douala,
Bafoussam, Bamenda, Garoua, Kousséri, Nkongsamba, Limbé, Maroua ainsi que le
serveur web/mail de la banque.

Comme nous pouvons le constater à travers les tableaux précédents, Nessus présente les
résultats des scans de vulnérabilités de manière très didactique : pour chaque faille, on a
une présentation claire du problème et une solution simple. Cet outil peut très
certainement permettre à un attaquant d'évaluer les faiblesses d'un réseau en vue d'une
attaque, en indiquant quelles failles exploiter et avec quelles techniques. Par contre, tout
administrateur devrait prendre une longueur d'avance sur les attaquants en se servant en
premier d'un tel outil pour éviter au moins les attaques connues de Nessus.

5. TESTS D'INTRUSIONS DIVERS ET VARIES

Un test d'intrusions consiste à se mettre dans la peau d'un attaquant externe et banalisé,
disposant d'un certain degré de compétences, de ressources, de temps et de motivation
pour pénétrer un système cible. Nous commencerons par faire une description de la
procédure utilisée par un attaquant et nous simulerons par la suite des attaques sur
certaines machines qui ne représentent aucun danger pour le fonctionnement du
réseau informatique de l'entreprise.

5.1. RÉSUMÉ DES ÉTAPES DU HACKER

1. Recherche d'une proie : scan de machines. L'attaquant utilise alors des outils de scan
comme Nmap et Nessus.

2. Pratique de l'exploit : le hacker prend le contrôle de la machine en tant que root à l'aide
d'un rootkit qui exploite une faille de sécurité connue du système. On aura alors besoin
d'un rootkit connaissant plusieurs exploits.

3. Se cacher : installation de trojans et effacement des fichiers de log. Cette étape

nécessite les trojans du rootkit et des outils de nettoyage.

4. Préparer ses prochaines visites : divers trojans (actifs ou passifs) installent des
backdoors pour pouvoir se reconnecter en tant que root sans problèmes. Pour ce faire, le
hacker utilise les autres outils et fonctionnalités du rootkit.

5. Trois possibilités :

§ premièrement, le hacker utilise le système comme plate-forme de lancement d'attaque

en scannant ou en forçant d'autres systèmes,

§ autrement, il peut tenter d'étendre sa prise en cherchant des informations pour connaître
les mots de passe des comptes utilisateurs,

§ la dernière possibilité est de commettre des actions destructrices (effacement de fichiers,

vol de données, ...) sur la machine à laquelle il a déjà accès, au risque de ne plus pouvoir
se réintroduire dans le système. Cette étape peut nécessiter des sniffeurs ou des outils de
scan selon les choix d'actions à mener.

5.2. TEST D'INTRUSIONS SUR LE RÉSEAU DE LA FIRST

BANK

Les tests d'intrusions existent sous plusieurs formes : les tests d'intrusions en « boîte
noire » c'est-à-dire sans informations préalables de la cible et les tests d'intrusions
en « boîte blanche » c'est-à-dire avec une connaissance préalable de la cible. De même
ces tests d'intrusions peuvent être aussi bien internes qu'externes.

5.2.1. Tests d'intrusions externes en « boîte noire »

Nous engageons les tests d'intrusions externes sur le réseau avec la seule connaissance du
site internet afrilandfirstbank.com qui est une information non réservée à priori. Les scans
avec Nmap et Nessus nous ont permis d'avoir l'adresse IP du serveur web à savoir
195.24.201.50.

5.2.1.1. Les bases Whois6(*)

La base Whois de AfriNIC répertorie tous les sous-réseaux de la région Afrique et leurs
propriétaires respectifs. Cela permet dans un premier temps de commencer par vérifier
que les adresses IP communiquées correspondent bien à l'organisation cible.

5.2.1.2. Les bases DNS

a) L'utilitaire nslookup

L'utilitaire nslookup est intégré à BIND qui permet de procéder à des requêtes DNS à des
fins de déboguage. Nslookup fonctionne dans deux modes :

§ mode interactif (lorsqu'il est évoqué sans arguments),

§ mode non-interactif (lorsqu'il est évoqué avec les paramètres requis pour une requête
précise).

Cet outil permet d'utiliser un grand nombre d'options et paramètres qui peuvent être
consultés en exécutant la commande « man nslookup » sur Linux.

L'utilisation de cet outil sur le serveur DNS nous a permis d'avoir plus d'informations sur
les noms d'hôtes des serveurs DNS de la banque.

b) L'utilitaire DIG

L'utilitaire D.I.G. (Domain Internet Groper) est un outil similaire à nslookup (qui est
destiné à remplacer) et est aussi livré avec les récentes versions de BIND. Il permet de
lancer des requêtes DNS dans une ligne de commande et affiche les réponses dans un
format compatible avec les enregistrements BIND.

La syntaxe de dig est de la forme : dig [@server] domain query-type

La sortie d'une commande dig commence par une ligne avec des informations sur la
commande même (version de dig) ainsi que sur le serveur utilisé. Suivent ensuite les
options utilisées pour la requête, la requête envoyée et la réponse obtenue. La partie
consacrée à la réponse est constituée de la réponse elle-même, d'une section sur l'autorité
de la zone concernée par la requête ainsi que d'une section pour des informations
complémentaires. La fin de la sortie est constituée d'informations sur le temps écoulé pour
traiter la requête, la machine à partir de laquelle elle a été lancée ainsi que la taille des
données envoyées et reçues.

5.2.1.2. Les moteurs de recherche

Les moteurs de recherche permettent également d'obtenir de nombreux renseignements

sur la cible. Nous avons utilisé dans nos travaux différents moteurs de recherche
notamment Google.com, domaintools.com et Yahoo.com. Ceci nous a permis d'avoir des
informations sur les serveurs DNS de la banque, le serveur web/mail entre autres.

5.2.1.3. Détection des systèmes et des services, cartographie

Nous allons maintenant établir la cartographie de la plate-forme cible. A ce stade, nous ne

sommes plus furtifs, car nous allons effectuer des requêtes directement sur les systèmes
cibles.

Pour déterminer les machines situées entre les serveurs cibles et nous, nous avons étudié
le routage des paquets échangés. Nous avons utilisé dans cette section les
outils traceroute et la technique du « firewalking » à travers l'outil hping2.

A ce stade, nous avons suffisamment d'informations sur la société pour procéder à une
véritable intrusion en suivant les étapes déjà décrites dans la section 4.1. pour pénétrer le
réseau et prendre le contrôle. Nous ne pouvons cependant pas continuer ce processus car
nos tests s'effectuent directement sur le réseau de production et un quelconque
disfonctionnement peut être redoutable.

Les tests d'intrusions sur les réseaux informatiques sont internes pour la plupart et donc
nous nous proposons dans la section suivante de procéder aux tests d'intrusions internes
en « boîte blanche » question d'évaluer la résistance du réseau à ce type d'attaques.

5.2.2. Tests d'intrusions internes en « boîte blanche »

Les tests d'intrusions internes en « boîte blanche » ont essentiellement consisté à sniffer
sur les réseaux LAN du siège en mode promiscus avec l'outil Wireshark. L'analyse des
paquets ainsi capturés a pour but de déterminer le niveau protection de données sur le
réseau.

4.2.2.1. Présentation et utilisation de Wireshark

Wireshark est un des analyseurs réseaux les plus populaires du monde. Cet outil
extrêmement puissant fournit des informations sur des protocoles réseaux et applicatifs à
partir de données capturées sur un réseau.

Comme un grand nombre de programmes, Wireshark utilise la librairie

réseau pcap7(*) pour capturer les paquets.
La force de Wireshark vient de :

§ sa facilité d'installation,

§ sa simplicité d'utilisation de son interface graphique,

§ son très grand nombre de fonctionnalités.

Wireshark fut appelé Ethereal jusqu'en 2006 où le développeur principal décida de

changer son nom en raison de problèmes de copyright avec le nom de Ethereal qui était
enregistré par la société qu'il décida de quitter en 2006.

L'analyse des paquets capturés sur le réseau interne de la banque à travers le logiciel Caen
& Abel n'a révélé aucune faille pouvant être exploitée en interne.

5.2.2.2. Intrusions internes divers

La plupart des tests d'intrusions internes (vol de mot de passe, usurpation d'IP, attaque de
force brute) sur les réseaux informatiques utilisent l'ingénierie sociale qui consiste à
manipuler les êtres humains c'est-à-dire utiliser la naïveté et la gentillesse exagérée des
utilisateurs du réseau pour obtenir des informations sur ces derniers. Ces informations
sont par la suite exploitées pour obtenir soit des privilèges supplémentaires soit pour
accéder aux services et données qui leur sont interdits.

C'est la raison pour laquelle la politique de sécurité doit être globale et intégrer les
facteurs humains (par exemple la sensibilisation des acteurs aux problèmes de sécurité).

La tâche des attaquants peut être plus compliquée si les administrateurs et responsables de
sécurité du réseau détectent en temps opportun les tentatives d'intrusions. Pour cela, ils
peuvent utiliser les IDS (Intrusion Detection System) pour détecter et bloquer les
tentatives d'intrusions. La section suivante est consacrée à un des IDS les plus utilisés du
moment à savoir « Snort ».

6. DETECTION D'INTRUSIONS AVEC « SNORT »

Snort est un projet Open Source de détection d'intrusion sur le réseau open-source
fonctionnant sur les systèmes Windows et Linux. Capable d'analyser en temps réel le
trafic et de consigner le transit des paquets de données sur le réseau IP, il peut réaliser une
analyse de protocole, une recherche sur le contenu et peut être utilisé pour détecter un
nombre important d'attaques réseau connues et permet ainsi d'alerter quant aux tentatives
d'intrusion sur votre réseau.

Nous avons utilisé dans nos travaux une version linux de Snort disponible sur la
distribution Debian version 4.
Les étapes d'installation de snort sont les suivantes :

§ les prérequis pour l'installation de snort,

§ ' installation de snort,

§ test de fonctionnement,

§ liaison snort avec mysql,

§ ' mise en place d'ACID (Interface php pour visualiser les logs snort).

6.1. LES PRÉREQUIS POUR L'INSTALLATION DE SNORT

Les packages suivants sont requis pour le fonctionnement de snort sur linux debian 4 :

§ mysql-server-5.0,

§ mysql-client-50,

§ php5-mysql,

§ apache2.

Remarque : sur Debian, il suffit de taper la commande apt-get install nom_du_paquet

6.2. INSTALLATION DE L'OUTIL SNORT

Vous pouvez télécharger snort, paquet source ou binaire, à partir du site

officiel: http://www.snort.org/ .

Dans un terminal shell exécutez les commandes suivantes :

À partir du binaires
À partir de source
# tar -xzvf snort-x.x.x # rpm -ivh snort-mysql-2.6.x.rpm

# cd snort-x.x.x

# make

# cd make install
Sur Debian il suffit juste d'exécuter la commande apt-get install snort.

Après l'installation, nous allons actuellement installer les règles de snort. Ces règles
peuvent être téléchargées à partir de l'adresse suivante : http://www.snort.org/.
La mise à jour de ces règles lorsqu'on n'utilise pas la version commerciale de snort est
décalée d'un mois.

# cp snort-pr-x.x.tar.gz /etc/snort

# cd /etc/snort

# tar -xzvf snort-pr-x.x.tar.gz

Les règles sont installées dans /etc/snort/rules. Maintenant, il faut éditer le fichier de
configuration snort (/etc/snort/snort.conf) et spécifier le réseau sur lequel l'IDS travaille. Il
faut pour cela modifier les variables suivantes:

«var HOME_NET any» à «var HOME_NET 192.168.99.0/24» (Selon votre plage)

«var EXTERNAL_NET any» à «var EXTERNAL_NET !$HOME_NET» (On ne fait

confiance à aucun réseau)

«var DNS_SERVERS $HOME_NET» à «var HOME_NET 195.24.194.177» (Adresse de

notre DNS)

«var RULE_PATH» à «var RULE_PATH /etc/snort/rules»

Il convient de choisir les règles de détection à activer selon l'environnement à surveiller,

en commentant ou décommentant les lignes d'appels des règles.

6.3. TEST DE FONCTIONNEMENT :

6.3.1. Mode sniffeur:

Ce mode permet d'écouter les paquets TCP/IP circulant dans le réseau et les afficher sur
l'écran. Pour cela, il suffit d'utiliser la commande snort avec les options -v et -vd.

6.3.2. Mode paquet logger :

Ce mode permet de sniffer le trafic des paquets TCP/IP et journalise les logs dans un
répertoire déjà créé. Pour cela nous avons utilisé l'option -l ./log de la commande snort.

6.3.3. Mode NIDS :

Le mode NIDS permet d'analyser le trafic réseau des paquets TCP/IP en le comparant à
des règles spécifiées dans le fichier « snort.conf ». Ce guide est déjà dédié pour la mise en
place de snort en mode NIDS.

Vous pouvez lancer snort avec cette commande :

snort -c /etc/snort/snort.conf -D
L'option «c»: permet de spécifier quelles sont les règles qui seront actives.

L'option «D» : permet de lancer snort en mode daemon (c'est-à-dire en arrière plan).

6.4. LIAISON DES LOGS DE SNORT AVEC MYSQL :

Un fois connecté sur la base mysql en tant qu'administrateur « mysql -u root -p », il

convient de suivre la procédure suivante afin de créer la base snort :

create database snort ; //création de la base snort

use mysql ; //on se place ici pour créer l'utilisateur qui gèrera la base snort

insert into user values ('localhost', 'root', password('root')); //création de l'utilisateur de la

base de données snort

grant ALL PRIVILEGES on snort.* to root@localhost identified by 'root' WITH

GRANT OPTION; //attribution des droits de la base snort à l'utilisateur root
Une fois ces commandes effectuées, il suffit d'exécuter le script sql fourni avec la
distribution de snort.

Mysql> source /etc/snort/contrib/create_mysql

6.5. CRÉATION DE NOUVELLES RÈGLES

Bien que le site officiel de Snort propose des règles prêtes à l'emploi et régulièrement
mises à jour, il peut être intéressant de créer ses propres règles afin d'adapter au mieux
snort au réseau qu'il doit surveiller et protéger. Par convention, les nouvelles règles
personnelles sont à placer dans le fichier local.rules.

Exemple de règle :

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB- ATTACKS /bin/ls
command attempt"; uricontent:"/bin/ls"; nocase; classtype:web-application-attack;

Cette règle permet de générer une alerte quand un paquet provient d'un couple
(adresse:port) quelconque, est à destination des serveurs HTTP définis dans snort.conf, et
contient la chaîne «/bin/ls » dans l'URI. Le message de l'alerte sera « WEB-ATTACKS
/bin/ls command attempt ». Cette attaque sera classée dans la classe web-application-
attack (priorité medium par défaut).
Il est bien sûr impossible d'être exhaustif ici pour décrire le format des règles Snort. Le
manuel utilisateur disponible sur le site officiel indique comment utiliser au mieux le
langage des signatures de Snort.

6.6. MISE EN PLACE D'ACID :

ACID est une interface PHP qui permet de visualiser les alarmes générées par snort.
ACID dépend de ces deux paquets :

§ Adodb : Contient des scripts PHP génériques de gestion de bases de données. Nous
avons utilisé la librairie PHP libphp-adodb de Debian.

§ PHPlot : librairie de scripts PHP utilisée par ACID pour présenter graphiquement
certaines données statistiques. PHPlot peut être téléchargé sur le site.

Après avoir téléchargé ACID et PHPlot, il faut installer ces derniers dans la racine
d'Apache de la manière suivante :

cd /var/www/

tar -xvzf acid*

tar -xvzf phplot*

Une fois l'installation terminée, il convient de configurer ACID dans son fichier de
configuration /var/www/acid/acid_conf.php. En ce qui nous concerne, certains champs
ont été modifiés comme suit :

§ $DBlib_path="/usr/share/php/adodb";

§ $Chartlin_path="/var/www/phplot-5.0.5";

§ alert_dbname="snort"

§ alert_host="localhost"

§ alert_user="root"

§ alert_password="root"

Voilà, maintenant nous pouvons vérifier qu'ACID est bien configuré en saisissant
l'url http://localhost/acid dans le navigateur.

Le résultat de ce test dans notre cas est le suivant :

Nous avons par cette dernière étape, terminé l'installation et l'utilisation de snort. Nous
allons dans les pages suivantes proposer un certain nombre de recommandations en vue
de l'amélioration de la sécurité du réseau informatique de la First Bank.

7. RECOMMANDATIONS

Les recommandations de cette partie ne sont qu'une conséquence des scans, des tests
d'intrusions effectués dans les précédentes sections ainsi que de notre expérience en audit
de sécurité.

R1 : FERMETURE DES PORTS NON UITLISES

Les ports non utilisés peuvent être exploités à tout moment par les attaquants comme
porte d'entrée dans le système.

C'est le cas des ports 21 (ftp) et 3306 (mysql) du serveur web/mail qui étaient ouverts au
moment de notre scan mais aucun service à l'écoute.

C'est le même constat pour les ports Telnet et SSH qui sont ouverts en même temps sur
les VPN des différentes agences. Il faut dire que SSH a été crée pour pallier les
insuffisances de Telnet et donc, le port Telnet doit être fermé en cas d'utilisation de SSH.

De même les ports, pop3 et pop3s, imap et imaps sont ouverts au moment de notre scan.
Ceux de ces ports qui ne sont pas utilisés doivent être fermés parce qu'ils présentent un
risque pour la sécurité.

R2 : RENDRE LES SERVEURS FURTIFS

Les configurations par défaut doivent être évitées au niveau des serveurs. Les
informations comme le type et la version du système d'exploitation utilisé, les versions
des services qui écoutent sur les différents ports doivent être cachées et rendues
inaccessibles lors des scans. Les sections réservées à cet effet se trouvent dans les fichiers
de configuration des différents services.

Les fichiers de configuration des différents serveurs doivent être édités et modifiés pour
éviter d'avoir des serveurs dits « bavards ».

Pour le serveur Apache par exemple, il faut ajouter les lignes suivantes dans le fichier
http.conf :

ServerTokens Prod
ServerSignature Off

R3 : DESARMER LA METHODE TRACE DE HTTP

La méthode TRACE du serveur http est utilisée pour le débogage des connections au
niveau du serveur web. Le diagnostic de Nessus propose un processus pour désarmer cette
méthode.

R4 : LA MISE A JOUR DES APPLICATIONS

L'évolution des applications ne concerne pas seulement les commodités d'utilisation au

niveau de l'interface et l'ajout des fonctions supplémentaires mais aussi la sécurité de ces
applications. Ce dernier aspect n'est pas souvent perçu par l'utilisateur non averti qui est
de ce fait insensible à la mise à jour des applications. Ainsi plusieurs versions d'une même
application offrent souvent les mêmes fonctions ainsi que les mêmes commodités
d'utilisation mais les dernières versions corrigent souvent certains détails de sécurité qui
ne sont pas facilement perceptibles.

Le diagnostic fait à travers Nessus plus haut dans ce document a notamment indiqué que
les serveurs Apache et SSL étaient exposés à certaines vulnérabilités du simple fait que
ces derniers n'étaient pas à jour.

R5 : RENFORCEMENT DE LA SECURITE DES MOTS DE PASSE ET CLES

CRYPTOGRAPHIQUES

SECURITE DES MOTS DE PASSE

Les mots de passe par défaut au niveau des serveurs, des routeurs ainsi que des
applications réseaux doivent être supprimés et remplacés par des mots de passe plus sûrs
dès la première utilisation de ces derniers. Bien plus, les mots de passe doivent être
choisis de manière à échapper aux attaques de type dictionnaire (noms, prénoms, date de
naissance, mots du langage courant) et aux attaques de force brute.

Pour combattre ce type d'attaques il est recommandé de :

§ ne pas utiliser des mots de votre langage courant,

§ choisir des mots de passe longs (souvent au moins 8 caractères), avec une suite de
caractères totalement aléatoires et avec des caractères spéciaux,

§ alterner les majuscules et les minuscules.

CRYPTOGRAPHIE

L'algorithme de cryptographie utilisé lors de l'envoi des données sur le réseau est DES. Ce
qui pose un problème de sécurité car cet algorithme a été cassé en 1998 et remplacé par
AES.

Nous proposons l'utilisation d'un protocole de cryptographie basé sur AES et RSA. AES
est le nouvel algorithme de cryptographie symétrique non encore cassé. RSA est le
meilleur algorithme de cryptographie asymétrique recommandé en ce moment.

L'utilisation RSA nécessite pour autant la mise en place d'une infrastructure à clefs
publiques (PKI) pour garantir l'authenticité des clés publiques. La banque doit pour cela
choisir une autorité de certification sûre et reconnue mondialement.

Par ailleurs, le stockage des certificats nécessaires au fonctionnement de HTTPS, IMAPS,

... doit être effectué avec la plus grande prudence (le responsable devra éviter d'en
conserver une copie dans un dossier mail par exemple).

R6 : DETECTION D'INTRUSIONS

Il faut installer à divers points stratégiques du réseau des IDS pour détecter les tentatives
d'intrusions (scan des ports, scan des vulnérabilités). Un processus d'installation et de
configuration de Snort a été proposé dans ce document. L'entreprise pourra acquérir la
version commerciale de ce produit pour bénéficier des mises à jour de la base des
vulnérabilités en temps réel.

Bien plus, l'installation d'une sonde Ntop au coeur du réseau est nécessaire pour visualiser
facilement les machines qui utilisent le réseau. C'est juste visuel mais très pratique.

R7 : ATTAQUES SUR LES PROTOCOLES

Nous allons proposer dans cette section les parades à prendre pour éviter les attaques sur
certains protocoles : ARP, DHCP.

ARP-POISONING

La solution la plus immédiate consiste à saisir manuellement sur chaque poste la table de
toutes les adresses physiques présentes sur le réseau local. Si elle est immédiate, cette
solution est quasiment inapplicable compte tenu du nombre d'hôtes connectés au réseau
local.

Une solution correcte consiste à mettre en place un serveur DHCP avec une liste «fermée»
de correspondance entre adresses physiques (MAC) et IP. Relativement à la solution
précédente, la liste exhaustive des adresses physiques est centralisée sur le serveur DHCP.
On peut ensuite configurer la journalisation du service pour que toute requête DHCP
relative à une adresse MAC inconnue génère un courrier vers l'administrateur système ou
réseau. Pour cela, l'administrateur réseau peut utiliser sous Windows l'outil DHCPCMD
pour configurer le serveur dhcp à la ligne de commande.

Cette deuxième solution convient également pour pallier les attaques sur le serveur
DHCP.

DNS ID SPOOFING ET DNS CACHE POISONING

Pour éviter ces diverses attaques sur le serveur DNS, il faut :

§ configurer votre serveur DNS pour qu'il ne résolve directement que les noms de
machine du réseau sur lequel il a autorité.

§ autoriser seulement des machines internes à demander la résolution de noms de

domaines distants.

§ mettre à jour ou changer les logiciels assurant le service DNS pour qu'ils vous protègent
de ces diverses attaques.

R8 : VEILLE SECURITE

Face aux multiples failles de sécurité des systèmes d'information et des réseaux
informatiques en particulier, seule la veille permet de répondre aux objectifs de continuité
de service. Pour assurer cette veille, les responsables sécurité et veille doivent surveiller
l'apparition de nouvelles vulnérabilités et alerter sur les menaces ciblant les systèmes et
réseaux informatiques.

La veille sécurité permet aux RSSI et à leurs équipes d'anticiper les incidents de sécurité :
intrusion, attaque virale, DoS, ...

La DARPA (Defense Advanced Research Projects Agency) a décidé la mise en place en

1988, à la suite d'une attaque sur Internet, des centres d'alerte et de réaction aux attaques
informatiques. Ces CERT proposent une base de données sur les alertes de sécurité. Ces
bases publiques sont accessibles à travers le site internet du CERT/CC www.cert.org.

En France, plusieurs CSIRT ont été crées :

§ le CERTA est le CERT dédié au secteur de l'administration française ;

§ le CERT-IST est le CERT dédié au secteur de l'Industrie, des Services et du Tertiaire

(IST) ;

§ le CERT-RENATER est le CERT dédié à la communauté des membres du GIP

RENATER (Réseau National de télécommunications pour la Technologie, l'Enseignement
et la Recherche).

Enfin, l'entreprise peut acquérir la version commerciale du logiciel d'analyse des

vulnérabilités connues Nessus dont l'installation, la configuration ainsi que l'utilisation ont
été effectués dans le présent document.

R9 : AUDITS INTERNES DE SECURITE

Des audits internes de sécurité doivent être réalisés de manière permanente et les
recommandations intégrées à la politique de sécurité.

La politique de sécurité doit être ainsi animée par des personnes différentes de celles qui
l'appliquent.

La séparation des responsabilités est essentielle pour l' application du cadre commun de la
Sécurité. En effet, une personne ne doit pas se trouver à la fois en position de donneur
d'ordre, de réalisateur et de contrôleur de bon achèvement. Cela permet d'éviter à ces
personnes d'être en même temps juge et partie.

DEUXIEME PARTIE : DEFINITION

DE LA POLITIQUE DE SECURITE
DU RESEAU INFORMATIQUE DE
LA FIRST BANK
Une politique de sécurité réseau est un document générique qui définit des règles à suivre
pour les accès au réseau informatique et pour les flux autorisés ou non, détermine
comment les politiques sont appliquées et présente une partie de l'architecture de base de
l'environnement de sécurité du réseau.

La mise en place d'une politique de sécurité adéquate est essentielle à la bonne

sécurisation des réseaux et systèmes d'information. L

1. OBJECTIF D'UNE POLITIQUE DE SECURITE

RESEAU

La définition d'une politique de sécurité n'est pas un exercice de style mais une démarche
de toute l'entreprise visant à protéger son personnel et ses biens d'éventuels incidents de
sécurité dommageables pour son activité.

La définition d'une politique de sécurité réseau fait intégralement partie de la démarche

sécuritaire de l'entreprise. Elle s'étend à de nombreux domaines, dont les suivants :

§ audit des éléments physiques, techniques et logiques constituant le système

d'information de l'entreprise ;

§ sensibilisation des responsables de l'entreprise et du personnel aux incidents de sécurité

et aux risques associés ;

§ formation du personnel utilisant les moyens informatiques du système d'information ;

§ structuration et protection des locaux abritant les systèmes informatiques et les

équipements de télécommunications, incluant le réseau et les matériels ;

§ ingénierie et maîtrise d'oeuvre des projets incluant les contraintes de sécurité dès la
phase de conception ;

§ gestion du système d'information de l'entreprise lui permettant de suivre et d'appliquer

les recommandations des procédures opérationnelles en matière de sécurité;

§ définition du cadre juridique et réglementaire de l'entreprise face à la politique de

sécurité et aux actes de malveillance, 80 pour 100 des actes malveillants provenant de
l'intérieur de l'entreprise ;

§ classification des informations de l'entreprise selon différents niveaux de confidentialité

et de criticité.

Avant de définir une politique de sécurité réseau, il faut en connaître les objectifs ou
finalités.

1.1. DÉFINIR UNE ANALYSE DE RISQUE

Déterminer les éléments critiques d'une entreprise est une tâche délicate, qui prête souvent
à discussion, chaque service ou département se considérant comme un secteur clé.

Un bon moyen de parvenir à déterminer ces éléments critiques consiste à mener avec les
responsables de l'entreprise une analyse de risque.

Une telle analyse consiste tout d'abord à identifier les ressources ou les biens vitaux à
l'entreprise.

Ces derniers peuvent être de plusieurs ordres :

§ matériel,

§ données,

§ logiciels,
§ personnes.

Il convient pour chacune de ces ressources vitales, d'associer les trois éléments suivants :

§ conséquence : il s'agit de l'impact sur l'entreprise de l'exploitation d'une faiblesse de

sécurité. Estimer une conséquence d'une faiblesse de sécurité nécessite généralement une
connaissance approfondie de l'entreprise et requiert l'ensemble des experts de cette
dernière.

§ menace : la menace désigne l'exploitation d'une faiblesse de sécurité par un attaquant,

qu'il soit interne ou externe à l'entreprise. La probabilité qu'un événement exploite une
faiblesse de sécurité est généralement évaluée par des études statistiques, même si ces
derniers sont difficiles à réaliser.

§ vulnérabilité : il s'agit d'une faiblesse de sécurité qui peut être de nature logique,
physique, etc. Une vulnérabilité peut découler d'une erreur d'implémentation dans le
développement d'une application, erreur susceptible d'être exploitée pour nuire à
l'application. Elle peut également provenir d'une mauvaise configuration. Elle peut enfin
avoir pour origine une insuffisance de moyens de protection des biens critiques, comme
l'utilisation de flux non chiffrés, l'absence d'une protection par filtrage de paquets etc.

La connaissance de ces faiblesses de sécurité n'est possible que par des audits réguliers de
sécurité effectués soit par l'équipe sécurité, soit par des consultants externes.

1.2. PRINCIPES GÉNÉRIQUES D'UNE POLITIQUE DE

SÉCURITÉ RÉSEAU

Afin d'éviter un certain nombre d'écueils classiques, une politique de sécurité réseau doit
respecter un ensemble de principes génériques. Ces principes permettent notamment à
chacun de bien cerner les enjeux de la rédaction d'un document de politique de sécurité,
qui n'est pas un document comme les autres.

Un document de politique de sécurité peut être écrit de plusieurs manières, allant d'un
texte unique à une infrastructure de politique de sécurité. Le choix d'écrire un ou plusieurs
documents est le plus souvent dicté par la taille de l'entreprise. Plus l'entreprise est
importante, plus il est intéressant de créer des documents séparés, chaque niveau faisant
référence au niveau supérieur.

Petites, moyennes et grandes entreprises s'exposent dans l'absolu aux mêmes risques si
elles n'émettent pas de politique de sécurité. La politique de sécurité dicte la stratégie de
sécurité de l'entreprise de manière claire et précise. Le fond et la forme sont donc
primordiaux.

Quelle que soit la nature de biens produits par l'entreprise, sa politique de sécurité réseau
doit satisfaire les points suivants :

§ identification : information permettant d'indiquer qui vous prétendez être. Une

identification élémentaire est le nom d'utilisateur que l'on saisit dans un système
informatique. Une identification plus évoluée peut être le relevé d'empreinte digitale,
l'analyse faciale, rétinienne bref les méthodes biométriques ;

§ authentification : information permettant de valider l'identité pour vérifier que vous

êtes celui que vous prétendez être. Une authentification élémentaire est le mot de passe
que vous entrez. Une authentification forte combine une chose que vous possédez, une
chose que vous connaissez (code personnel par exemple) et une chose que vous savez
faire (par exemple une signature) ;

§ autorisation : information permettant de déterminer quelles seront les ressources de

l'entreprise auxquelles l'utilisateur identifié et autorisé aura accès ainsi que les actions
autorisées sur ces ressources. Cela couvre toutes les ressources de l'entreprise ;

§ confidentialité : ensemble des mécanismes permettant qu'une communication de

donnée reste privée entre un émetteur et un destinataire. La cryptographie ou le
chiffrement des données est la seule solution fiable pour assurer la confidentialité des
données ;

§ intégrité : ensemble des mécanismes garantissant qu'une information n'a pas été
indûment modifiée ;

§ disponibilité : ensemble des mécanismes garantissant que les ressources de l'entreprise

sont accessibles pour qui a droit, que ces dernières concernant l'architecture réseau, la
bande passante, le plan de sauvegarde ... ;

§ non répudiation : mécanisme permettant de garantir qu'un message ne peut être renié
par son émetteur ;

§ traçabilité : ensemble des mécanismes permettant de retrouver les opérations réalisées

sur les ressources de l'entreprise. Cela suppose que tout événement applicatif soit archivé
pour investigation ultérieure.

1.2.1. Distinguer la politique de la procédure

La politique est l'extension du besoin de l'entreprise. La procédure est l'implémentation du

besoin. Il est donc impératif de distinguer les deux.

L'objectif d'une politique est d'énoncer les résultats à obtenir, et non les moyens par
lesquels les obtenir. C'est la raison pour laquelle il convient d'écrire :

§ l'accès à distance au réseau de l'entreprise (intranet) est autorisé à la condition exclusive

d'une authentification forte de l'individu via une connexion réseau chiffrée. L'accès à
Internet depuis le réseau interne de l'entreprise (intranet) est protégé contre les attaques
éventuelles, incluant les virus informatiques.

et non :

§ l'accès externe au réseau interne de l'entreprise est autorisé par un certificat électronique
validé auprès de la PKI de l'entreprise. De plus la connexion réseau est chiffrée par le
protocole IPSec. L'accès à Internet traverse un pare-feu filtrant le protocole IP. De plus, le
pare-feu est couplé à un système antivirus, qui analyse tous les e-mails et attachements
transitant entre Internet et le réseau interne de l'entreprise.

Une politique de sécurité est moins touchée par l'évolution technologique, car elle décrit
des besoins et non des moyens. Malgré tout, une politique de sécurité doit être revue tous
les deux ans afin de tenir compte des modifications organisationnelles de l'entreprise.

1.2.2. Contraintes d' application des politiques de sécurité réseau

Quelles que soient l'entreprise concernée et la politique de sécurité réseau définie,

l'application d'une politique de sécurité est confrontée aux trois contraintes suivantes :

§ technique : la technologie a ses limites. Certaines applications sont difficilement

filtrables par un pare-feu ou ne tolèrent pas que l'adresse source de l'expéditeur soit
modifiée au profit de celle du pare-feu par une technique de NAT. Par exemple, les outils
de partage de fichiers entre clients, appelés peer-to-peer, sont très difficile à bloquer. Par
ailleurs, des services réseau tels que H323 (ensemble de protocoles de communication de
la voix, de l'image et de données sur IP) et le protocole IPSec n'apprécient pas le NAT ;

§ économique : pour une solution technique donnée, une contrainte d'ordre économique
peut surgir, si bien qu'il faut parfois choisir une solution moins chère, même si elle ne
répond pas exactement aux besoins de sécurité. Une telle situation revient à une
acceptation d'un risque de sécurité, à condition que le décideur dispose d'une réelle
synthèse des risques, c'est-à-dire d'une description des menaces et de leur probabilité
d'occurrence, ainsi que de leurs conséquences ;

§ politique : pour une solution technique donnée, économiquement accepté, une

contrainte d'ordre politique peut survenir. Sans justification logique ou technique, une
telle contrainte peut engendrer de réels problèmes de sécurité. Ce type de situation
requiert également l'acceptation de risque de sécurité.

Le principe de propriété:

Le principe de propriété exige qu'une politique de sécurité décrive, pour chaque ressource
d'une entreprise, quels en sont les propriétaires. On doit entendre par « propriété », non
pas l'aspect légal de la propriété d'un bien, mais son aspect fonctionnel, qui consiste à
assumer la pérennité et la protection.

Les propriétaires d'une ressource en ont la responsabilité et dictent les règles d'accès à
cette ressource. Un schéma classique établit une distinction entre le propriétaire,
l'administrateur et l'utilisateur d'une ressource.

Le propriétaire définit les règles d'utilisations de ses ressources et les donne à

l'administrateur, lequel a pour rôle de les appliquer aux demandes d'un utilisateur. En cas
de problème, l'administrateur demande au propriétaire une dérogation aux droits d'accès.
L'utilisateur n'est jamais en contact direct avec le propriétaire.

Par exemple, tous les équipements informatiques de la First Bank sont la propriété de la
DSIG. Le DSIG définit donc les règles d'utilisation des équipements réseau et les confie à
l'Administrateur réseau qui tient lieu d'administrateur des équipements et applications
réseaux. Toutes les requêtes utilisateurs en ce qui concerne le matériel et les applications
réseaux s'adressent à l'Administrateur réseau et jamais au DSIG : c'est une délégation de
responsabilité.

Le fonctionnement est illustré sur la figure suivante :

L'autorité:

Une direction générale a autorité sur toutes les ressources de l'entreprise. Elle délègue
généralement cette autorité aux responsables de départements, qui peuvent à leur tour
mandater un groupe au sein de leur département.

Dans tous les cas, l'équipe sécurité, mandatée par la direction générale, dispose de
l'autorité de vérifier l'application de la politique de sécurité sur toutes les ressources de
l'entreprise.
L'universalité:

Le principe d'universalité veut qu'une politique de sécurité dicte des règles qui doivent
être non seulement validées, quels que soient les aspects techniques mis en jeu, mais aussi
appliquées.

L'idée est que la conception initiale d'une politique de sécurité et de ses domaines
d' application doit être essentielle et fondamentale, de sorte à éviter une évolution
inconsciente de la politique de sécurité, de ses guides et de ses recommandations.

L'orthogonalité:

Le principe d'orthogonalité précise qu'une politique de sécurité peut être découpée en sous
parties distinctes, sous la condition que ces sous parties forment un ensemble cohérent.

La simplicité:

Une politique de sécurité est simple dans sa structure et claire dans les règles qu'elle
énonce. Toute mauvaise compréhension d'une règle de la politique de sécurité conduit à
ce qu'elle ne soit pas appliquée ou qu'elle le soit mal.

L'auditabilité:

Une politique de sécurité est auditable. Cela demande que les règles qu'elle énonce
puissent être vérifiées dans les faits. Bien qu'il soit difficile de mesurer toute chose, la
politique de sécurité est écrite dans cet objectif. C'est d'autant vrai qu'un audit de sécurité
se réfère en priorité au document de politique de sécurité.

La hiérarchie:

Une politique de sécurité est structurée en une politique de sécurité de haut niveau, qui
englobe les politiques de sécurité couvrant des domaines précis. Ces mêmes politiques de
sécurité pointent sur des procédures qui détaillent des aspects techniques de domaine visé.

L'idée sous-jacente est qu'une politique de sécurité doit être structurée en sous politiques,
dans une approche allant du plus général au plus spécifique. Il est admis que deux à trois
niveaux de politique de sécurité conviennent dans la plupart des cas.

L'approbation:

Une politique de sécurité est approuvée par la direction générale, et ce, de manière
officielle. De plus la direction générale et les ressources humaines s'engagent à réprimer
toute violation de la politique de sécurité qui pourrait mettre en péril la survie de
l'entreprise.

Les cadres juridique et réglementaire couvrant la politique de sécurité et les actes de

malveillance sont connus de tout le personnel de l'entreprise.
 1.3. NIVEAUX D'UNE POLITIQUE DE SÉCURITÉ RÉSEAU

La déclinaison d'une politique de sécurité en sous niveaux n'est pas chose facile. Cela
demande notamment une parfaite connaissance du domaine visé. Seule l'expérience de
l'entreprise et de son historique permet d'éviter les pièges et surtout de ne retenir que les
éléments principaux et critiques.

La figure suivante illustre une classification en niveaux :

1.4. LES DIFFÉRENTS TYPES DE POLITIQUES DE SÉCURITÉ

Une politique de sécurité peut être trop permissive ou au contraire trop restrictive. Dans le
premier cas, elle risque de présenter une faiblesse de sécurité par son coté laxiste. Dans le
second, elle peut devenir inapplicable du fait de règles trop strictes.

Comme dans de nombreux domaines, seule l'expérience guide l'écriture d'une politique de
sécurité ainsi que ces règles. Dans tous les cas, plus les ressources sont critiques, plus les
règles doivent être strictes.

Quelle que soit la politique de sécurité définie, il faut savoir gérer les exceptions ou
entorses aux règles de sécurité. Ces exceptions sont connues, limitées, documentées et
sous contrôle.

Toutes déviation de la politique de sécurité fait l'objet d'une revue spécifique afin de
corriger la faiblesse de sécurité engendrée et les exceptions associées.

Une politique de sécurité réseau couvre les éléments suivants :

§ Sécurité de l'infrastructure : couvre la sécurité logique et physique des équipements et

des connexions réseau, aussi bien internes que celles fournies par des fournisseurs réseau.

§ Sécurité des accès : couvre la sécurité logique des accès locaux et distants aux
ressources de l'entreprise, ainsi que la gestion des utilisateurs et de leurs droits d'accès au
système d'informations de l'entreprise.

§ Sécurité du réseau intranet face à Internet ou aux autres parties : couvre la sécurité
logique des accès aux ressources de l'entreprise (Intranet) et l'accès aux ressources
extérieures (Extranet).

Pour résumer, la définition d'une politique de sécurité réseau vise tout à la fois à définir
les besoins de sécurité de l'entreprise, à élaborer des stratégies de sécurité afin de protéger
les biens les plus critiques et à définir le référentiel des contrôles de sécurité.

2. STRATEGIE DE SECURITE RESEAU

L'établissement de stratégie de sécurité exige de prendre en compte l'historique de

l'entreprise, l'étendue de son réseau, le nombre d'employés, la sous-traitance avec des
tierces parties, le nombre de serveurs, l'organisation du réseau, etc.

D'une manière générale, une bonne stratégie de sécurité vise à définir et mettre en oeuvre
des mécanismes de sécurité, des procédures de surveillance des équipements de sécurité,
des procédures de réponse aux incidents de sécurité et des contrôles et audits de sécurité.
Elle veille en outre à ce que les dirigeants de l'entreprise approuvent la politique de
sécurité de l'entreprise.

Nous allons montrer comment élaborer une stratégie de sécurité et donnerons les règles
élémentaires à considérer dans son élaboration, ainsi que quelques exemples de stratégie
de sécurité.

2.1. MÉTHODOLOGIE POUR ÉLABORER UNE STRATÉGIE DE

SÉCURITÉ RÉSEAU

Nous décrivons dans ce chapitre la méthodologie générique pour élaborer une stratégie de
sécurité réseau.

2.1.1. Prédiction des attaques potentielles et analyse de risque

La première étape consiste à déterminer les menaces qui pèsent sur les biens de
l'entreprise, ainsi que les impacts de ces menaces sur l'activité de l'entreprise si elles
devaient se concrétiser.

Le rapprochement entre les ressources critiques de l'entreprise et les risques de sécurités

associés, déterminés par les valeurs menaces-conséquences-vulnérabilités, permet de
définir la stratégie de sécurité de l'entreprise.
Afin de protéger ses biens critiques des menaces identifiées, l'entreprise doit aussi
analyser les techniques d'attaques utilisées pour enfreindre les contrôles de sécurité ou
tirer parti des vulnérabilités. Ce deuxième niveau d'analyse permet de définir des
stratégies de sécurité proactives, visant à diminuer les probabilités d'occurrence des
menaces.

Typologie des menaces:

Les différentes catégories de menaces qui pèsent sur les systèmes d'informations peuvent
être classés comme sur le schéma suivant :

Les menaces non intentionnelles ou imprévisibles, comme les catastrophes naturelles, ne

mettent pas en oeuvre d'outils ou de techniques particulières et n'ont évidemment pas
d'objectifs déterminés. A l'inverse, les menaces intentionnelles mettent généralement en
oeuvre des outils et des techniques d'attaques très variés.

Des études ont montrés que, dans les trois quarts des cas, les menaces réelles de sécurité
viennent de l'intérieur de l'entreprise. Face aux menaces identifiées lors de la première
étape, des stratégies proactives ou réactives doivent être définies pour tous les cas.

Stratégie proactive:

Une stratégie proactive consiste en un ensemble d'étapes prédéfinies qui doivent être
exécutées afin de se prémunir d'attaque identifiées.

Une telle stratégie doit tout d'abord évaluer les dommages causés par une stratégie
donnée. Ces dommages peuvent aller d'un impact mineur jusqu'à la perte totale du bien
attaqué.

La stratégie proactive évalue ensuite les degrés de vulnérabilité et les faiblesses exploitées
par chaque attaque identifiée. Cette étape vise à définir de manière précise les éléments
de contre-mesure à mettre en place en tenant compte de différents types de contraintes.
Les risques associés aux vulnérabilités et faiblesses détectées doivent être réduits par la
mise en place de ces éléments de contre-mesure.

La dernière étape de la stratégie proactive consiste à élaborer un plan de contingence, ou

Business Continuity Plan, visant à définir les actions à mettre en oeuvre en cas d'attaque
réussie. Ce plan définit chaque tâche à exécuter, ainsi que le moment de son exécution et
la personne qui en a la charge. Il doit résoudre le problème de la restauration des données.
Il peut inclure une contrainte de déplacement du bien vers un autre lieu, en cas d'impact
physique sur les locaux.

Un tel plan doit faire l'objet d'exercices réguliers afin que le personnel soit parfaitement
préparé au moment où le plan devra être réellement en oeuvre.

Stratégie réactive:

Une stratégie réactive définit les étapes à mettre en oeuvre après ou pendant un incident.
Elle suppose que la stratégie proactive a échoué.

Cette stratégie consiste à analyser l'incident de sécurité afin de déterminer les dommages
causés, les techniques et outils d'attaque utilisés. Il est primordial de déterminer le plus
vite possible l'étendue des dommages afin de décider des actions d'urgence à entreprendre.

Non moins importante est la détermination des causes de l'incident par une analyse des
traces système et réseau, sur les pare-feu, mais aussi par la détection de signatures de
programmes ou de « root kits », de zone utilisées comme nid par l'intrus, sur les systèmes
attaqués.

L'étape suivante commence dès la fin de l'analyse post-mortem. Elle consiste à réparer les
dommages causés. Elle vient nécessairement à la fin de l'analyse de façon que la
restauration des données affectées n'écrase pas les traces de l'incident de sécurité. Cette
logique est à rapprocher de celle à l'oeuvre dans les autopsies consécutives à des affaires
criminelles, lors desquelles les services de médecine ne sont pas autorisés à toucher au
cadavre avant que les enquêteurs aient fini l'investigation.

2.1.2. Analyse des résultats et amélioration

Les différentes simulations sont l'occasion d'améliorer les contre-mesures de sécurité,

voire de les remettre en question.

Il faut aussi valider l'efficacité des stratégies de sécurité mises en place face aux
simulations exécutées. Enfin, dans la mesure ou la stratégie existante n'a pas apportée de
résolution satisfaisante, il est nécessaire de la modifier ou d'en créer une nouvelle.

2.1.3. Règles élémentaires d'une stratégie de sécurité réseau

Lors de l'établissement d'une stratégie de sécurité, il faut toujours garder à l'esprit

quelques règles ou principes élémentaires afin de se prémunir des erreurs possibles dans
le choix de contre-mesures.

Simplicité:

Plus une stratégie est complexe, plus il est difficile de l'appliquer, de la maintenir dans le
temps ou de la faire évoluer.

La simplicité est un critère de réussite d'une stratégie de sécurité.

Le maillon le plus faible:

Un réseau est composé d'un ensemble d'équipement, ayant ou non une fonction de
sécurité implémentée. Un routeur a pour rôle d'acheminer du trafic de données tandis
qu'un pare-feu filtre les flux réseau. Pour qu'une stratégie de sécurité recouvre le
périmètre de l'entreprise, il faut s'assurer que toutes les méthodes d'accès fournissent un
même niveau de sécurité, faute de quoi le maillon le plus faible sera privilégié pour
pénétrer le réseau de l'entreprise.

Variété de protection:

La variété des solutions mises en place pour assurer la sécurité ne doit pas se fonder sur
un seul type de logiciel de pare-feu ou de détection d'intrusion.

A titre d'exemple, une architecture visant à protéger l'entreprise des accès réseau Internet
pourrait reposer sur deux types de pare-feux différents, un pour protéger un sous réseau
DMZ d'Internet et un autre pour protéger l'entreprise de cette DMZ. Illustration sur le
schéma suivant :

Pour réussir une attaque, l'intrus devrait être capable de passer les deux types de produits
pour atteindre le réseau de l'entreprise. Les deux pare-feux peuvent être de marques et de
modèles différents, voire implémenter des technologies différentes, complexifiant d'autant
les techniques de pénétration de l'entreprise.

2.1.4. Implémentation en profondeur des mécanismes de sécurité :

La sécurité ne doit jamais reposer sur un seul mécanisme de sécurité. Une imbrication de
mécanismes offre une garantie de sécurité bien supérieure, pour peu que le premier
élément de sécurité vienne à faillir.

Un premier élément de sécurité filtre l'accès aux adresses IP des équipements réseau par
des ACL.

Un deuxième élément de sécurité authentifie les accès à l'équipement à l'aide

d'algorithmes de chiffrement et de protocoles d'accès offrant de telles options, tels IPsec
ou SSH.

L'implémentation de mécanismes de sécurité en profondeur doit être comprise et perçue

comme une assurance de sécurité à plusieurs niveaux. Plus le système à protéger est
critique, plus le nombre de mécanismes de sécurité doit être important.

2.2. PROPOSITIONS DE STRATÉGIE DE SÉCURITÉ RÉSEAU

Ces stratégies de sécurité doivent être considérées comme des briques, que l'on peut
utiliser afin de construire une stratégie complète.

Nous prenons comme exemple une entreprise dont le réseau interne, ou Intranet, comporte
un sous réseau dédié à la production comme c'est le cas pour la First Bank.

Pour mieux comprendre ces propositions de stratégie, nous nous appuyons sur l'analyse
du château fort, dont le modèle est assez proche de celui du réseau.

2.2.1. Stratégie des périmètres de sécurité

Au commencement nous avons simplement une zone à protéger, il s'agit de l'emplacement

où sera érigé le château, qui n'est qu'un simple champ. La première étape dans la
construction consiste à définir le périmètre à protéger et à construire des remparts tout
autour. Ces remparts ont pour fonction de protéger le périmètre d'un environnement
extérieur considéré comme inconnu et donc à risque.

Principe:

Le réseau de d'entreprise est découpé en périmètres de sécurité logique regroupant des

entités ou fonctions afin de mettre en place des niveaux de sécurité à la fois imbriqués et
séparés. Dans le cas de la banque, les réseaux des différentes agences constituent les
différents périmètres de sécurité.

2.2.2. Stratégie de goulet d'étranglement

Maintenant que nous avons érigé des remparts plus ou moins solides et efficaces afin de
définir nos périmètres de sécurité, nous avons la possibilité de mettre en place des
contrôles d'accès. Nous allons donc parler des goulets d'étranglement et installer des
contrôles d'accès sur ces goulets.

Dès lors, il ne sera possible d'entrer dans le château que par un nombre défini d'entrées-
sorties. De plus, ces entrées-sorties sont gardées et les personnes qui entrent ou sortent
font l'objet d'un contrôle. Les goulets d'étranglement dans le cas du réseau de la banque
sont les différents PIX et Routeurs situés en entrée des LAN des agences.

Principe:

Des contrôles d'accès différenciés et en nombre limité sont implémentés pour permettre
l'accès à chaque périmètre de sécurité du réseau de l'entreprise.

Description:

Techniquement, les contrôles d'accès sont constitués de filtrage de paquets et de relais

applicatifs. Ces solutions permettent d'autoriser un certain nombre de flux réseau sortants
(http, FTP, SMTP) appliqués à l'ensemble du réseau interne ou à certaines adresses. Elles
interdisent tout trafic non autorisé vers le réseau interne.

Le schéma suivant illustre les contrôles d'accès représentés par des pare-feux sur chacun
des périmètres de sécurité :

2.2.3. Stratégie d'authentification en profondeur

Maintenant que nous avons défini des périmètres de sécurité et des goulets
d'étranglements, nous allons authentifier les passants qui traversent chaque porte, voir
chaque chemin au sein du château fort afin de prouver son identité sous peine d'être
stoppé.

Principe:

Des contrôle d'authentification sont mis en place afin d'authentifier les accès aux
périmètres de sécurité.

Description:

Les contrôles d'authentification des utilisateurs s'effectuent à plusieurs passages, au

niveau de la sortie Internet, où chaque utilisateur doit s'authentifier pour avoir accès à
Internet, mais aussi au niveau de chaque serveur pour accéder au réseau interne.

Chaque fois qu'un utilisateur s'authentifie, un ticket est crée sur un système chargé de
stocker les traces afin que le parcours de l'utilisateur soit connu de manière précise.

Cette logique peut être généralisée et entraîner la création d'une trace pour chaque action
de l'utilisateur sur chaque serveur. On parle dans ce cas de modèle AAA
(Authentification, Authorization, Accounting), autrement dit authentification, autorisation
et compatibilité des événements. La mise en place d'une telle infrastructure est toutefois
lourde et coûteuse. De plus, elle ne va pas sans un grand nombre d'inconvénients, à
commencer par la création d'un point unique de défaillance, pour peu que le système
d'authentification vienne à être indisponible.

2.2.4. Stratégie du moindre privilège

La stratégie du moindre privilège consiste à s'assurer que chacun dispose de tous les
privilèges et seulement des privilèges dont il a besoin. Pour reprendre notre analogie, le
manant n'a pas le droit d'accéder au château fort du seigneur ni aux mécanismes de
protection du château.

Principe:

Un utilisateur ne dispose que des privilèges dont il a besoin.

La mise en oeuvre de ce principe simple à énoncer est assez lourde pour l'entreprise en
termes de ressources et coûts.

Description:

De nos jours, un utilisateur au sein de l'entreprise est toujours relié au réseau interne,
lequel héberge les stations de travail des utilisateurs mais également les serveurs locaux,
de fichiers et d'impression, ou globaux, associés à l'activité de l'entreprise, offrant
également un accès à Internet.
L' application stricte de cette stratégie, dans laquelle un utilisateur dispose du droit d'accès
à un système spécifique et à aucun autre, est généralement difficile à réaliser de manière
globale.

2.2.5. Stratégie de confidentialité des flux réseau

Tout message qui doit être émis à l'extérieur vers d'autres réseaux doit être protégé. Pour y
parvenir, le message doit être chiffré au moyen d'un algorithme de cryptographie connu
par l'émetteur et le récepteur.

Principe:

Toute communication intersite transitant sur des réseaux publics est chiffrée si elle
contient des données confidentielles.

Description:

Cette stratégie est généralement appliquée aux réseaux d'entreprise répartis sur plusieurs
sites distants communiquant entre eux par l'intermédiaire de réseaux publics tels
qu'Internet, X25, liaisons spécialisées, etc.

Le chiffrement des flux peut se mettre en place à différents niveaux. Lorsqu'une entreprise
crée un réseau de type WAN, elle construit un réseau central et relie ses sites à ce réseau,
comme sur le schéma suivant :

Tous les flux qui sortent de chaque site sont chiffrés à la volée par le boîtier de
chiffrement placé en goulet d'étranglement.

Il existe bien d'autres moyens de chiffrer les communications au sein d'un réseau. Par
exemple au lieu d'utiliser la technologie http, le protocole HTTPS peut-être choisi.

2.2.6. Stratégie de séparation des pouvoirs

A ce stade, nous avons construit notre château, et nous contrôlons les points
d'entrées/sorties.
Tous ces services sont assurés par une même entité. Si cette entité vient à défaillir, elle
risque d'autoriser l'ennemi à rentrer dans tous les périmètres de sécurité du château,
conduisant toute la sécurité du château fort à s'écrouler.

Principe:

Des entités sont crées, chacune responsable de zones de sécurité spécifiques du réseau
d'entreprise.

Description:

Il n'existe souvent dans l'entreprise qu'un seul département pour prendre en charge toutes
les fonctions associées aux services informatiques interne (IT). Une telle organisation
convient aux petites entreprises, qui ne disposent pas de beaucoup de ressources pour
satisfaire ce besoin.

Plus l'entreprise est importante, plus il est nécessaire de séparer ou de limiter les pouvoirs
de chaque entité afin de limiter les conséquences ou les impacts sur l'entreprise en cas
d'acte de malveillance. Un bon exemple illustrant la nécessité de la séparation des
pouvoirs est celui d'un département qui doit à la fois assurer une fonction opérationnelle
et en contrôler l'application. S'il n'existe pas d'entité indépendante au niveau
organisationnel chargée du contrôle, il est pratiquement certain que les procédures les plus
contraignantes seront ignorées, créant ainsi un maillon faible.

Le schéma suivant illustre l'organisation idéale de notre réseau d'entreprise en équipes

chargées de la sécurité de chaque périmètre de sécurité.

Pour résumer, toute politique de sécurité réseau s'accompagne d'un ensemble de stratégies
ayant pour objectifs d'établir un premier niveau de règles de sécurité puis de mettre en
oeuvre des solutions techniques.

Les architectures réseau et les services offerts deviennent de plus en plus complexes.
Cette complexité est susceptible de remettre en cause les mécanismes de sécurité
préalablement définis. L'entreprise doit être à la fois adaptable et réactive dans ses choix
stratégique afin de protéger ses périmètres de sécurité.

Nous avons montré tout au long de cette section que la politique de sécurité réseau est un
long processus qui doit intégrer toutes les entités de l'entreprise et de manière progressive.
Nous exposons au cours de la section suivante une notion importante, celle de modèle de
sécurité.

3. LES MODELES DE SECURITE

A partir du début des années 70, plusieurs modèles de sécurité se sont succédés : I-BAC,
R-BAC, V-BAC, T-MAC et plus récemment Or-BAC. Nous allons évoquer brièvement
ces modèles de sécurité mais nous marquerons un temps d'arrêt sur le modèle Or-BAC
que nous utiliserons dans la suite.

3.1. LE MODÈLE I-BAC (IDENTITY BASED CONTROL

ACCESS)

Premier modèle de contrôle d'accès proposé dans la littérature, ce modèle introduit les
concepts fondamentaux de sujet, d'action et d'objet :

§ le sujet est l'entité active du SI (utilisateur, ordinateur, processus, programme,...) ;

§ l'objet est l'entité passive du SI (fichier, base de donnée, ordinateur, programme,...) ;

§ l'action désigne l'effet recherché lorsqu'un sujet accède à un objet (lire, écrire,
modifier,...).

L'objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets via
l'utilisation des actions. Ce contrôle est basé sur l'identité du sujet et l'identificateur de
l'objet, d'où le nom du modèle I-BAC.

Le modèle I-BAC présente cependant des limites. La politique d'autorisation devient

complexe à exprimer et administrer. Il est en effet nécessaire d'énumérer les autorisations
pour chaque sujet, action et objet. En particulier, lorsqu'un nouveau sujet ou objet est créé,
il est nécessaire de mettre à jour la politique d'autorisation pour définir les nouvelles
permissions associées à ce sujet ou objet.

3.2. LE MODÈLE R-BAC (ROLE BASED ACCESS CONTROL)

Le modèle RBAC (Role Based Access Control) propose de structurer l'expression de la

politique d'autorisation autour du concept de rôle. Un rôle est un concept organisationnel :
des rôles sont affectés aux utilisateurs conformément à la fonction attribuée à ces
utilisateurs dans l'organisation. Le principe de base du modèle R-BAC est de considérer
que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles
reçoivent donc des autorisations de réaliser des actions sur des objets.

Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir
réaliser une action sur un objet, un utilisateur doit d'abord créer une session et, dans cette
session, activer un rôle qui a reçu l'autorisation de réaliser cette action sur cet objet. Si un
tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la
permission de réaliser cette action sur cet objet une fois ce rôle activé. Lorsqu'un nouveau
sujet est créé dans le SI, il suffit d'affecter des rôles au sujet pour que ce sujet puisse
accéder au SI conformément aux permissions accordées à cet ensemble de rôles.

Comparé au modèle I-BAC, la gestion de la politique d'autorisation s'en trouve simplifiée

puisqu'il n'est plus nécessaire de mettre à jour cette politique chaque fois qu'un nouveau
sujet est créé.

Mais comme I-BAC, le modèle R-BAC ne considère que des autorisations positives
(permissions) et fait donc l'hypothèse que la politique est fermée. Bien plus, dans les
modèles I-BAC et R-BAC, les actions correspondent généralement à des commandes
élémentaires, comme la lecture du contenu d'un objet ou l'écriture dans un objet. Dans les
applications récentes, le besoin apparaît de contrôler la réalisation d'actions composites,
appelées tâches ou activités. Par exemple, dans une agence de voyage, la tâche d'achat
d'un billet d'avion se décompose en plusieurs actions plus élémentaires telles que la
réservation du billet, le paiement du billet et l'édition d'une facture. Le besoin de contrôle
sur des activités composites est en particulier présent dans les applications de type
workflow8(*) d'où la modèle T-BAC.

3.3. LE MODÈLE T-BAC (TASK BASED ACCESS CONTROL)

Le modèle T-BAC fut le premier modèle à introduire le concept de tâche. D'autres

modèles ont ensuite été développés pour contrôler l'exécution des activités dans un
workflow. En particulier, l'utilisateur ne doit obtenir une permission que lorsque c'est
nécessaire pour poursuivre l'exécution de l'activité considérée ("just in time" permission).
Ainsi, dans l'exemple d'achat d'un billet d'avion, la permission d'éditer une facture ne doit
être activée qu'après la réservation et l'achat du billet. Il est parfaitement possible de
combiner les concepts de rôle et de tâche pour spécifier une politique d'autorisation et
obtenir ainsi un modèle que l'on peut appeler TR-BAC (Task and Role Based Access
Control). Dans ce cas, les permissions affectées aux rôles portent sur la réalisation des
tâches. Diverses contraintes peuvent être spécifiées pour par exemple spécifier qu'un
même sujet doit intervenir dans certaines actions nécessaires à la réalisation de la tâche
(éventuellement avec des rôles différents).

Les modèles R-BAC et T-BAC ont respectivement introduit les concepts de rôle et de
tâche pour structurer les sujets et les actions. Pour faciliter l'expression et la gestion d'une
politique d'autorisation, nous avons également besoin d'un concept pour structurer les
objets. Parmi les modèles de contrôle d'accès proposant une telle structuration des objets,
on peut citer le modèle de sécurité proposé par SQL pour les bases de données
relationnelles.

L'expression d'une politique de sécurité en SQL repose sur le concept de vue. Ce type de
modèle de contrôle d'accès basé sur les vues est appelé V-BAC.

3.4. LE MODÈLE V-BAC (VIEW BASED ACCESS CONTROL)

Intuitivement, dans une base de données relationnelle, une vue correspond au résultat
d'une requête SQL auquel on a donné un nom. Ce concept de vue est ensuite utilisé pour
structurer l'expression d'une politique d'autorisation à l'aide des instructions GRANT (qui
permet d'accorder une nouvelle permission à un utilisateur) et REVOKE (qui permet de
supprimer une permission que possédait un utilisateur). Une vue constitue donc un moyen
efficace pour accorder un accès à l'ensemble des objets contenus dans la vue.

Cependant, dans les applications récentes, il est souvent nécessaire de considérer

plusieurs organisations simultanément. Par exemple, dans les applications de services
web, un utilisateur d'une certaine organisation peut souhaiter accéder aux données
appartenant à une autre organisation. Une organisation est une entité structurée. Par
exemple, un hôpital correspond à une organisation qui se décompose en plusieurs sous-
organisations : les différents départements de l'hôpital, les différents services de ces
départements, etc. Chaque organisation gère en général sa propre politique d'autorisation.
Certaines organisations peuvent également être créées dynamiquement en fonction des
activités que doit prendre en charge l'hôpital. Par exemple, une équipe de soin peut être
créée pour prendre en charge un patient particulier. Cette organisation pourra ensuite être
dissoute une fois les activités réalisées. Remarquons que les autorisations d'un sujet
dépendent non seulement du rôle du sujet mais également de l'organisation dans laquelle
ce sujet exerce son rôle. Ce problème a été identifié dans le modèle T-MAC.

3.5. LE MODÈLE T-MAC (TEAM BASED ACCESS CONTROL)

Le modèle T-MAC introduit la notion d'équipe. Dans T-MAC, des autorisations sont
associées aux rôles ainsi qu'aux équipes. Les autorisations que possède un sujet résultent
de la combinaison des autorisations associées aux rôles exercés par le sujet et des
autorisations associées à l'équipe à laquelle est affecté le sujet. Plusieurs combinaisons
(par exemple, l'union des autorisations) sont envisagées. En fait, le modèle T-MAC est
incorrect car il introduit deux relations binaires : rôle-autorisation et équipe-autorisation.
Si l'on introduit la notion d'équipe, il est en fait nécessaire de considérer une relation
ternaire équipe-rôle-autorisation pour spécifier que les autorisations dépendent non
seulement du rôle mais aussi de l'équipe dans laquelle est exercé ce rôle. A l'aide d'une
telle relation ternaire, on pourra ainsi facilement spécifier que les autorisations du rôle
médecin changent suivant qu'il s'agit d'un médecin dans une équipe de garde ou d'un
médecin dans une équipe d'urgence.

Cette imperfection du modèle T-MAC a été corrigée dans le modèle Or-BAC, que nous
allons présenter dans les sections suivantes.

3.6. LE MODÈLE OR-BAC (ORGANIZATION BASED ACCESS

CONTROL)
3.6.1. Les objectifs et avantages d'Or-BAC

L'objectif d'Or-BAC est de permettre la modélisation d'une variété de politiques de

sécurité basées sur le contexte de l'organisation. Pour arriver à ce but, et afin de réduire la
complexité de gestion des droits d'accès, le modèle Or-BAC repose sur quatre grands
principes :

§ l'organisation est l'entité centrale du modèle ;

§ il y a deux niveaux d'abstraction :

o un niveau concret : sujet, action, objet,

o un niveau abstrait : rôle, activité, vue,

§ la possibilité d'exprimer des permissions, des interdictions, et des obligations ;

§ la possibilité d'exprimer les contextes.

Ainsi, en plus d'avoir une politique de sécurité indépendante de son implémentation, Or-
BAC a d'autres avantages. Il permet d'exprimer aussi bien des permissions, que des
interdictions et des obligations. Il prend en compte les contextes, les hiérarchies et
la délégation.

L'introduction d'un niveau permet aussi la structuration des entités comme on le voit sur le
schéma suivant:

Ainsi dans Or-BAC, un rôle est un ensemble de sujets sur lesquels sont appliquées les
mêmes règles de sécurité. Identiquement, une activité est un ensemble d'actions sur
lesquels sont appliquées les mêmes règles de sécurité et une vue est un ensemble d'objets
sur lesquels sont appliquées les mêmes règles de sécurité.
3.6.2. Les interactions d'Or-BAC

Sur le schéma suivant, on peut apercevoir les interactions existantes dans Or-BAC. Afin
de ne pas surcharger celui-ci l'interaction entre le contexte et les entités concrètes n'est pas
représentée.

Les prédicats d'Or-BAC liés aux interactions seront décrits dans la section du même nom.

3.6.3. La notion de contexte

On voit apparaître sur ce schéma des interactions une entité qui n'apparait pas dans les
autres modèles de contrôle d'accès : le contexte. Celui-ci est défini pour une organisation,
un sujet, une action, des objets donnés. Les contextes permettent d'exprimer des
permissions ou des interdictions dans certaines circonstances (urgence à l'hôpital, heures
de travail dans une entreprise,...). Il est facile d'imaginer que dans un contexte d'urgence,
on désirera qu'un infirmier puisse accéder au dossier d'un patient sans avoir besoin
d'appeler l'administrateur afin que celui-ci lui donne les droits (peut-être trop tard). Cette
possibilité de nuancer les autorisations n'est pas offerte par les autres modèles, alors que
dans de nombreuses organisations (hôpital, entreprise,...) il existe un réel besoin de ne
donner des droits que dans des circonstances précises.
Pour le modèle Or-BAC, on a regroupés les différents contextes par type (comme sur le
schéma ci-dessus) :

§ contexte temporel : ce sont des contextes régissant la durée de validité des privilèges ;

§ contexte spatial : il peut être lié à l'appartenance à un réseau, ou la position

géographique, ou à toute autre situation spatiale ;

§ contexte déclaré par l'utilisateur : ce type de contexte est activé, par exemple, par le
médecin en cas d'urgence, ou pour signaler que l'on effectue un audit. Dans ces cas
exceptionnels, des permissions peuvent être données alors qu'elles seraient interdites dans
un cas normal. L'utilisateur qui déclare le contexte est obligé en contrepartie de faire un
compte-rendu des opérations effectuées et peut être des raisons qui l'ont motivé à déclarer
ce contexte ;

§ contexte prérequis : leur utilisation permet de contraindre les sujets concernés par les
permissions ou les interdictions dépendant de ces contextes et qui vient réduire ou étendre
les droits d'accès hérités du rôle associé ;

§ contexte provisionnel : ce contexte permet de donner des privilèges en fonction de

l'historique. Par exemple, le contexte "accès limités à 2 fois" regarde si le document, objet
de l'action, a été accédé au moins 2 fois.

A noter que dans une modélisation Or-BAC, on définit toujours un contexte par défaut.

3.6.4. La notion de hiérarchie

Afin de gérer plus facilement des sous-organisations, en automatisant la dérivation des

permissions, Or-BAC permet de définir des hiérarchies sur les rôles, les activités, les vues
et les contextes. On a ainsi l'héritage des permissions et des interdictions en descendant
dans la hiérarchie des rôles, des activités, des vues et des contextes. Tout comme dans R-
BAC, l'héritage permet de simplifier la tâche de l'administrateur en automatisant
partiellement l'attribution des privilèges. Comme dans R-BAC, il existe deux façons de
définir la hiérarchie de l'héritage :

§ la première vision pour définir la hiérarchie est la hiérarchie organisationnelle. Le

directeur est hiérarchiquement supérieur à un ingénieur. Dans certains cas, il peut donc
hériter de toutes les permissions de ce rôle (pour vérifier le travail de celui-ci). On dit
alors que R1 est senior de R2 et R2 est junior rôle de R1, si un utilisateur jouant le rôle R1
est supérieur hiérarchique de R2 ;

§ la deuxième vision est la hiérarchie obtenue par la relation de

spécification/généralisation est définie telle que R1 est un senior rôle de R2 si chaque fois
qu'un utilisateur joue le rôle de R1, elle joue le rôle de R2. Par exemple sur la hiérarchie
présentée sur le schéma un peu plus en dessous, le chirurgien est aussi un médecin. Donc
à chaque fois qu'un utilisateur est associé au rôle de chirurgien, il joue aussi le rôle de
médecin. Le rôle chirurgien est un senior rôle de du rôle médecin. Un rôle R1 senior de
R2 hérite donc les permissions affectées à R2.

Dans Or-BAC, ces deux hiérarchies réapparaissent mais les droits qui leur sont associés
sont quelque peut modifiés. En effet, avec le modèle Or-BAC, on peut définir des
permissions mais aussi des interdictions. Dans Or-BAC, on peut aussi spécialiser un rôle.
On voit donc apparaître une hiérarchie liée à cette spécification. Dans cette hiérarchie si
on veut qu'un rôle senior puisse avoir plus de pouvoir que son rôle junior, alors il faut que
le rôle senior hérite des permissions de son rôle junior et que les interdictions liées au rôle
senior soient héritées par son rôle junior. De plus, par rapport à R-BAC, Or-BAC introduit
le concept d'organisation, ce qui donne une nouvelle dimension à l'héritage. En effet, il est
possible qu'un rôle puisse toujours englober un certain sous-rôle quelle que soit
l'organisation dans laquelle on se place. Par exemple, dans tout hôpital, le rôle de
chirurgien est une spécialisation du sous-rôle médecin. Or-BAC permet donc au
chirurgien d'hériter de tous les droits du médecin en ne définissant qu'une seule fois les
droits. Le reste se fait grâce à la relation de spécialisation/généralisation. Identiquement,
les vues et les activités possèdent des sous-vues et des sous-activités. On les hiérarchise
donc afin de créer pour elles aussi cette relation de spécialisation/généralisation.

Un petit exemple de dérivation de privilèges par la hiérarchie dans Or-BAC, sur le

schéma, si on a :

Permission (Org.HOP, Médecin, Opérer, patient, ctx.MéduPat.OUctx.Urg)

alors à partir de la hiérarchie définie, on dérive automatiquement :
Permission (Org.HOP, Urologue, Opérer, patient, ctx.MéduPat.OUctx.Urg) et
Permission (Org.HOP, Chirurgien, Opérer, patient, ctx.MéduPat.OUctx.Urg)

3.6.5. La notion de délégation

La délégation permet de donner à un utilisateur particulier un privilège, sans donner ce

privilège à toutes les personnes ayant le même rôle que lui. La délégation, bien que très
utilisée, est très peu modélisée dans les politiques de sécurité car ce concept est très
complexe.

En effet, grâce à une délégation, une permission peut être donnée par le détenteur d'un
droit à un tiers pour agir à sa place ou à la place d'un autre. On voit déjà ici apparaître
qu'une délégation peut faire intervenir plusieurs parties :

§ le sujet qui possède le privilège,

§ le sujet a qui on délègue le privilège,

§ le sujet qui délègue le privilège (pour agir à sa place ou à la place d'un autre).

Il existe trois types de situation dans lesquelles la notion de délégation apparaît :

§ la maintenance d'un rôle,

§ la décentralisation de l'autorité,

§ le travail de collaboration.

La maintenance d'un rôle correspond au cas où un utilisateur doit déléguer une partie de
ses permissions afin qu'on puisse remplir toutes ses obligations pendant son absence. La
décentralisation de l'autorité est surtout utile dans le cas où on modifie une partie de
l'organisation. En pratique, ce cas peut correspondre à l'ouverture d'un nouvel hôpital dans
lequel on va transférer une partie des médecins exerçant dans les autres hôpitaux de la
région. Le cas du travail en collaboration est évident, si on souhaite que notre partenaire
puisse lire les documents que l'on possède sur un projet donné, il faut lui en donner
l'autorisation.

Cependant, la délégation pose de nombreux problèmes. Entre autre, un utilisateur X ayant

obtenu tous les droits d'un autre utilisateur Y peut ôter les droits à Y si X possède certains
droits administratifs. Il peut aussi arriver que l'on oublie de révoquer une délégation faite
à Z et qui n'a plus d'utilité d'être, ce qui peut laisser la possibilité à Z de se faire passer
pour quelqu'un d'autre. C'est l'une des raisons pour lesquelles il est important de définir
deux types de permission, celles qui sont délégables et celle qui ne peuvent l'être.
De plus, la délégation est liée à une multitude de notions :

§ délégation temporaire/permanente : il faut tout d'abord distinguer les délégations

temporaires ou permanentes. En effet, on peut souhaiter qu'un utilisateur ait de façon
permanente un droit, afin de ne pas à avoir à renouveler sans cesse ce droit ;

§ délégation monotone/non-monotone : c'est le droit de conserver son privilège quand on

le délègue. Dans le cas où la délégation est monotone, la personne qui délègue le droit
conserve ce droit. Tandis que si la délégation est non-monotone, la personne qui délègue
un droit perd ce droit ;

§ délégation "grant-dependant"/"grant-independant" : dans le cas, où la délégation est

temporaire et monotone, alors il faut alors choisir quelles sont les personnes susceptibles
de révoquer les droits sous-délégués. Si on autorise uniquement la personne ayant
déléguée originellement le droit à révoquer un droit délégué, alors on dit que c'est une
délégation de type "grant-dependant". Si on autorise toute personne X ayant délégué un
droit, avant que Y ait reçu ce droit par délégation, à révoquer ce droit à Y, alors on dit que
la délégation est de type "grant-independant". Ce dernier type de délégation permet d'ôter
rapidement un droit à une personne qui peut être malveillante, sans avoir à retrouver qui
était à l'origine de la délégation (ce qui peut être très fastidieux si l'organisation est
importante) ;

§ délégation totale/partielle : On peut choisir de déléguer partiellement ou totalement un

ensemble de droits. Lorsque l'on souhaite déléguer la totalité de ses droits à quelqu'un, par
exemple son remplaçant, alors on applique une délégation totale. Par contre, si on ne veut
donner qu'une partie de ces droits, pour déléguer juste une tâche à quelqu'un, alors on a
une délégation partielle ;

§ délégation par agent/auto-active : il y a deux façons d'administrer la délégation, si une

personne X veut déléguer un droit à Y. La première solution est que c'est X qui administre
la délégation. C'est la délégation auto-active. La deuxième solution est que X demande à
un agent d'affecter ce droit à Y. C'est la délégation par agent. L'agent pouvant être
n'importe quelle tierce personne dans l'organisation. Généralement, l'agent ne peut pas
s'affecter les droits qu'il gère. Il est possible de définir le nombre de sous-délégation
possible ;

§ délégation à un-pas/à pas-multiple : dans la délégation à n-pas, un même droit pourra

être délégué à une chaine de n personnes. Par exemple, X délègue à Y un droit D à 2-pas
et Y délègue D à 1-pas à Z.

§ délégation simple/multiple : de plus, il faut choisir si lorsqu'on autorise une personne à

déléguer, elle peut elle-même déléguer son droit à une unique personne, ou à plusieurs
personnes (c'est la délégation multiple).

§ délégation par accord unilatéral/bilatéral : pour déléguer un droit, il faut qu'au moins
une personne donne son accord. On peut envisager deux types d'accord pour la délégation.
L'accord unilatéral ne prend en compte que la décision de la personne désirant déléguer
son droit. L'accord bilatéral vérifie que les deux parties, celle qui délègue et celle qui
reçoit, sont d'accord.

§ révocation de la délégation simple/en cascade : si la délégation est temporaire, il faut

pouvoir la révoquer. On a pu voir précédemment deux types de délégation jouant sur la
révocation. Lorsque la délégation est "grant-dependant" alors seule la personne à l'origine
de la délégation peut ôter ce droit. Quand la délégation est de type "grant-indépendant"
seules les personnes ayant engendré la délégation d'un droit à une personne peuvent lui
révoquer ce droit. Cependant, la personne, dont les droits ont été révoqués, a peut être pu
déléguer ce droit auparavant. Cette situation peut poser des problèmes dans certains cas.
Selon le type de délégation, la personne ayant était déchue d'un droit peut récupérer ce
droit grâce à une personne à qui elle aurait délégué le droit. Pour anticiper ce problème,
on peut créer deux types de révocation. Un premier type permet de ne révoquer le droit
qu'à une personne désignée. Le deuxième type permet de révoquer le droit sur une
personne, ainsi que sur toutes les personnes ayant reçu ce droit par délégation, c'est une
révocation en cascade.

La délégation a de multiples avantages et offre de nombreuses possibilités. Cependant, il

apparaît que si on l'autorise à mauvais escient, alors elle peut aller à l'encontre de la
politique. En effet, la révocation d'une délégation permet à une personne d'ôter un droit D
à une personne X. Mais que se passe-t-il lorsque la personne X possède ce droit avant la
délégation? Des personnes mal intentionnées pourraient ainsi utiliser la délégation afin
d'effectuer des révocations qu'ils n'avaient pas le droit de faire. D'où l'importance de bien
administrer sa politique de contrôle d'accès, si la délégation est mise en place.

3.6.6. Les prédicats d'Or-BAC

Afin de comprendre les règles définies dans Or-BAC, on récapitule dans ces tableaux les
différents prédicats liés à Or-BAC.

Les prédicats liés à l'affectation des entités abstraites aux organisations :

Domaine Description
Nom de prédicat
Si org est une organisation et r un rôle,
Relevant_role Org*Role alors Relevant_role signifie que le rôle r est défini
dans l'organisation org
Si org est une organisation et a une activité,
Relevant_activity Org*Activity alors Relevant_activity signifie que l'activité a est
définie dans l'organisation org
Relevant_view Org*View Si org est une organisation et v une vue,
alors Relevant_view signifie que la vue v est définie
dans l'organisation org
Les prédicats liés aux relations d'abstraction :

Domaine Description
Nom de
prédicat
Si org est une organisation, s un sujet et r un rôle,
Empower Org*Subject*Role alors Empower signifie que
l'organisation org habilite le sujet s dans le rôle r
Si org est une organisation, A une action et a une
activité, alors Consider signifie que
Consider Org*Action*Activity
l'organisation org considère l'action A comme
faisant partie de l'activité a
Use Org*Object*View Si org est une organisation, o un objet et v une vue,
alors Use signifie que l'organisation org utilise
l'objet o dans la vue v

Les prédicats liés aux définitions des contextes :

Domaine Description
Nom de
prédicat
Hold Org*Subject*Action Si org est une organisation, s un sujet, A une
*Object*Context action, o un objet et c un contexte,
alors Hold signifie que dans l'organisation org, le
contexte c est défini pour le sujet s, l'action A et
l'objet o
Domaine Description
Les
Nom prédicats
de liés aux permissions abstraites :
prédicat
Permission Org*Role*Activity Si org est une organisation, r un rôle, a une
 activité, v une vue et c un contexte,
alors Permission signifie que
*View*Context l'organisation org accorde la permission au
rôle r de réaliser l'activité a sur la vue v dans le
contexte c

Les prédicats liés aux permissions concrètes :

Domaine Description
Nom de
prédicat
Si s est un sujet, A une action et o un objet,
alors Is_permitted signifie que le sujet s a
Is_permitted Subject*Action*Object
concrètement la permission de réaliser
l'action A sur l'objet o

3.6.7. La gestion de conflit

Or-BAC permet d'exprimer des permissions et des interdictions. Or-BAC offre donc la
possibilité de spécifier une politique mixte. Il existe dans Or-BAC une troisième catégorie
de privilège : l'obligation. La notion d'obligation décrit les actions qu'un utilisateur doit
faire sur un ensemble d'objets. Par exemple, dans un contexte d'urgence, un infirmier aura
le droit d'accéder aux dossiers médicaux mais uniquement s'il fait ensuite un rapport, c'est
une obligation.
La politique mixte pose de nombreux problèmes liés à la gestion des conflits potentiels et
des règles redondantes. Afin d'éluder le problème des règles redondantes, on ajoute des
prédicats. Ceux-ci, pour deux règles données R1 et R2, interdisent d'avoir la priorité de
R1 moindre que celle de R2, lorsque toutes les conditions suivantes sont vérifiées :

§ R1 et R2 sont définies pour une même organisation ;

§ R1 est définie pour un rôle r1 et R2 est définie pour un rôle r2, avec r1 sous-rôle de r2 ;

§ R1 est définie pour une activité a1 et R2 est définie pour une activité a2, avec a1 sous-
activité de a2 ;

§ R1 est définie pour une vue v1 et R2 est définie pour une vue v2, avec v1 sous-vue de
v2 ;

§ R1 est définie pour un contexte c1 et R2 est définie pour un contexte c2, avec c1 sous-
contexte de c2 ;

Il peut apparaître un conflit, par exemple si un même utilisateur possède deux rôles et que
l'un de ces rôles lui permet de faire une activité et l'autre lui interdit. On est sûr que s'il n'y
a aucun conflit au niveau abstrait, il n'y en aura pas au niveau concret. Ceci est dû au fait
que les permissions concrètes sont déduites des permissions organisationnelles, de même
pour les interdictions. Donc on résout les conflits potentiels au niveau abstrait On décide
pour cela de donner des priorités aux interdictions et permissions du niveau abstrait.
Cependant, si le conflit subsiste (par exemple: l'interdiction et la permission on même
priorité) alors Or-BAC prévient le concepteur de la politique. Celui-ci choisit alors de
modifier les règles liées aux privilèges, ou le niveau des priorités des privilèges.

Donc, Or-BAC simplifie la conception de la politique de contrôle d'accès en automatisant

la dérivation des permissions, il a l'avantage d'offrir une politique mixte qui gère les
problèmes conflictuels.

4. APPLICATION DU MODELE OR-BAC A LA

DEFINITION DE LA POLITIQUE DE SECURITE
RESEAU : CAS DU LAN DE PRODUCTION DU
SIEGE DE LA FIRST BANK

4.1. LES ORGANISATIONS

 Architecture du LAN de production du siège de la First Bank

L'organisation dans le cas d'une politique de sécurité réseau est une organisation au sens
Or-BAC réunissant un ensemble de matériel réseau utilisé pour les contrôles d'accès à ce
dernier. Sa structure est donnée par le schéma de hiérarchie d'organisation suivant :

La hiérarchie proposée est la suivante :

§ l'organisation Org_FB est l'entreprise Afriland First Bank

§ le réseau local de l'organisation Org_LAN ;

o la passerelle externe Org_fwe ,

o la passerelle interne Org_fwi ,

§ les serveurs d'applications de la banque Org_ser ;

§ l'administration des passerelles Org_admin_fw.

4.2. LES SUJETS ET RÔLES

Les entités actives qui manipulent les objets sont appelées sujets. Ces derniers possèdent
des autorisations (droits d'accès) sur les objets et demandent d'y accéder. Un sujet peut
être considéré comme un objet dans le cas où ce dernier est susceptible d'être manipulé
par un autre sujet. Dans un environnement réseau, une machine peut être considérée
comme un sujet car se chargeant de contacter d'autres machines à travers le réseau. Elle
peut également être considérée comme un objet dans la mesure où elle est manipulée par
un utilisateur est ici le sujet. Dans le formalisme OrBAC, les sujets sur lesquels peuvent
être appliqués les mêmes règles de sécurité forment un même rôle. Voici quelques rôles
envisagés dans le cas du LAN de production de la First Bank :

§ Private_host : rôle pouvant être joué par un hôte de la partie privée du réseau de
l'organisation hors zones d'administration ;

§ Int_firwall : rôle pouvant être joué par les interfaces des firewalls ;

§ Adm_fw_host : rôle joué par les hôtes d'administration des passerelles ;

§ Adm_Ntwork : rôle joué par les administrateurs du réseau ;

§ Server : rôle pouvant être joué par un serveur quelconque ;

§ Ser_Mdw : rôle joué par le serveur middleware qui veut contacter celui d'une autre
agence;

§ Ser_Delta : rôle joué par le serveur Delta qui veut contacter celui d'une autre agence;

§ Ser_Gacha : rôle joué par le serveur qui veut contacter celui d'une autre agence;

§ Ser_AsMillenium : rôle joué par le serveur qui veut contacter celui d'une autre agence;

§ Ser_Mozilla : rôle joué par le serveur de messagerie interne ;

§ Multi_ser : rôle joué par un serveur multiple ;

§ Chef_Division : rôle joué par les chefs de division de la banque ;

§ Chef_département : rôle joué par les chefs de départements de la banque ;

§ Chef_agence : rôle joué par un chef d'agence ;

§ Sous_directeur : rôle joué par un sous directeur ;

§ Directeur : rôle joué par un directeur ;

§ DGA : rôle joué par le Directeur Général Adjoint ;

§ DG : rôle joué par le Directeur Général ;

Hiérarchie des rôles (spécialisation /généralisation):

4.4. SERVICES OFFERTS PAR LE RÉSEAU LOCAL DE

L'ORGANISATION ET HIÉRARCHISATION :
ACTIONS/ACTIVITÉS

Nous présentons ci-après une hiérarchie des activités possibles correspondant aux
principaux services réseaux de la banque.

4.4. DÉFINITION DES VUES ET HIÉRARCHISATION

Une vue est un ensemble des objets auxquels s'appliquent les activités.

Au niveau réseau, un objet t de la vue Target a deux attributs :

§ content : données transmises lors de l'utilisation du service,

§ dest : destinataire du service identifié par son rôle (peer-role).

On peut obtenir notion de sous-vue conformément au rôle du destinataire.

On peut également dériver les vues et sous-vues à partir des rôles et sous-
rôles to_target(role) ; dans ce cas, ces vues et sous-vues constituent la cible sur laquelle
les rôles et sous-rôles exercent des activités.

4.5. QUELQUES ORG_FB_PERMISSIONS

Nous avons présenté plus haut dans cette section la syntaxe suivante des permissions :

F Permission : org rôle activité vue contexte.

Nous définissons ci-après quelques permissions sur la hiérarchie d'organisations

existantes :

§ Permission (Org_LAN, admin_fw_host, admin_to_gtw, to-target(firewall), default) ce

qui traduit la règle de sécurité suivante : dans l'organisation Org, un hôte jouant le rôle
d'administrateur des firewalls a la permission d'utiliser les services d'administration des
firewalls en toutes circonstances ;

§ Permission (Org_LAN, private_host, smtp, to-target(ser_Mozilla), default);

§ Permission(Org_LAN, admin_server, all_tcp, to-target(multi_server), default);

§ Permission(Org_LAN, admin_ntwork, snmp, to-target(firewall), default);

§ Permission(Org_LAN, DGA, all_tcp all_icmp, to-target(server), default);

§ Prohibition (Org_LAN, private_host, adm_to_gtw , to-target(firewall), default);

4.6. DÉRIVATION DES PERMISSIONS

Les nouvelles permissions peuvent être dérivées à partir des permissions existantes de
manière suivante :

Permission (org, role, act, view, context)

sub_organization(sub_org,org)
Relevant_role(sub_org,role)

Relevant_act(sub_org,act)

Relevant_view(sub_org,view)

Permission (sub_org, role, act, view, context)

Dérivation à partir des hiérarchies et de l'héritage

Permission (Org_LAN, admin_fw_host, admin_to_gtw, to-target(firewall), default)

Permission (Org_fwe, admin_fw_host, admin_to_gtw, to-target(ext_firewall), default).

Dérivation des permissions concrètes à partir des permissions abstraites

Permission (Org_FB, admin_ntwork, UDP, to-target(firewall), default)

Habilite (Org_FB, JJ, admin_ntwork)

Utilise (Org_FB, fwe, firewall)

Considère (Org_FB, SNMP, UDP)

Définit (Org_FB, JJ, SNMP, fwe, default) Est_permis (JJ, SNMP, fwe)

CONCLUSION
Nous nous sommes intéressés dans la première partie à l'audit de sécurité du
réseau informatique de la First Bank. Ceci nous a permis, grâce aux outils libres,
d'évaluer le niveau de vulnérabilités sur ce réseau. Les recommandations de notre audit, si
elles sont suivies, permettront de renforcer le niveau de sécurité sur le réseau informatique
de l'organisation.

Dans la deuxième partie, nous avons fait un état de l'art des modèles de sécurité avant de
nous arrêter sur le modèle Or-BAC qui est l'un des plus utilisés de l'heure. La phase
pratique de cette partie, consacrée à l'application du formalisme Or-BAC sur le LAN de
production du siège de la banque, nous a permis de dérouler les divers aspects de ce
formalisme sur un cas concret.

Toutefois, la sécurité d'un SI étant un secteur très sensible, nous n'avons travaillé que dans
la limite des possibilités offertes. Nous avons la conviction qu'une approche similaire,
utilisée par le personnel spécialisé de la banque, peut permettre non seulement de finaliser
cette étude mais aussi de l'étendre sur d'autres agences dans le cadre d'une politique de
sécurité réseau globale. Le modèle Or-BAC favorise cela à travers PolyOrbac. Une fois la
définition finalisée, la mise en oeuvre de cette politique de sécurité est facilitée par
l'utilisation du prototype MotOrBAC qui est un outil d'administration et de simulation des
politiques de sécurité.

Enfin, l'élaboration d'une charte d'utilisation du réseau informatique et surtout une

sensibilisation des utilisateurs du réseau sur le bien fondé de ces mesures de sécurité ainsi
que leurs importance sur la pérennité du SI est une étape non négligeable pour l'effectivité
de ces mesures.

BIBLIOGRAPHIE
[1] Frédéric JACQUENOD. Administration des réseaux. Editions CampusPress, Paris,
2002.

[2] Frédéric CUPPENS et Alexandre MIEGE. Or-BAC: Organization Based Access

Control. ENST Bretagne, Campus de Rennes 2, rue de la Chataigneraie 35576, Cesson
Sévigné CEDEX.

[3] François DAGORN. Sécuriser les réseaux par la connaissance des usages : cours de
Master 2, Université de Yaoundé I, 2007.

[4] Site officiel du modèle Or-BAC : http://www.orbac.org, mai 2007.

[5] Documentation de référence nmap : http://insecure.org/nmap/man/fr/man-port-

scanning-techniques.html, mai 2007.

[6] Abdalla ALTUNAIJI, Hugo ETIEVANT, Remy FABREGES, Benoît MAYNARD,

Jean-François RODRIGUEZ, Yohan VALETTE. Mise en place d'un réseau sécurisé - R5.
Université Claude Bernard - Lyon 1, Maîtrise IUP Génie Informatique Réseau, Novembre
2002.

[7] Guillaume Desgeorge. La sécurité des réseaux. Disponible sur http://www.guill.net/,

mai 2008.

[8] David Burgermeister, Jonathan Krier. Les systèmes de détection d'intrusions.

Disponible sur http://dbprog.developpez.com, mai 2008.

[9] http://projet.piratage.free.fr/menaces.html, mai 2007.