Plan de gestion des incidents de la TI du gouvernement du Canada

Ce document a été mis à jour!

Une version plus récente de ce document a été trouvée.

Also issued in English under the title Government of Canada Information Technology Incident Management Plan

Table des matières

1. Date d'entrée en vigueur

Le présent Plan entre en vigueur le 10 mai 2012. Il remplace le Plan de gestion des incidents de la technologie de l'information au gouvernement du Canada (PGI TI GC) de 2009. Le PGI TI GC sera examiné sur une base annuelle et fera l'objet de modifications, le cas échéant.

2. Application

2.1 Le présent Plan est préparé à l'appui des pouvoirs délégués au Secrétariat du Conseil du Trésor aux termes de la Loi sur la gestion des finances publiques et de la Politique sur la sécurité du gouvernement qui y est associée; des mandats ministériels; ainsi que des pouvoirs délégués au ministre de la Sécurité publique aux termes de la Loi sur la gestion des urgences.

2.2 Le présent Plan s'applique à toutes les institutions fédérales assujetties à la Politique sur la sécurité du gouvernement et il touche :

  • les menaces, les facteurs de vulnérabilité et les incidents, dans le contexte de la TI, qui touchent ou sont susceptibles de toucher les services fournis aux Canadiens, les opérations gouvernementales, la sécurité ou la confidentialité de l'information ou la confiance envers le gouvernement;
  • les incidents, dans le contexte de la TI, qui requièrent une intervention intégrée du GC;
  • les réseaux classés secret et moins.

2.3 Le présent Plan ne touche pas la coordination des cyberincidents nationaux et internationaux avec d'autres formes de gestion des crises et des urgences.

2.4 La présente version du plan exige que les ministères envoie leur rapport d'incidents de la TI au Centre d'évaluation des cybermenaces du gouvernement du Canada (CECM-GC) du Centre de la sécurité des télécommunications du Canada (CSTC), jusqu'à ce que les Services partagés Canada (SPC) soient prêts à assumer le rôle de l'Équipe canadienne d'intervention d'urgence en informatique (ECIUI).

2.5 Les procédures opérationnelles de gestion des incidents de la TI des ministères suivants seront fournies au SCT à des fins d'inclusion dans les annexes du présent document : Sécurité publique (SP), Centre de la sécurité des télécommunications du Canada (CSTC), Service canadien de renseignement de sécurité (SCRS), Gendarmerie royale du Canada (GRC), Secrétariat du Conseil du Trésor (SCT), Services partagés Canada (SPC) et ministère de la Défense nationale (MDN).

3. Contexte

Les incidents de la technologie de l'information (TI) touchant les réseaux et l'infrastructure du gouvernement du Canada (GC) peuvent avoir une grande incidence sur les opérations, les services fournis aux Canadiens et, en conséquence, la confiance envers le gouvernement. La capacité de déceler et de donner suite aux incidents d'une manière coordonnée et cohérente dans l'ensemble de l'administration fédérale est essentielle au maintien des opérations et des services gouvernementaux, et pour assurer la confidentialité, l'intégrité et la disponibilité des actifs de TI et de l'information du gouvernement.

Le Plan de gestion des incidents de la technologie de l'information au gouvernement du Canada (PGI TI GC ) établit un cadre opérationnel aux fins de la gestion des événements et des incidents de sécurité de la TI susceptibles d'avoir ou d'avoir eu une incidence sur les réseaux informatiques du GC.

3.1 Objectifs

  • Sensibilisation accrue dans l'ensemble de l'administration fédérale.
  • Amélioration de la coordination et de la planification de la gestion des incidents dans l'administration fédérale.
  • Règlement rapide des incidents qui touchent les services et les opérations du GC.
  • Éclairage du processus décisionnel et des processus d'intervention et d'atténuation des incidents connexes,
  • Responsabilité et partenariat partagés entre les collectivités de la TI et de la Sécurité de la technologie de l'information (STI) au GC.
  • Amélioration du partage des connaissances et du savoir faire au sein du GC.
  • Confiance accrue du public canadien envers le GC.

3.2 Hypothèses

Le présent Plan a été fondé sur les hypothèses suivantes :

  • toutes les organisations ont mis en place des plans/processus de gestion des incidents et des plans de continuité des activités (PCA) comme l'exige la Politique sur la sécurité du gouvernement;
  • les mandats et les responsabilités actuels des ministères seront respectés;
  • la gestion des incidents de sécurité de la TI liés à la divulgation de renseignements personnels ou de communications privées observera les marches à suivre établies en matière de protection des renseignements personnels;
  • en outre, si l'incident est considéré comme étant de nature criminelle, il sera rapporté directement à la Gendarmerie royale du Canada ou à la Police militaire, selon le cas, et s'il est considéré comme étant important pour la sécurité nationale, ses détails seront rapportés directement au Service canadien du renseignement de sécurité.

4. Modèle de gouvernance

Quand survient un incident grave, la mobilisation rapide des hauts fonctionnaires est essentielle à la vigueur et à l'efficacité de l'intervention. Le modèle de gouvernance du PGI TI GC désigne les fonctionnaires et les comités de la haute direction qui seront mobilisés quand les critères de gravité et de déclenchement d'une intervention seront réunis.

L'orientation établie par les comités et par les fonctionnaires de la structure de gouvernance du PGI TI GC couvrira à la fois les activités à court et à long termes dans le cas des incidents plus graves. Les activités à court terme sont axées sur des événements et elles sont exercées à l'étape de l'atténuation d'une menace ou d'un facteur de vulnérabilité, ou de l'intervention ou du rétablissement après un incident. Ces activités requièrent une intervention rapide et cohérente. Les activités à plus long terme englobent l'analyse postérieure à l'incident et les leçons à retenir, qui permettront au sous ministre adjoint du Comité de sécurité (SMA Sécurité) ou au sous ministre adjoint Sécurité nationale (SMA SN) et au Conseil des dirigeants principaux de l'information (CDPI) d'assurer un leadership stratégique, une orientation et une gouvernance à plus long terme en matière de sécurité et de TI respectivement.

La mobilisation des fonctionnaires et des comités suivants sera fondée sur les circonstances et la gravité de chaque situation.

Figure 1: Structure de gouvernance
Graphique de la Structure de gouvernance. Version textuelle ci-dessous :
Figure 1 - Version textuelle

Cet organigramme illustre le modèle de gouvernance du Plan de gestion des incidents de TI au gouvernement du Canada. Il fait état des comités de la haute direction et des cadres qui interviendront lorsque les critères de gravité et de déclenchement seront réunis.

