Video

Université Cheikh Anta DIOP de Dakar
Laboratoire d’Algèbre de Cryptologie de

Faculté des Sciences et Techniques Géométrie Algébrique et Applications
Département Mathématiques et Informatique LACGAA
Master Transmission de Données et Sécurité de l’Information
Sujet:
Gestion des incidents de sécurité dans un système

d’information avec RT (Request Tracker )
Sous la direction du:

Présenté et soutenu par:
Commandant M. Aly Mime et de
M. Mor Thiam
Aziz Guèye DSSIE/ADIE
Jury :
Président : Professeur Oumar Diankha UCAD/FST/
Membres : M. Adjehoua Haikreo Lacgaa/TDSI
M. Demba Sow Lacgaa/TDSI
Année Académique 2014 - 2015

Gestion des incidents avec Request Tracker | 2014-2015
Dédicaces
Je rends grâce au Tout Puissant ALLAH qui m’a donné l’occasion de produire ce travail
dans la santé et la sérénité.
Je dédie ce mémoire :
A ma mère Astou Sarr.
A mon défunt père Ndiaga Thiam qui m’a donnée une bonne éducation (Que la terre de
Darou Salam lui soit légère),
A mes sœurs et à toute ma famille en général et particulièrement à mon frère Sylla Thiam et
sa femme Fatou Diagne Rosalie Seck ;
A ma sœur Sokhna Thiam pour leur affection et leur soutien éternel.
A mon frère Ndiakhate Thiam, qui n’a ménagé aucun n’effort pour ma réussite,
A notre défunt professeur M. Christophe Paulo
A tous mes amis(es), pour leur amour, leur disponibilité et leur soutien sans faille: Libasse
Samb, Mory Diaw, Amadou Diongue, Mamadou Barro, Serigne Diop.
Je ne pourrai terminer sans dédier ce mémoire à Serigne Touba Khadim Rassoul à qui sa
voie m’a guidé dans le droit chemin.
MOR THIAM-M2TDSI I
Gestion des incidents avec Request Tracker|2014-2015 | Mor THIAM-M2TDSI
Remerciements
Dans l’élaboration de ce mémoire et durant mes recherches en général, j’ai été soutenu
par bon nombre de personnes à qui je tends à adresser ici mes plus sincères remerciements.
Ainsi, je remercie:
Le bon Dieu,
Ma mère Mme Thiam Astou Sarr, mon frère M. Sylla Thiam et sa femme Mme Thiam
Fatou Diagne Rosalie Seck,
Tous les étudiants de la M2tdsi et l’ensemble du corps professoral de TDSI pour la
qualité de la formation que vous nous avez dispensé.
M. Aziz GUEYE Directeur de la DSSIE ainsi que tous ces membres.
Madame DIAW responsable des ressources humaine de l’ADIE.
Tout le personnel de L’ADIE pour l’ambiance formidable que vous avez partagée avec
moi et mes collègues stagiaire durant notre séjour au sein de votre structure.
Mes collègues stagiaires pour toute l’importance que vous avez accordée à ce présent
mémoire et à toute la promotion LP3 Réseaux et services 2014-2015. Que Dieu fasse
de vous des grands Homme dans un futur proche
A mes amis : Libasse Samb, Fatou Sène Wellé, Mory Diaw, Amadou Diongue, Abou
Diallo, Mabouya Diagne.
A tous ceux qui m’ont soutenu de près ou de loin durant mon cursus ; je vous suis
sincèrement reconnaissant
MOR THIAM II
Gestion des incidents avec Request Tracker | 2014-2015
Avant-propos
A l’ère de la société de l’Information, la Sécurité des Systèmes d’Information se trouve au cœur

des préoccupations des entreprises. De ce fait, il est judicieux de songer à la formation de
personnes ressources capables d’apporter des solutions à de telles préoccupations.
C’est ainsi que, dans le cadre de la reforme LMD (Licence-Master-Doctorat) au sein de
l’Université Cheikh Anta Diop de Dakar, plus précisément à la Faculté des Sciences et
Techniques que le master Transmission de Données et Sécurité de l’Information (TDSI) a vu le
jour sous la diligence du Pr. Mamadou SANGHARE et de son équipe.
Ce Master a pour objectif d’assurer la formation de cadres ayant des connaissances solides dans
les domaines qui concernent les Communications (la fiabilité, l’intégrité et le secret de la
transmission de l’information) ; la Sécurité des Systèmes d’Information ; l’Audit Informatique;
le Développement de Solutions de Sécurité, les Réseaux, la gestion des incidents et failles de
sécurités informatiques etc.
Il a deux options à savoir : l’option professionnelle et l’option recherche.
En option professionnelle, les étudiants sont tenus en deuxième année d’effectuer un stage en
entreprise d’une durée minimale de quatre mois, sur un thème se rapportant à la Sécurité des
Systèmes d’Information.
En option recherche, les étudiants choisissent un sujet de recherche proposé par les professeurs.
D’où le présent mémoire sur la gestion des incidents de sécurité d’un Système d’information.
Ce document n’est pas écrit sous la forme d’un tutoriel, donc vous n’aurai pas toutes les captures
car notre démarche n’est pas séquentielle mais elle se veut plutôt méthodique.
MOR THIAM-M2TDSI III

Gestion des incidents avec Request Tracker| 2014-2015
Liste des Acronymes et abréviations
Acronyme Signification
ADIE Agence de l’informatique de l’Etat
CERT Computer Emergence Response Team : Equipe de réponse aux incidents de sécurité.
C’est une marque déposée.
CSIRT Computer Sécurité Incidence Response Team : Equipe de réponse aux incidents de
sécurité
CCSIRT Equipe de réponse aux incidents centralisés
CERT/CC Central Emergency Response Team/ Coordination Center situé à l’université de

Carnegie Mellon aux Etas-Unis
CERTA Centre d’Expertise Gouvernemental de Réponse et de Traitement des attaques

informatiques
DCSIRT Equipe de réponse aux incidents centralisée distribuée
DSSIE Direction de la Sécurité des Système d’Information de l’Etat
DDoS Distributed denial of service attack : Attaque par dénis de service de type distribuée
Freshmeat Est un site web répertoriant un grand nombre de logiciels, majoritairement libres.
Forensics Investigations
GNU licence publique générale
HTTP HyperText Transport protocole
IDS Intrusion Détection Système : Système de détection d’intrusion
IPS Intusion Protection Système : Système de protection d’intrusion
LMD Licence Master Doctorat
MSSP Managed Security Services Provider
NASA National Aeronautics and Space Administration
PSSI Politique de Sécurité du Système d’Information
PCA: plan de continuité d'activité
PRA Plan de Reprise d’activité
PDCA Plan Do Check Act
RTFM M8Request Traquer Faq Manager
RT Request Tracker : Outil de gestion d’incidents
RTIR Request Tracker for Incidence Response
RSSI Responsable de la Sécurité des Système d’Information
SSI Sécurité des Système d’Information
SI Système d’Information
MOR THIAM- M2TDSI IV

Gestion des incidents avec Request Tracker| 2014-2015
SMSI Système de Management de la Sécurité de l'Information
SIEM Security Information Event management : management des évènements de sécurité du

système d’information
TIC Technologie d’Information et Communication
VOIP Voix sur IP
WAF Web Application Firewall:
XSS cross-site Scripting
MOR THIAM- M2TDSI IV

TABLES DES MATIERES
Dédicaces ……………………………………………………………………………………………………………………….i
Remerciements ………………………………………………………………………………………….……………………ii
Avant propos ………………………………………………………………………………………………………………….iii
Liste des acronymes ……………………………………………………………………………………………………….iv
INTRODUCTION .................................................................................................................... 5
CHAPITRE I: PRESENTATION GENERALE ................................................................... 6
I.1. Présentation de la structure d’accueil ......................................................................................... 6
I.2 Présentation du projet ............................................................................................................ 12
I.2.1. Contexte ............................................................................................................................. 12
I.2.2. Problématique ..................................................................................................................... 12
I.2.3. Périmètre .......................................................................................................................... 13
I.2.4. Les parties prenantes au projet .................................................................................... 13
I.2.5. Les buts .............................................................................................................................. 16
I.2.6. Les objectifs : ....................................................................................................................... 17
CHAPITRE II : ANALYSE ET DEFINITION DES CONCEPTS DE BASE ................. 18
II.1 Evaluation des besoins ............................................................................................................... 18
II.1.1. Analyse de l’existant .......................................................................................................... 18
II.1.2. Identification de piste de solution ..................................................................................... 19
II.1.3. Présentation d’un SIEM ..................................................................................................... 19
II.1.4. Présentation d’un CERT/CSIRT .................................................................................... 20
II.1.5. Les différents types de CSIRT ............................................................................................. 20
II.1.6. Avantages fonctionnels d’un CSIRT................................................................................... 21
II.1.7. L’Etat des CSIRT en Afrique et au Sénégal ........................................................................ 21
II.2. Etude des Outils de gestion d’incidents .................................................................................... 22
II.2.1. Etude comparative des outils de gestion des incidents de sécurité ................................ 22
II.2.2. Présentation de l’outil Request Tracker (RT)..................................................................... 23
II.2.4. Présentation de l’outil RTIR (Request Tracker for Incidence Response) .......................... 33
Chapitre III: ANALYSE ET CONCEPTION DE LA SOLUTION .................................. 35
III.1. Définition d’un incident ....................................................................................................... 35
III.2. Politique de la gestion des incidents de la sécurité ............................................................ 36
III.3. Les Mesures à mettre en place ............................................................................................ 36
III.4 Organisation .............................................................................................................................. 37
MOR THIAM-M2TDSI 1
III.4.1 Préambule........................................................................................................................... 37
III.5. Processus de traitement des incidents .................................................................................... 46
III.6.Gestion des incidents de SSI ..................................................................................................... 48
III.6.1. Détection et signalement de l’incident ............................................................................ 48
III.6.2. Enregistrement de l’incident ............................................................................................. 49
III.6.3. Catégorisation de l’incident .............................................................................................. 49
III.6.4. Qualification de l’incident ................................................................................................. 50
III.7. Réponse à l'incident SSI............................................................................................................ 50
III.7.1. Mesures de réponses immédiates .................................................................................... 50
III.7.2. Investigations .................................................................................................................... 51
III.7.3. Traitement ......................................................................................................................... 53
III.7.4. Revues post-incident ......................................................................................................... 55
III.7.4.2. Rapport de synthèse ............................................................................................... 55
III.7.5. Actions post-incident ................................................................................................. 56
III.7.5.1. Bilan de l’incident ................................................................................................... 56
Chapitre IV : MISE EN ŒUVRE DE LA SOLUTION ..................................................... 59
IV .1. Architecture de la solution...................................................................................................... 59
IV.1.1. Les outils utilisés ................................................................................................................... 61
IV.1.2. Installation et Configuration de RT................................................................................... 61
IV.1.3. Installation et Configuration de RTIR .............................................................................. 66
IV.1.4.Installation et Configuration de postfix ............................................................................ 69
IV.2 Envoie d’alertes d’Ossim à RT ................................................................................................... 75
IV.3 Test de validation et de recette ............................................................................................... 76
Conclusion ............................................................................................................................... 85
Bibliographie :.................................................................................................................................... 86
Webographie: .................................................................................................................................... 86
MOR THIAM-M2TDSI 2
Table des Figures
Figure 1: Logo de l'ADIE ............................................................................................................ 7

Figure 2: Organigramme de l'ADIE .......................................................................................... 10
Figure 3: Vue synoptique d'un SIEM ........................................................................................ 19
Figure 4: Logo attestant l'utilisation du nom CERT.................................................................. 20
Figure 5:Acteurs/partenaires de l’équipe de réponses aux incidents de sécurité ........................ 41
Figure 6: Grands domaines d’activité des services liés à la gestion d’incidents de sécurité ........ 42
Figure 7: Schématique du processus de gestion des incidents .................................................... 47
Figure 8:architecture de la solution ........................................................................................... 59
Figure 9: Système de notification par email de RT ....................................................................... 61
Figure 10: Fichier de configuration de RT ..................................................................................... 64
Figure 11:page d'authentification de RT ................................................................................... 65
Figure 12: configuration de la passerelle de la messagerie /etc/aliases ...................................... 66
Figure 13:Installation de RTIR ................................................................................................. 67
Figure 14:Initialisation de la base de données ............................................................................. 68
Figure 15:Activation du plugin RT::IR .................................................................................... 69
Figure 16: Visualisations des emails avec Thunderbird ................................................................. 71
Figure 17: autorisation du domaine cert.adie.sn .......................................................................... 72
Figure 18: Activation du connecteur d'envoi ................................................................................ 73
Figure 19:espaces d'adressage .................................................................................................... 74
Figure 20:liste des domaines acceptés......................................................................................... 75
Figure 21:Configuration de l'envoie d'email sous Ossim ............................................................... 75
Figure 22: réception de message envoyé depuis RT ..................................................................... 76
Figure 23:Reception d’un emaill dans momo@cert.adie.sn .......................................................... 77
Figure 24:Format d'email provenant d'Ossim Alien Vault............................................................. 78
Figure 25: Ajout d'un utilisateur .................................................................................................. 79
Figure 26:resultat de la création d'un utlisateur.......................................................................... 79
Figure 27: Ajout d'un groupe....................................................................................................... 80
Figure 28: Résultats de l'ajout d'un groupe .................................................................................. 80
Figure 29:Ajout des membres du groupe ..................................................................................... 80
Figure 30: Création d'une file ...................................................................................................... 81
Figure 31: Résultats de la création d'une file ............................................................................... 81
Figure 32: ajout des droits de groupe .......................................................................................... 82
Figure 33: résultats ajout des droits de groupe ............................................................................ 82
Figure 34: Création des observateurs d'une file ........................................................................... 82
Figure 35: interface pour créer un ticket...................................................................................... 83
Figure 36: Affecter une file à un ticket ......................................................................................... 83
Figure 37: commentaires sur un ticket ........................................................................................ 84
Figure 38: Réponse et cloture de la résolution d'un incidents....................................................... 84
Figure 39: Fichier de configuration de Postfix .............................................................................. 87
Figure 40: message d'erreur possible sur l'interface web de RT .................................................... 88
Figure 41: liste des adresses ip autorisées ................................................................................... 88
Figure 42: Personnalisation de l'interface RT ............................................................................... 89
MOR THIAM-M2TDSI 3
Liste des tableaux
Tableau 1: Les parties prenantes au projet ...................................................................................... 16

Tableau 2: Panorama des acteurs du marché ................................................................................... 23
MOR THIAM-M2TDSI 4
INTRODUCTION
L'environnement socio-économique d'aujourd'hui, évolue et devient de plus en plus soucieux
de la sécurité. Les gens prennent de plus en plus de mesures pour s'assurer de leur sécurité et
prennent les mêmes dispositions dans leurs organisations gouvernementales et industrielles.
Ces changements à leur tour font écho dans les exigences de sécurité informatique. Les
personnes averties en réclament d’avantages pour que leurs informations personnelles soient
traitées, transmises ou stockées en toute sécurité. Les demandes sont reconnues aussi bien par
les gouvernements que par l'industrie et commencent à se refléter dans la constitution des lois
et dans la pratique des affaires.
Les Menaces et les vulnérabilités, sous une forme ou une autre, sont probablement toujours
vues comme une incidence sur le Système d’Information.
Les organisations et les entreprises devront continuellement déterminer où ils sont menacés et
essayer de trouver des façons d'atténuer les risques. Toutefois, les actions préventives ne sont
pas toujours infaillibles.
À ce titre, les méthodes de détection doivent être mises en place pour identifier quand un
compromis a eu lieu. Les activités d'intervention, doivent à leur tour, être mises en place, pour
faire face à ces détections. C'est là que la nécessité de disposer d’une équipe CSIRT (Computer
Security Incident Response Team) devient plus évidente.
Une équipe CSIRT est l'un des meilleurs moyens de rassembler l'expertise nécessaire pour faire
face à la multiplicité des possibles incidents de sécurité informatique qui peuvent survenir.
Dans la suite du document, on fera une présentation de la structure d'accueil et du projet .On
va ensuite décrire les besoins nécessaires pour construire et exploiter une équipe CSIRT.
Dans la seconde partie, on va définir et expliquer la nécessité d'une équipe CSIRT, définir et
introduire les rôles possibles et les responsabilités, les exigences pour la construction, le
fonctionnement et la structure organisationnelle possible d'une équipe d'intervention. En fin
terminer avec la conception et la mise en œuvre de la solution.
MOR THIAM-M2TDSI 5
CHAPITRE I: PRESENTATION GENERALE

Ce chapitre présente la structure d’accueil, le contexte, la problématique, les buts et les
objectifs du projet.
I.1. Présentation de la structure d’accueil

Jusqu’en 1987, la politique informatique de l’Etat du Sénégal était prise en charge par la
Section Informatique du Bureau Organisation et Méthodes (BOM), notamment à travers la
coordination du Comité National Informatique (CNI). Cette structure était très mal outillée, en
termes d’effectifs (maximum trois personnes).
Ses interventions se limitaient à l’appui de l’Administration et du secteur parapublic dans la

mise en œuvre de leurs projets d’informatisation.
Les besoins de cette Section Informatique étaient pris en charge par le budget du BOM rattaché
au Secrétariat Général de la Présidence.
A partir de novembre 1987, avec l’avènement de la Délégation à l’Informatique, les missions

essentielles s’orientent plus spécifiquement vers l’animation, la coordination et le contrôle de
l’informatisation des administrations et des organes du secteur parapublic.
Avec la création de la Direction Informatique de l’Etat (ADIE) en juin 2001, les missions se
sont notablement renforcées, avec de nouvelles orientations, notamment :
 le renouvellement et le renforcement des équipements informatiques et réseaux de

l’Administration ;
 le déploiement de réseaux locaux dans les bâtiments administratifs ;
 l’étude et le développement d’applications transversales ;
Globalement, il faut considérer qu’à partir de 2001, le Sénégal s’est engagé dans une nouvelle
dynamique de développement des réseaux informatiques et de promotion des Technologies de
l’Information et de la Communication en s’appuyant sur :
 l’adoption d’un nouveau code des télécommunications ;

 la libéralisation du secteur des télécommunications ;
 la création et le renforcement des institutions chargées de définir et de mettre en œuvre
la politique du secteur des Tics.
MOR THIAM-M2TDSI 6
La nouvelle vision e-Sénégal déclinée dès janvier 2002 se fonde sur la conviction que les TIC
constituent un levier essentiel pour le développement économique d’un pays.
Cette vision a l’ambition d’inverser la polarité entre le gouvernement et le citoyen en mettant

ce dernier au cœur des préoccupations de l’Administration.
Cette vision e-Sénégal, un des fondements de la stratégie de développement du Sénégal vise :
 Une meilleure application des principes de transparence et de bonne gouvernance ;

 Un Etat plus efficace et plus performant ;
 Une administration véritablement au service du citoyen et des entreprises ;
Un encadrement juridique favorable au développement des TIC.
LA CREATION DE L’AGENCE DE L’INFORMATIQUE DE L’ETAT
La complexité des procédures administratives et l’exigence accrue des usagers du service public
en termes de célérité et d’efficacité ont conduit l’Etat du Sénégal à créer, des organes
d’exécution décentralisés appelés agences d’exécution dotées de l’autonomie financière
apportant plus de souplesse dans la gestion publique. Cette politique d’externalisation vise à
améliorer la performance et la qualité dans l’Administration. C’est ainsi qu’en 2004, l’Etat du
Sénégal a créé l’Agence de l’Informatique de l’Etat (ADIE) pour :
 donner plus d’impulsion, d’autorité et de moyens aux activités d’informatisation

 rendre un service de qualité aux usagers en apportant des solutions appropriées fondées
sur la proximité et la réactivité
 rendre le secteur plus attentif à la notion de performance et de résultats
Figure 1: Logo de l'ADIE
MOR THIAM-M2TDSI 7
I.1.1. Organisation
 La Direction générale assure la coordination et fixe les objectifs. Elle comprend : Le

Directeur Général (DG), le Directeur Général Adjoint (DGA), les chargés de
programmes et le coordonnateur du bureau des projets (PMO).
 L’Agence Comptable a pour mission de mobiliser les ressources de l’ADIE, de payer
les dépenses, de conserver les valeurs et les fonds, de gérer la trésorerie, de tenir la
comptabilité générale et d’établir les états financiers de synthèse.
 L’Audit et Contrôle de Gestion assure la performance de l’entreprise dans le respect
des obligations légales et des procédures internes et participe au pilotage et à la prise de
décision. Elle est chargée d’harmoniser les procédures comptables et financières et de
superviser la clôture des comptes.
 La Cellule de passation des marchés est chargée de veiller à la qualité des dossiers de
passation de marchés ainsi qu’au bon fonctionnement de la commission des marchés de
l’ADIE.
 La Commission des marchés est chargée de l’exécution et du suivi des activités
d’ouverture des plis, d’évaluation des offres et d’attribution provisoire des marchés
l’ADIE conformément aux dispositions du code des marchés publics.
 La Cellule de Solidarité Numérique (CSN) a pour mission générale de lutter contre la
Fracture Numérique et l'exclusion sociale grâce à une intégration des TIC à l’école, à
travers le recyclage utilitaire et durable des équipements informatiques et la formation
des enseignants et des couches vulnérables.
 La Direction des Réseaux, des Systèmes et des Télécoms (DRST) est chargée de
l'administration, de la maintenance des infrastructures systèmes, réseaux et télécoms.
Elle est également chargée de la gestion du parc informatique de l’Etat, du support aux
utilisateurs, de la mise en production et de l’exploitation des systèmes d’information.
 La Direction des Services de l’Ingénierie (DSI) est chargée de la maîtrise d’ouvrage,
de la maîtrise d’œuvre des projets et de la veille technologique. Elle assure
l’accompagnement des structures administratives dans la mise en œuvre de leurs projets
TIC et s’occupe du développement, de l’intégration et de la commercialisation des
applications/produits/services.
 La Direction des Relations Extérieures, du Marketing, de la Formation et de la
Communication (DRMFC) a pour mission de promouvoir les produits, les services,
les réalisations et l’image de l’ADIE. Elle est chargée de renforcer les relations de
MOR THIAM-M2TDSI 8
l’Agence avec les structures administratives. Elle contribue également à la mise en

œuvre de la politique de renforcement des capacités des agents de l’Etat. Elle est aussi
en charge de définir et d’adopter une démarche pour la rétribution de services.
 La Direction de la Sécurité des Systèmes d’Information de l’Etat (DSSIE) gère
l’élaboration et la mise en œuvre des politiques de sécurité des systèmes d’information
de l’Etat. Elle assure la définition des normes et règles de sécurités, la mise en place et
l’administration des équipements de sécurité.
 La Direction Administrative et Financière (DAF) prend en charge la gestion
comptable et financière, la gestion du personnel, l'intendance qui comprend notamment
la gestion des locaux, des approvisionnements et des véhicules et la conduite des
procédures administratives et juridiques.
 La Direction de la Logistique et de la Maintenance (DLM) est chargée de concevoir,
d’organiser et de définir les meilleures stratégies de gestion des processus, du suivi des
acquisitions et de leurs entreposages, de leur distribution. Elle assure le suivi des
constructions et de l’entretien des ouvrages génie civil, la maintenance des véhicules et
autres matériels roulants, l’entretien des matériels de bureau, l’approvisionnement en
carburant pour les véhicules et matériels pour l’énergie. Elle est charge de la
maintenance des équipements informatiques, de télécommunications et de production
d’énergie (transformateurs, groupes électrogènes, onduleurs, régulateurs, climatiseurs
…), ainsi que des matériels et outils de maintenance du réseau de l’intranet.).
MOR THIAM-M2TDSI 9
Figure 2: Organigramme de l'ADIE
I.1.2. Missions générales

Les missions dévolues à l’Agence sont :
 La modernisation de l’Administration Sénégalaise par la dématérialisation des
procédures administratives ;
 la rationalisation des dépenses informatiques de l’Etat en mutualisant et en harmonisant
les choix technologiques des services de l’Administration ;
 l’édification d’une infrastructure nationale de réseaux pour l’interconnexion des
structures de l’Etat ;
 la mise à disposition d’un système d’information fiable pour un suivi efficace de l’action
gouvernementale ;
 la coordination de la mise en place d’un cadre législatif et réglementaire propice au
développement des technologies de l’information et de la communication.
 la réduction de la fracture numérique et l'exclusion sociale par la généralisation de
l'accès aux TICs.
MOR THIAM-M2TDSI 10
Elle participe également à la définition de la stratégie de l’administration électronique,

communément dénommée « e-gouvernement », de l’Etat du Sénégal en vue :
 de doter l’Etat d’un système d’information et d’outils d’aide à la prise de décision ;
 de fournir aux citoyens et aux entreprises une interface décentralisée d’accès à
l’Administration ;
 de pérenniser et sécuriser les archives de l’Etat en dotant celui-ci d’une mémoire
électronique ;
 de définir des indicateurs de performances des systèmes d’information mis en place, et
d’en assurer le suivi et l’évaluation ;
 d’évaluer l’impact des investissements réalisés dans le domaine de l’informatique ;
 de contribuer à la bonne gouvernance notamment par la promotion de la télé démocratie.
I.1.3. Missions de la DSSIE

La DSSIE est chargée de l'élaboration, de la mise en œuvre et du suivi de la politique de Sécurité
des systèmes d'informations de l'Etat en vue de :
 Elaborer et implémenter la Politique de Sécurité des systèmes d’Information (PSI) de

l’État du Sénégal
 Mettre en place et maintenir en conditions opérationnelles les solutions de sécurité;
 Sensibiliser, former l'ensemble des parties prenantes sur la sécurité;
 Mettre en conformité le système d'information par rapport aux normes et standards en
la matière.
 Surveiller, améliorer et maintenir le système de management de la Sécurité de
l'information
 Coordonner la mise en œuvre et le suivi du plan de reprise/continuité sur activités en
cas de sinistre;
 Coordonner l'identification l'analyse et l'optimisation des risques liés au système
d'information;
 Assurer la mise en place et la gestion de l'Infrastructure à Gestion de Clé (IGC) national
du Sénégal;
MOR THIAM-M2TDSI 11
 Contribuer à la mise en place et la gestion d'un CSIRT national (ou Computer Security
Incident Response Team) ou CERT national (Centre d'alertes et de réponses aux
attaques informatiques);
 Mettre en œuvre et opérer un dispositif de suivi du niveau de sécurité des SI.
 D’autre part il faut protéger les particuliers en développant des actions de sensibilisation
et de formation.
I.2 Présentation du projet

I.2.1. Contexte
L’ADIE (Agence de l’Informatique de l’Etat), dans sa mission de traiter et de diffuser les
informations qu’ils stockent, est soucieux de la sécurité de ces dernières.
En effet l’infrastructure de l’intranet Gouvernemental, administratif et celui des établissements

privés du Sénégal sont de plus en plus victimes d’incidents de sécurité (piratage, vol de
données…). Par ailleurs, le crime informatique est un crime sophistiqué, réalisé le plus souvent
au niveau international avec le plus souvent un effet à retardement. Les traces laissées dans les
systèmes sont immatérielles et difficiles à collecter et à sauvegarder.
C’est pourquoi après avoir misé sur la prévention et la protection, nous devons investir dans la
détection et la réaction. Détecter pour identifier le plus en amont possible une tentative
d’attaque, un comportement anormal sur ses réseaux ou une exfiltration de données. Répondre
en étant préparé à réagir en cas d’incident de sécurité (attaque virale, DDoS, phishing…) à
travers un véritable processus de gestion et de réponse à incident qui va être piloté et mis en
œuvre par un équipe de type CSIRT.
I.2.2. Problématique
L’Agence De l’Informatique de l’Etat (ADIE) du Sénégal est confrontée à un défaut de gestion

des incidents. En effet un SIEM (Security Information and Event Management) dénommé
Ossim qui permet de faire l'agrégation, la normalisation, la corrélation, le reporting, l'archivage
et le rejeu des évènements. Cette application récupère les évènements de ces serveurs et les
incidents et les attaques signalées par le CDS (Centre De Services). Chaque évènement doit
contenir suffisamment d’informations en vue de permettre une analyse ultérieure efficiente.
MOR THIAM-M2TDSI 12
En outre, il y a un défaut de capitalisation des connaissances, car les connaissances acquises et

détenues par les utilisateurs simples, les administrateurs systèmes, les développeurs
d’application et l’équipe responsable de la sécurité, dans la pratique quotidienne de leur activité,
principalement les savoir-faire et les retours d’expérience ne sont pas sauvegardés ni
documentés.
Aujourd’hui, aucune organisation ne peut affirmer maîtriser à cent pour cent (100%) son
système d’information et encore moins sa sécurité. Il y a eu, il y a et il y aura de plus en plus de
cyber attaques. Les organisations ne doivent plus se demander quand elles ont été victimes
d’une attaque informatique mais plutôt s’interroger depuis quand, comment et pourquoi leur
système d’information a été compromis. Les organisations (entreprise privée ou administration)
se rendent maintenant à l’évidence : aucune défense n’est parfaite et il faut se préparer à réagir
le plus efficacement à un cyber attaque.
I.2.3. Périmètre
Le projet de réalisation d’une plateforme qui va assurer la couverture des besoins en sécurité
de l’intranet gouvernemental et les ressources impactées dans le traitement des incidents de
sécurité des systèmes. Cette plateforme permettra de disposer d’une base de connaissances, des
documentations relatives aux bonnes pratiques à suivre en cas d’incidents de sécurité et la
résolution de ces incidents.
I.2.4. Les parties prenantes au projet
La matrice d’identification des acteurs est une évaluation de l’importance relative des différents
acteurs dans la situation problématique. Le tableau d’identification des acteurs que nous
proposons comporte cinq (05) colonnes. Nous sommes parvenus à réaliser la matrice
d’identification des acteurs (parties prenantes) ci-après pour définir notre périmètre d’action :
MOR THIAM-M2TDSI 13
ACTEURS UNITE ACTEUR POURQUOI INTERNE /

D’ORGANISATION CLE EXTERNE
(OUI(O)/NON
(N))
DG Direction Générale O Interne
de l’ADIE  Evalue la
performance des
équipes chargées
de gérer les
évènements de
sécurité
DAF Direction O
Administrative et  Evalue les
Financière de l’ADIE impacts
financiers qui
affectent les
actifs IT suite à
un incident de
sécurité
DSSIE O
 Piloter les
équipes chargées
de la gestion des
Direction de la évènements et
Sécurité des incidents de
Systèmes sécurité
d’informations de  Définir la
l’Etat stratégie de
gestion des
évènements et
MOR THIAM-M2TDSI 14
incidents de
sécurité
DRST Direction des O

Réseaux, des  Réaliser les
Systèmes et tâches de gestion
Télécoms des évènements
de sécurité
 Fournir des
informations
pour analyse
(logs , journaux)
DSI Direction des O  Aider les

services et de organisations à
l’ingénierie développer des
applications
sécurisées
 Définir les
mesures à
prendre en cas
d’incidents.
 Former et
sensibiliser à la
sécurité
applicative
 Intégrez la
sécurité dans les
processus de
réalisation des
projets
informatiques
MOR THIAM-M2TDSI 15
CNDP Commission O  Fournir le cadre Externe

Nationale de institutionnel du
protection des traitement des
données personnelles données
personnelles
AUTRES Ministères et O  Appliquer les Externe

administrations mesures de
sécurité fournies
par la DSSIE
 Informer la
DSSIE par
rapport aux
failles et aux
erreurs de
traitement, via
téléphone, email
ou à travers la
plateforme de
gestions des
incidents de
sécurité
Tableau 1: Les parties prenantes au projet
I.2.5. Les buts

Les buts du CSIRT pour l’administration sont :
 Créer un cadre de concertation et une veille active sur les vulnérabilités menaçant les
systèmes d’information de l’Etat du Sénégal, l’étude de leur exploitabilité et leur mode
de détection;
MOR THIAM-M2TDSI 16
 Proposer des contre-mesures pertinentes et élaborer des avis et d’alertes avec les autres
CSIRT et les éditeurs des produits;
 Collecter des éléments techniques, analyser et qualifier les cause, avoir une meilleure
compréhension des scénarii d’attaque et de l’étendue de la compromission ;
 Favoriser la définition de mesures d’assainissement et de durcissement ;
 Etablir la coordination avec les partenaires et les victimes dans les gestions de crise ou
d’incidents ;
 Elaborer des synthèses et une capitalisation des informations issues des incidents
traités ;
 Créer et conduire des campagnes de recherche de victimes.
 Proposer des solutions de défenses et de protections contre ces attaques
I.2.6. Les objectifs :

Ce plateforme de traitement des incidents de sécurité a pour objectif d’assurer la continuité ou
la reprise d’activité d’un système d’information en cas problème de sécurité survenant de
manière accidentelle ou délibérée. Elle va accompagner les propriétaires des ressources
impactées dans le traitement des incidents de sécurité des systèmes.
En outre notre démarche est de mettre en place une plateforme centralisée, spécialisé à la
sensibilisation des utilisateurs et la vulgarisation des bonnes pratiques de sécurité informatique.
Il sera aussi une sentinelle pour la remontée d’informations liées à la cybercriminalité.
MOR THIAM-M2TDSI 17
Mémoire de M2TDSI | Gestion des incidents avec Request Tracker|2014-2015 | Mor THIAM-
M2TDSI
CHAPITRE II : ANALYSE ET DEFINITION DES CONCEPTS DE BASE

Dans ce deuxième chapitre, nous allons appliquer notre méthodologie de travail; il s’agira
d’abord d’étudier l’existent, d’analyser les besoins, ensuite de définir les concepts de bases sur
les informations de management des évènements de la sécurité et de la gestion d’incidents,
pour enfin faire une étude comparative des différents outils de gestion d’incidences sur le
marché.
II.1 Evaluation des besoins

II.1.1. Analyse de l’existant
L’Agence De l’Informatique de l’Etat du Sénégal offre en direction des entités administratives,
un service d’hébergement qui s’appuie principalement sur des serveurs web. Ce service, en
termes de gestion des journaux d’évènements de sécurité repose sur une architecture centralisée.
L’infrastructure de gestion des évènements de sécurité génère un volume important de journaux
d’évènements aux formats syslog, evt et evtx.
Ces évènements sont soit générés, soit identifiés ou bloqués par les IDS (intrusions Détection
System) et les WAF (Web Application Firewall) installés sur les serveurs.
L’IDS permet de repérer tous les activités anormales ou suspectes sur la cible analysée (un
réseau ou un hôte). Il permet ainsi d'avoir une connaissance sur les tentatives réussies comme
échouées des intrusions.
Le WAF peut être un appareil, ou un plugin de serveur, ou un filtre qui applique un ensemble
de règles pour une conversation HTTP. Généralement, ces règles couvrent les attaques
courantes telles que le cross-site Scripting (XSS) et l’injection SQL. En personnalisant les
règles de nombreuses attaques peuvent être identifiés et bloqués.
Tous ces divers évènements seront centralisés et managés par OSSIM (Open Source Security
Information Management).
On a constaté aussi que la gestion des incidents provenant du SIEM est manuelle, il n’existe
pas une base de données des incidents et une absence de base de résolution des incidents.
MOR THIAM-M2TDSI 18
M2TDSI
II.1.2. Identification de piste de solution

Les problèmes précités soulèvent un grand nombre de besoins qui peuvent être pris en compte
par une équipe de gestion des incidents de sécurités appelés CSIRT. Les CSIRTs sont capables
de collecter, agréger, normaliser, corréler et traiter les évènements et incidents de sécurité d’un
System d’information.
II.1.3. Présentation d’un SIEM

Etant donné que l’étude d’un SIEM a été traitée par mon prédécesseur, après avoir fait une
brève présentation d’un SIEM je vais passer directement à la présentation d’un CERT
Les SIEM sont des outils de supervision de la sécurité, ils sont habilités à recevoir des journaux
d’évènements et des flux d’information en provenance d’une grande variété d’actifs de support
de service (Firewall, IPS, IDS, Antivirus, Active Directory, systèmes de contrôle d’accès,
systèmes de gestion des identités, équipements de la VOIP, systèmes DLP, serveurs de
messagerie…).. Ils combinent deux éléments principaux :
Figure 3: Vue synoptique d'un SIEM
Les SEM pour Security Events Management qui garantissent le traitement des événements,
c’est-à-dire la supervision à temps réel, la collecte et la corrélation de données.
Les SIM pour Security Information Management qui, eux, se focalisent sur l’analyse des
informations; ils fournissent un moyen de rétention de données et de reporting d’événements.
La supervision centralisée de la sécurité du système d’information par les outils SIEM se réalise
en plusieurs étapes: la collecte, la normalisation, l’agrégation, la corrélation, le reporting, la
réponse et le stockage.
MOR THIAM-M2TDSI 19
M2TDSI
II.1.4. Présentation d’un CERT/CSIRT

Aujourd’hui on peut entendre parler de CSIRT (Computer Security Incident Response Team)
ou de CERT (Computer Emergency Response Team). Derrière ces deux acronymes se cachent
des équipes d’experts en sécurité informatique organisées pour réagir en cas d’incident
informatique.
Le terme CERT est le plus utilisé et le plus connu mais il s’agit d’une marque américaine qui
appartient à l’université Carnegie Mellon. Les CSIRT peuvent demander l’autorisation
d’utiliser le nom de « CERT ». Aujourd’hui, 79 CSIRT sont autorisés à utiliser la marque «
CERT ».
Figure 4: Logo attestant l'utilisation du nom CERT
Généralement un CSIRT est une équipe de sécurité opérationnelle, composée d’experts de

différents domaines (malwares, test d’intrusion, veille, lutte contre la cybercriminalité,
forensics…). Elle est chargée de prévenir et de réagir en cas d’incidents de sécurité
informatique. En amont, elle assure notamment une veille sécurité (les nouvelles attaques, les
nouveaux logiciels malveillants, les dernières vulnérabilités) pour « connaître » l’état de la
menace et évaluer les propres vulnérabilités de son organisation. En aval, elle analyse et traite
les incidents de sécurité en aidant à leur résolution. C’est une équipe qui centralise et sert de
relais que ce soit en interne et ou externe de l’entreprise car la communication est une de ses
fonctions principales.
II.1.5. Les différents types de CSIRT

Il existe plusieurs types de CSIRT. Il peut s’agir d’un CSIRT interne (d’entreprise ou d’une
administration / université / Etat…) comme on trouve, par exemple, chez de grands groupes
MOR THIAM-M2TDSI 20
M2TDSI
bancaires comme BNP Paribas et Société Générale. Le CSIRT a alors un rôle d’ « alerte » et
de cyber pompier, prêt à intervenir pour aider et conseiller l’ensemble du groupe, ses filiales
voire ses clients en cas d’incident de sécurité.
On retrouve également des CSIRT « commerciaux ». Ce sont des équipes d’experts appartenant
à des prestataires de services qui vont proposer des offres de veille, de réponse à incidents et de
forensics (investigation numérique légale) à leurs clients. C’est donc un CSIRT externalisé et
mutualisé.
II.1.6. Avantages fonctionnels d’un CSIRT

L’avantage d’un CSIRT/CERT est de centraliser la réponse à incident mais également de servir
de relai vers l’intérieur de l’organisation (pour prévenir les menaces en informant et
sensibilisant) et surtout vers l’extérieur à destinations des autres CSIRT et CERT et de la
communauté pour la sécurité en général.
Les CSIRT/CERT peuvent aider l'administration sénégalaise:
 dans la gestion de sa cyber-sécurité,

 dans l'appropriation des connaissances nécessaires en matière de gestion proactive et
réactive des incidents de cyber-sécurité,
 à la mise en place des politiques nécessaires pour sa cyber-sécurité,
 à la mise en pratique de méthodes de travail adéquates à une culture de la cyber-sécurité
au sein de l'administration.
 regrouper les CSIRT de la sous-région, du continent et leur permettre de coopérer
II.1.7. L’Etat des CSIRT en Afrique et au Sénégal

Il n’existe pas encore de CSIRT national au Sénégal alors que l’Agence de régulation de la
Cote d'Ivoire a déjà mise en place un, appelé CI-CERT. La République de Maurice a mis en
place l’un des meilleurs Computer Emergency response Team (CERT) d’Afrique. Un projet de
mise en place de CERT a aussi commencé au Ghana où les législateurs se penchent sur une loi
contre la cybercriminalité.
Avec l’appui des Nations Unies qui ont développé un centre Africain de prévention de la
cybercriminalité, alors tout l’enjeu pour l’Afrique sera la capacité des Etats à mutualiser leurs
MOR THIAM-M2TDSI 21
M2TDSI
efforts et leurs infrastructures pour coopérer afin d’assurer la coordination entre les différents
CERT nationaux et privés d’Afrique mais aussi internationaux.
Mais, le Sénégal semble être sur la bonne voie. Car un projet de CERT piloté par l’ADIE et
l’armée est en cours de réalisation. On notera que ce sont deux prestataires de services, ce qui
démontre que le besoin des entreprises à recourir à ce type de service est de plus en plus fort.
Ce faible nombre de CSIRT « officiels » ne signifie pas non plus que certaines entreprises
privées ne disposent pas en interne d’équipe de réponse à incidents. Seulement, elles ont peut-
être fait le choix de ne pas créer des CSIRT publiques. C’est l’exemple des banques comme la
SGBS.
Mais il faut quand même avouer qu’encore beaucoup d’entreprises ne disposent pas de ce type
de compétences en interne. Souvent par manque de moyens (il reste assez difficile de dénicher
des profils expérimentés) ou de volonté. Certaines d’entre elles préfèrent faire appel à des
CSIRT étrangers qui sont souvent « commerciaux »
II.2. Etude des Outils de gestion d’incidents

II.2.1. Etude comparative des outils de gestion des incidents de sécurité
Voici une liste non exhaustive des outils les plus utilisées par les équipes CERT/CSIRT :
Logiciel Domaine d'application Licence
Libre (GNU
SIRIOS Gestion d'incidents de sécurité.
GPL)
Gestion des incidents, des problèmes et des

Siebel HelpDesk Commercial
changements.
Gestion des incidents, problèmes, changements,

ServiceCenter Commercial
configuration
Service Management Gestion des incidents, des problèmes, des

Commercial
Suite changements, des configurations.
gestion d’incidents, de projets, de processus, de la

Request Tracker avec
qualité, de la relation client, de gestion de Service Libre(GPL)
RTIR (WebRT)
Après-Vente
Système de suivi et de gestion des incidents et des

Plain Ticket Commercial
problèmes, sur le web, application infonuagique.
MOR THIAM-M2TDSI 22
M2TDSI
Logiciel Domaine d'application Licence
Logiciel
OTRS Suivi de problème.
libre(GPL)
Tableau 2: Panorama des acteurs du marché
Sur la base de ce tableau, nous avons porté notre choix sur la solution RT. Les principales
raisons qui ont motivé notre choix sont, entre autres :
 le caractère open source et personnalisable
 la modularité
 l’évolutivité
 la communauté active
 la richesse fonctionnelle…
II.2.2. Présentation de l’outil Request Tracker (RT)

C’est un système de suivi d'incidents extensible. Request Tracker (RT) est un système de
billetterie qui permet à un groupe de personnes à gérer efficacement les tâches, les questions et
demandes présentées par une communauté d'utilisateurs.
Il dispose d'interfaces de ligne de commande (voir les paquets rt4-clients), email et web. .etc
RT gère les tâches essentielles telles que l'identification, la hiérarchisation, l’affectation, la

résolution et la notification requise par les applications critiques de l’entreprise y compris la
gestion de projets, d'assistance, CRM (Customer Relationship Management=gestion de la
relation client) et développement de logiciels.
a °) Les objets de RT
 La file :
Au commencement est la file. Et particulièrement la file générale qui est même la première et
indestructible file. Une file est un conteneur à tickets, un ticket représentant une demande et
toutes les informations nécessaires ou relevées pendant son traitement.
MOR THIAM-M2TDSI 23
M2TDSI
Une file peut avoir pour but de regrouper les demandes destinées à une équipe particulière (les
administrateurs système par exemple), les demandes émanant d'un client particulier (son point
d'entrée unique), ou servir de pseudo-liste de diffusion ou boîte aux lettres d'équipe, comme
une file dont l'adresse est abonnée aux listes de sécurité. Les attributs d'une file sont ses deux
adresses de messagerie, des priorités initiale et finale, ainsi que l'échéance normale de résolution
d'un ticket.
 Le ticket :
Le ticket est la représentation d'une demande ou d'un incident qui devra être résolu, et dont il
faut garder trace.
Un ticket dans RT se voit attribuer un acteur et un seul (qui est Nobody au départ) ou
propriétaire, qui a pour charge de mener à bien la résolution de cette demande. C'est cet acteur
qui va pouvoir en modifier l'état ou statut (nouveau, ouvert, bloqué, résolu, rejeté, effacé).
L'état nouveau est l'état par défaut d'un ticket venant d'être créé : personne ne l'a pris (le
propriétaire change) ni n'a commencé à travailler dessus (passage à l'état ouvert).
On peut passer un ticket à l'état bloqué pour signifier qu'il est en attente de quelque chose,
l'effacer s'il avère que l'anti-spam n'a pas fait son travail, en cas d'activation des demandes par
mail ou le rejeter si le demandeur n'a pas fait son travail en amont (RTFM). On peut enfin
résoudre une demande (passage à l'état résolu) afin de le faire disparaître de la base des tickets
actifs.
Il a aussi un ou plusieurs demandeurs, des personnes en copie, un niveau de priorité et un

ensemble de dates (création, butoir, résolution effective). Des observateurs peuvent être définis
pour un ticket, ou plus généralement sur une file (toute une équipe) voire globalement. Ces
observateurs peuvent être au même niveau que le demandeur, ou au même niveau que les
acteurs : un demandeur ou une personne en Cc: ne verront que les correspondances, l'acteur
ou ses pairs verront les correspondances et les commentaires sur le ticket. C'est là
qu'interviennent les deux adresses de messagerie d'une file : il y a une adresse pour les
correspondances (seule utilisable par les demandeurs), une autre pour les commentaires.
MOR THIAM-M2TDSI 24
M2TDSI
Des champs temporels peuvent être définis comme le temps passé (rempli manuellement), le
temps estimé de résolution, l'échéance prévue pour la résolution, le temps restant avant cette
échéance, ainsi que des priorités, allant de 0 à 99.
La sémantique associée à ces priorités devra être définie avant de commencer à utiliser RT, de
façon à ce que tout le monde se mette d'accord sur la priorité « très urgent »... Ça évitera de voir
des tickets de priorité 20 traîner car un acteur s'est mis 20 comme limite, alors que ses voisins
de bureau qui le remplacent pendant ses vacances mettent la barre de l'urgence à 50...
Dernière chose primordiale, l'historique du ticket, qu'il n'est normalement pas possible de
modifier dans RT.
Cet historique est constitué des messages échangés entre demandeurs et acteurs, des
commentaires des acteurs (successifs), et des notifications des actions prises par RT, soit dans
son fonctionnement normal, soit par le biais d'un scrip, comme les changements de priorité,
d'acteurs, etc.
 Des champs personnalisés
On peut aussi associer à un ticket des champs personnalisés qui permettent d'ajouter des
sémantiques personnalisées à ceux-ci. Ces champs personnalisés sont définis au niveau global,
et associés aux tickets soit à ce même niveau global, soit file par file.
Cela peut représenter des champs de formulaire avec des données qu'on aimerait obligatoires
(on ne peut pas encore obliger un acteur à renseigner un champ, mais ça va venir dans les
prochaines versions), le nom du client, le poste de facturation ou que sais-je encore. Je laisse
votre imagination faire ses preuves sur le sujet :-). Créer des champs personnalisés
Mais comme tout objet de RT, les champs personnalisés sont soumis à des contrôles d'accès. Il
faut que les utilisateurs et/ou les groupes concernés disposent du droit «
FixerChampsPersonnalisés ».
Ensuite, la création de champs personnalisés se fait par le menu « Configuration » / « Champs

Personnalisés » / « Nouveau champ personnalisé ». Il est possible ensuite de laisser fixer des
valeurs à choisir ou au contraire de laisser le champ libre aux utilisateurs pour saisir des mots
dans les champs personnalisés, mais l'exploitation n'en sera que plus difficile.
MOR THIAM-M2TDSI 25
M2TDSI
Il faut ensuite attribuer le champ personnalisé à une file, par le menu « Configuration » / « Files
» / (Choisir la file) / « Champs personnalisés du ticket » / (Cocher dans la liste les « Champs
personnalisés non sélectionnés ») / Valider.
Ou, si vous préférez, attribuer ce champ personnalisé à toutes les files, passez par le menu «
Configuration » / « Global » / « Champs Personnalisés » / « Ticket » / (Cocher dans la liste les
« Champs personnalisés non sélectionnés ») / Valider.
 Des modèles
Les modèles sont un contenu générique pour les notifications. Ces modèles sont associés aux
scrips, et peuvent inclure un minimum de code perl de façon à intégrer des variables ou résultats
de méthodes de RT dans l'instanciation du modèle. Vous trouverez des exemples intéressants
dans les modèles par défaut de RT que je vous laisse découvrir (Configuration -> Global ->
Modèles).
 Des scrips
Les scrips (sans « t ») sont un ensemble de conditions d'exécution et des actions associées qui
peuvent être assimilées aux déclencheurs (triggers) que l'on trouve dans les SGBD. Les
conditions et actions peuvent être prédéfinies ou personnalisées, auquel cas elles sont écrites en
Perl et s'exécuteront directement dans RT par le biais d'un eval.
Une petite dizaine de scrips sont livrés dans l'installation standard de RT de façon à assurer son
comportement par défaut de façon globale : envoyer une notification de prise en compte à la
réception d'une demande, notifier les observateurs sur les commentaires et les correspondances,
notifier au demandeur que sa demande a été résolue, même si l'acteur n'a pas envoyé
explicitement de message, etc.
 Des utilisateurs
