Vous êtes sur la page 1sur 31

Gestion des

incidents de sécurité

Guide
Trousse d’outils

Document adopté par :

• Le Comité national sur la protection des renseignements personnels et la sécurité (CNPRPS) le


23 septembre 2003
• La Table des coordonnateurs régionaux de sécurité le 14 novembre 2003

Novembre 2003

Version 1.3
Guide d’élaboration d’un processus de gestion des
incidents de sécurité

Ce guide a été élaboré par le cabinet KPMG sous la supervision de la Direction du Technocentre
national et de SOGIQUE :

M. Robert Brochu
Conseiller senior en sécurité et technologie
Société de gestion informatique inc. (SOGIQUE)

Francis Beaudoin
Directeur principal – Groupe sécurité de l’information
KPMG s.r.l./S.E.N.C.R.L.

Personnes consultées :

Jean Laterrière Éric Dallaire


Directeur du Technocentre national Coordonnateur de la sécurité du réseau
Société de gestion informatique inc. Direction des ressources informationnelles MSSS
(SOGIQUE)
Richard Halley Yves Viau
Conseiller en sécurité Coordonnateur des ressources informationnelles
Direction des ressources informationnelles Régie régionale de Santé et Services sociaux des
MSSS Laurentides
Gilles Potvin Nathalie Malo
Coordonnateur des technologies de Analyste-conseil en technologie de l’information
l’information Régie régionale de Santé et Services sociaux de
Régie régionale de Santé et Services sociaux de Lanaudière
Lanaudière
Yvan Fournier Lucie Beauregard
Responsable du secteur serveur et sécurité Coordonnatrice sécurité et confidentialité / service
Centre hospitalier universitaire de Québec informatique
Centre universitaire de santé McGill
Denis Lebeuf Jean Asselin
Officier de sécurité Coordonnateur, secteur ressources matérielles,
Centre hospitalier de l'Université de Montréal financières et informationnelles
Association des Centres jeunesses du Québec
Normand Baker
Directeur général
CLSC Frontenac et Centre hospitalier région
amiante

I
Membres du comité de lecture et de validation :

Jean Laterrière Éric Dallaire


Directeur du Technocentre national Coordonnateur de la sécurité du réseau
Société de gestion informatique inc. Direction des ressources informationnelles
(SOGIQUE) MSSS
Robert Brochu Francis Beaudoin
Conseiller senior en sécurité et technologie Directeur principal – Groupe sécurité de
Société de gestion informatique inc. l’information
(SOGIQUE) KPMG s.r.l./S.E.N.C.R.L.
Hance Brière Jocelyne Legras
Analyste en informatique / responsable du
Coordonnateur régional de la sécurité des actifs
dossier de la sécurité de l’information régionale
informationnels
Régie régionale de Santé et Services sociaux de
Technocentre régional de l’Estrie
Québec
Gilles Potvin Guy Mathieu
Coordonnateur des technologies de Coordonnateur
l’information Direction de l’information et de la planification
Régie régionale de Santé et Services sociaux de Secteur des technologies et des systèmes
Lanaudière d’information
Régie régionale de Santé et Services sociaux de
Montréal-centre

Dans ce document, le générique masculin est utilisé pour simplifier la lecture du texte, mais
s'applique autant pour le féminin que pour le masculin.

Pour toute question ou commentaire, veuillez communiquer avec votre coordonnateur régional de
la sécurité de l'information.

Remerciements

L’équipe de réalisation tient à remercier toutes les personnes ayant collaborées avec elle.

II
Table des matières

1 CONTEXTE...................................................................................................................1

2 OBJECTIFS DU GUIDE................................................................................................2
2.1 OBJECTIFS ..................................................................................................................2
2.2 AUDIENCE ..................................................................................................................3
2.3 LIMITATIONS ..............................................................................................................4
2.4 SOUTIEN .....................................................................................................................4

3 GÉNÉRALITÉS SUR LE PROCESSUS DE GESTION DES INCIDENTS DE


SÉCURITÉ.....................................................................................................................5
3.1 POSITIONNEMENT DE LA GESTION DES INCIDENTS DE SÉCURITÉ......................................5
3.2 POURQUOI UN PROCESSUS DE GESTION DES INCIDENTS? ................................................6

4 ÉLÉMENTS D’UN PROCESSUS DE GESTION DES INCIDENTS DE


SÉCURITÉ.....................................................................................................................7
4.1 PRÉSENTATION GLOBALE DU PROCESSUS ......................................................................7
4.2 ÉTAPES DU PROCESSUS DE GESTION DES INCIDENTS.......................................................8

5 MÉTHODOLOGIE D’ÉLABORATION D’UN PROCESSUS DE GESTION


DES INCIDENTS.........................................................................................................17
5.1 LES FACTEURS CLÉS DE RÉUSSITE............................................................................... 17
5.2 COMPOSITION DE L’ÉQUIPE DE PROJET ........................................................................ 17
5.3 LES ÉTAPES DE PRÉPARATION .................................................................................... 18

ANNEXE A – EXEMPLE DE PROCÉDURE D’ESCALADE............................................21

ANNEXE B – FORMULAIRE DE RAPPORT D’INCIDENT............................................26

i
1 Contexte

La sécurité des actifs informationnels 1 est devenue une préoccupation majeure des intervenants
oeuvrant dans le domaine de la santé. Étant donné l’importance stratégique des systèmes
d’information utilisés par les établissements et les organismes2 de même que la nature sensible
des informations qu’ils traitent, la sécurisation des actifs informationnels devient un enjeu
stratégique pour le réseau sociosanitaire.

En ce sens, le Ministère de la Santé et des Services sociaux a récemment adopté le Cadre global
de gestion des actifs informationnels appartenant aux établissements du réseau de la santé et des
services sociaux – Volet sur la sécurité (appelé « Cadre global » ci-après) Le Cadre global vise à
communiquer les attentes, les obligations et les rôles de chacun des intervenants en matière de
sécurité des actifs informationnels. À ce titre, les établissements ont notamment l'obligation de se
doter d'une politique de sécurité tel que stipulé à l'article 3.3 du Cadre global.

Afin de les appuyer dans leurs efforts, le Ministère a créé en octobre 2001 la « table des
coordonnateurs régionaux en sécurité » afin d’échanger et de partager quant aux enjeux reliés au
déploiement du Cadre global en général. Or, la responsabilité de sécuriser les actifs
informationnels revient aux propriétaires des actifs afin de supporter les établissements. Sogique
a été mandatée afin de développer une trousse destinée à accompagner et à supporter les
établissements dans l’implantation du Cadre global.

C’est donc dans ce contexte que le présent « guide d’élaboration d’un processus de gestion des
incidents de sécurité » a été développé. Il est important de mentionner que chaque organisme a la
responsabilité de gérer ses incidents.

1 La notion d’actif informationnel est définie au lexique. De plus, le domaine d’application de la sécurité
de l’information est défini au Cadre global à l’article 2, page 7.
2
Dans un souci d'allègement du texte, nous utiliserons uniquement le terme « établissements » pour
désigner l'ensemble des organisations du secteur sociosanitaire assujetti à l'application du Cadre global
art. 2

1
2 Objectifs du guide

2.1 Objectifs

L’objectif du présent guide est de supporter les établissements dans l’élaboration et la mise en
œuvre d’un processus de gestion des incidents de sécurité de l’information.

Un tel processus permet de s’assurer que, si un incident de sécurité survient, les actions adéquates
seront posées, les intervenants appropriés seront contactés et, le cas échéant, les informations
nécessaires à la tenue d’une enquête seront enregistrées.

Il est à noter qu’il existe deux types d’incidents en regard aux incidents de sécurité des actifs
informationnels : les incidents de nature technique et les incidents de nature éthique.

Dans le présent guide, les incidents de nature technique sont définis comme des événements
mettant en péril la disponibilité, l’intégrité, la confidentialité, l’authentification et l’irrévocabilité
d’un actif informationnel et de ses dérivés (impression) Par exemple, une attaque de déni de
service, l’installation d’un cheval de Troie sur un serveur critique ou une intrusion dans le but
d’accéder à des données nominatives sont trois exemples d’incidents de sécurité affectant,
respectivement, la disponibilité, l’intégrité et la confidentialité des actifs informationnels qui en
sont les victimes. Néanmoins les événements nécessitant la mise en œuvre du plan de secours, tel
qu’un incendie majeur, une inondation ou une coupure électrique ne serons pas traité par le
présent guide, car elle relève plutôt du domaine des pans de mesures d’urgence.

Les incidents de nature éthique, quant à eux, seront définis comme étant reliés au comportement
des individus. Par exemple, le non-respect d’une loi, l’utilisation d’équipements informatiques à
des fins, de pédophilie, de participation à des groupes de discussion racistes, de piratage de
logiciel et tout autre incident de nature similaire pouvant nuire à l’image corporative des
établissements envers la population seront de plus traité dans le présent guide.

2
Ces deux types d’incidents, bien que tous deux reliés aux actifs informationnels,
nécessite une approche de gestion différente. Par exemple, la composition de
l’équipe de gestion de l’incident pourra différer en fonction de la nature technique
ou étique de l’incident. Lorsque approprié, nous ferons ressortir les distinctions tout au long du
guide. Cependant, il est à noter que ce guide ne porte pas sur la gestion des aspects éthiques d’un
incident car ces éléments relèvent généralement du domaine des relations de travail.

Ce guide est construit autour de deux sections principales, soit :

n La section 4 – Éléments d’un processus de gestion des incidents;

n La section 5 – Méthodologie d’élaboration d’un processus de gestion des incidents.

La section 4 expose les différents éléments qui constituent un processus de gestion des incidents.
Pour chaque élément, la raison d’être de cet élément, sont les meilleures pratiques le concernant,
ainsi qu’une liste de suggestions et d’exemples.

La section 5, quant à elle, propose une méthodologie permettant d’élaborer un processus de


gestion des incidents. Comme toute méthode de travail, cette dernière devra être adaptée aux
particularités de chaque établissement.

2.2 Audience

Ce guide s’adresse principalement aux personnes suivantes :

n Responsable auquel la tâche d’élaborer un processus de gestion des incidents de sécurité


a été assignée qui, dans la majorité des cas, devrait être le responsable de la sécurité des
actifs informationnels de l’établissement.

n Le responsable de la sécurité des actifs informationnels (RSAI) de l’établissement;

n Les détenteurs d’actifs informationnels;

n Le directeur de la gestion des ressources informationnelles.

3
2.3 Limitations

La disparité entre les établissements et leurs stades variables d'avancement quant aux activités de
gestion de la sécurité de l'information fait en sorte que le guide devra être adapté. Il ne ce
substitut en aucun cas au jugement professionnel des intervenants des établissements, et son
utilisation demeure une prérogative de ceux-ci.

2.4 Soutien

Les Régies régionales de la Santé et des Services sociaux ont le mandat de supporter les
établissements dans leur démarche d’élaboration d’un processus de gestion des escalades des
incidents de sécurité. Pour toutes questions concernant ce guide, vous pouvez vous adresser au
coordonnateur de votre région.

4
3 Généralités sur le processus de gestion des
incidents de sécurité

3.1 Positionnement de la gestion des incidents de sécurité

La gestion des incidents de sécurité est un élément essentiel du cycle de vie de la sécurité
informatique, tel qu’illustré à la figure 1 ci-dessous :

Détection

Mesures
préventives

Gestion des
incidents

Figure 1 – Cycle de vie de la sécurité informatique

Les mesures préventives sont généralement choisies et déployées des suites d’une analyse de
risques, et en accord avec les meilleures pratiques énoncées dans le domaine. Elles contribuent à
l’atténuation des menaces à la sécurité des actifs informationnels et à l’atteinte à l’image
corporative de l’établissement.

La détection des incidents permet de déterminer si la sécurité d’un ou de plusieurs des actifs
informationnels de l’établissement a été compromise, et, en conséquence, de jauger l’efficacité
des mesures préventives.

5
La gestion des incidents suit logiquement l’étape de détection, et les activités qui la caractérisent
peuvent susciter le déploiement de nouvelles mesures préventives. Ces activités seront couvertes
en détail dans la section 4, « Éléments d’un processus de gestion des incidents ».

3.2 Pourquoi un processus de gestion des incidents?

Comme nous l’avons vu précédemment, la gestion des incidents contribue de façon notable au
cycle de vie de la sécurité informatique, puisqu’elle permet non seulement de répondre aux
évènements néfastes affectant les actifs informationnels, mais aussi de signaler les failles
éventuelles des mesures préventives en vigueur.

