Memoire Online - Audit et definition de la politique de sécurité du réseau informatique de la first bank

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 :

M. François DAGORN M. Jean Jacques MATJEI MATJEI Enseignant à l'Université de Rennes I Administrateur du réseau informatique

DEDICACES

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.

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 :

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

§ 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

AES	: Advance Encryption Standard - Algorithme de cryptographie symétrique
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

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 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.

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 menace^1(*) 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 ;

2.2. LES PANNES ET ERREURS (NON INTENTIONNELLES)

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 détournements des données (l'écoute sur le réseau à l'aide des sniffeurs^2(*), les indiscrétions) : c'est le cas le cas de l'espionnage industriel, l'espionnage commercial, les violations déontologiques ;

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 :

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 :

§ 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.

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.

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
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Charset: iso-8859-1,*,utf-8
Accept-Language: en
Connection: Close
Host: admin.cenet.cm
Pragma: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

CVE : CVE-2004-2320
BID : 9506, 9561, 11604
Other references : OSVDB:877, OSVDB:3726

Nessus ID : 11213

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.

§ 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

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 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.

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 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 pcap^7(*) pour capturer les paquets.

La force de Wireshark vient de :

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.

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

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

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/ .

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.

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:

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.

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 :

Une fois ces commandes effectuées, il suffit d'exécuter le script sql fourni avec la distribution de snort.

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.

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 :

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 :

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

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é.

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é.

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 :

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.

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

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.

§ 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,

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).

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.

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

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.

§ 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.

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.

§ 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.

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.

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.

§ 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é 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é.

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.

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.

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.

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.

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é.

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.

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.

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.

§ 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.

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.

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.

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.

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

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.

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.

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.

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.

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é.

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

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.

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

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.

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

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.

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

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 :

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

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.

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 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 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.

§ 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 :

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 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

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 :

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 ;

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

§ 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;

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

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

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 :

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, admin_server, all_tcp, to-target(multi_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_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).

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.

[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.

ANNEXES : CAHIER DE CHARGES

* ² Un sniffeur est un Logiciel qui observe les informations véhiculées sur le réseau. Par exemple : RealSecure, Netmon, et Readsnmb sous Windows, et Tcpdump sous Unix.

* ³Une backdoor (en français, une porte dérobée) est un moyen laissé par une personne malveillante pour revenir dans un système.

* ⁶ Whois (contraction de l' anglais who is ? signifiant littéralement qui est ?) est un service de recherche fourni par les registres Internet,

* ⁷ pcap est une interface de programmation (API) permettant de capturer un trafic réseau. Dans les systèmes Unix/Linux, pcap est implémenté au sein de la librairie libpcap. WinPcap est le portage sous Windows de libpcap.

* ⁸ On appelle « workflow » (traduisez littéralement « flux de travail ») la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier.