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