Malgré la présence d’une infrastructure technologique de sécurité sophistiquée et de personnel


technique hautement technique il est important de mettre en place un processus de gestion des
incidents pour les raisons suivantes :

n Meilleure compréhension des rôles et responsabilités des intervenants;

n Rapidité d’exécution lors d’un incident;

n Gestion optimale des ressources;

n Meilleures communications entre l’ensemble des parties prenantes.

Il est donc clair qu’aucun établissement ne peut se passer d’un processus formel de gestion des
incidents, tel qu’il est décrit dans la section suivante.

6
4 Éléments d’un processus de gestion des incidents
de sécurité

4.1 Présentation globale du processus

Le processus global proposé est présenté dans le diagramme ci-bas :

Préparation du processus de gestion des incidents (4.2.1)

Détection et escalade

Incidents techniques Incidents éthiques

Personnel Personnel
Utilisateur
informatique informatique

R.S.I.
Supérieur
immédiat

Supérieur
R.S.A.I.
immédiat
Police
Détection

Confinement
des domages
(4.2.3)
Suivi (4.2.6)

Équipe de
gestion de
l'incident
Éradication
(4.2.4)

Retour à la
normale (4.2.5)

Figure 2 – Méthodologie de gestion des incidents

7
Il est à noter que la durée et l’importance de chacune des ces étapes varieront d’un incident à
l’autre, selon sa sévérité, sa complexité, et l’étendue des dommages.

Nous abordons chacune de ces étapes dans la sous-section suivante.

4.2 Étapes du processus de gestion des incidents


Validation, rétroaction et mise à jour
4.2.1 Préparation

L’étape de préparation est sans aucun doute la plus importante puisque c’est durant celle-ci que
s’élabore l’infrastructure de gestion des incidents, en particulier :

n L’équipe de gestion des incidents;

n L’identification et la classification des incidents;

n Les procédures d’escalade;

n Les procédures d’éradication;

n Les procédures de retour à la normale;

n Toute documentation connexe nécessaire (listes téléphoniques, etc.)

Examinons de plus près chacune de ces composantes.

Équipe de gestion des incidents

Une équipe de gestion des incidents doit être mise en place avant toute autre chose. Cette équipe
sera, non seulement responsable de l’exécution des procédures décrites plus bas, mais jouera un
rôle consultatif important lors de leur élaboration. La nature de l’incident, soit technique ou
éthique influencera la composition de l’équipe. La figure de la page suivante présente certaines
suggestions quant aux de membres qui pourraient composer l’équipe de gestion des incidents en
fonction de la nature de l’incident.

8
Incident de nature technique Incident de nature éthique

- Professionnel de la sécurité
informatique (PSI) - RSAI
- Services juridiques

- Direction des ressources - Responsable de l'informatique


financières - Services des
communications
- Responsable sécurité physique
Responsable des mesures
d'urgence - Direction des ressources
- Supérieur immédiat humaines

- Directeur général
Administrateur réseau - Détenteur de l'actif
informationnel

Équipe de gestion des incidents

Comme la figure le démontre, la composition de l’équipe de gestion des incidents sera influencée
par la nature de l’incident. Par exemple, dans le cas d’un incident de nature strictement
technique, il est peu probable que les services juridiques soient impliqués. À l’inverse, dans le
cas d’un incident de nature purement éthique, l’administrateur réseau pourrait ne pas avoir de rôle
à jouer. Certains intervenant toutefois risquent d’être sollicité dans pratiquement toutes les
situations. C’est le cas par exemple du Responsable de la Sécurité des Actifs Informationnels
(RSAI), du responsable de l’information et des autres intervenants figurant à l’intersection des
deux cercles.

9
Le degré et la nature de l’implication de chacun des membres de l’équipe de gestion des incidents
seront bien évidemment variables, mais tous les intervenants devront être préparés à répondre,
selon leur rôle, aux exigences de la situation, quelle qu’elle soit.

Le responsable de la sécurité des actifs informationnels de l’établissement (RSAI) sera le


coordonnateur de l’équipe de gestion des incidents. Celui-ci aura pour rôle principal la direction
de l’équipe de gestion des incidents, mais sera également en charge de la communication avec la
haute direction, et de la formation de l’ensemble des membres de l’équipe sur les types
d’incidents, les actions à prendre, et l’importance de leur participation.