Les utilisateurs sont eux identifiés comme dans les gestionnaires de listes de diffusion : par leur
adresse de messagerie. Cela permet une chose très pratique : éviter la saisie des personnes. En
effet, chaque personne envoyant une demande à RT est enregistrée dans la base des utilisateurs
si elle n'y est pas encore. Même les futurs acteurs du support peuvent ainsi avoir l'essentiel de
leurs coordonnées saisies automatiquement, juste en envoyant un mail à RT. Il suffira ensuite
MOR THIAM-M2TDSI 26
M2TDSI
de donner à ces utilisateurs le droit d'avoir des droits (i.e. de devenir un acteur du support) et
un mot de passe.
 Des groupes
Les utilisateurs peuvent bien évidemment être regroupés par groupes, des groupes
pouvant inclure d'autres groupes. Cela permet de simplifier d'autant la gestion des droits,
idéalement les utilisateurs ne devant avoir aucun droit sauf celui d'être dans un ou plusieurs
groupes qui lui aura des droits.
 des rôles
Dernier point permettant de catégoriser des utilisateurs de RT : les rôles. Ceux-ci sont au
nombre de quatre : Cc, Intervenant, Demandeur, et AdminCc.
Un Demandeur est une personne qui a créé un ticket, et qui a mis éventuellement mis en copie
d'autres personnes, qui se voient attribuer le rôle Cc (du même Cc: -- carbon copy ou copie
conforme -- que celui de nos messageries). Demandeur et Cc ne verront que les réponses faites
sur un ticket.
Un Intervenant est donc un utilisateur privilégié qui a pris un ticket pour le traiter. Les personnes
en Admin CC sont d'autres intervenants (ou non, mais c'est souvent le cas) qui sont en copie de
tous les messages concernant le ticket, commentaires comme réponses.
 Des droits associés
Les droits sont donc attribués à un utilisateur ou un groupe d'utilisateurs donnés.
Ils portent de façon globale, sur une file donnée, ou un groupe, bref sur les objets de RT.
Cependant, la gestion des droits dans RT n'est pas aisée. En effet, le nombre de droits différents
sur les objets est très important. Il est facile de s'y perdre, d'autant que ces droits ne sont pas
toujours très bien documentés.
b °) Droits sur les files et leurs tickets
MOR THIAM-M2TDSI 27
M2TDSI
Les droits sont ici listés sous leur nom originel anglais, et leur traduction française dans la
dernière version de RT (3.4.4 à l'heure où ces lignes sont écrites).
 AdminQueue (GérerFile)
L'utilisateur possédant ce droit sur une file peut administrer la file en question.
 AssignCustomFields (AttribuerChampsPersonnalisés)
Permet d'attribuer des champs personnalisés à une file.
 CommentOnTicket (CommenterTicket)
Permet à un utilisateur de déposer des commentaires sur un ticket. Cela peut permettre à un
superviseur de faire des suggestions tout en étant sûr que celles-ci ne se retrouveront pas chez
le client.
 CreateTicket (CréerTicket)
Ce droit est plus que souvent attribué à tout le monde (Everyone), afin d'avoir le moins
d'intermédiaires possibles entre l'émetteur d'une demande et celui qui l'enregistre.
Concrètement, si les utilisateurs non privilégiés n'ont pas ce droit, la fonction de création de
ticket par mail ne fonctionnera pas.
 DeleteTicket (SupprimerTicket)
Auto-décrit. À noter que les tickets ne sont pas détruits mais marqués comme tels, ce qui les
fait disparaître de toutes les recherches. Ce droit, si vous avez la possiblité de faire créer des
tickets par mail depuis internet vous évitera d'être noyé sous les spams.
 ModifyACL (ModifierACL)
Auto-décrit.
 ModifyQueueWatchers (ModifierObservateurs)
Idem
 ModifyScrips (ModifierScrips)
Permet la modification des scrips RT. Ce droit ne doit être confié qu'à un administrateur RT
chevronné, sous peine de trou de sécurité avec tout ce que cela implique.
 ModifyTemplate (ModifierModèle)
MOR THIAM-M2TDSI 28
M2TDSI
La modification des modèles de correspondance doit aussi n'être confié qu'aux administrateurs
RT.
 ModifyTicket (ModifierTicket)
Permet aux intervenants, de même qu'aux demandeurs d'enrichir le ticket.
 OwnTicket (PrendreTicket)
Ce droit de posséder un ticket permet, au contraire du précédent, de différencier les intervenants

ayant leur mot à dire, de ceux qui traiteront véritablement le ticket.
 ReplyToTicket (RépondreTicket)
Idem CommentOnTicket, pour les réponses. Ce droit ne devrait être donné qu'aux intervenants,
de façon à éviter les discours incohérents envers les demandeurs.
 SeeQueue (VoirFile)
Voir une file. Ce droit a des implications qui vont relativement loin. En effet, voir une file, c'est
aussi pouvoir y déplacer un ticket. Comme par exemple une demande système qui fait des
allers-retours avec la file bases de données.
 ShowACL (AfficherACL)
Autorise la vision sur les permissions sur les objets RT.
 ShowOutgoingEmail (AfficherEmailSortant)
Ce doit permet d'autoriser un utilisateur d'afficher des emails sortants
 ShowScrips (AfficherScrips)
Ceci est réservé aux administrateurs RT qui pourront afficher les scrips
 ShowTemplate (AfficherModèle)
Idem. Ce droit ainsi que le précédent permettent de voir l'essentiel du paramétrage du

comportement de RT.
 ShowTicket (AfficherTicket)
La vue sur un ticket implique qu'on l'on voit aussi les tickets sur la page d'accueil, entre autres.
Ce qui peut polluer par exemple la vision de l'administrateur système s'il n'y voit que des
MOR THIAM-M2TDSI 29
M2TDSI
demandes pour les fonctionnels SAP. Ce droit permet uniquement de voir les échanges publics.
Le droit suivant le complète.
 ShowTicketComments (AfficherCommentairesTickets)
Ce droit a son importance si l'on considère que le commentaire est privé aux intervenants. On
ne le donnera évidemment pas aux demandeurs, mais pas non plus aux intervenants d'autres
files pouvant voir les tickets de la file considérée.
 StealTicket (VolerTicket)
Voler un ticket n'est pas mal. C'est le travail qui se transmet. Dans les faits, c'est même le seul
moyen d'assurer la continuité d'activité sur l'absence d'un des intervenants (maladie, congés,
etc.).
 TakeTicket (PrendreTicket)
Ce droit va souvent de pair avec celui de posséder un ticket. Cependant, les tickets peuvent être
assignés par un superviseur, auquel cas le droit de prendre un ticket n'est pas nécessaire, le droit
de le posséder l'étant.
 Watch (Observer)
Le droit d'observer est la base d'un fonctionnement symbiotique d'une équipe. Observer une file
permet de ressentir l'activité d'une équipe. Ce droit précis n'est pas à confondre avec le suivant,
car il ne concerne que la partie visible des transactions sur un ticket, les demandes et les
réponses, les commentaires n'étant pas vus.
 WatchAsAdminCc (ObserverCommeAdminCC)
Similaire au droit précédent, il permet aux personnes le possédant d'être destinataires des
demandes, réponses, mais aussi commentaires sur les tickets d'une file.
Ce droit va souvent de pair avec celui de posséder un ticket. Cependant, les tickets peuvent être
assignés par un superviseur, auquel cas le droit de prendre un ticket n'est pas nécessaire, le droit
de le posséder l'étant.
 Watch (Observer)
MOR THIAM-M2TDSI 30
M2TDSI
Le droit d'observer est la base d'un fonctionnement symbiotique d'une équipe. Observer une file
permet de ressentir l'activité d'une équipe. Ce droit précis n'est pas à confondre avec le suivant,
car il ne concerne que la partie visible des transactions sur un ticket, les demandes et les
réponses, les commentaires n'étant pas vus.
 WatchAsAdminCc (ObserverCommeAdminCC)
Similaire au droit précédent, il permet aux personnes le possédant d'être destinataires des
demandes, réponses, mais aussi commentaires sur les tickets d'une file.
c °) Droits sur champs personnalisés

Les droits sur les champs personnalisés sont explicites, citons rapidement :
 AdminCustomField (GérerChampPersonnalisé) : les personnes possédant ce droit

peuvent gérer un champ personnalisé
 ModifyCustomField (ModifierChampPersonnalisé) : les personnes possédant ce
droit peuvent modifier un champ personnalisé
 SeeCustomField (VoirChampPersonnalisé) : les personnes possédant ce droit
peuvent superviser un champ personnalisé
d °) Droits sur Groupes

Idem pour les groupes d'utilisateurs :
 AdminGroup (GérerGroupes) : droit d’administrer un groupe

 AdminGroupMembership (GérerAppartenanceGroupes) : droit d’administrer les
membres d’un groupe
 SeeGroup (VoirGroupe) ; droit de voir les membres d’un groupe
 ModifyOwnMembership (ModifierPropresAppartenances) : droit de modifier
‘appartenance d’un membre à un groupe
e °) Droits sur les recherches sauvées
Il Existe les droits suivants :
 CreateSavedSearch (CréerRechercheSauvée) : droit de créer des recherches et de les

sauvegarder,
 EditSavedSearches (ModifierRecherchesSaugardées) : droit d’éditer les recherches
sauvegardées,
MOR THIAM-M2TDSI 31
M2TDSI
 LoadSavedSearch(ChargerRechercheSauvée) : droit de charger les recherches

sauvegardé,
 ShowSavedSearches (AfficherRecherchesSauvées) : droit d’afficher les recherches
sauvegardées,
f°) Droits globaux

Ces droits globaux, ou plutôt attribués globalement, et de portée globale, sont constitués de la
totalité des droits déjà cités, associés à ceux, spécifiques, qui suivent :
 AdminAllPersonalGroups (AdminAllPersonalGroups) :
Gestion de tous les groupes personnels, y compris ceux appartenant à d'autres.
 AdminOwnPersonalGroups (GérerGroupesPersonnelsPropres)
Gestion de vos groupes personnels.
 AdminUsers (GérerUtilisateurs)
Pas besoin d'en dire plus.
 AssignCustomFields (FixerChampsPersonnalisés)
AssignCustomFields autorise l'utilisateur qui le possède à assigner des champs personnalisés

de façon globale.
 DelegateRights (DéléguerDroits)
Le fait de donner le droit DelegateRights à un utilisateur lui permettra à son tour d'attribuer des
droits à d'autres. Ce droit est à manier à précaution, comme peut l'être le droitGRANT de SQL.
Il peut avoir une implication en termes de sécurité. Déjà que les ACL de RT sont difficiles à
maîtriser, n'allez pas vous créer de problèmes dès le départ en donnant ce droit.
 ModifyOwnMembership (ModifierPropresAppartenances)
Permet d'entrer ou sortir de groupes.
 ModifySelf (ModifierDonnéesPerso)
ModifySelf permet entre autres à un utilisateur de modifier son mot de passe et ses informations
personnelles.
 ShowConfigTab (VoirOngletConfiguration)
MOR THIAM-M2TDSI 32
M2TDSI
ShowConfigTab indique que l'utilisateur a le droit de voir l'onglet Configuration de RT.
 SuperUser (SuperUtilisateur)
SuperUser indique que l’utilisateur a les mêmes droits que le super utilisateur.
g°) Les points forts de RT

La plus grande force du logiciel, est la facilité de personnalisation :
 champs personnalisables (« Custom Fields »), il s'agit d'attribuer des champs de

différents types à un événement ;
 scrips il s'agit d'un système de macros déclenchées en fonction d'un événement.
Par exemple, il est possible d'envoyer un mail à un responsable lorsqu'un certain
type d'incident est signalé ;
 une multitude d'options de configuration ;
 une architecture modulaire
h°) Les points faibles de RT

L’installation n'est pas des plus aisée et demande des compétences non négligeables en
informatique, il faut donc compter une bonne journée ;
 l'application est gourmande en ressources, il est nécessaire de la déployer sur une

machine relativement puissante avec des ressources disques et mémoire conséquentes
et même sur une bonne machine.
 la charte graphique par défaut n'est pas très jolie, mais c'est un point assez subjectif ;
 l'ergonomie de l'interface graphique n'est pas ce qu'ont fait de mieux en la matière.
Certains écrans sont fouillis et très complexes à utiliser. De plus, les contraintes liées aux
formulaires web n'arrangent pas les choses. Toutefois, RT est le logiciel libre de référence en
matière de gestion d'incidents. Il est utilisé par de nombreuses entreprises ou organisations
parmi lesquelles : la NASA, Merrill Lynch, Freshmeat, Free Telecom, etc...
II.2.4. Présentation de l’outil RTIR (Request Tracker for Incidence

Response)
RTIR est l'extension de RT pour la gestion d'une équipe de réponse à des incidents de sécurité
(des CERT, en anglais). Ce logiciel permet donc de gérer les incidents, depuis l'alerte sur un
MOR THIAM-M2TDSI 33
M2TDSI
incident, le recensement et le suivi des contre-mesures mises en œuvre jusqu'à la chronologie

des investigations.
MOR THIAM-M2TDSI 34
M2TDSI
Chapitre III: ANALYSE ET CONCEPTION DE LA SOLUTION
RT est un logiciel libre de gestion d’incident par ticket, il permet la prise en charge des
demandes client.
Lorsqu’un problème survient chez un de nos clients (plantage serveur, coupure de service,
etc…).Celui-ci envoie un mail ou bien téléphone au support pour signaler l’incident.
Cet incident donne lieu à un ticket qui sera pris en charge par le support technique.
Grace à ce système :
* Les demandeurs peuvent suivre en temps réel, la résolution de l’incident
* Communiquer avec le support
* Le support facture les interventions si le service est payant
* L’ensemble des interventions sont archivées.
Dans la suite du document nous allons voir le processus de mise en place d’ une politique de
gestion d’un incident , ensuite de passer à la condition de formation des équipes de réponse
d’urgence aux incidents et enfin de terminer avec le traitement d’un incident .
III.1. Définition d’un incident

Un incident de Sécurité du Système d’Information(SSI) est un évènement indésirable et/ou
inattendu présentant une probabilité forte d’impacter la sécurité de l’information dans ses
critères de disponibilité, d’intégrité, de Confidentialité et ou de Preuve.
Un incident de SSI correspond à une action malveillante délibérée, au non-respect d’une règle
de la Politique de Sécurité du Système d’Information (PSSI) ou, d’une manière générale, à
toute atteinte aux informations, toute augmentation des menaces sur la sécurité des informations
ou toute augmentation de la probabilité de compromission des opérations liées à l’activité.
Concernant la disponibilité, on fera la différence entre les sinistres majeures (incendie,

inondation, etc.) considérés comme des cas de force majeure et nécessitant l’activation d’une
cellule de crise et les autres incidents (panne d’un serveur). Une atteinte à la disponibilité pourra
être considérée comme étant un incident de sécurité (déni de service suite à une intrusion) ou
non (panne de serveur suite à une défaillance d’un composant), après analyse des causes.
MOR THIAM-M2TDSI 35
M2TDSI
III.2. Politique de la gestion des incidents de la sécurité