Au premier échelon, les renseignements sur l’incident ou la menace sont communiqués à l’ECIUI du GC par différentes organisations (ministères touchés, SP, partenaires). L’ECIUI transmet ces renseignements au SCT et au CECM (dans le cas d’une cybermenace). L’UTC reçoit les renseignements de l’ECIUI ou du CECM. L’ECIUI évalue les renseignements; s’il est question d’une cybermenace, le relais est transmis à l’Unité d’intervention en cas de cyberincidents (UIC), qui compte des représentants du SCRS, du SCT, du CECM, du CCIRC (SP), du MDN/FC, de la GRC et de SPC, et qui est présidée par des directeurs du CECM, de la DDPI du SCT, du CSTC et de SPC.

S’il ne s’agit pas d’un cyberincident, les renseignements sont transmis directement à l’équipe de direction sans passer par l’intermédiaire de l’UIC. Cette équipe de direction se compose de représentants de la DDPI du SCT, du DG de la défense cybernétique du CSTC et de DG des organismes d’enquête concernés. Il peut aussi y avoir au besoin des représentants du MDN/FC (DGOGI), du ministère de la Justice (repr. de SP), de SP (DG, Cybersécurité nationale et DG, Communications) et de SPC (DG); l’équipe est présidée par le DG, Opérations, SP, et le DE, Sécurité, DDPI, SCT. L’équipe de direction communique avec le GT des DG des communications, présidé par le DG des Communications de SP et comptant des représentants du SCT, du BCP, des ministères touchés, des ministères fournissant un soutien et de SPC. L’axe de communication s’étend ensuite à l’agent de coordination fédéral, aux comités des SMA (CGD et DPI du GC; CDPI, SMA, Opérations, SN et DPI du GC), puis au comité des SM et au comité du Cabinet.

5. Processus de gestion des incidents de sécurité

Le processus de gestion des incidents sera constitué des cinq étapes définies qui suivent (voir la figure 2) : les étapes de la « préparation » et de l'« identification » sont des composants intégrantes d'un plan de gestion des incidents qui doit être mis en place et qui doit être tenu à jour afin de se préparer comme il se doit à la gestion d'un incident. Les trois autres étapes, à savoir l'« intervention », la « reprise » et l'« analyse postérieure à l'incident », seront au centre des préoccupations de la structure directrice.

Figure 2: Étapes de la gestion d'un incident de cybersécurité
Étapes de la gestion d'un incident de cybersécurité. Version textuelle ci-dessous :
Figure 2 - Version textuelle

Le processus de gestion des incidents comporte cinq étapes préparation par le ministère; identification par le ministère; intervention par le ministère; rétablissement par le ministère et analyse postérieure à l’incident par le ministère. L’étape de l’intervention par le ministère comporte un processus parallèle « Intervention PGI TI GC », qui met en lumière le chevauchement des processus ministériels et des processus gouvernementaux. De même, les étapes du rétablissement par le ministère et de l’analyse postérieure à l’incident par le ministère sont assorties des étapes « Rétablissement PGI TI GC » et « Analyse postérieure à l’incident PGI TI GC », respectivement, pour illustrer le chevauchement de ces processus.

Les responsabilités des ministères liés au processus de gestion des incidents sont documentées pour chacune des étapes dans les sections suivantes. Un résumé des responsabilités ministérielles pour toutes les étapes du processus de gestion des incidents figure à l'annexe B.

5.1 Préparation

Figure 3: Étapes de la gestion d'un incident de cybersécurité (Préparation par le ministère)
Étapes de la gestion d'un incident de cybersécurité (Préparation par le ministère). Version textuelle ci-dessous :
Figure 3 - Version textuelle

Le processus de gestion des incidents comporte cinq étapes préparation par le ministère; identification par le ministère; intervention par le ministère; rétablissement par le ministère et analyse postérieure à l’incident par le ministère. L’étape de l’intervention par le ministère comporte un processus parallèle « Intervention PGI TI GC », qui met en lumière le chevauchement des processus ministériels et des processus gouvernementaux. De même, les étapes du rétablissement par le ministère et de l’analyse postérieure à l’incident par le ministère sont assorties des étapes « Rétablissement PGI TI GC » et « Analyse postérieure à l’incident PGI TI GC », respectivement, pour illustrer le chevauchement de ces processus.

Points Saillants - Préparation par le ministère

L'étape de la préparation comporte des activités de formation et de planification de la gestion des incidents conçues pour fournir des capacités suffisantes de déceler et de prévenir les incidents.