Identification et classification des incidents

Avant de rédiger des procédures d’escalade et de retour à la normale, il est nécessaire de se


familiariser avec les incidents pouvant affecter les actifs informationnels de l’établissement, puis
d’attribuer à chacun de ces incidents une cote de sévérité, de 1 à 3 (1 – Élevé, 2 – Moyen,
3 – Bas). Cette cote permettra de déterminer rapidement les niveaux d’escalade pour un incident
donné.

Les incidents identifiés et les cotes associées pourront être consignées dans une grille de
classification de ce type :

Incident de nature technique (D,I,C) Incident de nature éthique

Attaque de déni de service du portail de Vol d’un ordinateur portatif contenant des données
l’établissement sensibles

Programme malveillant, virus Utilisation des équipements informatiques à des fins


de pédophilies

Intrusion d’un utilisateur non autorisé …

Tableau 1 – Exemple de grille de classification des incidents

10
Pour obtenir des informations à jour concernant les incidents de sécurité informatique et
les nouvelles vulnérabilités, il est recommandé de s’abonner à une liste postale telle
que celle du CERT/CC3 .

Procédures d’escalade

Des procédures d’escalade doivent être rédigées pour chacun des incidents ou groupes d’incidents
identifiés. En fonction de la nature de l’incident (technique ou éthique), la procédure appropriée
devra être invoquée (voir figure 2) Les procédures d’escalade seront utilisées durant les étapes 2,
« Détection », et 3, « Confinement des dommages » du processus. Ces procédures doivent
contenir, au minimum, les informations suivantes :

n Qui contacter, dans quelles circonstances;

n Les actions spécifiques à poser, dans quelles circonstances, et selon quel ordre de
priorité;

n Les rôles assignés à chacun des individus participant à l’effort de gestion d’incident.

Ces procédures doivent être simples, claires et concises – il ne faut pas perdre de vue lors de leur
élaboration qu’elles seront utilisées en situation de crise et d’urgence. De plus, il est crucial de
s’assurer qu’elles sont régulièrement maintenues à jour, une attention particulière devant être
accordée aux informations concernant les individus à contacter.

Le schéma opérationnel est un format parfaitement adapté aux procédures d’escalades


car il permet une visualisation rapide du cheminement et des priorités d’action.

Un exemple de procédure d’escalade est présenté dans l’annexe A.

3
http://www.cert.org/contact_cert/certmaillist.html

11
Procédures d’éradication

La documentation des procédures d’éradication permet de s’assurer qu’aucun détail n’est omis
lors de cette étape importante du processus de gestion des incidents. La complexité de ces
procédures variera selon la nature et la gravité de l’incident : Ainsi, autant une procédure
d’éradication de virus sera simple, spécifiant, au mieux, l’exécution d’un logiciel antivirus, au
pire le formatage du disque dur du système affecté, autant une procédure d’éradication suite à une
intrusion ou une compromission de système pourra être complexe.

Dans tous les cas, les procédures d’éradication s’adressent au personnel technique du
Service informatique, elles doivent donc respecter le format habituel des procédures de
ce service.

Un exemple de procédure d’éradication est présenté dans l’annexe B.

Procédures de retour à la normale

Des procédures de retour à la normale, qui seront utilisées durant l’étape 5 « Retour à la
normale » du processus, doivent également être élaborées. Celles-ci doivent être spécifiquement
rédigées pour le personnel technique du Service informatique, et préciser les étapes à suivre pour
rétablir un niveau de service satisfaisant des systèmes affectés, une fois les mesures immédiates
de confinement des dommages et d’éradication appliquée.

Elles doivent traiter, par exemple, des aspects suivants :

n Rappel des supports magnétiques

n Restauration des données

n Validation des configurations

Ces procédures, puisqu’elles s’adressent à une audience technique, doivent être


détaillées et précises, et respecter le format en vigueur pour les autres procédures du
Service informatique.

12
Un exemple de procédure de retour à la normale est présenté dans l’annexe C.

Documentation connexe

Finalement, il est important de ne pas négliger certains détails qui pourraient faire toute une
différence en cas d’incident :

n Les listes téléphoniques consignant les numéros de téléphone, au bureau et à la maison,