La mise en œuvre d’un processus de gestion des incidents de sécurité nécessite la définition
 du périmètre,
 des objectifs (politiques de gestion des incidents)
 des mesures (processus, bonnes pratiques, etc.),
 des moyens associés (organisation des ressources matérielles / humains / budgétaires
Une politique de gestion des incidents de sécurité passe par la définition de deux objectifs
majeurs :
 garantir que le mode de notification des évènements et des failles liés à la sécurité de
l’information permet la mise en œuvre d’une action complémentaire ou corrective dans
les meilleurs délais,
 garantir la mise en place d’une approche cohérente et efficace pour le traitement des
incidents liés à la sécurité de l’information.
III.3. Les Mesures à mettre en place

Les mesures suivantes sont essentielles à l’atteinte de ces deux objectifs.
1-Les évènements liés à la sécurité de l’information doivent être signalés, dans les meilleurs
délais, par les circuits appropriés.
2- Il doit être demandé à tous les salariés, contractants et utilisateurs tiers des systèmes et
services d’information de noter et de signaler toute faille de sécurité observée ou soupçonnée
dans les systèmes ou services.
3- Des responsabilités et des procédures doivent être établies, permettant de garantir une
réponse rapide, efficace et pertinente en cas d’incident lié à la sécurité de l’information.
4- Des mécanismes (organisation, procédures, outils, etc. .) doivent être mis en place,
permettant de quantifier et surveiller les différents types d’incidents liés à la sécurité de
l’information ainsi que leur volume et les couts associés.
5- Un programme d’assurances adapté doit être mis en œuvre pour protéger les personnes, les
investissements, les informations et l’ensemble des actifs de l’entreprise ou de l’organisme. La
définition du périmètre à assurer fait en règle générale l’objet d’une analyse de risques menée
avec l’assureur. Il faut évaluer le plus précisément possible, la nature des risques encourus, les
MOR THIAM-M2TDSI 36
M2TDSI
conséquences financières qu’ils peuvent engendrer, puis arbitrer entre l’auto-assurance

(provision, franchise) et le transfert de risques à l’assureur.
Ces contrats d’assurances doivent couvrir également les risques informatiques (pannes,
destruction, vol de matériel, fraude, etc.) et tout particulièrement le poste « surcoût
d’exploitation en cas de sinistre ». Des assurances de type « pertes d’exploitation » permettent
de surmonter les difficultés financières engendrées par un sinistre.
6- Lorsqu’une action en justice civile ou pénale peut être engagée contre une personne physique
ou un organisme, à la suite d’un incident lié à la sécurité de l’information, les éléments de
preuve doivent être recueillis, conservés et présentés conformément aux dispositions légales
relatives à la présentation de preuves régissant la ou les juridiction(s) compétente(s).
III.4 Organisation
III.4.1 Préambule
Une fois l’incident qualifié en tant qu’incident de sécurité il doit être confié à une équipe
spécialement constituée pour l’analyse, l’évaluation d’impact, les actions correctives et la
remise en fonction du service affecté. Cette équipe porte très souvent le nom de CSIRT
(Computer Security Incident Response Team) ou ISIRT (Information Security Incident
Response Team).
En fonction de la taille de l’entreprise ou de l’organisation cette équipe peut avoir une

organisation très différente :
 Modèle centralisé (CCSIRT) : est matérialisé par une équipe unique et centralisée prenant
en charge tous les incidents de l’organisation/entreprise. Ce modèle est efficace pour les
organisations de taille limitée ou les grandes organisations avec les moyens informatiques
très centralisés,
 Modèle distribué (DCSIRT): on a plusieurs équipes dispersées géographiquement en

fonction de la localisation de centres d’hébergement de ressources informatiques. Il est
important, pour une meilleure efficacité et communication, que ces équipes soient malgré
tout administrés par une autorité centrale garantir l’application des procédures homogènes
et un échange efficace d’informations entre équipes,
MOR THIAM-M2TDSI 37
M2TDSI
 Entité de coordination : dans le cas du modèle distribué fortement dispersé ou d’une

communauté d’organisations indépendantes l’équipe de coordination remplit les rôles
suivants :
 coordination des actions des différents DCSIRT quand l’incident a un impact sur
plusieurs entités,
 centre d’expertise et d’assistance,
 émetteur de recommandations et des bonnes pratiques,
 gestionnaire de base de connaissances partagée par tous les membres d’organisation ou
communauté,
Un exemple de centre de coordination pour la communauté d’utilisateurs d’Internet est le
CERT/CC (Central Emergency Response Team/ Coordination Center situé à l’université de
Carnegie Mellon aux Etas-Unis) ou le CERTA (Centre d’Expertise Gouvernemental de
Réponse et de Traitement des attaques informatiques) du gouvernement français (liste non
exhaustive).
Indépendant du modèle d’organisation les membres de chaque équipe doivent disposer des
moyens fiables et sécurisés de communication interne, mais également externe pour collaborer
avec les équipes concernées dans le cadre de leur activité.
Un autre aspect d ‘organisation de moyens de gestion d’incidents de sécurité est la décision du

mode de gestion des ressources humaines et des services.
Dans le cas le plus simple l’équipe est constituée d’employés de l’entreprise ou de

l’organisation et prend en charge l’ensemble des services. Dans certains cas, elle fait appel au
support offert par les sociétés externes. Ce modèle peut être difficile à faire fonctionner à cause
du large éventail de compétences exigées dans plusieurs domaines d’une part et de l’obligation
d’opérer le plus souvent 24H / 24 et 7j/7, d’autre part. Seules les grandes entreprises
/organisations peuvent s’offrir ces capacités.
A l’opposé du modèle précédent il est possible d’externaliser entièrement la gestion des

incidents de sécurité à des prestataires de services spécialisés (MSSP : Managed Security
Services Provider). Dans ce cas les taches de prise d’appel, de monitoring et détection,
d’analyse, d’évaluation d’impact et de reporting sont entièrement prises en charge par le
prestataire et les actions correctives et restitutions des services sont faites en collaboration avec
les équipes de production (internes ou externes).
MOR THIAM-M2TDSI 38
M2TDSI
Souvent le modèle mixte de répartition des tâches entre le personnel interne et les prestataires
peut être le mieux adapté.
Dans de nombreux cas, il est très important de définir précisément, de publier et de

communiquer les missions et les services à fournir par chacune des entités concernés.
Enfin, les équipes opérationnelles, dans de nombreux cas, seront obligées de communiquer avec
les décideurs, l’administration et le support technique. Elles doivent donc disposer à tout
moment d’une liste à jour des contacts nominatifs représentant différentes entités comme :
 la Direction Générale,
 le RSSI,
 les télécoms et réseaux,
 le support IT,
 les services juridiques,
 la communication (relations presse et média),
 les RH,
 les acteurs du PCA,
 la sécurité physique,
 les services généraux,
III.4.2. Équipe de réponse aux incidents SSI
Pour que les incidents de sécurité puissent être correctement traités, il est nécessaire qu’une structure
existe et qu’elle soit dédiée à la gestion d’incidents. Les sigles CERT (Computer Emergency Team) ou
CSIRT (Computer Security Incident Response Team) décrivent les activités de telles équipes.
Cette structure est amenée à être sollicitée par sa hiérarchie ou par des contacts techniques pour
qualifier des évènements et intervenir sur un incident de sécurité. Pour cela , cette équipe doit être
clairement identifiée comme un point de passage obligé dans tout circuit de notification d’incident.
Cette équipe doit également disposer de la légitimité nécessaire pour pouvoir agir rapidement. Pour
cela, le management doit être persuadé de l’intérêt des actions de l’équipe, il doit donc être impliqué
dans la définition des objectifs de l’équipe et être bénéficiaire de services offerts par l’équipe.
MOR THIAM-M2TDSI 39
M2TDSI
III.4.3. Fonctionnement
Une équipe de réponse aux incidents de sécurité doit répondre à différents objectifs imposés par son
environnement. Parmi ses objectifs on peut lister :
 la rationalisation de la veille dans l’entreprise ou l’organisation,
 la nécessité de traiter rapidement tout type d’incident de sécurité par du personnel

qualifié habileté et avec des modes opératoires éprouvés,
 la nécessité d’avoir une vue du risque d’exposition du SI de l’entreprise ou de
l’organisme.
Ces objectifs répondent à des stratégies d’entreprise ou d’organisation (conformité réglementaire,

protection de l’image, efficacité opérationnelle, etc.).
L’environnement d’une équipe de réponse aux incidents de sécurité est constitué de cercles d’acteurs/
partenaires avec lesquels elle travaille (cf. Figure 5):
 cercle de premier niveau : les commanditaires du service (responsables hiérarchiques ou

fonctionnels),
 cercle de second niveau : les acteurs internes pour lesquels elle intervient (responsables sécurité,
responsables informatiques),
 cercle de troisième niveau : les acteurs internes avec lesquels elle travaille au quotidien (équipes
de production, support informatique, équipes projet),
 cercle de quatrième niveau : les acteurs internes avec lesquels elle a besoin de travailler
ponctuellement (juristes, ressources humaines, chargé de communication, cellule de crise),
 cercle de cinquième niveau : les acteurs externes avec lesquels elle travaille (fournisseurs de
services, prestataires de service),
 cercle de sixième niveau : les acteurs externes avec lesquels elle échange (CERTs, forces de
police, chercheurs indépendants, etc.).
MOR THIAM-M2TDSI 40
M2TDSI
Figure 5:Acteurs/partenaires de l’équipe de réponses aux incidents de sécurité
Cet environnement complexe requiert d’être maintenu à jour pour assurer une pleine capacité
de réaction à l’équipe de réponse aux incidents. Une veille permanente et attentive aux
nouvelles tendances et méthodes d’attaques est également nécessaire.
Pour être contactée rapidement, l’équipe de réponse aux incidents doit bénéficier d’une bonne
visibilité en interne comme en externe. L’attente de cet objectif nécessite du temps et la mise
en œuvre de différentes actions telles que : rencontres, présentations orales, participations à des
conférences.
Il est utile de fournir à l’équipe une adresse de messagerie générique et un numéro de téléphone.
Les compétences requises au sein de l’équipe de réponse aux incidents sont multiples et
dépendent des services qui sont fournis par l’équipe. Dans la plupart des cas, il sera nécessaire
de disposer :
 de compétences techniques pour pouvoir analyser précisément le contexte opérationnel

dans lequel l’incident s’est produit et identifier rapidement des contre-mesures pouvant
être mises en œuvre sans mettre en péril le Système d’Information,
 d’une connaissance du contexte et des enjeux métier,
 de compétence rédactionnelle pour pouvoir formaliser correctement toutes les actions
entreprises dans le cas de réponse à incident,
MOR THIAM-M2TDSI 41
M2TDSI
 d’une aisance relationnelle pour pouvoir échanger facilement avec les acteurs concernés
en adaptant le discours en fonction du profil des interlocuteurs.

III.4.4 .Services et périmètre
L’équipe peut offrir de multiples services liés à la gestion d’incidents de sécurité. Ces services
peuvent être regroupés en trois grands domaines d’activité (cf. Figure 6) :
 services réactifs,
 services proactifs,
 services qualitatifs.
Figure 6: Grands domaines d’activité des services liés à la gestion d’incidents de sécurité
Services réactifs :
Le domaine réactif regroupe tous les services qui peuvent être mis en œuvre lors du traitement
d’un incident de sécurité. Les services suivants sont rattachés à ce domaine :
MOR THIAM-M2TDSI 42
M2TDSI
 service d’alerte : ce service a pour objectif de notifier les parties prenantes d’un danger
à très court terme. Des contremesures sont listées permettant de remédier au problème,
 service de traitement des incidents : ce service assure la prise en charge partielle ou
totale de l’incident par l’équipe de réponse aux incidents de sécurité. L’équipe pourra
apporter une simple assistance téléphonique, fournir des modes opératoires ou assister
physiquement les équipes opérationnelles lors de cet incident. L’équipe intervenant sur
l’incident aura à sa charge la détection ; l’isolation et la remédiation de la menace
associée à l’incident. Un service sous intervention est préférable mais demande des
compétences multiples, des procédures rodées et de l’outillage,
 service de gestion des vulnérabilités : ce service consiste à centraliser les vulnérabilités
sur le périmètre de l’entreprise ou de l’organisme, à les analyser et à coordonner leur
correction,
 PCA /PRA : un incident analysé et jugé important pourra engendrer la nécessité de
déclencher un plan de continuité d’activité (PCA) voire un plan de reprise d’activités
(PRA). Dans ce cas, il est capital que l’équipe en charge du traitement de l’incident soit
intégrée aux procédures d’alerte et de qualification du PCA. L’équipe de réponse aux
incidents pourra contribuer à la gestion de crise selon la nature de l’incident.
Services proactifs :
Le domaine proactif regroupe des services qui ont pour objectif de prévenir l’apparition d’un
incident ou tout du moins d’anticiper son traitement. Les services suivants sont rattachés au
domaine proactif :
 annonces : diffusion d’informations permettant d’anticiper une menace (informations

concernant les vulnérabilités ou l’état de la propagation d’une menace constatée en
externe),
 veille technologie : mise à disposition d’une synthèse sur les informations de sécurité
essentielles sur une période donnée,
 audits de sécurité et tests d’intrusion : ces services permette d’avoir une meilleure
visibilité du niveau du risque et repérer les points de faiblesse de certains pans dus SI,
 administration de composants sécurité : ce service permet d’assurer l’administration des
briques de l’infrastructure sécurité de façon à garantir la maitrise du traitement en cas
d’incident,
 développement d’outils : ce service vise à développer quelques outils de sécurité,
MOR THIAM-M2TDSI 43
M2TDSI
 détection d’intrusions : ce service permet d’avoir une visibilité sur les attaques à
destinations du SI,
 corrélation d’évènements de sécurité : ce service permet d’associer les évènements de
sécurité pour identifier s’ils donnent lieu à un incident de sécurité,
 surveillance : ce service très générique peut être décliné en activités distinctes suivant
le métier de l’entreprise /organisme ou ses centres d’intérêt. Dans tous les cas, des
services de surveillance permettront d’identifier des comportements anormaux
probablement caractéristiques d’un incident de sécurité.
Services qualitatifs:
Le domaine qualitatif regroupe des services qui participent à l’élévation du niveau de sécurité
par des actions de fond. Ces services ne sont pas propres à la gestion d’incident, mais une
équipe de réaction aux incidents peut souvent y apporter une forte valeur ajoutée. Les services
suivants sont rattachés à ce domaine :
 analyse de risques : une équipe de réponse aux incidents peut apporter une aide
précieuse pour identifier rapidement les menaces et leurs impacts sur un actif de
l’entreprise ou de l’organisme. Dans ce cas, une interaction doit être créée entre les
équipes projets ou d’architecture en charge des analyses de risque et l’équipe de réaction
aux incidents,
 PCA/PCR : une équipe de réponse aux incidents acquière rapidement de l’expérience
sur les typologies d’incidents rencontrés dans l’entreprise ou l’organisme et sur le mode
de traitement le plus adapté pour leur éradication. L’équipe de réponse aux incidents
pourra contribuer à la gestion de crise selon la nature de l’incident,
 qualification des incidents de sécurité : l’équipe de réponse aux incidents de sécurité
contribue à l’élaboration de guides de qualification des incidents, notamment pour
l’équipe d’assistance de premier niveau,
 conseils : la bonne maitrise des attaques et des contremesures confère à l’équipe de
réponse aux incidents des connaissances qui pourront être mises à contributions pour
des missions de conseil. Tout du moins, il est important que l’équipe soit reconnue par
les équipes projet pour solliciter son conseil sur des points précis,
 sensibilisation : les incidents rencontrés par l’équipe
MOR THIAM-M2TDSI 44
M2TDSI
III.4.5.Les différentes types de menaces:
Nous allons passer à une rapide description des types d'incidents les plus courants.
a°) Compromission
Une compromission signifie qu'un élément extérieur a réussi à prendre le contrôle d'un
système informatique ou lancer l'exécution de programmes avec des intentions discutables sur
la machine en question. Elle s'accompagne généralement de l'introduction de backdoor
permettant au pirate un accès discret à la machine pour la suite de ses opérations.
b°) Defacement
On peut dire aussi : défiguration. Ce type d'incident consiste en la modification frauduleuse
d'une ou plusieurs pages du site Web attaqué.
c°) Déni de Service

Attaque ayant pour objectif de saturer un système informatique, un service en ligne et d'en
rendre l'accès impossible ou très difficile. Pour arriver à ses fins, l'attaquant peut envoyer un
flux de données très important vers la cible, occupant toute la capacité de la ligne de
communication du système. Il peut aussi envoyer vers un service en ligne un nombre de
requêtes suffisamment important pour que toute nouvelle requête légitime soit rejetée.
Ce type d'attaque nécessite un flux de données beaucoup moins important que l'attaque
précédente et est en général plus ciblée. Certaines failles de sécurité de systèmes peut aussi
provoquer des erreurs dans le fonctionnement de programmes pouvant aboutir à l'arrêt brutal
(crash) ou au gel d'un service en ligne ou d'un ordinateur. Elles peuvent aussi être utilisées par
un attaquant pour perpétrer ce type d'attaque.
d°) Déni de Service Distribué (ou DDoS)

Un très grand nombre d'ordinateurs génèrent le trafic d'attaque (de manière volontaire ou
forcée, suite à un piratage) : on peut dire que la charge de l'attaque est distribuée sur plusieurs
systèmes sources.
e°) Phishing
Il s'agit d'une forme d'escroquerie consistant a créer une copie de certaines pages Web
légitimes d'un organisme et de s'en servir pour donner à ses victimes l'illusion de se trouver
dans un environnement connu et de confiance. L'attaque consiste alors à profiter de leur
confusion pour les amener à donner des informations personnelles et sensibles. Il s'agit en
général de données permettant de se connecter à leur espace client bancaire ou d'autre types
d'établissement gérant des fonds. Les clients du site copié sont le plus souvent incités à se
rendre sur le faux site web via un e-mail. La tendance est aujourd'hui à la diversification des
données d'accès volées : on voit maintenant des attaques ciblant les utilisateurs de
fournisseurs d'accès Internet, de services administratifs en ligne, de réseaux sociaux, de
services d'hébergement web, de chaines de TV payantes…
MOR THIAM-M2TDSI 45
M2TDSI
f°) Scan
Sondage réseau : le but de la manœuvre est de toquer à la porte des systèmes pour tenter de
découvrir des informations sur les systèmes accessibles depuis l'Internet (leurs adresses, les
services accessibles, les versions des logiciels utilisés, l'organisation interne d'un serveur, la
présence ou non de certaines vulnérabilités, etc). Cette activité est souvent entreprise dans des
phases de prise d'information préparatoires à des attaques…
g°) Scam
On peut aussi dire arnaque… Connu aussi sous le nom de nigerian 419, d'après l'article du
code pénal nigérian réprimant ce type d'escroquerie cette attaque consiste à envoyer, par
email, à des Internautes non ciblés une demande d'aide pour sortir des fonds plus ou moins
légaux d'un pays en fournissant un compte intermédiaire contre rémunération. Bien
évidemment, la personne ayant fourni ses coordonnées bancaires ne verra jamais de fonds
transiter par son compte, celui-ci étant simplement vidé.
Spam
Le spam ou courrier électronique non-sollicité est le nom générique donné à toutes formes
d'envoi massif d'émail non sollicité, en général à caractère publicitaire.
III.5. Processus de traitement des incidents

