|
1
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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 soeurs 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 soeur 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.
2
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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
3
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
TABLES DES MATIERES
Dédicaces 1
Remerciements 2
Liste des Acronymes et abréviations 6
Avant-propos 9
INTRODUCTION 10
CHAPITRE I: PRESENTATION GENERALE 11
I.1. Présentation de la structure d'accueil
11
I.2 Présentation du projet 17
I.2.1. Contexte 17
I.2.2. Problématique 17
I.2.3. Périmètre 18
I.2.4. Les parties prenantes au projet 18
I.2.5. Les buts 21
I.2.6. Les objectifs : 22
CHAPITRE II : ANALYSE ET DEFINITION DES CONCEPTS DE BASE
23
II.1 Evaluation des besoins 23
II.1.1. Analyse de l'existant 23
II.1.2. Identification de piste de solution
24
II.1.3. Présentation d'un SIEM 24
II.1.4. Présentation d'un CERT/CSIRT
25
II.1.5. Les différents types de CSIRT
25
II.1.6. Avantages fonctionnels d'un CSIRT 26
II.1.7. L'Etat des CSIRT en Afrique et au
Sénégal 26
II.2. Etude des Outils de gestion d'incidents
27
II.2.1. Etude comparative des outils de gestion des
incidents de sécurité 27
II.2.2. Présentation de l'outil Request Tracker
(RT) 28
II.2.4. Présentation de l'outil RTIR (Request
Tracker for Incidence Response) 38
Chapitre III: ANALYSE ET CONCEPTION DE LA SOLUTION
40
III.1. Définition d'un incident 40
III.2. Politique de la gestion des incidents de la
sécurité 41
III.3. Les Mesures à mettre en place
41
III.4 Organisation 42
4
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
III.4.1 Préambule 42
III.5. Processus de traitement des incidents
51
III.6.Gestion des incidents de SSI 53
III.6.1. Détection et signalement de l'incident
53
III.6.2. Enregistrement de l'incident 54
III.6.3. Catégorisation de l'incident
54
III.6.4. Qualification de l'incident 55
III.7. Réponse à l'incident SSI
55
III.7.1. Mesures de réponses immédiates
55
III.7.2. Investigations 56
III.7.3. Traitement 58
III.7.4. Revues post-incident 60
III.7.5. Actions post-incident 61
Chapitre IV : Mise en OEuvre de la solution
63
IV .1. Architecture de la solution 63
IV.1.1. Les outils utilisés 65
IV.1.2. Installation et Configuration de RT
65
IV.1.3. Installation et Configuration de RTIR
70
IV.1.4.Installation et Configuration de postfix
73
IV.2 Envoie d'alertes entre Ossim et RT 79
Conclusion 89
Bibliographie : 90
Webographie: Erreur ! Signet non
défini.
Annexe 92
5
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
Table des Figures
Figure 1: Logo de l'ADIE 12
Figure 2: Organigramme de l'ADIE 15
Figure 3: Vue synoptique d'un SIEM 24
Figure 4: Logo attestant l'utilisation du nom CERT
25
Figure 5:Acteurs/partenaires de l'équipe de
réponses aux incidents de sécurité 46
Figure 6: Grands domaines d'activité des
services liés à la gestion d'incidents de sécurité
47
Figure 7: Schématique du processus de gestion
des incidents 52
Figure 8:architecture de la solution 63
Figure 9: Système de notification par email de
RI 65
Figure 10: Fichier de configuration de RI
68
Figure 11:page d'authentification de RT 69
Figure 12: configuration de la passerelle de la
messagerie /etc/aliases 70
Figure 13:Installation de RTIR 71
Figure 14:Initialisation de la base de données
72
Figure 15:Activation du plugin RT::IR 73
Figure 16: Visualisations des emails avec Ihunderbird
75
Figure 17: autorisation du domaine
cert.adie.sn
76
Figure 18: Activation du connecteur d'envoi
77
Figure 19:espaces d'adressage 78
Figure 20:liste des domaines acceptés
79
Figure 21:Configuration de l'envoie d'email sous Ossim
79
Figure 22: réception de message envoyé
depuis RI 80
Figure 23:Reception d'un emaill dans
momo@cert.adie.sn
81
Figure 24:Format d'email provenant d'Ossim Alien Vault
82
Figure 25: Ajout d'un utilisateur 83
Figure 26:resultat de la création d'un
utlisateur 83
Figure 27: Ajout d'un groupe 84
Figure 28: Résultats de l'ajout d'un groupe
84
Figure 29:Ajout des membres du groupe 84
Figure 30: Création d'une file 85
Figure 31: Résultats de la création
d'une file 85
Figure 32: ajout des droits de groupe 86
Figure 33: résultats ajout des droits de groupe
86
Figure 34: Création des observateurs d'une file
86
Figure 35: interface pour créer un ticket
87
Figure 36: Affecter une file à un ticket
87
Figure 37: commentaires sur un ticket 88
Figure 38: Réponse et cloture de la
résolution d'un incidents 88
Figure 39: Fichier de configuration de Postfix
92
Figure 40: message d'erreur possible sur l'interface
web de RI 93
Figure 41: liste des adresses ip autorisées
93
Figure 42: Personnalisation de l'interface RI
94
6
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
Liste des tableaux
Tableau 1: Les parties prenantes au projet 21
Tableau 2: Panorama des acteurs du marché
28
Liste des Acronymes et abréviations
|
Acronymes
|
Signification
|
|
ADIE
|
Agence de l'informatique de l'Etat
|
|
SIEM
|
Security Information Event management : management des
évènements de sécurité du système
d'information
|
|
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é
|
|
RT
|
Request Tracker : Outil de gestion d'incidents
|
|
RTIR
|
Request Tracker for Incidence Response
|
|
SSI
|
Sécurité des Système d'Information
|
|
SI
|
Système d'Information
|
|
DSSIE
|
Direction de la Sécurité des Système
d'Information de l'Etat
|
|
TIC
|
Technologie d'Information et Communication
|
7
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
|
LMD
|
Licence Master Doctorat
|
|
DDoS
|
distributed denial of service attack : Attaque par
dénis de service de type distribuée
|
|
IDS
|
Intrusion Détection Système : Système de
détection d'intrusion
|
|
WAF
|
Web Application Firewall:
|
|
HTTP
|
HyperText Transport protocole
|
|
XSS
|
cross-site Scripting
|
|
IPS
|
Intusion Protection Système : Système de protection
d'intrusion
|
|
VOIP
|
Voix sur IP
|
|
forensics
|
Investigations
|
|
RTFM
|
Request Traquer Faq Manager
|
|
NASA
|
National Aeronautics and Space Administration
|
|
Freshmeat
|
est un site web répertoriant un grand nombre de logiciels,
majoritairement libres.
|
|
PSSI
|
Politique de Sécurité du Système
d'Information
|
|
CCSIRT
|
Equipe de réponse aux incidents centralisé
centralisée
|
|
DCSIRT
|
Equipe de réponse aux incidents centralisé
distribuée
|
|
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
|
|
MSSP
|
Managed Security Services Provider
|
|
RSSI
|
Responsable de la Sécurité des Système
d'Information
|
|
PCA:
|
plan de continuité d'activité
|
|
PRA
|
Plan de Reprise d'activité
|
8
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
|
GNU
|
licence publique générale
|
|
SMSI
|
Système de Management de la Sécurité de
l'Information
|
9
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
Avant-propos
A l'ère de la société de l'Information,
la Sécurité des Systèmes d'Information se trouve au coeur
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.
10
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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 oeuvre de la solution.
11
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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 oeuvre 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 oeuvre la politique du
secteur des Tics.
12
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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 coeur 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
13
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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'oeuvre des projets et de la veille
technologique. Elle assure l'accompagnement des structures administratives dans
la mise en oeuvre 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
14
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
l'Agence avec les structures administratives. Elle contribue
également à la mise en oeuvre 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 oeuvre 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.).
15
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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.
16
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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 oeuvre 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 oeuvre 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;
17
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
? 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 oeuvre 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 oeuvre 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.
18
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
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 :
19
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
ACTEURS
|
UNITE
D'ORGANISATION
|
ACTEUR
CLE
(OUI(O)/NON (N))
|
POURQUOI
|
INTERNE / EXTERNE
|
DG
|
Direction Générale
de l'ADIE
|
O
|
? Evalue la
performance des équipes chargées
de gérer les
évènements de
sécurité
|
Interne
|
DAF
|
Direction
Administrative et
Financière de l'ADIE
|
O
|
? Evalue les
impacts
financiers qui
affectent les
actifs IT suite à un incident de
sécurité
|
|
Direction de la
Sécurité des
Systèmes
d'informations de
l'Etat
|
O
|
? Piloter les
équipes chargées
de la gestion des
évènements et
incidents de
sécurité
? Définir la
stratégie de
gestion des
évènements et
|
|
20
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
|
|
|
|
|
|
incidents de
sécurité
|
|
DRST
|
Direction
|
|
des
|
O
|
|
|
|
|
Réseaux,
Systèmes
Télécoms
|
|
des
et
|
|
·
|
Réaliser les
tâches de gestion des évènements de
sécurité
|
|
|
|
|
|
|
·
|
Fournir des
informations
pour analyse
|
|
|
|
|
|
|
|
(logs , journaux)
|
|
DSI
|
Direction
|
|
des
|
O
|
·
|
Aider les
|
|
|
services l'ingénierie
|
et
|
de
|
|
|
organisations à 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
|
|
|
21
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
CNDP
|
Commission
Nationale de
protection des
données personnelles
|
O
|
? Fournir le cadre
institutionnel du traitement des données personnelles
|
Externe
|
AUTRES
|
Ministères et
administrations
|
O
|
? Appliquer les
mesures de sécurité fournies par la DSSIE
|
Externe
|
|
|
|
? 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;
22
Gestion des incidents de sécurité avec Request
Tracker | Mor Thiam
· 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é.
23
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
24
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
25
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
26
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
27
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
|
SIRIOS
|
Gestion d'incidents de sécurité.
|
Libre (GNU GPL)
|
Siebel HelpDesk
|
Gestion des incidents, des problèmes et des
changements.
|
Commercial
|
ServiceCenter
|
Gestion des incidents, problèmes, changements,
configuration
|
Commercial
|
Service Management Suite
|
Gestion des incidents, des problèmes, des changements,
des configurations.
|
Commercial
|
Request Tracker avec RTIR (WebRT)
|
gestion d'incidents, de projets, de processus, de la
qualité, de la relation client, de gestion de Service
Après-Vente
|
Libre(GPL)
|
Plain Ticket
|
Système de suivi et de gestion des incidents et des
problèmes, sur le web, application infonuagique.
|
Commercial
|
|
28
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
Logiciel
|
Domaine d'application
|
Licence
|
OTRS
|
Suivi de problème.
|
Logiciel 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 O) 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.
29
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
30
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
31
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
32
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
33
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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)
34
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
35
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
demandes pour les fonctionnels SAP. Ce droit permet
uniquement de voir les échanges publics. Le droit suivant le
complète.
s 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.
s 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.).
s 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.
s 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.
s 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.
s Watch (Observer)
36
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 0) 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 0) 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 0) 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,
37
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
· 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)
38
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
39
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
incident, le recensement et le suivi des contre-mesures mises
en oeuvre jusqu'à la chronologie des investigations.
40
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
41
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
III.2. Politique de la gestion des incidents de la
sécurité
La mise en oeuvre 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 oeuvre 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 oeuvre 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
42
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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,
43
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
? 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).
44
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
45
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.).
46
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 oeuvre 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 oeuvre 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,
47
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
? 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 oeuvre lors du traitement d'un incident de
sécurité. Les services suivants sont rattachés à ce
domaine :
48
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
· 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é,
49
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
· 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
50
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 à
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...
51
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
f°) Scan
Sondage réseau : le but de la manoeuvre 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.
52
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
53
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
54
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
55
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
56
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 oeuvre 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 oeuvre 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.
57
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 oeuvre, 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 :
58
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
· 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,
59
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
60
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
61
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.).
62
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
63
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
Chapitre IV : MISE EN OEUVRE 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.
64
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.).
65
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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).
66
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 :
67
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
68
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
69
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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/"
70
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
71
Figure 13:Installation de RTIR
72
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 ');
73
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
74
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 :
Cette ligne dit à postfix que les mails des utilisateurs
doivent aller dans un répertoire nommé mail.
command = procmail -a "$EXTENSION"
Commentons (ajoutez un #) la ligne où se trouve
mailbox_command pour que procmail ne soit pas utilisé :
#mailbox_
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
75
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
76
Figure 17: autorisation du domaine
cert.adie.sn
77
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
78
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
79
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
80
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
81
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
82
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
83
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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).
84
Figure 29:Ajout des membres du groupe
85
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
86
Figure 34: Création des observateurs d'une
file
87
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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.
88
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
89
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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 augmente 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.
90
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
Bibliographie :
o Mémoire d'Aminata Seck : Security Information et Event
Management
o CLUSIF-2011-Gestion-des-Incidents
Webographie :
o
http://cert.adie.sn
o
https://metacpan.org/pod/RT::Extension::CommandByMail
o
https://metacpan.org/pod/RT::Interface::Email::Filter::TakeAction
o
http://www.cyber-securite.fr/2013/12/13/un-csirt-a-quoi-ca-cert/
o
http://requesttracker.wikia.com/wiki/DebianSqueezeInstallGuide
o
http://www.africacert.org/home/
o
https://www.bestpractical.com/docs/rt/4.2/
o
http://doc.ubuntu-fr.org/request_tracker
o
http://www.fr.linuxfromscratch.org/view/blfs-7.5-fr/basicnet/fetchmail.html
o
http://lists.fsck.com/pipermail/rt-users/2008-December/056075.html
o
http://www.crinet.univ-metz.fr/docs/system/rt/
o
http://blog.wains.be/2008/2008-02-23-request-tracker-36-on-debian-etch-postfix-fetchmail.md
o
http://kb.mit.edu/confluence/display/istcontrib/Request+Tracker+(RT)+Q
ueue+Administrator's+Guide
o
https://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/mail-fetchmail.html
o
http://www.debianadmin.com/howto-setup-request-tracker-36-on-debian-etch.html
o
http://articles.mongueurs.net/magazines/linuxmag81.html
o
https://nsrc.org/workshops/2014/afnog-
nmf/rawattachment/wiki/Agenda/exercises-rt-lab1-vFR.htm
o
http://annaken.blogspot.sn/2013/09/how-to-set-up-rt-part-6-configuring-rt.html
o
http://kb.mit.edu/confluence/pages/viewpage.action?pageId=151106427
o
http://zero202.free.fr/cs66-smtp/html/ar01s02.html
o
www.request-tracker.fr/Presentation
91
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
o
http://requesttracker.wikia.com/wiki/Ubuntu_13.04_Server_and_Request
Tracker
o
https://www.isalo.org/wiki.debian-
fr/Configuration_d'un_serveur_mail_avec_Postfix
o
https://technet.microsoft.com/fr-
fr/library/bb124423(v=exchg.150).aspx#BKMK
InternalRelayDomains
92
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
93
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
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
:
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
94
Figure 42: Personnalisation de l'interface
RT
| 