les numéros de télé-avertisseur et de téléphone cellulaire des intervenants de l’équipe de
gestion des incidents doivent être facilement accessibles et maintenues rigoureusement à
jour.

n La documentation appropriée concernant les principaux fournisseurs d’équipement et de


support – incluant les numéros de contrat, numéros de série et autres – doit également
être disponible.

n Un formulaire de rapport d’incident pourrait être mis à la disposition du personnel


responsable du support de première ligne, afin de les assister dans le processus
d’escalade. Il leur permettra de consigner les informations de base concernant l’incident,
telles que le type d’incident, le système affecté, la date et l’heure de début de l’incident,
et le statut. Un exemple de formulaire est présenté dans l’annexe D.

4.2.2 Détection

Des moyens de détection des incidents doivent être mis en place afin de contenir l’impact de
ceux-ci et de faciliter un enclenchement rapide du processus d’escalade. Ces moyens doivent
également permettre une surveillance proactive, dans le but de prévenir la matérialisation d’un
incident donné et une analyse réactive, qui servira d’intrant, lors de la définition de mesures
curatives pour éviter la ré-occurrence d’un incident donné.

Les outils de détection les plus courants sont énumérés ci-dessous :

n Systèmes de détection d’intrusion (IDS);

n Antivirus;

n Vérificateurs d’intégrité des fichiers;

n Journaux de sécurité.

13
Toute anomalie révélée par ces outils doit être analysée au plus vite, par le personnel compétent,
et si cette anomalie se convertit en un incident de sécurité, les mesures suivantes doivent être, si
possible, mises en place :

n Activation d’une journalisation accrue;

n Prise de copie de sauvegarde du système affecté – à des fins d’examen et d’enquête;

n Documentation des évènements;

n Notification des individus appropriés.

Chacune de ces mesures doit figurer dans les procédures d’escalade mentionnées plus
haut.

4.2.3 Confinement des dommages

Les activités de confinement des dommages se caractérisent par leur rapidité d’exécution, et leur
impact sur la continuité d’opération des systèmes. Elles ne doivent donc être entreprises que dans
le contexte d’une procédure d’escalade.

Voici quelques exemples d’activités de confinement des dommages :

n Éteindre le système affecté;

n Le déconnecter du réseau;

n Modifier les règles de filtrage d’un pare-feu ou d’un routeur;

n Désactiver un code d’utilisateur;

n Désactiver un service.

La décision de recourir ou non à l’une de ces activités, à cause de ses conséquences sérieuses sur
la disponibilité des systèmes, ne peut être improvisée. Elle doit faire l’objet d’une étude à froid, et
s’inscrire dans la mise en œuvre d’un processus pré-défini.

14
4.2.4 Éradication

L’étape d’éradication, dans le processus de gestion des incidents, vise à éliminer la cause d’un
incident donné. Elle suit logiquement l’étape de confinement des dommages, et doit être exécutée
par le personnel technique du Service informatique, selon les instructions présentes dans les
procédures d’éradication définies précédemment.

4.2.5 Retour à la normale

Une fois les dommages contenus et la cause de l’incident éliminée, il convient de recourir à des
procédures de retour à la normale afin de rétablir un niveau d’opération acceptable, de la façon la
plus efficace possible.

C’est également durant cette phase du processus que l’on éliminera les mesures temporaires
mises en œuvre lors de l’étape de confinement des dommages, après avoir confirmé qu’elles
n’étaient plus requises.

4.2.6 Suivi

Le but principal de cette étape est de tirer les leçons de l’incident qui est survenu, afin d’améliorer
le processus de gestion des incidents, et, en général, les mesures préventives en place dans
l’établissement.

Une analyse post-mortem doit être effectuée pour chaque incident, et les questions suivantes
doivent, entre autres, être posées :

n Que s’est-il passé, exactement?

n Cet incident aurait-il pu être évité? Comment?

n Le personnel impliqué dans le processus a-t-il agit de façon adéquate?

n La documentation nécessaire au personnel était-elle immédiatement disponible? Était-elle


pertinente?

n Comment pourrait-on améliorer le processus, dans son ensemble?

15
Il est à noter que cette étape s’applique à tous types d’incident et qu’il est suggéré de
rédiger un rapport résumant les conclusions de ces analyses, et de conserver celui-ci à
des fins de formation et de référence.