Le processus de gestion des incidents de sécurité est représenté par le schéma ci-dessous. La
particularité du traitement des incidents de sécurité tient à l’intervention de l’équipe de réponse
aux incidents de sécurité. Les autres volets du processus appartiennent soit au processus général
de gestion des incidents (prise en compte de l’incident, catégorisation, qualification,
traitement), soit au processus de gestion de crise.
MOR THIAM-M2TDSI 46
M2TDSI
Figure 7: Schématique du processus de gestion des incidents
Le signalement d’un évènement susceptible d’être qualifié d’incident de sécurité est réalisé soit
par une personne (utilisateur, administrateur, etc) ou par des moyens techniques (outils de
surveillance, sites Internet spécialisés, etc).
La prise en compte est réalisée en général par un Help Desk. D’autres circuits peuvent exister.
Dans tous les cas, il est nécessaire que l’évènement soit enregistré de manière à pouvoir en
faire un suivi.
C’est à ce stade de la prise en compte que l’évènement est catégorisé .Il peut étre catégorisé
« incident de sécurité » ou être confié à des experts pour qualification.
Les incidents catégorisés « incident de sécurité » sont immédiatement soumis à l’équipe de

réponse aux incidents de sécurité. Les autres types d’incident sont transmis aux équipes
compétentes pour leur traitement (support).
L’équipe de gestion des incidents, après analyse, confirme ou infirme la catégorisation «

incident de sécurité » (qualification). Les incidents non confirmés « incident de sécurité » sont
retransmis aux équipes support.
MOR THIAM-M2TDSI 47
M2TDSI
Les incidents qualifiés « de sécurité » font alors l’objet d’un traitement spécifique dont les
particularités sont développées dans la partie suivante. Outre les investigations
complémentaires, le traitement des incidents de sécurité peut nécessiter des actions spécifiques
telles que la préservation des preuves ou des actions adaptées de communication.
Lorsque l’équipe de gestion des incidents de sécurité n’est plus à même de gérer la situation,
ou lorsque les conséquences potentielles sont à un niveau trop important, la cellule de crise est
alertée et juge de l’opportunité de passer en mode « gestion de crise ».
III.6.Gestion des incidents de SSI

Dans cette partie, nous allons détailler les étapes du processus de gestion des incidents présentée
d’une manière générale.
III.6.1. Détection et signalement de l’incident

La détection peut avoir pour origine :
 toute personne qui a connaissance d’un fait ou d’une menace pour l’organisme (par
exemple comportement anormal d’un équipement, d’une application ou d’une
personne),
 un administrateur lorsqu’il est informé par un dispositif de supervision ou lorsqu’il constate
une anomalie lors des contrôles,
 un acteur de la sécurité lorsqu’il est informé par un outil de surveillance (détection d’intrusion
ou d’action frauduleuse) ou lorsqu’il constate une anomalie lors des contrôles.
L’anomalie doit pouvoir être signalée à une personne compétente dans les plus brefs délais. Le
contact habituel pour l’utilisateur est le help desk.
Cependant, il doit également être possible de contacter directement un responsable de la sécurité
en toute discrétion si la situation l’exige. Les utilisateurs doivent être sensibilisés et informés
sur les différents niveaux d’alerte.
Dans tous les cas, on doit s’assurer que les moyens d’alerte sont suffisamment rapides, y
compris en dehors des heures ouvrées, pour permettre une réponse adaptée (empêcher que
l’incident se poursuive, préserver les preuves, etc.).
Des mesures immédiates peuvent être associées à la détection, soit sous forme de consignes
pour la personne qui détecte, soit par l’activation automatique de mécanismes de protection.
MOR THIAM-M2TDSI 48
M2TDSI
III.6.2. Enregistrement de l’incident

Comme indiqué précédemment, un incident supposé de sécurité peut être signalé à différentes
personnes, en général le help desk, selon des procédures devant être connues de tous. Dans tous
les cas, la personne qui réceptionne l’appel ou l’alerte doit en accuser réception.
L’événement doit immédiatement être enregistré dans une base de données des incidents. A ce
stade de la procédure, l’événement n’est pas encore qualifié d’incident de sécurité mais il est
catégorisé. L’enregistrement de l’événement doit comporter à minima la date et l’heure de
l’alerte, son origine (personne ou dispositif technique), les coordonnées du déclarant, une
description aussi précise que possible de l’événement et sa catégorisation. Comme pour tout
incident, un numéro de dossier est généré et communiqué si nécessaire au déclarant. La
personne qui enregistre l’événement doit également mentionner l’action immédiate traitement
des incidents de sécurité pour qualification).
L’enregistrement de l’événement est essentiel à plusieurs titres. Il permet de garder une trace
de chaque événement et d’en effectuer un suivi dans toutes les phases ultérieures, d’analyse ou
de traitement, jusqu’à la fermeture du dossier. La base des événements constitue également un
outil d’analyse a posteriori dans le cadre d’analyses de risques, pour évaluer l’efficacité des
dispositifs en place ou pour identifier des incidents récurrents pouvant être qualifiés de «
problème ».
III.6.3. Catégorisation de l’incident

Une fois l’incident identifié comme « incident de sécurité potentiel», l’équipe support peut être
habilitée pour prendre des mesures ou transmettre l’incident à l’équipe de gestion des incidents
de sécurité.
L’équipe de réponse aux incidents de sécurité établit des consignes d’alerte sécurité (fiches par
type d’incident) pour les équipes support.
Pour les incidents identifiés, ces consignes indiquent le mode opératoire du traitement de ces
incidents pour les équipes de support. Dans les autres cas, c’est l’équipe de réponse aux
incidents de sécurité qui doit être immédiatement sollicitée.
Par exemple : l’équipe de réponse aux incidents de sécurité peut également être sollicitée à
chaque fois qu’une équipe support ou qu’un membre du personnel pense être face à un
événement susceptible d’avoir un impact fort sur l’organisation.
MOR THIAM-M2TDSI 49
M2TDSI
Les consignes peuvent éventuellement spécifier que tout incident susceptible d’être d’origine
malveillante ou concernant certains équipements ou logiciels ou encore signalé par certains
dispositifs techniques, doit être transmis à l’équipe de réponse aux incidents de sécurité.
III.6.4. Qualification de l’incident

Une première analyse, conduite par l’équipe de réponse aux incidents de sécurité, confirme ou
infirme la catégorisation « incident de sécurité ». Les incidents non confirmés « incident de
sécurité » sont transmis aux équipes support pour traitement. L’équipe de réponse aux incidents
de sécurité procède si nécessaire à des investigations complémentaires pour qualifier
l’événement. Les critères d’évaluation d’impact prenant en compte différents axes d’analyse
(impacts financiers, impacts sur l’image, impacts sur les clients ou partenaires, risques de
poursuite judiciaire, etc.) doivent être préétablis et mis à la disposition de l’équipe.
Typiquement ces critères sont issus de l’analyse de risque. Il est nécessaire de tenir un journal
de bord horodaté et précis des événements et actions dès sollicitation de l’équipe.
III.7. Réponse à l'incident SSI

III.7.1. Mesures de réponses immédiates
Suite à la qualification, des mesures d’urgence peuvent être prises pour limiter les impacts
et préserver les traces. En effet, même sans connaître précisément la nature de l’incident, son
origine ou son impact réel qui seront l’objet de la phase d’analyse, le simple fait d’identifier le
type de danger peut déclencher des actions palliatives, comme par exemple :
• un confinement (ex : débranchement du réseau d’un poste infecté pour le mettre dans
un VLAN de quarantaine),
• une isolation (ex : couper tous les flux de messagerie Internet),
• une communication ciblée de recommandations.
Certaines de ces mesures peuvent être prévues à l’avance dans des procédures du support et
de l’équipe sécurité.
Si ces mesures s’avèrent insuffisantes ou/et si la situation n’est pas maitrisée ou/et si le niveau
d’impact de l’incident le justifie, au regard des critères d’évaluation, la cellule de crise doit
être activée.
MOR THIAM-M2TDSI 50
M2TDSI
III.7.2. Investigations
L’analyse de l’incident a pour objectif de préciser les éléments suivants :
 la nature de l’incident,
 le fait générateur,
 le périmètre concerné,
 l’impact.
Ces éléments permettront de définir les actions à entreprendre. Dans certains cas les conclusions
de l’investigation peuvent conduire à l’activation de la cellule de crise.
III.7.2.1. Préservation des traces

Certaines précautions doivent être prises. En particulier, en cas de piratage (par exemple), si le
but de l’analyse est de remonter à la source de la manipulation frauduleuse et de prendre des
mesures légales à l'encontre des auteurs des faits, il est nécessaire de préserver les informations
d’origines (logs, etc.) afin de conserver le contexte de preuve.
En effet, l’analyse peut, dans certains cas modifier (le travail d’analyse génère lui-même des
traces qui se confondent ensuite avec les traces laissées par l’agresseur), voire effacer, les traces
du passage d’un ‘attaquant’. De fait, il est nécessaire de sauvegarder (par exemple via une copie
intégrale, de type bit à bit) les informations avant d'entreprendre toute action susceptible de
nuire à l'intégrité des données sur le support d'origine.
Si une copie complète des disques n’est pas réalisable ou l’est difficilement, il faut au moins
conserver une copie des logs (journaux de connexions au système). Toutefois, cette sauvegarde
n’est pas toujours simple à mettre en œuvre et peut nécessiter des outils et/ou des compétences
particulières.
Enfin, les données ainsi sauvegardées doivent être protégées physiquement et un cadre
opératoire doit être mis en œuvre qui précisera notamment par qui ces sauvegardes ont été
effectuées, à quel moment, comment elles ont été protégées et qui y a eu accès. En fonction des
enjeux, il peut être recommandé de faire appel à un huissier de justice.
Le travail d’investigation pourra alors commencer, si possible sur les copies de sauvegarde, les
disques durs d'origine étant rangés en lieu sûr (une procédure pouvant durer des mois, voire des
années). Ces derniers ainsi que la sauvegarde des logs, pourront servir de preuves en cas de
poursuites judiciaires.
MOR THIAM-M2TDSI 51
M2TDSI
III.7.2.2. Environnements potentiellement concernés

Durant l’investigation il est important de déterminer le périmètre concerné :
• OS,
• réseau et téléphonie,
• serveurs,
• applications,
• locaux,
• groupe de personnes,
• données,
• services,
• clients, fournisseurs, partenaires, ...
III.7.2.3. Aide à l’analyse

Dans chaque environnement technique il existe des outils qui peuvent aider à déterminer
l'étendue de l'attaque menée.
Des procédures peuvent également être mises en œuvre, intégrant des check-lists qui permettent
de réaliser l’analyse dans les meilleures conditions. Par exemple, on peut positionner les actions
suivantes :
• vérifier les performances des systèmes,
• rechercher des processus ou des applications non autorisées en cours d'exécution,
• si des logs existent, y rechercher d’éventuelles connexions inhabituelles, tentatives d'ouverture
de session infructueuses, tentatives d'ouverture de session avec des comptes par défaut, etc.,
• déterminer si du matériel non autorisé a été connecté au réseau,
• examiner les groupes clés (administrateurs, etc.) afin de vérifier qu'ils ne contiennent pas de
membres non autorisés,
• etc
III.7.2.4. Identification du fait générateur et analyse de l’impact
L’objet principal de l’analyse de l’incident proprement dit permet de répondre à plusieurs
questions qui se posent, comme par exemple :
MOR THIAM-M2TDSI 52
M2TDSI
• quelle est la vulnérabilité ou la faiblesse qui a rendu possible l’incident ? C’est la question la
plus importante ! En effet, si aucune réponse claire n’est trouvée à cette question, le système
restera vulnérable une fois remis en service ; il pourrait être attaqué à nouveau,
• quel est l’inventaire des dégâts ou quel est l’impact de l’incident (déni de service, baisse de la
qualité du service, perte de donnée, divulgation d’information confidentielle, etc.).
III.7.3. Traitement
III.7.3.1. Mesures pour éviter l’aggravation des conséquences
En complément des mesures de réponses immédiates déjà prises dès la qualification de
l’incident, des mesures peuvent être prises pour éviter l’aggravation des conséquences.
Disposant à ce stade des informations obtenues lors des investigations, ces mesures seront plus
ciblées que les réponses conservatoires d’urgence :
• activation de la Cellule de Crise : elle n’a pas été activée lors de la phase de réponse immédiate,
la gestion de crise du PCA peut être déclenchée à ce stade, si la situation s’est dégradée entre
temps et l’impose,
• restrictions temporaires d’accès aux réseaux ou/et aux applications : ces restrictions peuvent
être, suivant les cas, des blocages ou des simples filtrages. (Exemple : interdiction d’accès à
certains sites Web),
• communications ciblées : pour adapter la communication, il faut évaluer très rapidement la
durée de la perturbation (exemple : évaluer la durée de restauration par rapport au volume de
données à restaurer en cas de pertes de données). On identifie trois types de communication :
o communication vers les utilisateurs: le communiqué contient en règle générale à
minima:
• les faits qui doivent être édulcorés dans certains cas,
• les activités impactées du fait des restrictions temporaires en place,
• des consignes de comportements (exemple : ne pas ouvrir les pièces jointes),
• l’heure prévisionnelle de retour à la normale,
o communication technique entre homologues (d’autres sites ou filiales) :
• les faits précis,
• les recommandations d’actions,
• une proposition d’actions coordonnées,
MOR THIAM-M2TDSI 53
M2TDSI
o communication vers les externes (clients, assureurs, fournisseurs, etc.). On peut utiliser
si besoin la communication de crise prévue dans le cadre du PCA.
III.7.3.2. Résolution de l’incident

Sans être exhaustifs, les quelques points ci-dessous nécessitent une attention particulière.
Appels aux supports externes
L’entreprise ou l’organisme peut avoir besoin d’urgence de compétences externes qui

interviendront à distance ou sur site et qu’il faut réserver en priorité en raison des délais
d’intervention.
Éradication
L’éradication du problème dépend du type d’incident rencontré.
On peut noter deux grandes tendances entre lesquelles il faudra choisir :
• le mode « réparation », souvent manuel mais qui peut être automatisé par un script,
• le mode « restauration ou réinstallation » en repartant d’une sauvegarde ou d’une image
système.
Les critères de choix entre ces deux méthodes sont :
• le temps total (estimation) pour éradiquer l’incident,

• le niveau de certitude d’avoir bien identifié tous les impacts précis liés à l’incident,
• le niveau de perte de données acceptable.
Dans les cas complexes, il peut être important d’écrire le plan d’action correctif pour bien
ordonnancer les étapes.
Détermination du point zéro de l’incident
Les éléments permettant de déterminer le point zéro sont (entre autres):
• le recueil des preuves et journaux,

• le témoignage des utilisateurs,
• tous les outils de supervision et reporting.
MOR THIAM-M2TDSI 54
M2TDSI
Cette compréhension de l’origine de l’incident permet de vérifier la pertinence des mesures

correctives et de réduire le risque de reproduction.
Délai de Réapprovisionnement de matériel
Même si l’entreprise/organisme utilise le matériel de secours, il n’est pas recommandé de «

rouler trop longtemps sans roue de secours ». C’est pourquoi le réapprovisionnement du
matériel est également une priorité.
Retour à la normale
Le retour à la normale doit être associé à une communication spécifique.
III.7.4. Revues post-incident

III.7.4.1. Investigation post-incident
Une fois l’incident maîtrisé, il est possible qu’il soit nécessaire de lancer des investigations
complémentaires pour bien comprendre comment cet incident a pu avoir lieu. Si tel est le cas,
il ne faut pas hésiter à consacrer le temps nécessaire à cette étape qui viendra enrichir le dossier
de synthèse.
Si des éléments de preuve sont encore présents et que l’incident a vocation à être présenté
devant un tribunal, la collecte des indices devra être particulièrement précise et se conformer
aux bonnes pratiques techniques en adéquation avec les obligations légales.
III.7.4.2. Rapport de synthèse