Les ministères doivent au moins :

  1. Élaborer et pratiquer des exercices et des activités de formation et de planification de la gestion des incidents afin de favoriser l'identification et une intervention efficace.
  2. Veiller à ce que le plan d'intervention et que les procédures de communication soient bien connus et qu'ils soient facilement accessibles pour tous les membres du personnel de la TI, et qu'ils soient examinés et mis à jour (au besoin) de manière périodique et après un incident.
  3. Identifier leurs systèmes essentiels (activités et opérations) afin de mieux déterminer les niveaux de préjudice et l'incidence au moment de déclarer un événement ou un incident.
  4. Intégrer les processus du PGI TI GC à leur Plan de sécurité ministériel (PSM), à leurs plans d'urgence en TI, et à leurs plans ministériels de sécurité et de continuité des activités.
  5. Assurer la prestation de la formation et de la sensibilisation qui s'imposent à l'identification des incidents, à la politique de gestion des incidents, et aux procédures destinées au personnel de la TI, de façon que toutes les personnes concernées comprennent leurs rôles et leurs responsabilités en ce qui a trait aux incidents.
  6. Veiller à ce qu'une formation de sensibilisation et d'intervention soit offerte à tous les employés, conformément à la menace en cours et à la menace émergente.
  7. Veiller à ce que des mesures normalisées soient définies à l'avance pour une mise en œuvre rapide au besoin.
  8. Surveiller et gérer les configurations des logiciels, du matériel et des micrologiciels, y compris les numéros des versions et le niveau de correctif dans une base de données ministérielle afin de veiller à ce que les ministères puissent déterminer les facteurs de vulnérabilité et agir en conséquence.
  9. Prendre les mesures raisonnables pour assurer la conservation et la protection des preuves (voir l'annexe C).

5.2 Identification

Figure 4: Étapes de la gestion d'un incident de cybersécurité (Identification par le ministère)
Étapes de la gestion d'un incident de cybersécurité (Identification par le ministère). Version textuelle ci-dessous :
Figure 4 - Version textuelle

Le processus de gestion des incidents comporte cinq étapes préparation par le ministère; identification par le ministère; intervention par le ministère; rétablissement par le ministère et analyse postérieure à l’incident par le ministère. L’étape de l’intervention par le ministère comporte un processus parallèle « Intervention PGI TI GC », qui met en lumière le chevauchement des processus ministériels et des processus gouvernementaux. De même, les étapes du rétablissement par le ministère et de l’analyse postérieure à l’incident par le ministère sont assorties des étapes « Rétablissement PGI TI GC » et « Analyse postérieure à l’incident PGI TI GC », respectivement, pour illustrer le chevauchement de ces processus.

Points Saillants - Identification par le ministère

L'étape de l'identification consiste à déceler un événement susceptible de constituer un incident de cybersécurité, d'informer les représentants de la technologie de l'information des systèmes touchés (qui procéderont à l'évaluation initiale visant à déterminer s'il s'agit réellement d'un incident), et de déterminer l'incidence, la gravité et la cause probable de l'incident soupçonné.

Les ministères doivent au moins :

  1. Mener des activités de surveillance et de détection des intrusions (p. ex., suivre et analyser les menaces, les facteurs de vulnérabilité, et les événements à partir des registres de diverses sources comme les murs pare-feu ou les systèmes de détection d'intrusions (IDS), qui peuvent avoir une incidence sur les systèmes ministériels de TI) conformément à la Norme de gestion de la sécurité des technologies de l'information (GSTI). Cela doit aussi inclure un processus proactif de gestion de la vulnérabilité fondé sur des cadres normalisés comme le Common Vulnerability Scoring System (CVSS) du National Institute of Standards and Technology (NIST).
  2. Surveiller l'information provenant de l'Équipe canadienne d'intervention d'urgence en informatique (ECIUI) ou du CECM-GC (p. ex., les rapports d'étape du GC, les demandes d'information (DI), les rapports d'incidents du GC, les rapports de situation en cas d'incident au GC, les avertissements et la connaissance de la situation qui prévaut au GC) et y donneront suite selon le cas.
  3. Communiquer avec l'ECIUI, qui les aidera à caractériser les événements susceptibles d'être suspects.
  4. Une fois qu'il est déterminé qu'un événement pourrait constituer un incident ou qu'il est confirmé qu'il s'agit d'un incident, envoyer un rapport ministériel initial d'incident à l'ECIUI (annexe E) et, quand d'autres renseignements sont connus, soumettre un rapport ministériel d'incident mis à jour.
  5. Les ministères doivent protéger les preuves comme précisé à l'annexe C.

L'information relative à l'incident doit être signalée à l'ECIUI au plus tard une (1) heure après la détection de l'incident. Le Modèle de déclaration d’un incident prévu à l'annexe E doit servir à établir le rapport d'incident. Dans le rapport d'incident, les ministères doivent attribuer un niveau de préjudice et de gravité de l'incidence. Les lignes directrices prévues à l'annexe D permettent d'établir un classement de ces niveaux.

S'il y a lieu, les ministères touchés doivent essayer de rapprocher de nombreux rapports d'incident afin de déterminer ceux qui ont trait à un seul et même incident.

Si l'ECIUI ou le CECM-GC avise le ministère d'un événement important, les ministères seront invités à confirmer si l'événement constitue en fait un incident. Les ministères doivent ensuite répondre en déclarant l'incident au moyen du Modèle de déclaration d’un incident prévu à l'annexe E.

L'ECIUI peut déclencher le processus de gestion des incidents si elle détecte un incident touchant un ou plusieurs ministères.

Classement

Le ministère touché doit attribuer une catégorie à l'incident soupçonné ou confirmé en utilisant le tableau prévu à l'annexe D.

Ordre de priorité

Les ministères touchés doivent établir l'ordre de priorité de l'incidence éventuelle des incidents. L'incidence correspond à l'effet qu'a l'incident sur les objectifs et la mission de l'organisation, en fonction des facteurs suivants :

  • Incidence technique (actuelle et future) : Les effets négatifs courants et les effets futurs probables de l'incident. Par exemple, la propagation d'un maliciel dans un bureau régional a une incidence locale immédiate, mais si le maliciel se répand sur le réseau étendu, il peut toucher les opérations de l'ensemble du ministère.
  • Nécessité des ressources touchées : La nécessité des ressources en systèmes d'information (IS) touchées ou susceptibles d'être touchées par l'incident. Les systèmes essentiels ont été répertoriés dans le cadre des évaluations de l'incidence opérationnelle et d'autres activités de continuité des activités.

5.3 Intervention

Figure 5: Étapes de la gestion d'un incident de cybersécurité (Intervention par le ministère)
Étapes de la gestion d'un incident de cybersécurité (Intervention par le ministère). Version textuelle ci-dessous :
Figure 5 - Version textuelle

Le processus de gestion des incidents comporte cinq étapes préparation par le ministère; identification par le ministère; intervention par le ministère; rétablissement par le ministère et analyse postérieure à l’incident par le ministère. L’étape de l’intervention par le ministère comporte un processus parallèle « Intervention PGI TI GC », qui met en lumière le chevauchement des processus ministériels et des processus gouvernementaux. De même, les étapes du rétablissement par le ministère et de l’analyse postérieure à l’incident par le ministère sont assorties des étapes « Rétablissement PGI TI GC » et « Analyse postérieure à l’incident PGI TI GC », respectivement, pour illustrer le chevauchement de ces processus.

Points Saillants - Intervention par le ministère

Figure 6: Flux de déclaration des incidents (aperçu ministériel)
Flux de déclaration des incidents (aperçu ministériel). Version textuelle ci-dessous :
Figure 6 - Version textuelle

Cette figure comporte trois sections distinctes Ministères/secteurs de responsabilité; Découverte/déclaration des incidents; Connaissance de la situation/intervention.Sous l’en‑tête « Ministères/secteurs de responsabilité Les ministères fédéraux touchés, Sécurité publique ou d’autres partenaires font rapport à l’ECIUI du GC. Les autres ministères ainsi que le SCT sont inclus dans une optique de conscientisation situationnelle. L’ECIUI du GC partage ensuite cette information avec le CEMC du GC, la GRC et le SCRS ainsi que le MDN/FC. Sous l’en‑tête « Découverte/déclaration des incidents » :

L’ECIUI du GC consignera l’information, ce qui sera suivi d’un plan d’action puis de l’étape de l’étude des tendances et de la conscientisation à l’égard de la situation. Le CECM du GC procédera à la détection proactive des incidents et demandera aux ministères concernés de confirmer les incidents. À partir du moment où un incident est confirmé, l’information est transmise à l’ECIUI du GC par le ministère concerné. L’information que l’ECIUI du GC ou le CECM du GC transmet à la GRC, au SCRS et au MDN/FC fera l’objet d’une évaluation et donnera lieu à une enquête si la chose est justifiée. À partir de l’information consignée, des plans d’action reçus puis de l’étude des tendances et de la conscientisation à l’égard de la situation, l’information peut être transmise à l’UIC (ce qui correspond à la section relative à la connaissance de la situation et à l’intervention). Le flux informationnel va ensuite de l’UIC aux étapes « Confinement/atténuation » « Reprise » et « Leçons apprises ». L’étape de l’étude des tendances et de la conscientisation à l’égard de la situation a trait aux autres ministères et au SCT.

Une fois qu'un événement est signalé par un ministère ou un partenaire touché, Sécurité publique ou le CECM-GC, l'ECIUI se charge d'envoyer un accusé de réception. S'il est déterminé qu'il s'agit bel et bien d'un incident, l'ECIUI évaluera les renseignements reçus afin de déterminer si l'incident est de nature informatique ou cybernétique et fournira les orientations et les conseils qui s'imposent en matière d'atténuation au(x) service(s) concerné (s) et alertera d'autres ministères de la menace. Il sera également responsable de les aviser quant à la façon de se protéger contre cet incident. Si l'incident est lié à la cybersécurité, l'ECIUI fournira également ces renseignements au CECM-GC à des fins d'analyse. L'ECIUI du GC fournira également un résumé des incidents sur une base régulière à la DDPI du SCT afin qu'elle soit consciente de la situation. Selon la catégorisation des incidents (annexe D), l'incident sera traité en conséquence, tel que précisé ci-dessous.

Si l'incident est réputé à être à risque faible :

  • Les renseignements seront inscrits et la situation sera surveillée dans le cadre du plan de connaissance de la situation. Ils seront aussi comparés à ceux d'événements antérieurs (même ceux qui sont réputés être à faible risque).

Si la situation est réputée être à risque moyen à élevé :

  • S'il est déterminé que l'incident est de nature non cybernétique, l'information sera fournie à l'équipe de direction à des fins d'examen. Celle-ci sera responsable de prendre les mesures qui s'imposent si cela est justifié.
  • Les renseignements seront fournis au SCT de façon que la gestion des incidents de sécurité soit effectivement coordonnée avec les ministères et l'ensemble de l'administration fédérale.
  • Les renseignements seront relayés à l'UTC pour y être évalués. Si une enquête est jugée nécessaire par la GRC ou le SCRS, le CECM-GC et l'ECIUI en seront informés immédiatement.
  • Si un incident a des répercussions pour la défense, les renseignements seront relayés au ministère de la Défense nationale/Forces canadiennes (MDN/FC). Si une enquête est jugée nécessaire par le MDN/FC, le CECM-GC et l'ECIUI en seront informés immédiatement.
  • Pendant qu'une enquête est en cours, la partie qui enquête peut fournir des renseignements au CECM-GC, à l'ECIUI ou à l'UIC aux fins d'atténuation.

L'UIC observera les procédures opérationnelles normalisées.

L'UIC vise principalement à fournir des conseils d'atténuation aux ministères touchés et à prévenir les autres ministères de la menace et les aider à se protéger contre celle-ci.

Si l'on n'arrive pas à confiner le problème au niveau ministériel, l'ECIUI dirigera les efforts de confinement selon les procédures établies.

Les ministères peuvent en tout temps mettre à jour leur rapport d'incident afin de fournir des renseignements additionnels à l'ECIUI ou demander d'autres conseils d'atténuation.

Les événements de menace et de vulnérabilité sont communiqués en escalade par l'ECIUI ou le SCT à l'UIC, quand le risque est élevé pour le GC.

Figure 7: Flux de déclaration ascendante des incidents
Flux de déclaration ascendante des incidents. Version textuelle ci-dessous :
Figure 7 - Version textuelle

Au départ, Sécurité publique, les partenaires et les ministères concernés signalent l’incident à l’ECIUI du GC. Cela correspond au niveau 1 (« Les mesures normalisées de protection et de surveillance sont généralement suffisantes, mais des mesures de sécurité accrues peuvent être requises.

  • Classement de l’incident préjudice faible/incidence faible ») et à l’étape « Événement » (« Coordination courante et continue des activités. L’événement est contrôlé par le ministère touché. Aucune aide supplémentaire n’est requise »). L’information reçue par l’ECIUI peut être transmise au CECM du GC et à l’UIC, ce qui correspond au niveau 2 (« Les mesures d’atténuation doivent être coordonnées rapidement dans le cadre des opérations courantes
  • Classement de l’incident préjudice moyen/incidence moyenne ») et à l’étape « Triage initial, coordination des incidents » (« L’UIC peut être appelée et commencer à planifier la préparation en vue d’une déclaration ascendante. L’UIC doit rédiger/mettre en œuvre un plan d’action en cas d’incident et informer l’équipe de direction de la situation »). L’information peut ensuite passer à l’équipe de la direction et au GT des DG des Communications, soit le niveau 3 (« L’atténuation est possible moyennant une attribution importante de ressources
  • Classement de l’incident préjudice élevé /incidence moyenne; préjudice moyen/incidence élevée ») et à l’étape « Les autorités doivent attribuer des ressources et adopter des mesures » (« L’équipe de direction doit fournir une orientation et approuver le plan d’action en cas d’incident »). Si une orientation additionnelle est requise, l’information est transmise aux comités des SMA (CGD et DPI du GC; CDPI, SMA, Opérations de SN, et DPI du GC), puis au comité des SM et, ultimement, au comité du Cabinet. Cela correspond au niveau 4 (« Aucune mesure d’atténuation connue de disponible ni aucune intervention majeure requise
  • Classement de l’incident préjudice élevé/incidence élevée ») et à l’étape « Intervention nationale » (« Leadership du Comité du Cabinet chargé des opérations, Comité des sous‑ministres sur la sécurité nationale ou CGE SMA/Opérations de SN SMA et CDPI du GC »).

L'équipe de direction est le groupe décisionnel qui doit dispenser des conseils et intervenir quand les tentatives de rétablissement des services n'ont pas produit les résultats escomptés ou quand aucune mesure adoptée/conçue ne permet d'assurer la continuité des opérations et le rétablissement rapide des services. L'équipe de direction a le pouvoir de prendre les décisions importantes qui sont nécessaires en temps de crise : déclenchement d'un service de reprise en cas de catastrophe, approbation de budgets spéciaux, etc. En outre, si les mesures d'atténuation requièrent des ressources additionnelles, l'équipe de direction sera appelée à examiner le plan d'action de l'UIC et à agir en conséquence.

Une orientation plus concise est en cours d'élaboration et sera terminée d'ici juin 2012. Entre temps, ces catégories d'incidents (annexe D) peuvent être utilisées.

5.4 Rétablissement

Figure 8: Étapes de la gestion d'un incident de cybersécurité (Rétablissement par le ministère)
Étapes de la gestion d'un incident de cybersécurité (Rétablissement par le ministère). Version textuelle ci-dessous :
Figure 8 - Version textuelle

Le processus de gestion des incidents comporte cinq étapes préparation par le ministère; identification par le ministère; intervention par le ministère; rétablissement par le ministère et analyse postérieure à l’incident par le ministère. L’étape de l’intervention par le ministère comporte un processus parallèle « Intervention PGI TI GC », qui met en lumière le chevauchement des processus ministériels et des processus gouvernementaux. De même, les étapes du rétablissement par le ministère et de l’analyse postérieure à l’incident par le ministère sont assorties des étapes « Rétablissement PGI TI GC » et « Analyse postérieure à l’incident PGI TI GC », respectivement, pour illustrer le chevauchement de ces processus.

Points Saillants - Rétablissement par le ministère

La plupart des incidents nécessitent l'adoption de mesures de reprise afin de rétablir le fonctionnement normal des systèmes et des services, et l'adoption de mesures préventives afin d'éviter que les problèmes ne se reproduisent. Parmi les mesures de reprise, mentionnons le rétablissement des systèmes à partir des supports ou des images d'origine, l'installation de correctifs et l'adoption de mesures d'atténuation immédiates afin de prévenir la réapparition du problème. Le rétablissement des systèmes/services doit être effectué d'une manière qui préserve l'intégrité du système afin de favoriser une enquête/analyse approfondie de l'incident.

Le processus de rétablissement doit être harmonisé avec les processus internes ministériels suivants : Gestion des incidents, Gestion des problèmes, Gestion du changement, Gestion de la configuration, et Gestion des versions.

Si un ministère ne réussit pas à se relever rapidement de l'incident, il peut faire appel à l'Équipe d'intervention en cas d'incident de sécurité des TI Footnote 1 (EIISTI) de SPC, et à l'Arrangement en matière d'approvisionnement en cyberprotection (AMAC).

Avant de rebrancher les systèmes ou de rétablir les services touchés, les responsables des incidents doivent veiller à ce que le rétablissement du système ou du service n'entraîne pas un nouvel incident.

Les ministères doivent au moins :

  • Donner suite aux produits d'information électronique de l'ECIUI et du CECM-GC au besoin. (bulletins sur les cyberincidents, demandes d'information, etc.)
  • Dans la mesure du possible, mettre en œuvre les mesures d'atténuation pertinentes au GC qui sont recommandées/mandatées par l'ECIUI, le CECM-GC ou la DDPI du SCT.
  • Fournir des comptes rendus de situation aux diverses étapes de l'incident et présenter un avis final à l'ECIUI une fois que les opérations sont revenues à la normale.

5.5 Analyse postérieure à l'incident

Figure 9: Étapes de la gestion d'un incident de cybersécurité (Analyse postérieure à l'incident par le ministère)
Étapes de la gestion d'un incident de cybersécurité (Analyse postérieure à l'incident par le ministère). Version textuelle ci-dessous :
Figure 9 - Version textuelle

Le processus de gestion des incidents comporte cinq étapes préparation par le ministère; identification par le ministère; intervention par le ministère; rétablissement par le ministère et analyse postérieure à l’incident par le ministère. L’étape de l’intervention par le ministère comporte un processus parallèle « Intervention PGI TI GC », qui met en lumière le chevauchement des processus ministériels et des processus gouvernementaux. De même, les étapes du rétablissement par le ministère et de l’analyse postérieure à l’incident par le ministère sont assorties des étapes « Rétablissement PGI TI GC » et « Analyse postérieure à l’incident PGI TI GC », respectivement, pour illustrer le chevauchement de ces processus.

Points Saillants - Analyse postérieure à l'incident par le ministère

L'analyse postérieure aux incidents est essentielle aux fins de l'apprentissage et de l'amélioration continue des mesures de protection, des procédures et des plans d'intervention du GC. L'examen des leçons à retenir des rapports d'incidents, la recommandation de modifications à apporter aux processus et aux procédures, et l'élaboration de solutions à long terme visant à améliorer les capacités sont essentiels au succès de l'étape de préparation.

Pour chaque incident majeur :

Les ministères doivent effectuer une analyse postérieure à l'incident dans laquelle ils résument les effets de l'incident, et ils énoncent :

  • les lacunes au chapitre de la protection;
  • les mesures qui empêcheront ce type d'incident de se reproduire;
  • les mesures permettant de réduire l'incidence d'une récurrence;
  • les améliorations à apporter aux procédures de traitement des incidents et aux politiques connexes;
  • l'étape de préparation pour ce qui est de l'intervention face à l'incident;
  • les leçons à retenir.

Les ministères touchés fourniront à l'ECIUI un résumé de l'analyse postérieure à l'incident. Le SCT conservera ces rapports.

La DDPI du SCT conclura l'étape de l'analyse postérieure à l'incident du PGI TI GC en fonction de la mise en œuvre de mesures d'atténuation.

En ce qui a trait aux incidents touchant plusieurs ministères, la DDPI du SCT dirigera l'analyse postérieure à l'incident ainsi que la mise en œuvre des modifications/améliorations à apporter.

6. Rôles et responsabilités ministériels

La présente section cerne les rôles et les responsabilités concernant le PGI TI GC du ministère.

Il incombe à l'agent de sécurité ministériel (ASM) :

  • D'établir des exigences de production de rapports sur les incidents de sécurité de la TI qui correspondent aux exigences établies dans le PGI TI GC dans le cadre de l'adoption d'une approche coordonnée en matière de gestion des incidents de sécurité ministériels.

Il incombe au coordonnateur ministériel de la sécurité de la TI :

  • De veiller à ce que des processus efficaces de gestion des incidents de sécurité de la TI soient élaborés, documentés, approuvés, promulgués et mis en œuvre au ministère, et que l'efficacité de ces processus soit surveillée.
  • De produire des rapports sur les incidents de sécurité de la TI décelés, conformément aux exigences établies par l'ASM.

Il incombe aux spécialistes de la sécurité et aux membres du personnel opérationnel de la TI :

  • De donner suite aux incidents de sécurité de la TI, conformément aux processus et aux procédures établis par le ministère.

Il incombe à tous les employés du ministère :

  • De rapporter les incidents de sécurité de la TI réels ou soupçonnés ou toute autre activité suspecte à des fonctionnaires du ministère, conformément aux processus et aux procédures établis par le ministère.

7. Rôles et responsabilités d'autres organisations gouvernementales

7.1 Équipe canadienne d'intervention d'urgence en informatique

Le rôle de l'Équipe canadienne d'intervention d'urgence en informatique (ECIUI) consiste à coordonner l'identification, l'atténuation, le rétablissement et l'analyse postérieure aux incidents de la TI au gouvernement du Canada.

7.2 Centre d'évaluation des cybermenaces du gouvernement du Canada

Le Centre d'évaluation des cybermenaces du gouvernement du Canada (CECM-GC), au sein du Centre de la sécurité des télécommunications du Canada (CSTC), appuie l'identification, l'évaluation des risques, le rétablissement et l'analyse postérieure aux incidents de cybersécurité, au gouvernement du Canada, qui sont liés aux cas de menace ou d'utilisation malveillante de la TI et qui sont susceptibles de toucher la confidentialité, l'intégrité ou la disponibilité des systèmes d'information, leur utilisation ou l'utilisation des renseignements qu'ils renferment.

7.3 Sécurité publique Canada – Centre canadien de réponse aux incidents cybernétiques

Sécurité publique – Rôle du CCRIC est de conseiller l'ECIUI ou le gouvernement, et il a été identifié comme infrastructure essentielle.

7.4 Unité de triage des cyberincidents

Le rôle de l'Unité de triage des cyberincidents (UTC) consiste à déterminer si une enquête du Service canadien de renseignement de sécurité (SCRS) ou de la Gendarmerie royale du Canada (GRC) est justifiée, ou si cette enquête est déjà en cours.

7.5 Unité d'intervention en cas de cyberincidents

Une fois déclenché, le rôle de l'Unité d'intervention en cas de cyberincidents (UIC) consiste à diriger ou à faciliter, ou les deux, l'intervention visant à atténuer l'incidence des incidents de cybersécurité pour le gouvernement du Canada en cas de besoin.

La nature de l'incident déterminera la composition de l'UIC. L'équipe sera constituée de membres de Services partagés Canada (SPC), de Sécurité publique (SP), du SCRS, du ministère de la Défense nationale/des Forces canadiennes (MDN/FC), du CSTC, de la GRC, et du Secrétariat du Conseil du Trésor (SCT) selon le cas.

7.6 Secrétariat du Conseil du Trésor - Direction du dirigeant principal de l'information

Le rôle du Secrétariat du Conseil du Trésor consiste est un rôle de surveillance et d'orientation. Il incombe au SCT de veiller à ce que la gestion des incidents de sécurité soit coordonnée comme il se doit à l'échelle des ministères et du gouvernement. Il lui revient également de surveiller la mise en œuvre de la Politique sur la sécurité du gouvernement et des directives et normes connexes.

Figure 10: Domaine de responsabilité pour les incidents de TI
Domaine de responsabilité pour les incidents de TI. Version textuelle ci-dessous :
Figure 10 - Version textuelle

Il y a deux sections distinctes. Celle de gauche comporte l’en‑tête « Les provinces et les territoires, les partenaires internationaux, industrie, infrastructures essentielles ». Il y a en dessous un cercle avec la mention « SP (CCRIC) » puis « coordination nationale de réponse aux incidents ». Des flèches relient les deux sections avec la mention « Infrastructure de TI intégrée [sic] ».

L’en‑tête de la section de droite est « Gouvernement du Canada ». Il y a ensuite un encadré comportant comme titre « SCT – Surveillance et direction » puis les points « Surveillance », « Coordination » et « L’analyse après incident ». Un peu plus bas, il y a un grand cercle contenant un cercle plus petit. Le grand cercle a comme titre « Incidents informatiques – ECIUI du GC », ce qui est suivi du point suivant « Centre de coordination central [sic] pour les incidents de TI du GC ». On retrouve dans le cercle plus petit les mots suivants « Incidents cybernétiques – CST (CECM) (cyberincident concentré) ».

8. Demandes de renseignements

Veuillez adresser vos questions au sujet du présent Plan à votre ASM. Aux fins de l'interprétation du présent Plan, l'ASM doit communiquer avec la :

Division de la sécurité, Direction du dirigeant principal de l'information
Secrétariat du Conseil du Trésor du Canada
2745, rue Iris
Ottawa (Ontario)  K1A 0R5

Courriel : sec@tbs-sct.gc.ca
Téléphone : 613-957-2549
Télécopieur : 613-946-4334

Annexe A – Définitions

Cyberincident :
Incident de TI délibéré qui est parrainé par un État ou qui exploite une faille informatique non connue du public.
Événement :
Changement observable du fonctionnement habituel d'un système, d'un environnement, d'un processus, du flux des travaux, ou du comportement d'une personne. Un événement peut déboucher sur un incident, mais l'inverse ne peut se produire.
Incidents de TI :
Tout événement ou série d'événements susceptible de toucher la confidentialité, l'intégrité, ou la disponibilité d'un système d'information, y compris ses composantes, ou un événement ou une série d'événements qui peut enfreindre la loi ou les politiques relatives aux systèmes d'information. Les incidents peuvent trouver leur origine de manière interne ou externe, et ils peuvent être délibérés ou fortuits. Les incidents incluent les atteintes à la vie privée, à savoir la collecte, l'utilisation, la communication, l'accès, la conservation ou l'élimination de renseignements personnels, délibérés ou fortuits, qui ne sont pas autorisés aux termes de la Loi sur la protection des renseignements personnels.
Responsable du traitement des incidents :
La personne qui est nommée ou qui est responsable de diriger toutes les étapes du traitement des incidents. Le responsable du traitement des incidents sera la personne-ressource de l' ECIUI tout au long du cycle de vie de l'incident.

Annexe B – Résumé des obligations ministérielles

Les ministères doivent élaborer et pratiquer des exercices et des activités de formation et de planification de la gestion des incidents afin de favoriser l'identification et une intervention efficace.

Les ministères doivent veiller à ce que le plan d'intervention et que les procédures de communication soient bien connus et qu'ils soient facilement accessibles pour tous les membres du personnel de la TI, et qu'ils soient examinés et mis à jour (au besoin) de manière périodique et après un incident.

Les ministères doivent identifier leurs systèmes essentiels (activités et opérations) afin de mieux identifier les niveaux de préjudice et l'incidence au moment de déclarer un événement ou un incident.

Les ministères doivent intégrer les processus du PGI TI GC à leur Plan de sécurité ministériel (PSM), à leurs plans d'urgence en TI, et à leurs plans ministériels de sécurité et de continuité des activités.

Les ministères doivent veiller à ce qu'une formation de sensibilisation et d'intervention soit offerte à tous les employés, conformément à la menace en cours et à la menace émergente.

Les ministères doivent assurer la prestation de la formation et de la sensibilisation qui s'imposent à l'identification des incidents, à la politique de gestion des incidents, et aux procédures destinées au personnel de la TI, de façon que toutes les personnes concernées comprennent leurs rôles et leurs responsabilités en ce qui a trait aux incidents.

Les ministères doivent veiller à ce que des mesures normalisées soient définies à l'avance pour une mise en œuvre rapide au besoin.

Les ministères doivent surveiller et gérer les configurations des logiciels, du matériel et des micrologiciels, y compris les numéros des versions et le niveau de rustine dans une base de données ministérielle afin de veiller à ce que les ministères puissent déterminer les facteurs de vulnérabilité et agir en conséquence.

Les ministères doivent prendre les mesures raisonnables pour assurer la conservation et la protection des preuves (voir l'annexe C).

Les ministères doivent mener des activités de surveillance et de détection des intrusions (p. ex., suivre et analyser les menaces, les facteurs de vulnérabilité, et les événements à partir des registres de diverses sources comme les murs pare-feu ou les systèmes de détection d'intrusions (IDS), qui peuvent avoir une incidence sur les systèmes ministériels de TI) conformément à la Norme de gestion de la sécurité des technologies de l'information (GSTI). Cela doit aussi inclure un processus proactif de gestion de la vulnérabilité fondé sur des cadres normalisés comme le Common Vulnerability Scoring System (CVSS) du National Institute of Standards and Technology (NIST).

Les ministères doivent communiquer avec l'ECIUI, qui les aidera à caractériser les événements susceptibles d'être suspects.

Les ministères doivent surveiller l'information provenant de l'ECIUI ou du CECM-GC (p. ex., les rapports d'étape du GC, les demandes d'information (DI), les rapports d'incidents du GC, les rapports de situation en cas d'incident au GC, les avertissements et la connaissance de la situation qui prévaut au GC) et y donneront suite selon le cas.

Les ministères doivent, une fois qu'il est déterminé qu'un événement pourrait constituer un incident ou qu'il est confirmé qu'il s'agit d'un incident, envoyer un rapport ministériel initial d'incident à l'ECIUI (annexe E) et, quand d'autres renseignements sont connus, soumettre un rapport ministériel d'incident mis à jour.

Les ministères doivent protéger les preuves comme précisé à l'annexe C.

Les ministères doivent donner suite aux produits d'information électronique de l'ECIUI et du CECM-GC au besoin (bulletins sur les cyberincidents, demandes d'information, etc.).

Les ministères doivent, dans la mesure du possible, mettre en œuvre les mesures d'atténuation pertinentes au GC qui sont recommandées/mandatées par l'ECIUI, le CECM-GC ou la DDPI du SCT.

Les ministères doivent fournir des comptes rendus de situation aux diverses étapes de l'incident et présenter un avis final à l'ECIUI une fois que les opérations sont revenues à la normale.

Les ministères doivent effectuer une analyse postérieure à l'incident dans laquelle ils résument les effets de l'incident, et ils énoncent :

  • les lacunes au chapitre de la protection;
  • les mesures qui empêcheront ce type d'incident de se reproduire;
  • les mesures permettant de réduire l'incidence d'une récurrence;
  • les améliorations à apporter aux procédures de traitement des incidents et aux politiques connexes;
  • l'étape de préparation pour ce qui est de l'intervention;
  • les leçons à retenir.

Les ministères touchés fourniront à l'ECIUI un résumé de l'analyse postérieure à l'incident.

Annexe C – Conservation des preuves

Aperçu des mesures de base de conservation de preuves pour les membres du personnel de la TI

Étape 1

Une fois qu’un incident a été décelé, les responsables du traitement des incidents doivent

Veiller à ce que les appareils infectés ne soient plus accessibles au personnel non autorisé (c.-à-d. qu’ils ne soient accessibles qu’aux responsables du traitement des incidents – maintien de la chaîne de possession)

Veiller à ce qu’il n’y ait aucune tentative d’explorer le contenu des appareils infectés ou de récupérer des données qui y sont stockées.

Les responsables du traitement des incidents doivent aussi consigner

  • Le moment auquel l’incident a été découvert.
  • Les circonstances dans lesquelles l’incident a été découvert.
  • L’identité de la personne ayant découvert l’incident.

Étape 2

La personne responsable du traitement des incidents doit conserver les preuves en adoptant les mesures suivantes

  • Veiller à ce que les appareils infectés demeurent en fonction, de façon que la mémoire vive puisse être recueillie.
  • Consigner tous les processus en marche sur les appareils infectés.
  • Consigner toutes les connexions matérielles entre les appareils infectés et tous les autres dispositifs.
  • Consigner toutes les adresses IP et les connexions sans-fil en provenance et à destination des appareils infectés sur l’ensemble du réseau.
  • Conserver tous les registres de trafic (pare-feu, IDS, IPS, HIDS, etc.) en provenance et à destination des appareils infectés sur l’ensemble du réseau.
  • Au moment de débrancher les appareils infectés du réseau, surveiller de près les processus afin de veiller à ce que le disque dur ne soit pas effacé. Si des données sont supprimées, il faut immédiatement éteindre l’appareil.

Étape 3

Après avoir conservé les registres du réseau et avoir protégé la chaîne de possession de la preuve, les responsables du traitement des incidents doivent adopter les mesures qui suivent

  • Consigner toutes les mesures liées à la collecte, à la conservation, à l’accès, au stockage et au transfert des preuves numériques.
  • Préparer un diagramme du réseau contenant les adresses IP de tous les appareils infectés et de tous les autres nœuds pertinents du réseau.
  • Préparer, dater et signer des notes détaillées au sujet de toutes les mesures adoptées dans le cadre de l’intervention.
  • Communiquer toutes les observations présentées et les mesures adoptées aux enquêteurs des forces de l’ordre.

Les intervenants doivent s’assurer d’être autorisés par la loi à collecter et à conserver tous les renseignements recueillis dans le cadre du processus d’intervention. Ils sont aussi responsables de toutes les mesures adoptées à l’égard des preuves numériques.

Annexe D – Classement des incidents

Étape 1 L'incident est survenu; définissez le degré de préjudice et le secteur en vous servant du guide ci-après.

Secteur Degré de préjudice
Faible Moyen Élevé
Santé et sécurité Aucune menace pour la santé ou la sécurité. Menace limitée à modérée pour la santé ou la sécurité. Menace importante pour la santé ou la sécurité; peut inclure un danger de mort.
Confiance du public envers le gouvernement du Canada Perte limitée ou nulle de la confiance du public ou incidence négative limitée ou nulle sur la réputation du GC. Perte modérée de la confiance du public ou incidence négative modérée sur la réputation du GC. Importante perte de la confiance du public ou incidence négative majeure sur la réputation du GC.
Prestation de services/ infrastructure essentiels Effet limité ou nul sur la prestation des services ou l'infrastructure essentiel(le)(s). Effet négatif modéré sur la prestation des services ou l'infrastructure essentiel(le)(s). Effet négatif important sur la prestation des services ou l'infrastructure essentiel(le)(s).
Productivité/aspect financier Effet négatif limité ou nul sur la productivité ou l'aspect financier. Effet négatif modéré sur la productivité ou l'aspect financier. Effet négatif important sur la productivité ou l'aspect financier.

Étape 2 Définissez l'incidence de l'incident en vous servant du guide ci-après.

Incidence Description
Faible
  • Incidence sur un seul poste de travail, appareil mobile/portable
  • L'incident touche de 1 à 4 % des utilisateurs
  • Incidence sur des renseignements Protégés A ou non classifiés
Moyenne
  • Incidence sur un serveur ou un compte d'administrateur
  • Incidence sur un grand nombre de postes de travail (au moins 10), d'appareils mobiles/portables (ou celui d'un fonctionnaire de haut niveau)
  • L'incident touche 5-9 % des utilisateurs
  • Incidence sur des renseignements Protégés B ou confidentiels
Élevée
  • Incidence sur un appareil d'infrastructure, comme un routeur 
  • Incidence sur au moins deux serveurs (ou un serveur de courriel, tel qu'indiqué dans votre évaluation de l'incidence opérationnelle)
  • L'incident touche 10 % ou plus des utilisateurs
  • Incidence sur des renseignements Protégés C ou Très secrets (à ne déclarer qu'au moyen de méthodes sécurisées)
  • Atteinte à la vie privée

Annexe E – Modèle de déclaration d’un incident

Si vous avez besoin d’aide pour déclarer un incident, veuillez communiquez avec la Division de la sécurité et gestion de l’identité.

1.0 Entité déclarante

  • Nom de l'organisation :

2.0 Coordonnées de la personne-ressource

  • Prénom :
  • Nom :
  • Numéro de téléphone :
    • Téléphone cellulaire
    • Télécopieur
  • Téléavertisseur :
  • Adresse courriel :
  • Initiales
  • Poste
  • Adresse du bureau

3.0 Description de l’incident, y compris le degré de préjudice et l’incidence

  • Date et heure de l’incident : (date, heure et fuseau horaire)
  • Emplacement touché par l’incident (si plusieurs emplacements sont touchés, prière de les indiquer)
  • Secteur/degré de préjudice estimatif
  • Incidence estimative
  • Durée de l’incident (si l’incident est terminé; sinon, préciser « continu »)
  • Nombre estimatif de systèmes touchés
  • Pourcentage de systèmes ministériels touchés
  • Brève description de l’incident
  • Mesures adoptées (inclure la date et l’heure dans la mesure du possible)
  • Pièces justificatives jointes (décrire, le cas échéant)
  • Priorité (en cas de déclaration de multiples incidents) (décrire, le cas échéant)

4.0 Statut des mesures d'atténuation

  • Détails des mesures d'atténuation adoptées jusqu'ici (énumérer les mesures qui ont été prises pour atténuer l'incident, et par qui)
  • Résultat des mesures d'atténuation :
  • Aide additionnelle requise?
    • OUI/NON

5.0 Type d'incident

  • Code malveillant ver informatique, virus, cheval de Troie, porte dérobée, programme malveillant furtif
  • Exploitation connue d'un facteur de vulnérabilité (préciser le numéro d'évaluation de CVE pour les facteurs de vulnérabilité connus)
  • Compromission de système : modification de registres, modification de l'information DNS
  • Compromission de données destruction de données, modification de données, dégradation de sites Web
  • Déni de service déni de service (DoS) ou déni de service distribué (DdoS)
  • Violations d'accès tentative d'accès non autorisé, réussite d'accès non autorisée, perçage de mot de passe
  • Accident ou erreur bris de matériel, erreur d'opérateur, erreur d'utilisateur, causes naturelles ou accidentelles
  • Autres ou inconnus

6.0 Systèmes touchés

  • Zone réseau touchée : Internet, zone démilitarisée (DMZ), administration, interne, enclave
  • Type de système touché serveur de fichiers, serveur Web, serveur courriel, base de données, poste de travail, autres (prière de préciser)
  • Système d'exploitation (préciser la version) Windows, Linux, Unix, MacOS, OS/390, autres (prière de préciser)
  • Protocoles ou services (énumérer tous ceux qui s'appliquent)
  • Application (inclure les versions précises)

7.0 Origine manifeste de l'incident ou de l'attaque

  • Adresse IP et port d'origine :
    • Adresse URL : (le cas échéant)
  • Protocole:
    • Maliciel : (le cas échéant)

Annexe F – Plan de transition

Figure 11: Secteurs de responsabilité des incidents de TI - en cours
Secteurs de responsabilité des incidents de TI - en cours. Version textuelle ci-dessous :
Figure 11 - Version textuelle

Il y a deux sections distinctes. Celle de gauche comporte l’en‑tête « Les provinces et les territoires, les partenaires internationaux, industrie, infrastructures essentielles ». Il y a en dessous un cercle avec la mention « SP (CCRIC) » puis « coordination nationale de réponse aux incidents ». Des flèches relient les deux sections avec la mention « Infrastructure de TI intégrée [sic] ».

L’en‑tête de la section de droite est « Gouvernement du Canada ». Il y a ensuite un encadré comportant comme titre « SCT – Surveillance et direction » puis les points « Surveillance », « Coordination » et « L’analyse après incident ». Un peu plus bas, il y a un grand cercle contenant un cercle plus petit. Le grand cercle a comme titre « Incidents informatiques – ECIUI du GC », ce qui est suivi des mots « (CST/CECM‑GC) » et du point suivant « Centre de coordination central [sic] pour les incidents de TI du GC ». On retrouve dans le cercle plus petit les mots suivants « Incidents cybernétiques – CST (CECM) (cyberincident concentré) ».

Le Centre d'évaluation des cybermenaces (CECM-GC) du gouvernement du Canada, au CSTC, est l'actuelle équipe canadienne d'intervention d'urgence en informatique (ECIUI) des ministères et organismes fédéraux. Tous les incidents doivent être déclarés au CECM-GC jusqu'à ce que Services partagés Canada (SPC) assume le rôle de l'ECIUI (en octobre 2013). Dans un effort visant à réduire le double emploi, les services seront fournis par diverses organisations du GC, et le SCT collabore avec les parties prenantes afin d'établir des procédures opérationnelles ministérielles à l'appui du PGI TI GC.

Figure 12: Secteurs de responsabilité des incidents de TI - état final (octobre 2013)
Secteurs de responsabilité des incidents de TI - état final (octobre 2013). Version textuelle ci-dessous :
Figure 12 - Version textuelle

Il y a deux sections distinctes. Celle de gauche comporte l’en‑tête « Les provinces et les territoires, les partenaires internationaux, industrie, infrastructures essentielles ». Il y a en dessous un cercle avec la mention « SP (CCRIC) » puis « coordination nationale de réponse aux incidents ». Des flèches relient les deux sections avec la mention « Infrastructure de TI intégrée [sic] ».

L’en‑tête de la section de droite est « Gouvernement du Canada ». Il y a ensuite un encadré comportant comme titre « SCT – Surveillance et direction » puis les points « Surveillance », « Coordination » et « L’analyse après incident ». Un peu plus bas, il y a un grand cercle contenant un cercle plus petit. Le grand cercle a comme titre « Incidents informatiques – ECIUI du GC (SPC) », ce qui est suivi du point suivant « Centre de coordination central [sic] pour les incidents de TI du GC ». On retrouve dans le cercle plus petit les mots suivants « Incidents cybernétiques – CST (CECM) (cyberincident concentré) ».

Signaler un problème ou une erreur sur cette page
Veuillez sélectionner toutes les cases qui s'appliquent :

Merci de votre aide!

Vous ne recevrez pas de réponse. Pour toute question, contactez-nous.

Date de modification :