Qu'est-ce que la réponse aux incidents ?

 

Les plans de réponse aux incidents sont des plans d'urgence utilisés par les organisations pour se remettre d'incidents inattendus et perturbateurs.

Un plan de réponse aux incidents est défini comme un ensemble de protocoles permettant d'identifier, de détecter et de traiter les événements perturbateurs tels que les violations de données. Ces incidents peuvent être causés par n'importe quoi, des pannes matérielles brutales à l'erreur humaine.

Qu'est-ce que la réponse aux incidents en matière de sécurité des données ?

Un plan de réponse aux incidents est un ensemble de protocoles qui identifient, détectent et traitent les événements perturbateurs tels que les violations de données.

Un incident est une situation ou une anomalie qui peut avoir un impact négatif sur les données de l'entreprise et du client, sur les actifs critiques et, par conséquent, sur la continuité des activités. Un incident peut être d'origine naturelle (par exemple, des dommages causés par un tremblement de terre) ou humaine (cyberattaques). Les exemples d'incidents vont des incendies naturels aux brèches de sécurité en passant par l'espionnage d'entreprise.

La réponse aux incidents est une chaîne de processus conçus pour être déclenchés lorsqu'un incident est détecté. Il ne s'agit pas d'une mesure préventive mais d'un plan détaillé sur la manière de réagir à un incident lorsque toutes les lignes de défense de sécurité échouent.

Les incidents peuvent être classés en plusieurs catégories :

Organisationnels : incidents limités à une seule organisation. Par exemple, un bâtiment qui prend feu.

Publics : Incidents de portée universelle, comme une pandémie.
liés à l'informatique : Incidents liés à la sécurité et à l'infrastructure. Ils affectent les systèmes, le réseau et les données de l'entreprise.

 

Un plan de réponse aux incidents doit présenter :

Ce qui constitue un incident pour l'entreprise - cela se fait en évaluant la probabilité qu'un événement se produise et les dommages fiscaux, juridiques et de réputation qu'il peut causer.
Les instructions étape par étape à suivre lorsque chaque incident se produit.
Une liste des personnes à impliquer, avec leurs coordonnées.
Une liste d'outils à utiliser pour atténuer l'attaque. Il peut s'agir de clés USB avec des sauvegardes, de disques durs pour copier des images de disques, de logiciels anti-malware, de logiciels d'investigation et d'outils réseau.
Un plan de communication à utiliser au sein de l'organisation et avec les consommateurs et le grand public.

Pourquoi les organisations ont-elles besoin d'un plan de réponse aux incidents ?

L'évaluation 2020 d'Interpol montre une augmentation alarmante du nombre de cyberattaques, les grandes entreprises étant davantage visées que les particuliers et les PME. Il s'agit d'une conséquence directe du nombre plus élevé d'employés contraints de travailler à distance pendant la pandémie de COVID-19. Si cette situation exige la mise en place d'un système SIEM robuste, elle signifie également que les entreprises doivent être préparées avec un plan d'action si l'une de ces cyberattaques réussit.

La documentation fait partie intégrante de la planification de la réponse aux incidents. Les procédures sont développées et documentées pour une utilisation future. Lorsqu'un incident s'est produit, la documentation de la chaîne des événements est conservée en parallèle avec le plan de réponse aux incidents. Le plan de réponse aux incidents est donc utile lors de l'audit de la réglementation de conformité. Par exemple, le GDPR impose aux entreprises de signaler les incidents de sécurité des données dans les 72 heures suivant leur découverte. Par extension, si l'incident devait un jour évoluer vers une violation du droit civil ou pénal, le même ensemble de documents peut être utilisé comme preuve.

Cela dit, l'objectif d'un plan idéal de réponse aux incidents est de minimiser l'effet d'une menace sur l'infrastructure, la marque et les actifs de l'entreprise. Ces menaces comprennent les attaques par déni de service distribué (DDoS), les logiciels malveillants, les ransomwares, le phishing, les pannes de courant, le matériel défaillant, ou simplement les mots de passe faibles et les contrôles d'accès mal structurés. Une étude réalisée en 2020 par le Cyentia Institute a montré que les entreprises qui ne disposent pas d'un bon plan de réponse aux cyberincidents ont subi des pertes 2,8 fois plus importantes que leurs homologues qui disposaient d'un bon plan de réponse aux incidents.

 

Comprenons les six étapes du cycle de vie d'une réponse à un incident.

Cycle de vie de la réponse aux incidents

1. Préparation

Il s'agit de la seule étape du plan de réponse aux incidents qui est exécutée à l'avance. Au cours de la phase de préparation du cycle de vie de la réponse aux incidents, l'équipe de réponse aux incidents de sécurité informatique (CSIRT) doit élaborer des politiques et un cahier des charges pour gérer les incidents lorsqu'ils surviennent. À ce stade, elle ébauche un plan de communication et d'exécution et documente toutes les informations nécessaires à l'exécution du plan de réponse aux incidents.

Au cours de cette étape, les menaces possibles sont analysées et signalées en fonction de leur probabilité d'occurrence et de l'ampleur des dommages qu'elles peuvent causer. Cette analyse est réalisée à partir des informations collectives du SOC et des équipes de renseignement sur les menaces. Toutes les menaces ne sont pas marquées comme des incidents. Les incidents sont généralement dirigés contre des ressources et des actifs informatiques et ont une chance réaliste de réussir.

