La dernière phase de la gestion d’un incident est la clôture de l’incident. Il s’agit de vérifier que toutes les actions nécessaires ont été effectuées, que l’incident ne va pas se reproduire à l’identique, et qu’aucune mesure prise dans l’urgence n’aura de conséquences néfastes pour l’organisation.
Pour toutes ces raisons, il est crucial de prendre un moment pour relire tout ce qu’il s’est passé une fois l’incident résolu.
Vérifiez que les actions prévues sont bien terminées
La première chose à faire est de reprendre la liste de tout ce qui a été fait durant les phases précédentes.
Durant l’investigation, vous avez dû noter toutes les actions que vous avez effectuées.
Durant le confinement et la résolution, toutes les mesures que vous avez prises ont dû être consignées dans le SIRP.
Toutes ces actions ont dû être datées avec l’heure précise.
Reprenez dans le SIRP la liste des actions prévues pour le confinement et la résolution de l’incident.
Reprenez les conclusions de l’investigation et la liste des actions effectuées, et demandez-vous :
Est-ce que toutes les actions qui étaient prévues ont bien été effectuées ?
À la lumière des conclusions de l’investigation, est-ce que vous avez fait tout ce qu’il fallait ? Est-ce qu’il y a des angles morts dans votre compréhension de l’incident ? c’est-à-dire des choses que l’attaquant aurait pu faire, mais que vous n’avez pas vérifiées ou corrigées ?
Vérifiez le retour sain à la normale
Une fois qu’on a vérifié tout cela, est-ce qu'on peut clôturer l’incident ?
Pas encore ! Sur les incidents les plus importants, on prend un moment pour observer les systèmes affectés avant de clôturer. Cela permet :
de confirmer que l’attaquant a bien été repoussé du système ;
de vérifier que le système est bien revenu à son état normal.
En effet, lorsque la résolution de l’incident amène à modifier les systèmes affectés, il faut suivre attentivement ces modifications. Sur un SI complexe, tous les systèmes sont connectés entre eux. La moindre modification d’un système peut donc en bloquer un autre ! Et ces complications ne sont pas forcément visibles tout de suite.
Faites le point sur les obligations légales
Cette phase est aussi l’occasion de vérifier que toutes les mesures liées aux obligations légales ont été prises :
Si l’organisation souhaite obtenir une réparation, il faut entamer une procédure de dépôt de plainte. Vous pouvez le faire dans un commissariat de police ou de la Gendarmerie nationale, qui ont toutes les deux des équipes spécialisées. Vous pouvez aussi faire un courrier au procureur du tribunal compétent.
Si votre organisation est un fournisseur de services numériques ou une organisation stratégique, telle un opérateur d’importance vitale (OIV) ou un opérateur de services essentiels (OSE), vous devez signaler l’incident à l’Agence nationale de sécurité des systèmes d'information (ANSSI) dans les plus brefs délais après sa détection. Le site de l’ANSSI regroupe tous les signalements à effectuer.
Dans le cas d’une fuite de données, si ces données concernent la vie privée de collaborateurs ou de clients, ou permettent de les identifier, il s’agit de données à caractère personnel. Dans ce cas, vous êtes tenu de signaler l’incident à la Commission nationale Informatique et Libertés (CNIL). Vous pouvez faire cette déclaration en ligne.
Communiquez avec les parties prenantes
Cette fois, on peut clôturer l’incident ?
Malheureusement, non ! Car le SOC n’est pas seul dans l’organisation. Vous avez fait le tour des impacts et des choses à améliorer en ce qui vous concerne. Mais il y a aussi d’autres équipes impactées par l’incident, ou par les changements qui en découlent.
Pour éviter un nouvel incident et pouvoir continuer à compter sur les différentes équipes de l’organisation, communiquez auprès de ceux qui ont été impactés.
Cela signifie de leur communiquer, de manière simple et vulgarisée :
la cause de l’incident, si elle est résolue ;
les impacts qu’ils vont constater ou qu’ils ont pu subir ;
ce qui a été entrepris pour gérer l’incident et le corriger ;
comment faire pour éviter ce genre d’incidents, ou au moins le détecter.
En particulier, si l’incident a été causé ou favorisé par de mauvaises pratiques de sécurité, n’hésitez pas à l’utiliser plus largement dans l’organisation. Cet incident vous donne un exemple concret et percutant des risques que cette pratique engendre pour l’organisation.
Clôturez l’incident
Une fois que cette étape est passée, vous pouvez effectivement clôturer l’incident. Dans la pratique, cela veut dire :
fermer les tickets associés dans le SIRP ;
changer le statut de l’incident dans le SOAR.
Et… c’est tout ? L’incident est clos ?
Pas tout à fait…
Tirez des leçons de l’incident
Avant de le clôturer, faites une relecture de la gestion de l’incident, mais cette fois-ci pour vous (le SOC). Cela va vous permettre de suivre l’évolution des capacités du SOC et de vous améliorer en permanence.
Posez-vous les questions suivantes :
Qu’est-ce qui a bien marché dans la gestion de cet incident ?
Qu’est-ce qui n’a pas marché ?
Qu’est-ce qui a ralenti la réponse ?
Qu’est-ce qui aurait dû être disponible plus tôt ?
Est-ce que vous aviez accès aux données dont vous aviez besoin ?
Est-ce qu’il y a des outils qui vous ont manqué ? ou qui n’ont pas été utiles ?
Est-ce qu’il y a des personnes qui n’ont pas été impliquées dans la gestion de l’incident (ou pas assez vite), et qui auraient dû ?
Est-ce qu’il y a eu des confusions entre les différentes équipes ou les différents membres ?
Est-ce que vos outils vous ont permis de partager les bonnes informations ?
Essayez de répondre à ces questions sous forme d’actions :
“mettre XXX en place” ;
“donner à YYY l’accès à l’outil ZZZ” ;
etc.
Dans la partie suivante, nous allons voir comment formuler, suivre et mettre en place ces actions pour améliorer en continu les procédures opérationnelles que vous avez suivies tout au long de cette partie.
Guillaume vous en dit plus sur la clôture des incidents cyber dans la vidéo ci-dessous.
À vous de jouer !
Vous avez rejoint le SOC de Méditronique, une entreprise de production de dispositifs médicaux.
Vous êtes intervenu sur un incident important sur le système de sauvegarde. L’investigation a permis d’identifier que l’attaquant est entré sur le réseau en utilisant un mot de passe compris dans une base de mots de passe volés. Puis il a compromis un serveur obsolète avant de compromettre le serveur de sauvegarde.
Proposez trois mesures que vous prenez ou que vous planifiez au moment de clôturer l’incident.
Correction du “À vous de jouer”
Durcir la sécurité au niveau du VPN. Dans le cas de Méditronique, il s’agit de mettre en place l'authentification multifacteurs. Il s’agit de l’utilisation d’un secret en plus du mot de passe pour s’authentifier, par exemple un code temporaire à confirmer sur son téléphone pour pouvoir se connecter.
Mettre en place un processus de gestion des correctifs pour éviter la présence de vulnérabilités sur le SI. Assurez-vous que l’équipe responsable des sauvegardes comprenne les causes de l’incident, comment il aurait pu être évité et ce que vous avez fait pour gérer l’incident.
Isoler les serveurs de sauvegardes pour empêcher un attaquant d’y accéder depuis le reste du SI.
Sensibiliser les employés aux risques liés à la réutilisation de mot de passe pour leur compte professionnel.
En résumé
La dernière phase de la gestion d’un incident est la clôture de l’incident. Il s’agit de vérifier que toutes les actions nécessaires ont été effectuées, que l’incident ne va pas se reproduire à l’identique, et qu’aucune de ces mesures prises dans l’urgence n’aura de conséquences néfastes pour l’organisation.
Pour vérifier tous ces points, il est essentiel de garder dans le SIRP une trace de chacune des actions qui ont été effectuées durant la gestion de l’incident. Ainsi le SIRP permet de suivre tous les incidents et leur bonne gestion.
Il faut aussi vérifier si l’incident est sujet à des obligations légales : obligation de communiquer l’incident à la CNIL s’il y a eu une fuite de données personnelles, obligation de communiquer l’incident à l’ANSSI pour les organisations suivies (OIV, OSE, FSN, prestataires qualifiés par l’ANSSI). Dans le cas où une poursuite judiciaire est pertinente, c’est à cette étape que l’on va faire la démarche de dépôt de plainte.
Il faut aussi assurer une bonne communication en interne, à la fois aux personnes qui ont été impactées par l’incident, mais aussi à celles qui seront impactées par les changements qui en découlent.
Si l’incident a été causé ou favorisé par de mauvaises pratiques de sécurité, il faut même communiquer largement en interne pour sensibiliser sur les causes de l’attaque.
Maintenant que l’incident est terminé, et que votre analyse post-mortem est effectuée, vous savez que vous avez des choses à améliorer :
dans votre détection ;
dans votre réponse ;
dans votre prévention.
Ces trois points correspondent au plan de la partie suivante !