16
5 Méthodologie d’élaboration d’un processus de
gestion des incidents

5.1 Les facteurs clés de réussite

Le succès d’un processus de gestion des incidents de sécurité de l’information repose sur une
série de facteurs, tous aussi importants les uns que les autres. En voici une liste sommaire :

n Engagement ferme de la direction de l’établissement, se traduisant par l’attribution des


ressources financières et humaines nécessaires.

n Collaboration du service informatique et transparence

n Sensibilisation du personnel impliqué dans l’effort de d’élaboration du processus de


gestion des incidents à l’importance de l’exactitude et la pertinence des procédures
développées. Ces procédures seront suivies scrupuleusement durant l’effort de gestion
des crises et ne peuvent laisser de champ à l’improvisation de leurs exécutants.

n Responsable de la Sécurité des Actifs Informationnels (RSAI) possédant des qualités


reconnues de leadership et de sang-froid, et dont la légitimité ne sera nullement contestée
en cas d’incident.

n Mise à jour et ré-évaluation constante des éléments du processus et de la documentation


supportant le processus.

n Formation adéquate de tous les intervenants sur son contenu et sa teneur.

5.2 Composition de l’équipe de projet

Nous recommandons de constituer un comité de sécurité provisoire qui supportera le chargé de


projet dans son mandat d'élaboration d’un processus de gestion des incidents. Le groupe devrait
être composé des intervenants suivants :

n Le responsable de la sécurité des actifs informationnels de l’établissement (RSAI);

n Quelques utilisateurs en mesure de représenter les détenteurs et les utilisateurs de système


(pilotes ou utilisateurs-experts);

17
n Le responsable du service informatique;

n Le responsable de la continuité des services TI;

n Un membre du service des Relations publiques.

5.3 Les étapes de préparation

La préparation d’un processus de gestion des incidents doit suivre le cheminement illustré ci-
dessous.

Étape 1 Mise en place d’une équipe de projet : Rencontre initiale des participants,
voir et élaboration d’un plan de projet, assorti d’un échéancier des livrables.
Section 5.2

Étape 2 Désignation des membres de l’équipe de gestion des incidents :


voir Assignation des rôles et responsabilités, création d’un organigramme, et
Section 4.2.1
présentation du plan de projet.

Étape 3 Identification et classification des incidents : Consulter les membres


voir appropriés du Service informatique afin de peupler la grille de
Section 4.2.1
classification des incidents.

Identification des procédures d’escalade à documenter : Identification


des niveaux de priorité d’élaboration, correspondant étroitement au niveau
Étape 4 de sévérité ou à la criticité des délais, de même qu’à la probabilité de
matérialisation des incidents.

Étape 5 Rédaction des procédures d’escalade : Consulter les membres appropriés


voir du Service informatique et de la Continuité des affaires afin d’obtenir les
Section 4.2.1
détails techniques nécessaires.

18
Étape 6 Compilation des informations connexes : Listes téléphoniques des
voir personnes ressources et des fournisseurs, consolidation des numéros de
Section 4.2.1 contrat de service, numéros de série d’équipement etc.

Étape 7 Rédaction des procédures d’éradication et de retour à la normale :


voir Consultation avec les membres appropriés du Service informatique.
Section 4.2.1 Certaines de ces procédures, déjà existantes, devront être validées.

Étape 8 Création du formulaire de rapport d’incident : Consultation avec le


voir personnel qui sera appelé à utiliser ce formulaire.
Section 4.2.1

Validation et approbation des procédures et documents connexes : Les


Étape 9 membres de l’équipe de gestion des incidents devront formellement
approuver chacun des documents créés précédemment.

Diffusion des procédures et documents connexes au personnel


Étape 10 concerné : Les participants potentiels à un effort de gestion des incidents
devront avoir un accès immédiat à la dernière version de ces documents.

Entreposage d’une copie des procédures et documents connexes hors-


Étape 11 site : Une copie à jour des ces documents devra être entreposée dans un site
sécuritaire, externe à l’établissement.

Formation du personnel concerné : Les participants potentiels à un effort


Étape 12 de gestion des incidents devront recevoir une formation rigoureuse sur le
contenu des procédures et documents, et le processus en général.

