Cet article fait partie de notre guide: Cyberattaque : comment faire face ?

Réponse à incident : 5 façons d’aider… les attaquants

Les responsables de la sécurité de Netskope et de Chipotle Mexican Grill ont profité de RSA Conference pour partager leurs expériences personnelles et les leçons retirées à l’occasion de réponses à des attaques.

Alors que les plans de réponse aux incidents sont cruciaux pour les entreprises, il arrive qu’ils échouent et entravent les organisations plutôt que de les aider.

Des scénarios d’attaque réels ont été discutés lors d’une session de l’édition 2021 de la RSA Conference, qui se déroule actuellement à San Francisco. L’accent y a été mis sur les erreurs commises lors de l’exécution du plan de réponse, au milieu du chaos. James Christiansen, vice-président et CSO de Netskope, et David Estlick, RSSI de Chipotle Mexican Grill, ont partagé des histoires personnelles tirées de situations de réponse à incident qu’ils ont vécues. Plus important encore, ils ont expliqué comment ces expériences ont révélé ce qu’il ne faut pas faire.

Parmi les leçons apprises, citons le maintien d’un petit cercle restreint pendant la réponse à une brèche, afin d’éviter les fuites d’informations, le maintien de plusieurs mandats pour différentes sociétés de réponse à incident et la disponibilité de cryptomonnaies en cas d’attaque par ransomware.

La session a mis en évidence cinq problèmes principaux qui contribuent à aider l’attaquant plutôt que la victime.

Conférence RSA Conference, Netskope et Chipotle, réponse à incident
James Christiansen (en haut), de Netskope, et David Estlick, de Chipotle Mexican Grill, ont présenté cinq façons dont les équipes de réponse à incidents peuvent donner l'avantage aux acteurs de la menace.

Le premier est l’incapacité à distinguer quelles activités sont normales pour son infrastructure. David Estlick a présenté un scénario réel qu’il a qualifié de « trop courant dans le monde actuel » : une organisation reçoit des rapports sur des systèmes inopérants suivis d’une demande de rançon. Le problème se pose lorsque les systèmes sont mis hors ligne et que l’équipe de réponse à incident ne peut y accéder, mais que les demandes de paiement continuent d’augmenter. « Nous avons vu cela souvent dans l’actualité ces derniers temps ».

Pour David Estlick, la solution réside dans la planification de la réponse à incident à froid et dans l’établissement d’une compréhension claire des actifs et d’un bon plan de sauvegarde qui permet la récupération si l’équipe de direction décide de ne pas payer la rançon. Il a souligné l’importance d’exécuter un scénario test avec l’équipe de direction afin de savoir à l’avance si l’organisation paiera ou non la rançon.

David Estlick a également recommandé d’organiser des exercices dans lesquels la demande de rançon est relativement faible par rapport à l’impact sur l’entreprise, afin que l’équipe de direction puisse avoir une conversation sérieuse sur la question de savoir s’il faut payer ou non, au lieu de rejeter une rançon élevée de plusieurs millions de dollars qu’il n’est tout simplement pas possible de payer.

« Et si vous payez la rançon, il y a certaines choses à préparer – avez-vous un compte Coinbase ? Avez-vous acquis des cryptodevises ? Ce sont des choses que vous ne voulez pas avoir à faire en temps de crise », a-t-il relevé.

Un autre défi consiste à déterminer si l’incident mérite une enquête. Selon David. Estlick, les équipes chargées de la réponse à incident sont souvent virtuelles et n’ont pas le temps de fouiller tout ce qui atterrit sur leur bureau ; il est donc crucial d’établir des priorités.

« De même, s’ils vérifient toutes les alertes et les alarmes et que vous avez un niveau élevé de faux positifs dans le système, cela peut conduire à la complaisance », souligne-t-il. « Assurez-vous que vous disposez d’une capacité excédentaire pour répondre aux besoins d’extension de capacité ».

David Estlick et James Christiansen ont tous deux indiqué avoir retenu les services de plusieurs entreprises parce que les incidents finissent par arriver en groupe. « Lorsqu’un incident survient, il va frapper fort et il n’y a aucun moyen d’avoir du personnel pour ce type d’événement. Il faut connaître ses systèmes d’exploitation et son réseau à l’avance », insiste James Christiansen.