Les risques de sécurité sont audités et un plan de réponse est créé pour les incidents marqués comme étant à haut risque. Une liste d'alerte est créée et un plan de communication est défini. Toute formation pertinente nécessaire est lancée à ce stade.

 

2. Identification

L'étape d'identification est le moment où un incident est signalé pour la première fois. Pour ce faire, l'équipe du centre des opérations de sécurité (SOC) utilise des outils de gestion des informations et des événements de sécurité (SIEM) et vérifie les journaux, les messages d'erreur et les intrusions dans le pare-feu. Des outils de surveillance du réseau et des systèmes de détection des intrusions sont également utilisés. Il est essentiel de signaler les anomalies sur la base de la classification effectuée lors de l'étape précédente. Un nombre élevé de faux positifs (signalant un incident qui n'a finalement pas beaucoup de conséquences) dilue le processus du plan de réponse aux incidents.

Par exemple, un indicateur d'un incident possible peut refléter la présence de fichiers inconnus sur un serveur. Cela ne signifie pas nécessairement qu'un incident a été déclenché. Un indicateur certain d'une attaque est la perte de disponibilité des données ou un flot soudain et non comptabilisé d'activités émergeant d'un serveur dormant.

La collecte des événements qui ont été utilisés pour identifier et évaluer l'incident à partir des journaux et des outils de surveillance est connue sous le nom de collecte de "preuves". Une fois les preuves réunies, le qui, le quoi, le où, le pourquoi et le comment de l'incident sont consignés dans une documentation permanente de l'incident. Ce document est mis à jour à chaque étape du cycle de vie. Il peut également être utilisé devant un tribunal, le cas échéant.

 

3. Confinement

Cette étape du cycle de vie de la réponse aux incidents vise à contenir l'incident et à minimiser les dommages causés. Cette étape vise à récupérer le contrôle du système. Le confinement peut être divisé en trois étapes :

Le confinement à court terme : Une fois qu'un incident a été identifié, la première étape consiste à mettre en place des mesures immédiates qui minimiseront ou empêcheront d'autres dommages. Cela inclut la révocation de l'accès au serveur affecté.
Sauvegarde du système : S'il est crucial de faire un retour en arrière de tous les systèmes affectés pour éviter toute nouvelle compromission, il est également crucial de prendre une copie du système à ce moment-là. C'est ce qu'on appelle une "image médico-légale", qui est utilisée pour les enquêtes ultérieures et sert de preuve.
Confinement à long terme : Il s'agit de l'étape finale du confinement. Elle vise à garantir que le même incident ne se reproduira pas dans un avenir proche. Tous les comptes compromis sont fermés, les logiciels malveillants ou les portes dérobées installés par les attaquants sont supprimés et les systèmes sont nettoyés en vue de leur récupération. Cette étape passe à l'étape suivante du cycle de vie de la réponse aux incidents, à savoir l'éradication.

 

À la fin de cette étape, l'équipe CSIRT doit être capable de dire si l'incident doit être escaladé ou s'il peut simplement être éradiqué. Un incident est escaladé en tant que "désastre" si :

L'équipe CSIRT est incapable de contenir l'impact de l'incident.
Les dommages créés par l'incident sont trop importants pour que l'organisation puisse reprendre immédiatement ses activités.

Lorsque ce type d'escalade se produit, le plan de reprise après sinistre entre en jeu.

 

4. Éradication

À ce stade, on suppose que la source de l'attaque a été identifiée, isolée et contenue. Tous les systèmes sont analysés pour vérifier l'étendue de la compromission. Les vulnérabilités du système qui ont permis à l'incident de se produire sont corrigées pour éviter qu'il ne se reproduise.

Il est également essentiel de continuer à surveiller les systèmes pour voir comment les attaquants réagissent à ces mesures. Les analystes de sécurité devront élaborer des réponses anticipées à toute nouvelle attaque que ces mesures pourraient avoir induite.

 

5. Récupération

Au cours des dernières étapes, certains systèmes ont pu être mis hors service en révoquant les accès et en arrêtant les services. Au cours de cette étape, l'accent est mis sur la remise en état de fonctionnement de tous les systèmes, afin de s'assurer que l'incident a été complètement éradiqué. Tous les systèmes sont testés.

Les changements de sécurité nécessaires, tels que l'installation de correctifs, la restauration à partir de sauvegardes et la modification des politiques d'authentification, entrent en vigueur. Chaque étape doit être documentée et communiquée, conformément au plan de réponse aux incidents. À ce stade, on suppose que l'incident a été traité et que tous les systèmes sont de nouveau en place.

 

6. Apprentissages

Le travail du CSIRT n'est pas terminé tant qu'il n'a pas réexaminé la réponse et procédé à un examen après action (AAR). L'équipe passe en revue la documentation, de l'identification à la récupération, et discute des points suivants :

Qu'est-ce qui s'est bien passé ?
Qu'est-ce qui aurait pu être mieux exécuté ?
Quelles parties du plan de réponse à l'incident doivent être modifiées pour les réponses futures ?

Le plan de réponse à l'incident est ensuite modifié pour refléter ces enseignements.