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