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

I

Membres du comité de lecture et de validation : Jean Laterrière Directeur du Technocentre national Société de gestion informatique inc. (SOGIQUE) Robert Brochu Conseiller senior en sécurité et technologie Société de gestion informatique inc. (SOGIQUE) Hance Brière Éric Dallaire Coordonnateur de la sécurité du réseau Direction des ressources informationnelles MSSS Francis Beaudoin Directeur principal – Groupe sécurité de l’information KPMG s.r.l./S.E.N.C.R.L.

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 Coordonnateur des technologies de l’information Régie régionale de Santé et Services sociaux de Lanaudière Guy Mathieu Coordonnateur Direction de l’information et de la planification Secteur des technologies et des systèmes 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 2 CONTEXTE...................................................................................................................1 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 n

La section 4 – Éléments d’un processus de gestion des incidents; 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. Le responsable de la sécurité des actifs informationnels (RSAI) de l’établissement; Les détenteurs d’actifs informationnels; Le directeur de la gestion des ressources informationnelles.

n n n

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

Meilleure compréhension des rôles et responsabilités des intervenants; Rapidité d’exécution lors d’un incident; Gestion optimale des ressources; 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 informatique

Personnel informatique

Utilisateur

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

R.S.A.I.

Détection

Suivi (4.2.6)

Confinement des domages (4.2.3)

É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 n n n n n

L’équipe de gestion des incidents; L’identification et la classification des incidents; Les procédures d’escalade; Les procédures d’éradication; Les procédures de retour à la normale; 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 financières

- Responsable de l'informatique - Services des communications

- Responsable sécurité physique Responsable des mesures d'urgence

- Supérieur immédiat

- Direction des ressources 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)
Attaque de déni de service du portail de l’établissement

Incident de nature éthique
Vol d’un ordinateur portatif contenant des données 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 n

Qui contacter, dans quelles circonstances; Les actions spécifiques à poser, dans quelles circonstances, et selon quel ordre de priorité; Les rôles assignés à chacun des individus participant à l’effort de gestion d’incident.

n

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

Rappel des supports magnétiques Restauration des données 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. 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. 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.

n

n

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

Systèmes de détection d’intrusion (IDS); Antivirus; Vérificateurs d’intégrité des fichiers; 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 n n n

Activation d’une journalisation accrue; Prise de copie de sauvegarde du système affecté – à des fins d’examen et d’enquête; Documentation des évènements; 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 n n n n

Éteindre le système affecté; Le déconnecter du réseau; Modifier les règles de filtrage d’un pare-feu ou d’un routeur; Désactiver un code d’utilisateur; 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 n n n

Que s’est-il passé, exactement? Cet incident aurait-il pu être évité? Comment? Le personnel impliqué dans le processus a-t-il agit de façon adéquate? La documentation nécessaire au personnel était-elle immédiatement disponible? Était-elle pertinente? Comment pourrait-on améliorer le processus, dans son ensemble?

n

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. Collaboration du service informatique et transparence 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. 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. Mise à jour et ré-évaluation constante des éléments du processus et de la documentation supportant le processus. Formation adéquate de tous les intervenants sur son contenu et sa teneur.

n n

n

n

n

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 n

Le responsable de la sécurité des actifs informationnels de l’établissement (RSAI); Quelques utilisateurs en mesure de représenter les détenteurs et les utilisateurs de système (pilotes ou utilisateurs-experts);

17

n n n

Le responsable du service informatique; Le responsable de la continuité des services TI; 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é cidessous. Étape 1
voir Section 5.2

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

Étape 2
voir Section 4.2.1

Désignation des membres de l’équipe de gestion des incidents : Assignation des rôles et responsabilités, création d’un organigramme, et présentation du plan de projet.

Étape 3
voir Section 4.2.1

Identification et classification des incidents : Consulter les membres appropriés du Service informatique afin de peupler la grille de classification des incidents.

Étape 4

Identification des procédures d’escalade à documenter : Identification des niveaux de priorité d’élaboration, correspondant étroitement au niveau de sévérité ou à la criticité des délais, de même qu’à la probabilité de matérialisation des incidents.

Étape 5
voir Section 4.2.1

Rédaction des procédures d’escalade : Consulter les membres appropriés du Service informatique et de la Continuité des affaires afin d’obtenir les détails techniques nécessaires.

18

Étape 6
voir Section 4.2.1

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

Étape 7
voir Section 4.2.1

Rédaction des procédures d’éradication et de retour à la normale : Consultation avec les membres appropriés du Service informatique. Certaines de ces procédures, déjà existantes, devront être validées.

Étape 8
voir Section 4.2.1

Création du formulaire de rapport d’incident : Consultation avec le personnel qui sera appelé à utiliser ce formulaire.

Étape 9

Validation et approbation des procédures et documents connexes : Les membres de l’équipe de gestion des incidents devront formellement approuver chacun des documents créés précédemment.

Étape 10

Diffusion des procédures et documents connexes au personnel concerné : Les participants potentiels à un effort de gestion des incidents devront avoir un accès immédiat à la dernière version de ces documents.

Étape 11

Entreposage d’une copie des procédures et documents connexes horssite : Une copie à jour des ces documents devra être entreposée dans un site sécuritaire, externe à l’établissement.

Étape 12

Formation du personnel concerné : Les participants potentiels à un effort 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
Analyser et identifier le problème

Détection d’un incident

Déni de service

Aviser le coordonnateur de l’équipe de gestion

Réponse dans les 15 minutes?

Non

Liste d’escalade

Oui Aviser l’administrateur du système et des Évaluer la équipements affectés situation

Réponse dans les 15 minutes?

Non

Liste d’escalade

Informer le fournisseur de services Internet

Oui

Coordonnateur, Équipe de gestion des incidents

Aviser le TCR concernée

Réponse dans les 15 minutes?

Non

Liste d’escalade

Oui

Administrateur du Consulter système affecté journaux du
système

Conserver informations pertinentes à la reconstitution de la preuve

Redémarrer le système, au besoin.

Suivi

Consulter journaux du Administrateur routeur externe

réseau

Identifier l’adresse IP du/des système(s) hostile(s)

Bloquer l’adresse IP du/des système(s) hostile(s) au niveau du routeur externe

Aviser le coordonnateur de l’équipe de gestion

Suivi

Légende:

Activité

Décision

Activité externe

Lien

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 : Souligné par : Nom et prénom : Téléphone : Date de l’incident :

Description :

Conséquences : Cause : Solution : Responsable de la mise en œuvre de la solution : Nom et prénom : Échéancier Signature du cadre Téléphone : Date de réalisation

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

Sign up to vote on this title
UsefulNot useful