Plan de réponse aux incidents de [Nom de l’organisation]

Ce processus décrit comment [Nom de l'organisation] réceptionne et répond aux incidents de sécurité informatique. Ce processus établit la façon dont les incidents sont assignés, analysés, gérés, remontés, clos et passés en revue pour en tirer des leçons.

Réception et assignation des incidents

Chaque fois qu’un incident est reçu, la personne qui traite de ce cas est responsable de la réponse initiale et de s'assurer du suivi de ce cas. Cette première réponse doit être fournie le plus vite possible, et doit toujours être proposée dans les [délais définis par l’accord de niveau de service SLA du CASNSC].

Le/La chargé·e de cas est responsable de l'analyse et de la réponse à l'incident. Les critères pour définir le/la chargé·e de cas doivent tenir compte des aspects suivants :

• Priorité du cas
• Langue du cas / langues parlées par les personnes traitant de l'incident
• Charge de travail des personnes traitant des incidents
• Situation géographique du/de la bénéficiaire / fuseau horaire
• Compétences requises pour résoudre l'incident

Les responsables d’équipe ont la responsabilité d’équilibrer la charge de travail au sein et entre bureaux. Si nécessaire, une personne traitant d’un incident peut demander que le cas soit assigné à quelqu'un·e d’autre, si le nouveau/la nouvelle chargé·e de cas est mieux adapté·e à la gestion de l'incident en cours. Ceci peut être fait en accord avec le/la chargé·e de cas actuel·le et le/la futur·e chargé·e de cas. Le cas échéant, le/la bénéficiaire doit également être informé·e de ce changement.

Assignation des priorités dans les cas

La priorité du cas fait référence à une valeur assignée à chaque cas. Les priorités aident les chargé·es de cas et en général, le/la responsable des équipes du CASNSC à allouer la quantité adéquate de ressources à chaque cas. Elles définissent également l’ordre dans lequel les cas doivent être résolus. La priorité reflète la réponse organisationnelle requise pour chaque demande.

Parmi les variables impliquées dans la priorisation, l'impact et l’urgence sont les plus importantes.

1. Impact pour la personne bénéficiaire.

Dans les situations où la personne bénéficiaire est en danger, physiquement ou numériquement, et où le fait de ne pas agir a de graves conséquences, le cas doit être traité en considérant les conséquences et effets possibles sur le problème et la solution qui peut être proposée. L’impact d’un cas a trois catégories : élevé, modéré et faible.

Retrouvez ci-dessous un tableau pour vous guider dans l’établissement de l'impact du cas :

Catégorie	Description
Élevé (E)	- Quelqu’un·e a été blessé·e ou a été menacé·e de l’être - Le/La bénéficiaire fait face à une situation réactive/dangereuse - Il existe un haut risque de compromission d'informations sensibles - Les informations personnelles de plusieurs bénéficiaires sont susceptibles d’être compromises - La réputation du centre d’assistance risque d’être sérieusement entachée si la situation n’est pas correctement gérée - La personne bénéficiaire pourrait être une personne haut placée/d’une certaine notoriété
Modéré (M)	- La valeur des conséquences de l'incident peut être définie comme intermédiaire, entre faible et élevée.
Faible (F)	- Le cas vise à prévenir tout futur incident de sécurité pour l'organisation - L'assistance fournie par le centre ne met pas la personne bénéficiaire en danger imminent

2. Impact pour le CASNSC

Parfois, les cas peuvent avoir un impact sur le centre d'assistance et sa réputation. Ces cas doivent être traités avec un soin tout particulier, avec l'implication de l’équipe de direction pour leur résolution.

3. Urgence

Elle se définit comme la quantité de retard pouvant être toléré et la rapidité nécessaire pour apporter la solution. Les cas peuvent être qualifiés de très urgents, moyennement urgents ou non urgents. Cela dépendra de plusieurs facteurs, notamment du temps et du degré de menace si des mesures ne sont pas prises dans un certain laps de temps.

Pour établir la priorité des cas, les personnes qui traitent des incidents doivent également tenir compte de ce qu’indique le/la bénéficiaire lorsque le cas est ouvert. Parfois, les bénéficiaires spécifient que le cas est urgent, pour une raison particulière. Retrouvez ci-dessous un tableau pour vous guider dans l’établissement de l'urgence des cas :

Catégorie	Description
Élevée (E)	- Les conséquences provoquées par l'incident s’accroissent plus le temps passe - Il est possible d’éviter qu’un incident mineur devienne un incident majeur en agissant immédiatement - Le cas a été ouvert de façon réactive par le/la bénéficiaire qui cherchait une assistance immédiate - S'agit-il d’un DDoS (déni de service distribué) ? Une violation des données est-elle en cours ?
Moyen (M)	- Les conséquences provoquées par l'incident s'accroissent lentement avec le temps
Faible (L)	- Les conséquences supposées par la non résolution du cas ne s'accroissent pas avec le temps - Le cas vise à prévenir tout futur incident de sécurité pour l'organisation

4. Priorité

En combinant les deux facteurs évoqués auparavant (urgence et impact), la personne qui traite l'incident peut évaluer la priorité du cas correspondante. Cette priorité est répertoriée dans le tableau ci-dessous :

REMARQUE : S’il y a un quelconque doute sur l’urgence ou l’impact d’un cas, il vaut toujours mieux pécher par excès de prudence et ne prendre aucun risque.

En règle générale, lorsqu’un cas a une priorité plus haute, il a également un impact significatif pour le centre d’assistance et le/la bénéficiaire. Notez qu’indépendamment de la priorité du cas, si la personne qui traite de l'incident n'est pas sûre des conseils à donner, elle doit solliciter le soutien de ses collègues.

Cycle de vie de réponse aux incidents

Voici notre flux de travail de réponse aux incidents. Il offre une vue d’ensemble de la façon dont les incidents de sécurité numériques doivent être gérés. Il ne donne pas de conseils sur la façon d’aborder des incidents en particulier. Pour des conseils spécifiques sur la façon de gérer différents types d’incidents, veuillez vous référer à notre documentation sur les procédures.

Le cycle de vie de la réponse aux incidents que suit le centre d’assistance se fonde sur : Paul Cichonski, Tom Millar, Tim Grance, Karen Scarfone, Computer Security Incident Handling Guide, NIST, 2021. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

Lorsqu’une organisation contacte notre CASNSC pour demander un soutien préventif, souvent elle prépare et ajuste ses pratiques pour éviter que ne se produisent des incidents de sécurité numérique. C’est là le scénario idéal, celui où nous aidons nos bénéficiaires à atténuer le risque de compromission de leur sécurité ou de leurs données.

Parfois, la demande de la personne bénéficiaire est d'enquêter sur un potentiel incident ou une tentative d’incident. Ce type de signalements n'inclut pas de preuves claires qu’un incident a déjà eu lieu et requiert donc une enquête initiale pour vérifier le signalement et confirmer s’il a bien eu lieu ou non. Cette phase s’appelle la détection et la personne qui traite du cas peut avoir besoin de davantage de preuves pour avancer dans son enquête, jusqu’à établir clairement que cet événement a en effet compromis la sécurité du/de la bénéficiaire ou qu’il s'agit d’un événement sans conséquences. Notre documentation sur les procédures aidera la personne qui traite du cas à comprendre les preuves ou les informations qui pourront lui être utiles pour enquêter sur différents types d’incidents. Ces types de cas seront habituellement moyennement voire très urgents, en particulier pendant la période où il faut encore déterminer si l'incident s’est bien produit ou non.

Toutefois, les bénéficiaires contactent souvent notre centre d’assistance lorsqu’un incident s’est déjà produit. Ceci veut dire qu’une ou plusieurs actions ont eu lieu qui nuisent intentionnellement ou tentent de nuire au système, au réseau ou aux données du/de la bénéficiaire. Exemples : indisponibilité du système, fuite de données, saisie du dispositif, compromission du compte, etc. Nous priorisons donc normalement l’endiguement de cet incident afin d’empêcher la propagation des dégâts à d’autres parties.

Souvent, les actions que nous prenons pour endiguer les incidents sont : demander à une plateforme en ligne de suspendre un compte compromis, isoler un système compromis du réseau, suspendre un site web défacé, supprimer toute donnée filtrée, etc. L’endiguement doit être rapide dans la plupart des cas et il doit être priorisé. Dans certains cas, nous dépendrons des actions du/de la bénéficiaire qui devra supprimer son système du réseau ou l'isoler tandis que nous lui fournissons les instructions techniques à distance. L’urgence sera normalement plus élevée dans les cas où l’on essaie d’endiguer un incident qui est en train de se produire.

Une fois l’endiguement effectué, il est souvent important que le/la chargé·e de cas consacre du temps à analyser la cause profonde du problème. Ceci mène habituellement à une enquête qui a lieu lors de la phase de détection et analyse. Selon la catégorie du cas, d’autres preuves peuvent être demandées au/à la bénéficiaire, afin d'effectuer une analyse, comme la source de l’email malveillant reçu dernièrement, le lien vers le téléchargement d’une appli malveillante, des captures d’écran d’alertes anti-virus, etc. Le but ici est de déterminer si d’autres mesures devraient être prises pour s’assurer que la récupération après l'incident est bien intégrale. Encore une fois, la personne qui traite du cas doit se référer à notre documentation sur les procédures, pour savoir quelles autres informations peuvent lui être utiles pour réaliser son analyse.

L’éradication consiste à nettoyer tout système compromis pour s’assurer d’une récupération intégrale. Ce peut être aussi simple que le fait d’installer et lancer une application anti-virus, mais dans certains cas, l'installation d’un nouveau système peut s’avérer nécessaire.

Quoiqu’il en soit, dans tous les cas, il est essentiel de connaître et documenter ce que le cyberagresseur a laissé derrière lui (si c'est le cas) et le nettoyer. Ceci sert à surveiller un possible retour de l’agresseur mais aussi à détecter toute autre attaque semblable contre d’autres systèmes ou bénéficiaire. Dans les situations où les systèmes ne peuvent pas être réinstallés ou redéfinis aux paramètres d’usine, les artefacts du cyberagresseur qui sont identifiés au stade de l’analyse peuvent être supprimés manuellement : voir les tâches de démarrage ou cron pour relancer une porte dérobée. Dans les cas tels que les attaques DDoS, l’éradication n’est pas possible car dans de tels incidents, le cyberagresseur ne laisse pas d’artefacts et la source de l'attaque est si diffuse que démonter tout hôte impliqué dans l’attaque n’est ni possible ni raisonnable. Toutefois, dans les cas où l’infrastructure de l'agresseur n'est pas diffuse, démonter cette infrastructure malveillante doit faire partie de la phase d’éradication. Signaler un compte qui fait fuiter des informations ou suspendre une adresse email envoyant des emails de hameçonnage peut également être considéré comme de l’éradication. L’éradication ne doit pas être urgente, car à ce stade, la menace aura déjà dû être endiguée. Toutefois, si le système continue d’être opérationnel ou connecté (selon la préférence du/de la chargé·e du cas) et que l’analyse a permis de détecter des artefacts qui permettent à l'agresseur de revenir bientôt ou immédiatement, l’urgence du cas doit être marquée comme élevée.

La distinction entre le stade de récupération et celui de l’éradication n'est pas toujours très claire, car on finit par se récupérer de l’incident en éradiquant simplement l’artefact de l’agresseur : par exemple, lorsque l’on supprime l’adresse email ou le numéro de téléphone du compte et que l’on y associe l'adresse et le numéro légitimes, ou lorsque l’on utilise un anti-virus pour nettoyer un ver non persistant.

Toutefois, il est important de s’assurer de la récupération, et dans certains cas, de surveiller le possible retour de l’agresseur. Cette tâche doit être considérée comme particulièrement importante lorsque l’on découvre que l’attaque est hautement ciblée et que la menace est persistante. Dans ces cas-là, les agresseurs n’hésiteront pas à attaquer à nouveau la même vulnérabilité/faiblesse ou en chercheront de nouvelles. Si c’est possible de le faire, vous pouvez aider la personne bénéficiaire à surveiller tout artefact qui aura été trouvé et supprimé au stade de l’éradication.

L’activité post-incident consiste à effectuer des activités de prévention qui sont possibles suite à l’attaque. Il peut s’agir de formation, de renforcement du système, d’un audit et d’une évaluation de la sécurité de l'organisation du/de la bénéficiaire, entre autres choses. Certaines de ces activités de prévention peuvent toutefois être réalisées plus tôt dans le cycle de l'incident, afin de s’assurer d’une récupération intégrale. Par exemple, vous pouvez aider un·e bénéficiaire dont le compte a été piraté à créer une nouvelle adresse email protégée par un mot de passe solide et une authentification à deux facteurs, afin de lui permettre de récupérer son compte. Dans le cas de la compromission d’un système, une analyse de vulnérabilité peut être effectuée pour éliminer toute vulnérabilité qui pourrait permettre d’autres attaques avant que ce système soit de nouveau opérationnel. Dans les cas de harcèlement, une recherche de renseignements en open-source peut aider la victime à se remettre d’une attaque de harcèlement, pour identifier toute information en ligne disponible pouvant être utilisée à nouveau par l’agresseur. L’activité post-incident nécessaire à se remettre de l’incident ne doit jamais être marquée comme faiblement urgente !

Considérations importantes

Lorsque vous répondez à des demandes, tenez compte des indications suivantes :

• Lorsqu’un cas est réceptionné, outre la réponse automatique envoyée par le système de tickets d’assistance, la personne qui travaille à ce moment-là doit répondre personnellement à la personne effectuant la demande, en lui expliquant qu’elle sera chargée de son cas et qu'elle se rendra disponible face aux problèmes qui pourront surgir.

• La vérification et approbation d’un·e bénéficiaire peut prendre du temps. Pendant que ce processus est en cours, le/la chargé·e du cas doit commencer à travailler à la solution, car si le/la bénéficiaire n’est pas vérifié·e, il faudra prendre encore plus de précautions quant aux informations qui seront partagées et les actions qui seront réalisées, vu que le lien de confiance n'est pas encore confirmé.

• Lors de la recherche de solutions pour les cas, veuillez toujours tenir compte des suggestions suivantes :

  • Ayez recours aux procédures documentées correspondantes.
  • Transmettez à d’autres collègues/envisagez de contacter des organisations partenaires pour certains cas.
  • Envisagez de contacter CiviCERT.
  • Si vous vous trouvez dans une impasse, transmettez et discutez toujours du cas avec votre responsable.

Motifs de clôture

Au moment de la clôture d’un cas, la personne ayant traité l'incident doit enregistrer le motif de sa clôture. Plusieurs options sont possibles :

• Résolution réussie : l’objectif du cas a été complètement rempli.
• Manque de réactivité de la part du ou de la cliente : le/la bénéficiaire n’a pas répondu après plusieurs

tentatives de communication.

• Amélioration future : l’objectif du cas n’a pas été complètement rempli et d’autres actions

doivent être réalisées dans le futur.

• Échec de la solution : l’objectif du cas n’a pas été rempli.
• Demande de la part du ou de la cliente : le/la client·e a expressément demandé la clôture du cas.
• Annulation du cas en interne : le cas a été annulé sur demande d’un·e membre de l’équipe en interne.

Un cas sera clos en raison du manque de réactivité du/de la bénéficiaire seulement lorsque cette absence de réponse nous empêche de remplir l’objectif de répondre à l'incident. Si la personne chargée du cas a répondu aux exigences pour terminer le cas, alors celui-ci devra être étiqueté avec résolution réussie, que le/la bénéficiaire nous réponde ou non.