Le second problème est de ne pas avoir toutes ses équipes de réponse à incident bien alignées. Et cela souligne un autre problème courant : la sécurité des mots de passe. S’il est prouvé que les mots de passe de comptes administratifs ont été piratés et sont utilisés sur de nombreux systèmes critiques, alors les équipes doivent être prêtes à changer tous les mots de passe administrateur au pied levé.

David Estlick a raconté l’anecdote d’un incident survenu chez un précédent employeur, où il a dû réinitialiser toutes les informations d’identification à 3 heures du matin, après plusieurs jours d’un incident continu. Après être rentré chez lui pour dormir quelques heures, il est revenu au bureau en s’attendant à vivre la pire journée professionnelle de sa carrière. Mais, il a été agréablement surpris : « personne n’est venu dans mon bureau pour me demander : “qu’avez-vous fait et pourquoi ?”. L’équipe de direction était consciente que le scénario était possible et m’a en fait protégé des réactions de l’organisation ». Au lieu d’une volée de bois vert, la réaction a été de se dire que « si la sécurité le juge nécessaire, alors il y avait une raison de le faire. C’était le résultat de relations et d’un travail acharné avant l’incident ».

Dans le même ordre d’idées, le troisième point portait sur l’épuisement de l’énergie côté réponse, bien avant qu’il ne survienne côté assaillants. Comme l’anecdote de David Estlick l’a montré, les équipes de réponse aux incidents peuvent être debout à toute heure de la nuit. En outre, les délais de rétablissement des services et de récupération complète sont inconnus. La réponse aux attaques peut prendre des heures, des jours ou des semaines.

James Christiansen a fait part d’une expérience désagréable lorsqu’un membre de son propre personnel a été blessé sur le chemin du retour parce qu’il s’était endormi. « Cela s’apprend par l’expérience et en s’assurant d’insister sur le repos. Les personnes clés voudront rester – elles sont sous l’effet de l’adrénaline ». David Estlick a vu des exemples passés où des éléments critiques tels que des données de logs ont été modifiés ou supprimés parce que les membres de l’équipe étaient simplement épuisés et avaient commis des erreurs.

Le quatrième problème qu’ils ont mis en évidence est le manque d’appréciation de la difficulté d’arrêter complètement une attaque en cours. Des problèmes peuvent survenir lorsque les attaquants compromettent les services cloud et que les équipes de réponse à incident ne sont pas compétentes dans ce domaine. Il est donc important de former ces équipes à la manipulation des technologies ou de disposer d’une expertise sur place.

En ce qui concerne le 5e et dernier problème, que les intervenants ont appelé « la gestion de la situation », James Christiansen souligne que la communication entre les cadres est essentielle. « La réalité est que, si vous effectuez une analyse de la compromission, vous allez devoir annoncer beaucoup de mauvaises nouvelles. Il y en aura un flux important, alors préparez l’équipe de direction à cela ». Et d’ajouter qu’il est important de montrer que la situation est sous contrôle.

« Il est également important de savoir quel est leur rôle :  qui ne va pas parler à la presse, qui va parler aux cadres et au personnel interne, aux membres du conseil d’administration. »
James ChristiansenVice-président et CSO de Netskope

La façon dont l’équipe de réponse à incident est formée est un autre élément crucial. Pour James Christiansen, elle doit être composée des principales parties prenantes, des services juridiques, des relations publiques, de l’équipe de sécurité, du groupe informatique et du service client qui seront impliqués dans les processus de notification.

« Il est également important de savoir quel est leur rôle – qui ne va pas parler à la presse, qui va parler aux cadres et au personnel interne, aux membres du conseil d’administration – c’est un élément clé important. Le fait de placer tout le monde sous contrainte de confidentialité est un moyen de minimiser l’impact et d’empêcher la désinformation de se propager dans le public, car cela peut porter un coup énorme à votre image de marque ».

À cet égard, David Estlick estime qu’il est important d’essayer de garder le groupe aussi soudé que possible. Dans le cas où l’incident deviendrait un événement public de grande envergure, toutes ces personnes pourraient être auditionnées. « Il y a beaucoup de pression de la part des personnes qui veulent être au courant, mais demandez-vous vraiment qui est essentiel pour faire partie de cette équipe ».

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

Close