19
Certaines de ces étapes devront être répétées, régulièrement ou des suites d’un incident révélant
une lacune dans le processus, car celui-ci n’est pas ponctuel, mais continu. L’exactitude et la
pertinence de ses éléments sont les garants de son succès.

20
ANNEXE A – EXEMPLE DE PROCÉDURE D’ESCALADE

Fourni à titre d’exemple seulement

21
Déni de service

Détection Analyser et
identifier le Déni de service Aviser le coordonnateur Réponse dans Non Liste
d’un incident les 15 minutes? d’escalade
problème de l’équipe de gestion

Oui

Aviser l’administrateur
du système
Évaluer la et des Réponse dans Non Liste
équipements
situation affectés les 15 minutes? d’escalade

Oui
Informer le fournisseur
de services Internet

Coordonnateur,
Équipe de gestion Aviser le TCR Réponse dans Non Liste
des incidents concernée les 15 minutes? d’escalade

Oui

Administrateur
Consulter
du Conserver informations Redémarrer le
système affecté
journaux du pertinentes à la système, au besoin. Suivi
système reconstitution de la
preuve

Consulter Bloquer l’adresse IP


Identifier l’adresse IP du/des système(s) Aviser le coordonnateur
journaux du Suivi
Administrateur du/des système(s) hostile(s) au niveau du de l’équipe de gestion
routeur externe
hostile(s) routeur externe
réseau

Activité Décision Activité externe Lien


Légende:

22
Exemple de liste d’escalade

Gestion des incidents


1 - Coordonnateur (111) 123-4567 ext. 1234
(111) 987-6543 (cellulaire)
(111) 567-5543 (téléavertisseur)
(111) 432-6554 (maison)

2 – Coordonnateur, suppléant (111) 123-4567 ext. 1235


(111) 987-5466 (cellulaire)
(111) 567-5453 (téléavertisseur)
(111) 321-6654 (maison)

Équipements réseau
1 - Administrateur (111) 123-4567 ext. 1134
(111) 555-6543 (cellulaire)
(111) 634-5543 (téléavertisseur)
(111) 333-6554 (maison)

2 – Administrateur, suppléant (111) 123-4567 ext. 1135


(111) 786-5466 (cellulaire)
(111) 221-5453 (téléavertisseur)
(111) 321-7895 (maison)

23
Serveurs WEB
1 - Administrateur (111) 123-4567 ext. 1334
(111) 555-5005 (cellulaire)
(111) 634-4400 (téléavertisseur)
(111) 333-4400 (maison)

2 – Administrateur, suppléant (111) 123-4567 ext. 1335


(111) 786-5000 (cellulaire)
(111) 221-4000 (téléavertisseur)
(111) 321-2000 (maison)

TCR
(111) 123-4567 ext. 1336
(111) 786-5001 (cellulaire)
(111) 221-4001 (téléavertisseur)
(111) 321-2001 (maison)

Coordonnateur de sécurité régionale


(111) 123-4567 ext. 1337
(111) 786-5002 (cellulaire)
(111) 221-4002 (téléavertisseur)
(111) 321-2002 (maison)

Directeur général de l’établissement


(111) 123-4567 ext. 1338
(111) 786-5003 (cellulaire)
(111) 221-4003 (téléavertisseur)
(111) 321-2003 (maison)

24
Responsable du TCN
(111) 123-4567 ext. 1339
(111) 786-5004 (cellulaire)
(111) 221-4004 (téléavertisseur)
(111) 321-2004 (maison)

MSSS – Directeur des ressources informationnelles


(111) 123-4567 ext. 1340
(111) 786-5005 (cellulaire)
(111) 221-4005 (téléavertisseur)
(111) 321-2005 (maison)

25
Annexe B – Formulaire de rapport d’incident

26
RAPPORT DE DÉCLARATION D’INCIDENT
Date : Date de l’incident :
Souligné par :
Nom et prénom : Téléphone :

Description :

Conséquences :

Cause :

Solution :

Responsable de la mise en œuvre de la solution :


Nom et prénom : Téléphone :
Échéancier Date de réalisation
Signature du cadre

Suivi :
Date du suivi :
Description :

Signature du responsable de l’application de la politique :

Doit être remis au :

Supérieur immédiat
Responsable de l’application de la politique

27