Réponse à incident (4/10) : comment courir à l'échec ?

Recourir à un prestataire externe pour réagir à incident de sécurité peut être incontournable. Mais l’opération n’a rien de trivial. Les causes d’échec sont nombreuses.

Renaud Templier, directeur des activités Risque & Sécurité chez Devoteam, soulignait récemment dans nos colonnes que « faire appel à une prestation externe pour répondre à un incident cyber est toujours délicat ». Il évoquait un point crucial : « il est particulièrement nécessaire d'anticiper les besoins logistique, physique et physiologique des intervenants ». Et justement, pour lui, « le manque d’anticipation de ces besoins » est une bonne clé de l’échec.

Ne pas savoir ouvrir les portes du royaume

Et cela commence donc par des éléments de simple logistique. Yann Fareau, responsable Business Development EMEAR chez Cisco, souligne ainsi que « au quotidien, exécuter des actions simples peut prendre beaucoup de temps pour diverses raisons – complexité des processus, organisation en silos, problèmes d’égo, etc. » Ne pas lever ces contraintes peut s’avérer préjudiciable en retardant la signature avec le prestataire, ou encore l’accès « à des locaux sensibles pour lesquels des vérifications sont nécessaires ».

La mauvaise identification des interlocuteurs concernés peut pénaliser le processus : « à titre d’exemple, sur un cas de ransomware, l’entreprise organisait un point de suivi toutes les heures avec plus de 20 personnes qui donnaient leur avis. Au-delà du bruit généré et des propositions hasardeuses, cela laissait trop peu de temps pour dérouler le plan d’action ».

Penser que le prestataire peut tout…

De fait, la gestion de la relation avec le prestataire apparaît essentielle. Pour Agnieszka Bruyere, directrice des services de sécurité chez IBM France, « ne pas donner en amont au fournisseur un accès aux données nécessaires pour dérouler le processus de réponse lors d’une détection d’incident » est un excellent moyen d’échouer dans la réaction. De même que « tout déléguer à un tiers, sans participer à la définition des processus ». Ou sans impliquer « les bons niveaux de management dans les prises de décision ayant un impact sur le business », comme le souligne David Grout, directeur technique de FireEye pour l’Europe du Sud.

Michael Bittan, associé responsable des activités de gestion des risques cyber chez Deloitte, ne dit pas autre chose. Pour lui, « ne pas avoir défini le cadre dans lequel le fournisseur doit intervenir » et ne pas « le piloter » sont deux bonnes sources d’échec.

D’ailleurs, Vincent Nguyen, directeur technique du Cert de Wavestone (anciennement Solucom), met en garde contre le fait de « disposer d’un contrat 24/7 avec un prestataire… mais n’avoir personne en interne pour l’accueillir » en cas de besoin !

Pour Laurent Maréchal, spécialiste solutions Europe du Sud chez Intel Security, estime aussi qu’il est plus que dangereux de « penser que l’on peut confier 100 % de l’incident à son fournisseur sans collaboration ». Et si parfois, « le prestataire de sécurité est perçu comme une personne cherchant à désigner un coupable », il faut pourtant « faire en sorte que l’intervention soit facilitée par la coopération des équipes en place ».

… tout seul, sans coordination…

En fait, Wade Woolwine, directeur des services de détection de brèche et de réponse de Rapid7, décrit la relation entre entreprise et prestataire comme « symbiotique : le fournisseur prend la responsabilité du travail technique, mais il est nécessaire d’avoir un échange bidirectionnel pour profiter d’un partenariat à réelle valeur ajoutée ».

D’ailleurs, Fortunato Guarino, consultant solutions Cybercrime & Protection des données chez Guidance Software, estime qu’un bon moyen de courir à l’échec consiste à « laisser le prestataire prendre des décisions stratégiques » alors qu’il convient « d’observer, orienter, décider et agir conformément à la séparation des devoirs et suivant des processus étape-par-étape » impliquant toutes les parties concernées. Un point que souligne aussi Agnieszka Bruyere. Et qui vaut surtout si l’omet de faire le lien avec les équipes de gestion de crise et de communication, comme le relèvent Michael Bittan et Fortunato Guarino. Pour ce dernier, il convient d’ailleurs de « ne jamais traiter un incident comme un simple problème IT ».

… et sans connaître l’entreprise

Et Wade Woolwine prévient : « penser qu’un prestataire externe peut simplement venir, tout connaître, et être capable de piloter l’enquête jusqu’à la remédiation », est surtout le moyen de « découvrir trop tard que l’on n’a pas dédié suffisamment de ressources pour faire l’interface avec son partenaire ou pour mettre en œuvre des recommandations critiques de remédiation ».

Pierre-Yves Popihn, directeur technique de NTT Security France, relève qu’il « faut impérativement que le prestataire externe ait une parfaite connaissance de l’entreprise et de l’infrastructure technologique ». D’où le conseil d’Eric Soares, directeur Europe centrale de SecureWorks : « éviter de choisir [son prestataire] une fois l’incident survenu. Il est important de prévoir un contrat d’intervention type « retainer » (forfait prépayé) qui permet de faire de la prévention afin d’avoir un cadre en place et une bonne connaissance de l’environnement. Ceci garantit une intervention bien préparée et dans un délai très court ».

Et là, Laurance Dine, associé exécutif chez Verizon Enterprise Solutions, encourage à la prudence. Car pour lui, la pire erreur peut bien être de « retenir le mauvais prestataire de service, ou bien de n’en choisir aucun » : « les RSSI doivent évaluer scrupuleusement les prestataires. C’est là que comptent l’expérience, les compétences, les certifications, la réputation et l’investissement dans la formation continue des équipes ».

Cet article publié le 11 octobre 2016 sur LeMagIT.fr fait partie d'une série consacrée à la réponse aux incidents de cybersécurité. Retrouvez le reste de cette série :

• Retirer tous les bénéfices d'une prestation de réponse à incident
• Savoir recevoir son prestataire
• Se préparer aux incidents futurs
• Ces erreurs à éviter dans la réponse à incident
• Ce qu'il est facile de négliger
• La préparation au fil de l'eau, un impératif
• Pourquoi prendre un contrat "retainer" ?
• Connaître la menace, un atout important
• Connaître et surveiller son infrastructure

La mauvaise identification des interlocuteurs concernés peut pénaliser le processus : « à titre d’exemple, sur un cas de ransomware, l’entreprise organisait un point de suivi toutes les heures avec plus de 20 personnes qui donnaient leur avis. Au-delà du bruit généré et des propositions hasardeuses, cela laissait trop peu de temps pour dérouler le plan d’action ».

Penser que le prestataire peut tout…

De fait, la gestion de la relation avec le prestataire apparaît essentielle. Pour Agnieszka Bruyere, directrice des services de sécurité chez IBM France, « ne pas donner en amont au fournisseur un accès aux données nécessaires pour dérouler le processus de réponse lors d’une détection d’incident » est un excellent moyen d’échouer dans la réaction. De même que « tout déléguer à un tiers, sans participer à la définition des processus ». Ou sans impliquer « les bons niveaux de management dans les prises de décision ayant un impact sur le business », comme le souligne David Grout, directeur technique de FireEye pour l’Europe du Sud.