Chaque incident de sécurité doit être accompagné d’un dossier de suivi et si possible d’un
rapport de synthèse. Ce rapport doit être rédigé par l’équipe en charge de la résolution de
l’incident. Il peut servir de cadre directeur lors d’une revue post-incident, dans la mesure où il
apporte les réponses par rapport aux causes techniques, à la défaillance du SMSI et à la perte
financière.
Le rapport de synthèse doit être rédigé au plus près de la date de résolution de l’incident afin
d’éviter que le temps n’efface dans la mémoire des acteurs des éléments ou des détails
importants pour la compréhension et l’analyse de l’incident. Le rapport doit prioritairement
présenter des conclusions claires compréhensibles par les responsables. Ce rapport doit être
conservé dans un espace dédié servant de base de connaissance aux incidents de sécurité. Cette
base d’information pourra par la suite être mise à profit pour une meilleure anticipation des
MOR THIAM-M2TDSI 55
M2TDSI
incidents, pour définir les contremesures les plus appropriées ou encore pour vérifier si les
décisions actées ont été suivies d’effets.
III.7.4.3. Analyse post-incident

L’analyse post-incident s’inscrit dans une démarche d’amélioration continue et de qualité.
PDCA permettant de prendre connaissance des éléments qui doivent évoluer dans le Système
d’Information. Cette analyse post-incident doit impliquer les responsables pour que les
engagements soient pris rapidement en matière d’évolution du Système d’Information. Celle-
ci peut prendre la forme d’un comité de pilotage ou tout autre type de réunion impliquant les
décideurs adéquats. Un compte-rendu de l’analyse post-incident doit être rédigé pour acter des
évolutions du Système d’Information
III.7.5. Actions post-incident
III.7.5.1. Bilan de l’incident

Les informations et les mesures déterminées lors du traitement de l’incident doivent être
conservées et permettre d’enrichir la base de connaissances. Dans le traitement d'un incident
majeur, il est important d’analyser avec recul, ce qui a bien fonctionné et ce qui a moins bien
fonctionné.
Cela doit se traduire par la rédaction d'un bilan adressé aux directions concernées. La mise en
place des mesures du bilan, de préférence sous forme de plan d’actions précis, devra être suivie
par le responsable sécurité.
III.7.5.2. Révision des contrats

Il peut être nécessaire de réviser les contrats d’assurance ou d’engagement avec des
fournisseurs.
III.7.5.3. Communication interne spécifique (sensibilisation, etc.)

Les incidents rencontrés par l'équipe de réponse aux incidents lui procurent une bonne visibilité
des choses à faire et à éviter. Cette connaissance peut être mise à contribution pour des actions
ponctuelles ou récurrentes de sensibilisation auprès de publics variés (salariés, managers,
développeurs, etc.).
MOR THIAM-M2TDSI 56
M2TDSI
III.7.5.4.Amélioration de la gestion des incidents SSI

Les enseignements tirés des traitements des incidents de sécurité doivent contribuer à
l’amélioration générale des processus et des moyens de gestion de ces incidents.
L’ensemble des éléments doit être revu périodiquement suite aux incidents ayant un impact fort
sur le SI, et donner lieu à des évolutions :
 politique de gestion des incidents

 organisation (principaux acteurs)
 processus
 prévention,
 détection,
 déclaration d'incidents,
 résolution,
 problématique de préservation des preuves ;
 contrôle du processus de gestion de l’incident,
 tableaux de bord sur les différents types d’incidents (fréquence, impacts),
 analyse post-incident,
 alimentation de la gestion des problèmes,
 recours,
 juridique (recherche de preuve),
 assurance,
 communication interne,
 information des utilisateurs,
 communication externe,
 processus annexes (PCA, gestion des problèmes, etc.),
 audit.
MOR THIAM-M2TDSI 57
M2TDSI
MOR THIAM-M2TDSI 58
M2TDSI
Chapitre IV : MISE EN ŒUVRE DE LA SOLUTION
IV .1. Architecture de la solution
Figure 8:architecture de la solution

Description de la solution
(1) : La machine qui héberge RT doit récupérer les alertes envoyées par le serveur hébergeant
OSSIM, et l’administrateur doit ouvrir un ticket suite à la réception d'emails
(2) : Réception d'un email envoyé par un particulier par email
(3) : Le système de notification de RT, envoie un email à un utilisateur lorsqu’il y’a

commentaire sur un ticket, changement d’état d’un ticket ou clôture de la résolution d’un ticket.
Le serveur ou est installé RT sera configuré comme MTA (Mail Transfer Agent) et va recevoir
les emails qui sont en réalités des demandes et ces demandes seront transformés en tickets par
l’administrateur. Les messages reçus proviennent des alertes du serveur Ossim et les
utilisateurs n’ayant pas de compte RT. Les utilisateurs qui sont inscrits sur l’interface RT
recevront les emails à partir des comptes emails qu’ils ont renseignés lors de l’inscription.
MOR THIAM-M2TDSI 59
M2TDSI
En outre, les files d’attentes de RT peuvent être configurées à l’aide de scrip de telles sortes à
modifier le comportement de RT :
 On Create Autoreply to Requestors with Template Autoreply:

Ce scrip enverra un message de réponse automatique tel que spécifié dans le modèle global
de réponse automatique au demandeur quand un nouveau ticket est créé.
 On Create Notify AdminCcs with Template Create Notification:
Ce scrip enverra un message email de notification aux observateurs AdminCc d'une file
d'attente quand un nouveau ticket est créé.
 On Correspond Notify Requestors, Ccs, AdminCcs, and Other Recipients with
Template Correspondence:
Ce scrip relaie une copie de tout message sur un ticket comme correspondance sur l'adresse
de la file d'attente vers les demandeurs de ticket, des observateurs de Cc, des observateurs
d’AdminCc, et d'autres destinataires spécifiés manuellement.
 On Comment Notify AdminCcs and Other Recipients as a Comment with Template
Comment:
Ce scrip relaie une copie de tout message que reçoit un ticket comme commentaire sur
l'adresse de la file d'attente vers les observateurs d’AdminCc de billet et d'autres
destinataires spécifiés manuellement. Il va faire comme un commentaire, venant du
commentaire l'adresse de la file d'attente. (Les réponses seront donc également être
considérées comme des commentaires.).
MOR THIAM-M2TDSI 60
M2TDSI
Figure 9: Système de notification par email de RT
Extension de la solution :
Pour rendre la solution beaucoup plus facile à utiliser, on peut créer un script en perl qui va
transformer chaque email reçu par postfix en ticket et lui affecté une file d’attente. Au lieu que
l’admin crée lui-même les tickets.
IV.1.1. Les outils utilisés

IV.1.2. Installation et Configuration de RT
RT est un système de suivi des problèmes au niveau de l’entreprise. Il permet aux organisations
de garder une trace de ce qui doit être fait, qui travaille sur des tâches, ce qui a déjà été fait, et
quand les tâches ont été (ou n'a pas été) terminées.
RT est libre et disponible sous les termes de la version 2 de la GNU (General Public License).
MOR THIAM-M2TDSI 61
M2TDSI
IV.1.2.a. Les paquets nécessaires :

 RT supporte Perl 5.10.1 téléchargeable sur le son site officiel (http://www.perl.org). RT
ne démarre pas sur les versions de Perl antérieures à la version 5.10.1.
 Une base de données SQL pris en charge: actuellement la version prise en charge est
MySQL 5.1 ou le support InnoDB : Postgres 8.4 ou version ultérieure; 9.0 ou version
ultérieure suggéré Oracle 9iR2, SQLite 3.0 ou version ultérieure.
 RT est installé avec Apache version 1.3.x ou 2.x (http://httpd.apache.org) avec
mod_perl (http://perl.apache.org) ou avec FastCGI - (http://www.fastcgi.com) ou un
autre serveur web avec le support FastCGI.
 Les modules perl :
Un module perl ou mod_perl est un module Perl pour le serveur Apache HTTP. Il
incorpore un interpréteur Perl dans le serveur Apache, en sorte que le contenu
dynamique produit par Perl puisse être fourni en réponse aux requêtes HTTP reçues,
sans subir les pertes de temps dues au lancement répétitif de l'interpréteur Perl pour
chaque nouvelle requête.
 L'outil fourni avec RT utilise CPAN (Comprehensive Perl Archive Network ) de Perl
CPAN. Il s'agit d'une archive dense de logiciels, de bibliothèques de fonctions utilitaires
écrits en langage Perl.
IV.1.2.b. Installation Générale

1) On télécharge et décompresse la dernière version de la distribution de RT dans le site officiel
de RT. Exécutons les commandes suivantes:
Wget https://bestpractical.com/rt/download.html
tar xzvf rt.tar.gz -C / tmp
2) Exécuter le script "configure", pour voir la liste des options :

. /configure –help
Parcourir les options, puis on relancer configure avec les options appropriées. Par défaut, RT
s'installe dans /opt / RT4 et utilise MySQL comme base de données.
3) Pour s’assurer que Perl et les bibliothèques système dont RT a besoin pour fonctionner sont
bien installer, vérifions si les dépendances manquantes :
MOR THIAM-M2TDSI 62
M2TDSI
make testdeps
4) Si le script signale toute dépendance manquante, installer-les manuellement, ou exécuter la

commande suivante en tant qu'utilisateur qui a la permission d'installer des modules perl sur
notre système:
make fixdeps
Certains modules nécessitent des variables d'entrée ou d'environnement que l’utilisateur à

installer .Il peut être nécessaire de les installer manuellement.
5) Pour s’assurer que tous les dépendances ont été installé correctement, on tape cette
commande :
make testdeps
NB : Il pourrait être parfois nécessaire pour exécuter «make fixdeps » à plusieurs reprises
pour installer tous les modules Perl nécessaires.
6) Si c'est une nouvelle installation, comme un utilisateur avec la permission d'installer RT dans
votre répertoire choisi et taper :
make install
Pour démarrer une instance de RT avec l'installateur Web, exécuter la commande :
/opt/RT4/sbin/rt-serveur
Une fois terminé, on doit maintenant avoir une instance RT qui travaille avec le serveur de
RT autonome.
Pour configurer manuellement RT, on doit configurer le fichier etc / RT_SiteConfig.pm dans
votre répertoire d'installation de RT. On aura besoin de changer les valeurs par défaut du fichier
etc /RT_Config.pm en tant qu'un utilisateur avec la permission de lire le fichier de configuration
de RT.
MOR THIAM-M2TDSI 63
M2TDSI
Figure 10: Fichier de configuration de RT

Pour initialiser la base de donner et effacer les données unitules.
make initialize-database
Si le make échoue, tapez:
make dropdb
et ensuite on retape : make initialize-database.
7) Configurez le serveur Web, tel que décrit dans docs / web_deployment.pod, et la passerelle
de messagerie, comme décrit ci-dessous.
REMARQUE: Après installation, lorsqu’on se connecte pour la première fois sur l’interface
web de RT, voici les informations d'identification par défaut :
Utilisateur: root
Mot de passe : password
MOR THIAM-M2TDSI 64
M2TDSI
Figure 11:page d'authentification de RT
7°) Passons maintenant à la configure de la passerelle de la messagerie de RT, pour qu’il puisse
recevoir des e-mails depuis notre serveur, nous devons ajouter ces quelques lignes de la
configuration à votre courrier "alias" le dossier de serveur. Ces lignes "pipe" e-mails entrants à
partir de votre serveur de messagerie pour RT.
Ajoutez les lignes suivantes dans / etc / alias (ou l'équivalent dans votre local)
sur votre serveur de messagerie:
rt: "|/opt/rt4/bin/rt-mailgate --queue general --action correspond

--url http://cert.adie.sn/"
rt-comment: "|/opt/rt4/bin/rt-mailgate --queue general --action
comment --url http://cert.adie.sn/"
MOR THIAM-M2TDSI 65
M2TDSI
Figure 12: configuration de la passerelle de la messagerie /etc/aliases
IV.1.3. Installation et Configuration de RTIR

RTIR ou Request Tracker for Incident Response est la partie de RT qui gère les incidents. C’est
une open source, de qualité industrielle. C’est un outil de gestion d’incident conçu pour fournir
un flux efficace de travail pour les membres des équipes de CERT et CSIRT. Il permet aux
membres de l'équipe de suivre, répondre et traiter les incidents signalés et dispose d'un nombre
d'outils pour faire des opérations courantes rapide et facile. RTIR est construit au-dessus de RT,
qui est également disponible gratuitement dans le site officiel de Best Practical Solutions :
http://www.bestpractical.com/rt/.
RT et RTIR sont des logiciels libres d’utilisation mais l'appui, la formation, le développement
personnalisé ou les services professionnels sont commerciales.
IV.1.3.a. Les paquets nécessaires :

Avant de procéder à l’installation de RTIR, vérifions si ces deux paquets sont présents
 Il faut avoir la version RT 4.2.9 ou nouvelles versions de la série 4.2 déjà installé
 Net Whois RIPE 1.31 : est un package livré avec l'API RTIR pour s'exécuter sans
avertissement sous perl 5.18.
MOR THIAM-M2TDSI 66
M2TDSI
IV.1.3.b. Instructions d'installation:

1°) On installe la version actuelle de la série RTIR 3.2 .0 en suivant les instructions
d’installation régulière de RTIR 3.2.0. On télécharge et décompresse la dernière version de
RTIR.
Wget https://download.bestpractical.com/pub/rt/release/RT-IR-
3.2.0.tar.gz
tar xvf RT-IR-3.2.0.tar.gz -c /tmp
2°) On exécute "perl Makefile.PL" pour générer un fichier makefile pour RTIR.
perl Makefile.PL
3°) On Installe les modules Perl supplémentaires de RTIR. La sortie de l'étape précédente va
lister de nouveaux modules nécessaires.
4) On tape "make install".

make install
Figure 13:Installation de RTIR
MOR THIAM-M2TDSI 67
M2TDSI
5) Si on installe RTIR pour la première fois, on doit initialiser la base de données RTIR en
tapant : make initdb
Figure 14:Initialisation de la base de données
6) Ensuite on doit activer l'extension RTIR dans le fichier RT_SiteConfig.pm:
Plugin («RT :: IR ');
MOR THIAM-M2TDSI 68
M2TDSI
Figure 15:Activation du plugin RT::IR
7) Arrêter et démarrer votre serveur web pour apporter les changements et terminer l'installation
de RT :
/etc/init.d/apache2 restart
IV.1.4.Installation et Configuration de postfix

Postfix est un serveur de messagerie électronique et un logiciel libre développé par Wietse
Venema et plusieurs contributeurs. Il se charge de la livraison de courriers électroniques
(courriels) et a été conçu comme une alternative plus rapide, plus facile à administrer et plus
sécurisée que Sendmail.
Il est le serveur de courriel par défaut dans plusieurs systèmes de type UNIX.
Postfix est publié sous licence IBM Public License1.0. C'est une licence libre, mais
incompatible avec la GPL.
a°) Installation de Postfix
Avant d’installer, vérifions le nom de notre machine :
$ hostname
Cette commande doit vous retourner cert.adie.sn. Si ce n'est pas le cas, éditer le fichier
/etc/hosts et vérifier qu’on une ligne comme suit :
127.0.0.1 cert.adie.sn
Puis on tape:
# hostname cert.adie.sn
Il est important que le hostname de votre machine soit le même que celui retourné par la
commande host -t MX smtpsn.gouv.sn, sinon Postfix posera des problèmes.
Installons postfix :
# apt-get install postfix
On choisit la configuration Internet Site. On indique ensuite le nom de votre machine :

cert.adie.sn
Si notre configuration ne nous convient pas on peut toujours recommencer en tapant :
# dpkg-reconfigure postfix
MOR THIAM-M2TDSI 69
M2TDSI
b°) Configuration
Le fichier de configuration de postfix est /etc/postfix/main.cf. Il est par défaut très bien sécurisé.
Nous allons dans un premier temps y ajouter cette ligne :
home_mailbox = mail/
Cette ligne dit à postfix que les mails des utilisateurs doivent aller dans un répertoire nommé
mail.
Commentons (ajoutez un #) la ligne où se trouve mailbox_command pour que procmail ne soit
pas utilisé :
#mailbox_command = procmail -a "$EXTENSION"
Pour que la modification soit prise en compte, redémarrons postfix :
# /etc/init.d/postfix restart
Pour la création d'un nouveau mail, nous avons notre domaine, notre serveur mail tourne, il faut
créer une adresse mail est très simple. Il suffit d'ajouter un utilisateur sur notre machine.
# adduser momo
Tester l'adresse en local
Nous allons envoyer un mail à Momo, vérifions que le paquet mailx est installé :
# aptitude install mailx
On envoie le mail :
# echo "Le contenu du mail" | mail -s "ceci est le sujet" momo@cert.adie.sn
Le mail sera automatiquement déposé dans le répertoire mail situé dans le home de momo . S'il
n'existe pas, le répertoire mail sera automatiquement créé.
# ls /home/momo
N'hésitez pas à consulter les logs pour voir tout ce qui se passe sur votre serveur mail :
# cat /var/log/mail.log
Envoyer des mails, c'est bien mais pouvoir les lire, c'est mieux. Pour que Momo puisse lire ses
emails dans un client comme Mozilla Thunderbird, c'est tout simple :
Momo veut réceptionner ces mails via POP :
# aptitude install dovecot-pop3d
On peut maintenant utiliser notre client mail favori pour réceptionner nos mails.
Serveur : cert.adie.sn
Login : momo
Mot de passe : passer123
MOR THIAM-M2TDSI 70
M2TDSI
Figure 16: Visualisations des emails avec Thunderbird
c°) Utiliser le SMTP du FAI de l'ADIE

