Le processus de réponse aux incidents dans le détail

Déterminer l’étendue du problème

La première chose qu’un prestataire de services de réponse à incident va vouloir entendre, c’est une explication aussi détaillée que possible de ce qui se passe. Les organisations qui sont la cible d’une attaque par logiciel malveillant à plusieurs couches, ou d’une intrusion réseau, n’ont souvent pas une idée complète de l’origine ou de l’étendue du problème. Pourtant, il est vital de pouvoir fournir autant de détails que possible. « Normalement, lorsqu’un client entre en contact avec un spécialiste de la réponse à incident, la première chose que l’on veut savoir, est ce qui est en train de se passer », relève ainsi Bob Shaker, directeur des opérations stratégiques, préparation cyber et réponse, chez Symantec.

Un spécialiste de la réponse à incident va vouloir des informations sur ce qui conduit son client à penser qu’il a été compromis, quand et comment il l’a découvert, et encore s’il l’a fait grâce à une source interne ou externe, des autorités locales, par exemple, ou encore un émetteur de cartes bancaires.

Durant la phase d’établissement de l’étendue du problème, il est vital de disposer de personnes internes à l’organisation sachant quelles informations il est possible de fournir au prestataire, qu’il s’agisse de journaux d’activité ou de tout autre élément de preuve, explique Jim Aldridge, directeur de l’activité de conseil et Mandiant, l’unité de réponse aux incidents de FireEye.

Le prestataire va utiliser l’information qui lui est fournie pour évaluer l’étendue des dégâts et déterminer le type de ressources – y compris les experts à dépêcher sur place – nécessaires. « Lorsqu’une organisation contacte un prestataire de services de réponse à incident, il faut engager une discussion sur l’étendue du problème pour s’assurer que le prestataire comprend la situation sur laquelle il va intervenir », relève Aldridge.

La phase de contractualisation

Une fois que le prestataire a eu l’opportunité d’évaluer la situation, il pourra fournir une estimation de ce dont il aura besoin pour son intervention. Le contrat proposer doit généralement contenir des explications détaillées des services qui seront apportés, précisant au passage s’il aidera effectivement à remédier à l’incident, ou s’il ne fera que fournir les informations permettant à son client d’assurer seul la remédiation.

Dans cette phase, il est important de bien comprendre quelle documentation, accès et savoirs seront nécessaires au prestataire. Christopher Pierson, RSSI de Viewpost, une plateforme de paiement en ligne, estime qu’il est « crucial de s’assurer que les bonnes ressources seront fournies ». Les entreprises utilisant des applications et des services en mode Cloud sont parfois limitées dans le choix des tiers d’investigation qu’elles peuvent solliciter. Il est donc important d’examiner ces points avant de signer le contrat.

En outre, il est vital d’identifier les compétences que peut apporter le prestataire, ainsi que ses ressources technologiques, ses outils ou encore ses renseignements sur les menaces.

Signer pour un engagement de longue durée avec un prestataire, avant le premier incident, peut s’avérer profitable : ainsi, il n’est pas nécessaire de consacrer un temps critique en plein incident aux détails du processus de contractualisation, ou d’expliquer ses processus internes de réponse aux incident au milieu d’une crise. De fait, souligne Bob Shaker, « en pleine crise, la personne susceptible de signer un contrat est généralement sur le pont au centre de crise ». Réussir à l’en extraire peut s’avérer difficile…

Enquêter sur l’incident

Le prestataire de service aura besoin de toute l’information possible : logs systèmes et réseau, diagrammes de topologie réseau, images systèmes, rapports d’analyse du trafic réseau, etc.

Souvent, il est tentant de céder à la panique et d’arrêter les systèmes dans la précipitation. Mais pour Shaker, c’est une mauvaise idée : « la première chose importante est de ne pas éteindre les systèmes. Une fois qu’un système est éteint, une quantité considérable d’éléments de preuve peuvent être effacés, en particulier tout ce qui réside en mémoire vive ».

Les équipes d’investigation utilisent les informations fournies par les entreprises clients, ainsi que celles qu’elles collectent elles-mêmes sur leurs points de terminaison et d’autres sources, via des outils propriétaires, pour identifier des indicateurs de compromission, relève Kevin Strickland, consultant réponse à incident sénior chez Dell SecureWorks.

C’est après cela que le prestataire est généralement en mesure d’informer son client sur ce qui s’est passé, sur la manière dont l’intrusion est susceptible d’avoir commencé, ou comment le logiciel malveillant a été introduit sur le réseau, et sur quoi faire pour contenir l’incident : « nous allons fournir cette information et indiquer où des actions sont requises », explique Stickland. Et si les options recommandées sont difficiles à mettre en œuvre, il peut y avoir alors quelques aller-retour.

Contrôle et remédiation

L’équipe responsable de la remédiation travaille souvent en tandem avec l’équipe chargée de l’investigation, selon Aldridge. « Nous avons deux flux de travail. Le premier est lié à l’enquête et vise à identifier quels systèmes, comptes et données ont été compromis ; le second touche à la remédiation ». Et dès que la première équipe trouve des éléments relatifs à l’incident, elle les transmet à la seconde qui travaille avec le client à la mise en œuvre des mesures correctrices.

Mais discrétion peut s’avérer essentielle. Pour Strickland, il n’est pas question de laisser les attaquants savoir que l’on est sur leurs traces : « il est très important de comprendre ce qui se passe avant d’effectuer des changements drastiques ».

Adapté de l’anglais.