Plongez dans l’univers de la détection et des réponses aux incidents cyber

Votre incident de sécurité est maintenant confiné, et l’attaquant n’a plus accès aux actifs qu’il a compromis.

Mais à présent, comment retourner à la normale ?

C’est l’objectif de la phase de remédiation : prendre toutes les actions nécessaires pour revenir à la normale.

Par conséquent, il faut s’assurer :

• que les dommages infligés sont réparés ;

• que l’attaquant ne peut pas revenir ;

• que l’incident ne se reproduira plus.

Planifiez le retour à la normale

Réparer les dommages infligés

Les dommages infligés par l’incident peuvent être de trois types :

• fuite de données ;

• indisponibilité de services liés à l’attaquant. Par exemple, un incident peut causer la mise à l’arrêt d’un site de production industrielle, qui entraîne un retard et un manque à gagner considérable pour l’organisation ;

• destruction d’actifs : chiffrement de documents, destruction des sauvegardes, suppression de données, etc.

En revanche, le rôle du SOC est bien de communiquer eret de fixer puis suivre les conditions de sécurité du retour à la normale.

Dommages liés aux fuites de données

Dans le cas des fuites de données, les risques sont plutôt d’ordre légal. Dans la pratique, ce n’est pas votre rôle d’effectuer ces démarches, mais vous devez vérifier qu’elles seront bien effectuées.

Traitez les actifs compromis

Traiter les actifs consiste à remettre en état de marche et au bon niveau de sécurité les actifs compromis ou endommagés.

Ce processus va mobiliser les actifs pendant un temps variable, et donc empêcher les équipes de Méditronique de les utiliser normalement. Par ailleurs, il amène à modifier les systèmes concernés, ce que l’on va chercher à éviter au maximum quand ce n’est pas dans le cadre d’une modification anticipée, planifiée et communiquée aux équipes concernées.

Il y a donc un arbitrage à faire entre :

• traiter l’actif en profondeur, ou le laisser disponible ;

• minimiser les changements ou en profiter pour améliorer la sécurité du SI.

Reconstruire le système

Reconstruire un système est la manière la plus sûre de s’assurer qu’il est revenu à un bon état de sécurité. Mais dans la pratique, les systèmes affectés sont parfois très complexes, ou adaptés au contexte de l’organisation.

On préfère donc reconstruire de zéro quand la mise à niveau de sécurité nécessite une refonte complète du système. Dans ce cas, le risque potentiel fait pencher la balance bénéfices/risques pour une reconstruction complète.

Nettoyer le système

Inversement, nettoyer le système nécessite une analyse approfondie de ce qu’a fait l’attaquant, à la recherche d’accès dérobés ou de dommages. Il faut alors réparer un à un les dommages infligés, et désactiver les accès dérobés.

Selon l'incident, ce processus peut prendre beaucoup de temps ! Mais il a le mérite de pouvoir faire fonctionner le système pendant son traitement.

On préfère nettoyer lorsque le système est trop critique pour être arrêté ou modifié, par exemple un système industriel, l’annuaire ou un service critique pour le réseau.

Il peut arriver aussi que les données soient critiques, ou trop compliquées à récolter pour reconstruire le système. Par exemple, si on peut reconstituer une base de données clients, on préférera le faire plutôt que de repartir d’une base de données vierge.

On préfère également nettoyer lorsque l’on peut se permettre de prendre le temps de traiter le système, parce que les complications potentielles de l’incident sont remédiées par un autre moyen. L’isolation au niveau du réseau, la sécurisation de sa configuration ou l’installation d’un EDR ou d’un EPP.

Remontez à la cause de l’incident

Pour empêcher cela, il faut identifier la cause qui est à la racine de l’incident. Il peut s’agir d’une vulnérabilité, d’une mauvaise pratique ou d’une attaque qui n’a pas pu être identifiée ou bloquée à temps.

Au fur et à mesure du traitement, l’investigation a dû identifier cette cause initiale de l’incident.

À vous d’organiser les mesures à prendre.

• S’il s’agit d’une vulnérabilité, il faut appliquer les correctifs s’ils existent. Si ce n’est pas possible, il faut planifier la création d’un correctif, et désactiver les composants vulnérables en attendant.

• S’il s’agit d’une mauvaise pratique, il faut communiquer dessus ! L’incident est une bonne occasion de sensibiliser les populations concernées pour expliquer les risques qui ont été évités (voire les dommages qui ont été infligés !). Il ne s’agit pas de pointer du doigt les coupables, mais de faire preuve de pédagogie. Le but est vraiment de vous assurer qu’ils ont compris ce qu’il faut faire pour éviter cet incident et vous aider.

• S’il s’agit d’une attaque qui n’est pas du fait de l’organisation, comment auriez-vous pu la détecter ? et la bloquer ? Peut-être même qu’elle a été détectée, mais qu’elle n’a pas été traitée à temps ? Il faut donc améliorer votre SOC en continu.

À vous de jouer !

Vous devez traiter la compromission d’un serveur critique de l’infrastructure de sauvegarde de l’entreprise Méditronique. Pour rappel, le chemin de compromission identifié est le suivant :

• l’attaquant a récupéré les identifiants du compte eve.lefevre@méditronique.com dans une fuite de données publique ;

• il s’est connecté avec ce compte sur le VPN ;

• il a exploité une vulnérabilité sur un serveur obsolète, grâce à laquelle il a volé le mot de passe de l'administrateur local du serveur de sauvegarde.

Vous devez traiter les actifs compromis.

Remplissez le tableau suivant pour arbitrer entre la reconstruction des actifs ou leur nettoyage, sachant que :

• une investigation a déjà été effectuée sur le serveur de sauvegarde ;

• ce serveur est critique pour l’infrastructure de sauvegarde.

Correction du “À vous de jouer”

Retrouvez une correction du tableau accompagné d'une explication dans ce document pdf téléchargeable.

En résumé

• Une fois la situation stabilisée, il faut passer à la phase de résolution de l’incident. Il s’agit du traitement de la cause initiale de l’incident et de la réparation des dégâts faits par l’attaque.

• Pour traiter un système, il faut arbitrer en fonction du contexte entre reconstruire le système ou le nettoyer. De façon générale, les deux principes sont : limiter au maximum les impacts sur le système d’information et terminer l’incident avec la configuration la plus sécurisée possible.

• On préfère donc reconstruire de zéro quand le système initial était mal sécurisé et que le travail à fournir pour le reconstruire de zéro est plus petit que le travail à fournir pour le sécuriser, ou pour s’assurer que l’attaquant n’a pas laissé de moyen de persistance.

• On préfère nettoyer lorsque le système est trop critique pour être arrêté ou modifié, et que l’on peut le sécuriser par d’autres moyens, tels que l’isolation au niveau du réseau, la sécurisation de sa configuration ou l’installation d’un EDR ou d’un EPP.

• Il faut aussi traiter la racine du problème qui a causé l’incident. Si besoin, corriger la vulnérabilité qui a permis à l’attaquant de rentrer dans le SI.

Non, il reste des choses à faire pour clôturer l’incident pour de bon. Nous allons détailler tout cela dans le chapitre suivant !