Cet article fait partie de notre guide: Réponse à incident : les conseils pour réussir

Ces erreurs à éviter en cas d’un incident de sécurité

La réponse à incident est un exercice délicat aux contraintes techniques nombreuses. Mais les faux pas sont fréquents.

Répondre à un incident de sécurité informatique s’avère complexe. La composante organisationnelle joue un rôle clé, mais ce n’est pas la seule. Et les erreurs stratégiques et techniques qu’il est possible de commettre s’avèrent nombreuses. Et cela commence par l’évaluation du périmètre affecté.

Mal évaluer le périmètre

Vincent Nguyen, directeur technique du Cert de Wavestone (anciennement Solucom), ne manque pas de le souligner : pour échouer, rien de tel que l’absence de connaissance du périmètre concerne, car « le prestataire va forcément avoir des questions sur l’utilité de tel ou tel actif, processus ou donnée. Il a besoin de sachants du périmètre affecté ». Michael Bittan, associé responsable des activités de gestion des risques cyber chez Deloitte, ne dira pas autre chose : pour lui, il apparaît critique « d’avoir bien évalué l’incident ».

David Grout, directeur technique de FireEye pour l’Europe du Sud, insiste sur le risque lié à une mauvaise détermination du périmètre de l’incident : « une mauvaise interprétation des signaux d’alerte, une mauvaise sélection des ressources adéquates pour la réponse, peuvent entraîner un échec complet sur définition du périmètre de l’attaque et de ses impacts, et faire complètement échouer la réponse ».

Tout miser sur les outils

Certes, Fortunato Guarino, consultant solutions Cybercrime & Protection des données chez Guidance Software, estime que l’absence de workflows prédéfinis et automatisés est susceptible de mener à l’échec de la réponse à incident. David Grout estime également que « ne pas utiliser les outils présents » est une erreur courante : « les outils d’investigations de types analyse réseaux, SIEM, EDR doivent être implémentés en amont de l’incident afin de ne pas perdre des minutes cruciales leur du démarrage de la mission ».

Mais cela ne signifie pas qu’il faille se reposer entièrement sur les outils.

Laurent Maréchal, spécialiste solutions Europe du Sud chez Intel Security, prévient d’ailleurs : « se dire que la sécurité repose uniquement sur un empilement de produits de sécurité sans processus en place et sans personnels compétents formés à la sécurité » est l’une des clés de l’échec. Même son de cloche du côté de Fortunato Guarino.

Dès lors, sans surprise, ne pas avoir de processus de prise en charge des incidents clair et précisément défini n’aide pas, comme le soulignent aussi bien David Grout que Michael Bittan de Deloitte.

Ne pas maîtriser son infrastructure

Laurent Maréchal explique constater que « la plupart des entreprises ne sont pas prêtes à faire face à un incident de sécurité ». Et en général, à l’occasion d’intervention, ses équipes constatent que « la gestion du réseau et du système n’est pas maîtrisée ».

Cette gestion est pourtant essentielle car, comme le souligne Wade Woolwine, directeur des services de détection de brèche et de réponse de Rapid7, au moment d’intervenir, le prestataire a besoin d’éléments nombreux et variés, comme des « images disques, des logs, la compréhension des utilisateurs, applicatifs et actifs critiques ».

Yann Fareau, responsable Business Development EMEAR chez Cisco, partage ce regard : « Il est essentiel de collecter les données qui seront clés en cas d’incident et de s’assurer qu'elles soient bien collectées, ainsi qu’établir la liste des actifs critiques et surveiller ces environnements ». Et d’évoquer l’exemple d’un e-commerçant qui a sollicité ses services « pour traquer un potentiel incident : quand nous lui avons demandé si les relevés du site Web (leur principale source de revenu) étaient disponibles, il nous a été fourni un fichier si lourd qu'il nous a fallu 24 heures pour le télécharger et en assurer la récupération. La seule source d’information – ce qui est trop peu - n’était même pas gérée correctement ».

Laisser ses équipes travailler en silos

David Gout ne dira pas autre chose : « la non maitrise de l’infrastructure, la non connaissance des actifs clefs, des personnels importants, peuvent mener toute une investigation vers l’échec ». Et c’est sans compter avec l’absence d’analyse pertinente ou de logs essentiels : « les bonnes captures de réseaux sont rares ; on a tendance à se concentrer sur le périmètre, ce qui n’est pas suffisant. Une vision exhaustive est nécessaire pour comprendre les mouvements latéraux des assaillants ». Et puis « oublier de collecter les logs peut s’avérer désastreux dans le cadre d’une réponse à incidents car cela peut limiter la capacité des intervenants dans leur compréhension de l’évolution de l’assaillant et par conséquent de ses impacts ».

Laurent Maréchal insiste là sur les risques induits par les cloisonnements des équipes : « en 2016, la sécurité repose sur l’interconnexion et l’échange entre les produits de sécurité. La même chose doit s’appliquer au niveau des équipes au-delà de toute considération politique comme c’est parfois le cas. C’est là que le RSSI a un rôle important à jouer ».

Détruire des indices

Dans la phase d’investigation, détruire des indices, voire des éléments de preuve, peut survenir rapidement. Stanislas de Maupeou, directeur du secteur Conseil, évaluation et sécurité de Thales, prévient au passage d’erreurs qu’il peut être bien tentant de commettre : « réaliser l’investigation sur la machine elle-même et non pas sur une copie. Et par conséquent, chercher à faire soi-même l’investigation si l’on n’a pas les compétences – et bien évidemment sans prévenir son RSSI… Typiquement, la copie physiques d’un disque est une opération délicate ».

Chez Wavestone, Vincent Nguyen évoque d’autres exemples de pratiques à proscrire : « l’équipe du commanditaire qui utilise les mêmes identifiants que l’attaquant sur le SI ‘parce que c’est plus simple d’investiguer avec’ ! » ou encore « ‘oublier’ de fournir ‘quelques terminaux’ de l’utilisateur dont le compte a été volé par l’attaquant – évidemment, les traces de compromission étaient sur ces fameux terminaux oubliés ». Et bien sûr, « le bien connu redémarrage des actifs impactés… et par conséquent la perte des traces les plus volatiles – mais néanmoins intéressantes – contenues dans la mémoire vive ».

Cela peut paraître évident, mais David Grout souligne qu’il est « courant de minimiser les impacts, de sous-estimer les séquelles laissés sur un réseau ». Alors, « afin de ne pas détruire tous les efforts d’investigations par un nettoyage partiel, il est crucial de bien comprendre la menace et ses impacts réels et ne pas traiter dans la précipitation ». 

Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)

Close