Identifying Root Cause and Recovery

Une fois qu'un incident a été maîtrisé, que les preuves ont été collectées et que tous les artefacts malveillants ont été supprimés, il est temps d'identifier la cause première, si elle n'est toujours pas connue à ce stade, et d'effectuer des actions correctives afin que les systèmes puissent être renvoyés dans les environnements de production, permettant ainsi à l'entreprise de fonctionner à la même capacité qu'avant l'incident. Nous verrons ci-dessous comment les organisations peuvent s'y prendre pour identifier la cause première et quelles actions sont généralement menées pendant la phase de reprise.

Identifier la cause première

Pour certains incidents, la cause première sera immédiatement présente, par exemple lorsqu'un utilisateur informe l'équipe de sécurité qu'il a ouvert une pièce jointe dans un e-mail inhabituel, puis que son ordinateur portable commence à faire des choses étranges. Mais dans certains cas, il peut

falloir beaucoup d'analyse pour découvrir comment l'incident a débuté, en se référant à la Cyber Kill Chain ou au cadre ATT&CK pour cartographier les étapes observées au cours d'un incident, ce qui peut aider à identifier la cause en utilisant des voies d'attaque similaires et en étudiant des hypothèses concernant l'infection initiale.

En prenant des images médico-légales de tous les systèmes affectés, les analystes peuvent consacrer du temps à analyser les données dans le but de découvrir les actions entreprises par l'acteur malveillant lors de l'attaque. Il est important d'identifier la cause première pour que les efforts de restauration soient efficaces, car si vous précipitez cette étape, le point d'entrée initial pourrait rester ouvert, ce qui pourrait permettre à l'attaquant d'y accéder à nouveau.

Récupération après incident

Maintenant que l'incident est terminé, il est temps de réparer les systèmes qui ont été affectés par l'incident ou qui présentent des faiblesses similaires. Si un incident est dû à une vulnérabilité dans un programme, celui-ci doit être corrigé pour empêcher qu'il ne soit à nouveau exploité à l'avenir. Si l'incident est le résultat d'une erreur humaine, la personne ou les personnes doivent bénéficier d'une formation et/ou d'un soutien afin qu'un incident similaire ne se reproduise pas à l'avenir. Lorsque vous envisagez des mesures de rétablissement, la liste ci-dessous résume les réponses les plus courantes :

• Appliquer des correctifs aux systèmes avec des mises à jour du programme, du système d'exploitation et de sécurité pour garantir la correction des vulnérabilités. Des tests manuels doivent être effectués après l'application du correctif pour s'assurer que le correctif fonctionne.
• Désactiver les services qui ne sont pas nécessaires sur un système.
• Mettez à jour les règles de détection et de réponse (EDR), d'antivirus (AV), du système de détection et de prévention des intrusions (IDPS) et du SIEM pour permettre la surveillance et l'envoi d'alertes en cas d'activité similaire survenue lors de l'incident.
• Partagez les informations concernant l'incident, telles que les indicateurs de compromission, avec d'autres organisations afin de leur permettre d'améliorer la détection et d'effectuer des contrôles d'exposition aux menaces dans leurs environnements.

What Went Well?

1. Incident Response

2. Lessons Learned and Reporting

3. What Went Well?

Bien qu'il soit important de réfléchir aux faiblesses de la réponse à un incident pour en tirer des leçons et progresser, il est tout de même essentiel de se concentrer sur la manière dont la réponse s'est bien déroulée. Les membres de l'équipe d'intervention en cas d'incident doivent être évalués pour leur travail de maîtrise et de gestion de l'incident, afin de rétablir la normale des activités commerciales. Comme mentionné au début de ce cours, le simple fait de recevoir une évaluation et des commentaires peut prévenir des problèmes tels que le syndrome de l'imposteur et l'épuisement professionnel.

Lors d'une réunion qui suit l'incident, toutes les parties prenantes concernées doivent se réunir pour examiner l'incident du début à la fin. Voici quelques exemples de points de discussion :

• Qui s'est bien comporté ?
• De nouveaux outils ou processus ont-ils été utilisés qui ont apporté des avantages ?
• Passez en revue les indicateurs qui ont été collectés à la suite de l'incident.
• Passez en revue la communication entre les différents services de l'entreprise.

Il convient de mettre en évidence les domaines dans lesquels l'équipe de sécurité et les autres services ont bien fonctionné, et ceux-ci doivent être correctement enregistrés dans des cahiers de bord afin que la même approche puisse être utilisée lors de futurs incidents.