Postfix possède son propre service SMTP, mais ce dernier sera généralement bloqué. Pour
limiter les envois de SPAMS, les FAI bloquent généralement l'envoi de mails.
Pour que notre serveur mail puisse envoyer des mails, il faut lui dire d'utiliser le SMTP de notre
FAI. C'est le paramètre relayhost du fichier de configuration /etc/postfix/main.cf qu'il faut
modifier :
relayhost = smtpsn.gouv.sn
L’ADIE utilise Microsoft Office 365 hébergé sur son Cloud privé, pour la messagerie
électronique, mais aussi pour la gestion d'agenda, de contacts et de tâches, qui assure le stockage
des informations et permet des accès à partir de clients mobiles (Outlook Mobile Access,
Exchange Active Server Sync) et de clients Web (navigateurs tels qu’Internet Explorer, Mozilla
Firefox, Safari (Apple)).
Pour que notre domaine CERT.ADIE.SN soit accepté et puisse recevoir et envoyer des emails
avec le serveur Exchange 2013.Il faudra que notre domaine cert.adie.sn soit accepté dans
Exchange et avant de passer à la création des connecteurs.
MOR THIAM-M2TDSI 71
M2TDSI
Les types de connecteur les plus couramment utilisés sont les connecteurs d’envoi qui
contrôlent les messages sortants et les connecteurs de réception qui contrôlent les messages
entrants.
d°) Domaines acceptés
Un domaine accepté désigne un espace de noms SMTP quelconque pour lequel votre
organisation Exchange envoie ou reçoit des courriers électroniques. Parmi les domaines
acceptés, on compte ceux pour lesquels l’organisation Exchange fait autorité, ainsi que les
domaines de relais internes et externes.
Une organisation Exchange fait autorité lorsqu'elle gère la remise des messages pour les
destinataires dans le domaine accepté. Parmi les domaines acceptés, on compte également ceux
pour lesquels l’organisation Exchange reçoit du courrier électronique, puis le relaie vers un
serveur de messagerie en dehors de l’organisation.
Figure 17: autorisation du domaine cert.adie.sn
MOR THIAM-M2TDSI 72
M2TDSI
d°) Les connecteurs :

Les connecteurs sont utilisés pour contrôler le flux de messagerie entrant et sortant dans
Microsoft Exchange Server 2013. Grâce aux connecteurs, vous pouvez router et recevoir des
messages électroniques vers et depuis des destinataires situés en dehors de votre organisation,
un partenaire via un canal sécurisé ou un dispositif de traitement des messages.
e°) Créer un connecteur d’envoi pour les messages électroniques envoyés vers Internet :
1. Dans le Centre d’administration Exchange, accédons au Flux de
messagerie>Connecteurs d’envoi, puis on clique sur Ajouter .
2. Dans l’Assistant Nouveau connecteur d’envoi, on spécifie le nom du connecteur d’envoi,
puis on sélectionne Internet en tant que Type. On Clique sur Suivant.
Figure 18: Activation du connecteur d'envoi
3. On vérifie si l’Enregistrement MX associé au domaine du destinataire est sélectionné,

ce qui spécifie que ce connecteur utilise le système DNS (Domain Name System) pour
acheminer les messages. Cliquons sur suivant.
4. Sous espace d’adressage, on clique sur ajouter . Dans la fenêtre ajouter un domaine,
vérifions si SMTP apparaît dans la liste Type. Pour nom de domaine complet (FQDN),
entrons la signe étoile (*) pour indiquer que ce connecteur d’envoi s’applique aux messages
destinés à n’importe quel domaine. Cliquons sur enregistrer.
MOR THIAM-M2TDSI 73
M2TDSI
Figure 19:espaces d'adressage
5. IL faut s’assurer que la case à cocher connecteur d’envoi délimité est désactivée, puis
cliquez sur suivant.
6. Pour serveur source, on clique sur ajouter . Dans la fenêtre sélectionner un serveur, on
sélectionne un serveur de boîtes aux lettres qui sera utilisé pour envoyer des messages à
l’Internet via le serveur d’accès au client puis cliquez sur ajouter . Après avoir sélectionné
le serveur, cliquez sur ajouter . Cliquons sur OK.
7. Cliquons sur Terminer.
MOR THIAM-M2TDSI 74
M2TDSI
Figure 20:liste des domaines acceptés
IV.2 Envoie d’alertes d’Ossim à RT

Pour qu’Ossim Alienvault puisse envoyer des alertes au serveur qui héberge la machine de
RT. Il faut apporter des modifications à la configuration Ossim Alienvault en allant au menu
configuration, ensuite on clique la rubrique threat intelligent et action pour voir les actions
qu’Ossim doit faire s’il détecte une nouvelle alerte. On crée une nouvelle action et on remplit
tous les champs du formulaire. Mais au niveau des champs Type et To , mettre
respectivement le type d’action : send an email message (envoyer un courriel) et To permet de
renseigner l’email du destinataire ici c’est : ticket@cert.adie.sn.
Figure 21:Configuration de l'envoie d'email sous Ossim
MOR THIAM-M2TDSI 75
M2TDSI
IV.3 Test de validation et de recette

Dans cette partie nous allons évoquer l’ensemble des tests effectués au cours de la réalisation
de ce mémoire.
a°) Test n°1 :
Cette capture nous montre la réception d'un email envoyé depuis RT à mail.gouv.sn suite à la
création de ticket.
Figure 22: réception de message envoyé depuis RT
b°) Test n°2 :

Cette capture nous montre la réception d'un email envoyé depuis mail.gouv.sn au domaine
accepté cert.adie.sn à l’email de test momo@cert.adie.sn.
MOR THIAM-M2TDSI 76
M2TDSI
Figure 23:Reception d’un emaill dans momo@cert.adie.sn
c°) Test n°3 :

Cette capture nous montre la réception d'un email envoyé depuis la machine qui héberge
Ossim Alienvault au domaine accepté cert.adie.sn à l’email ticket@cert.adie.sn.
MOR THIAM-M2TDSI 77
M2TDSI
Figure 24:Format d'email provenant d'Ossim Alien Vault
d°) Création d’un utilisateur et de son groupe:

Pour créer un utilisateur RT, on doit ouvrir une session RT en tant qu'utilisateur "root". Si tel
n'est pas le cas, on doit obligatoirement se reconnecter en tant que root.
Une fois connecté on clique sur Configuration ensuite sur Users, puis sur Create .
La boîte de dialogue suivante s'affiche à l'écran. Remplissez les champs, et vérifiez que la
case "Let this user be granted rights" (accorder des droits à cet utilisateur) est cochée et on
clique sur le bouton Create (créer) en bas à droite.
MOR THIAM-M2TDSI 78
M2TDSI
Figure 25: Ajout d'un utilisateur
Figure 26:resultat de la création d'un utlisateur
Pour créer un groupe, on clique sur configuration, puis sur groups et cliquons sur create.
MOR THIAM-M2TDSI 79
M2TDSI
Figure 27: Ajout d'un groupe
Figure 28: Résultats de l'ajout d'un groupe
Ajoutons à maintenant des membres au groupe netmgmt. Cliquons sur Configuration, puis
sur Groups. Cliquons sur "netmgmt" (le groupe que nous venons de créer).Cliquez sur
Members (menu supérieur).
Figure 29:Ajout des membres du groupe
MOR THIAM-M2TDSI 80
M2TDSI
e°) Création d’une file:
La file est un objet très important dans le fonctionnement de RT. De ce fait, il est impératif de
bien la configurer .Cliquons sur la configuration, puis sur le menu central Queues .On Clique sur
Ajouter.
Figure 30: Création d'une file
Figure 31: Résultats de la création d'une file
Ensuite nous allons attribuer des droits à notre groupe sur la file d'attente net. On cliquez sur
configuration, puis sur le menu files. On clique sur "net" (la file d'attente que nous venons
juste de créer). On clique sur "droits de groupe", dans le menu supérieur.
MOR THIAM-M2TDSI 81
M2TDSI
Figure 32: ajout des droits de groupe
Figure 33: résultats ajout des droits de groupe
f°) Création des observateurs (Watchers):

Les observateurs seront notifiés par email quand l’état d’un ticket de la file associée est modifié,
commenté ou résolu. Pour créer un observateur, on clique sur configuration, ensuite file et on choisit
la file ou veut ajouter des observateurs, on clique sur le menu observateurs et on saisit les noms des
utilisateurs ou groupes qu’on veut ajouter.
Figure 34: Création des observateurs d'une file
MOR THIAM-M2TDSI 82
M2TDSI
g°) Création d’un ticket:
Figure 35: interface pour créer un ticket
On peut créer un ticket suite à un appel téléphonique, à un email ou par l’interface web de RT. On
clique sur l’onglet créer un ticket dans et choisir une file dans la liste disponible et on remplit le
formulaire qui s’affiche.
Figure 36: Affecter une file à un ticket
Une fois le ticket créé, On peut maintenant répondre à la demande, commenter et transférer.
On clique sur commenter pour ajouter un commentaire à la file comme nous le montre
l’image.
MOR THIAM-M2TDSI 83
M2TDSI
Figure 37: commentaires sur un ticket
On clique sur répondre et on saisit une réponse ; on changer le statut du ticket à résolu dans
le menu déroulant en haut à droite, puis on clique sur mettre à jour le ticket:
Figure 38: Réponse et cloture de la résolution d'un incidents
MOR THIAM-M2TDSI 84
M2TDSI
Conclusion
Avoir au sein de son entreprise une équipe de gestion des incidents n’est pas une option mais
une obligation. Peu importe combien votre organisation est protégée, la sécurité de vos
systèmes d’informations n’est jamais à risque zéro, même avec un personnel qualifié, de la
technologie appropriée, et des procédures éprouvées. Il est impossible de préciser avec
cohérence, de prédire le type, la fréquence ou la gravité des attaques.
Les vulnérabilités sont publiées à un rythme de plus en plus élevées et que la complexité de la
technologie est à l’origine de l’augmentation de la probabilité du nombre de vulnérabilités.
La nature des ordinateurs et des réseaux augmentent la menace de base à cela s’ajoute
l'introduction de nouvelles motivations et les capacités qui n'existaient pas auparavant. Le
résultat est que les incidents de sécurité informatique se produiront.
Une équipe de réponse aux incidents de sécurité informatique (CSIRT) est l'une des meilleures
façons de rassembler l'expertise nécessaire pour faire face à la large gamme de possible
d’incidents de sécurité informatique qui peuvent survenir.
RTIR installé au-dessus de RT est conçu pour coordonner et faciliter le travail des équipes
CSIRT.
Ce mémoire a été réalisé avec pas mal de problèmes qu’on a pu résoudre avec l’aide de l’équipe
de Sécurité et l’équipe système de l’ADIE, Sans lesquelles les taches seraient beaucoup plus
difficiles.
Pour étendre ce projet il serait nécessaire de créer un script en perl qui va créer des tickets sur
l’interface web de RT dès la réception d’un email de façon automatique.
MOR THIAM-M2TDSI 85
M2TDSI
Bibliographie :
o AMINATA SECK, Mémoire de master 2, sujet : Security Information et Event

Management, [mémoire], consulté le 5 juillet 2015)
o Club de la Sécurité de l’Information Français (CLUSIF) 2011, Gestion des
Incidents, [livre], consulté le 9 juillet 2015)
Webographie:
o NICOLAS CAPRONI, cyber-securite.fr, [en ligne], http://www.cyber-

securite.fr/2013/12/13/un-csirt-a-quoi-ca-cert/, (page consultée le 10 juillet 2015)
o WIKIA, le wiki de Request Tracker, [en ligne],

http://requesttracker.wikia.com/wiki/DebianSqueezeInstallGuide, (page consultée le
11 juillet 2015)
o BEST PRACTICAL, Site Officiel de Request Tracker, [en ligne],

https://www.bestpractical.com/docs/rt/4.2/, (page consultée le 11 juillet 2015)
o MIT INFORMATION SYSTEMS & TECHNOLOGY WEBSITE, Site officiel de mit

[en
ligne],http://kb.mit.edu/confluence/display/istcontrib/Request+Tracker+(RT)+Queue+
Administrator's+Guide, (page consultée le 12 juillet 2015)
o LES MONGUEURS DE PERL, les articles des mongueurs de perl, [en

ligne],http://articles.mongueurs.net/magazines/linuxmag81.html, (page consultée le 15
juillet 2015)
MOR THIAM-M2TDSI 86
M2TDSI
Annexe
 Fichier de configuration : etc/postfix/main.cf
Figure 39: Fichier de configuration de Postfix
 Message d’erreurs après installation de RT :

Après l’installation de RT, on ne pouvait rien faire à partir de l’interface web car à chaque
fois qu’on voulait soit créer
MOR THIAM-M2TDSI 87
M2TDSI
Figure 40: message d'erreur possible sur l'interface web de RT
 Résolution du message d’erreurs

Pour résoudre cette erreur, il va fallu ajouter la ligne Set(@ReferrerWhitelist,
qw(10.42.2.170 :443 10.42.2.170 :80)) ; dans le fichier de configuration de RT
(opt/rt/etc/RT_SiteConfig.pm). Cette ligne permet d’ajouter l’adresse du server RT dans la
liste des ip autorisées plus les ports : 443 pour https et 80 pour http.
Figure 41: liste des adresses ip autorisées
 Personnalisation du logo et de la couleur de RT :
MOR THIAM-M2TDSI 88
M2TDSI
Figure 42: Personnalisation de l'interface RT
MOR THIAM-M2TDSI 89

Langue

Video

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Video

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Université Cheikh Anta DIOP de Dakar

Laboratoire d’Algèbre de Cryptologie de

Département Mathématiques et Informatique LACGAA

Master Transmission de Données et Sécurité de l’Information

Gestion des incidents de sécurité dans un système

Sous la direction du:

Année Académique 2014 - 2015

A l’ère de la société de l’Information, la Sécurité des Systèmes d’Information se trouve au cœur

MOR THIAM-M2TDSI III

Liste des Acronymes et abréviations

ADIE Agence de l’informatique de l’Etat

CCSIRT Equipe de réponse aux incidents centralisés

CERT/CC Central Emergency Response Team/ Coordination Center situé à l’université de

CERTA Centre d’Expertise Gouvernemental de Réponse et de Traitement des attaques

DCSIRT Equipe de réponse aux incidents centralisée distribuée

DSSIE Direction de la Sécurité des Système d’Information de l’Etat

GNU licence publique générale

HTTP HyperText Transport protocole

IDS Intrusion Détection Système : Système de détection d’intrusion

IPS Intusion Protection Système : Système de protection d’intrusion

LMD Licence Master Doctorat

MSSP Managed Security Services Provider

NASA National Aeronautics and Space Administration

PSSI Politique de Sécurité du Système d’Information

PCA: plan de continuité d'activité

PRA Plan de Reprise d’activité

PDCA Plan Do Check Act

RTFM M8Request Traquer Faq Manager

RT Request Tracker : Outil de gestion d’incidents

RTIR Request Tracker for Incidence Response

RSSI Responsable de la Sécurité des Système d’Information

SSI Sécurité des Système d’Information

MOR THIAM- M2TDSI IV

SMSI Système de Management de la Sécurité de l'Information

SIEM Security Information Event management : management des évènements de sécurité du

TIC Technologie d’Information et Communication

VOIP Voix sur IP

WAF Web Application Firewall:

XSS cross-site Scripting

MOR THIAM- M2TDSI IV

TABLES DES MATIERES

Table des Figures

Figure 1: Logo de l'ADIE ............................................................................................................ 7

Liste des tableaux

Tableau 1: Les parties prenantes au projet ...................................................................................... 16

CHAPITRE I: PRESENTATION GENERALE

I.1. Présentation de la structure d’accueil

Ses interventions se limitaient à l’appui de l’Administration et du secteur parapublic dans la

A partir de novembre 1987, avec l’avènement de la Délégation à l’Informatique, les missions

 le renouvellement et le renforcement des équipements informatiques et réseaux de

 l’adoption d’un nouveau code des télécommunications ;

Cette vision a l’ambition d’inverser la polarité entre le gouvernement et le citoyen en mettant

Cette vision e-Sénégal, un des fondements de la stratégie de développement du Sénégal vise :

 Une meilleure application des principes de transparence et de bonne gouvernance ;

Un encadrement juridique favorable au développement des TIC.

LA CREATION DE L’AGENCE DE L’INFORMATIQUE DE L’ETAT

 donner plus d’impulsion, d’autorité et de moyens aux activités d’informatisation

Figure 1: Logo de l'ADIE

 La Direction générale assure la coordination et fixe les objectifs. Elle comprend : Le

l’Agence avec les structures administratives. Elle contribue également à la mise en