Plan de réaction aux incidents de sécurité : à faire et à ne pas faire

Tim Holman, président de l’association britannique de la sécurité des systèmes d’information, l’ISSA UK, voit passer de nombreuses organisations dépourvues d’un plan de réaction aux incidents de sécurité. Et de dresser la liste de ce qui est susceptible de leur arriver lorsque survient finalement un incident.

De mauvaises retombées médiatiques

Les mauvais interlocuteurs dans l’organisation adressent le mauvais message aux médias. Il est fréquent, selon Tim Holman, que des PDG pensant mieux savoir que les autres formulent des réponses mal pensées, ou émettent des déclarations telles que « les attaquants ont utilisés des techniques avancées et se sont simplement montrés trop intelligents pour nous. » Ce qui peut avoir des implications légales immédiates, sans compter le risque d’une reconnaissance publique de responsabilité. Et ce type de déclaration ne contribue pas à la construction de l’image d’une entreprise sérieuse.

Des délais de récupération trop lents

Sans plan de réaction en place, les organisations se rétablissent plus lentement. Parle-t-on de minutes, d’heures ou de jours ? Qui sait… Mais avec un plan de réaction, les délais de récupération peuvent être testés, puis réduits, afin d’assurer une disponibilité aussi élevée que possible. Souvent, les organisations ne disposant pas d’un plan de réaction aux incidents ne disposent pas non plus d’un plan de continuité - du moins d’un qui fonctionne.

Assigner les mauvaises personnes

Pour les professionnels de l’IT qui aiment régler des problèmes, jouer aux pompiers, et adopter une approche réactive, créer et tester un plan de réaction apparaît particulièrement ennuyeux et chronophage. Pire, ce travail de pompier va les détourner de la tâche clé consistant à formuler le niveau de réponse adéquat. Dans ce genre de situation, il faut une personne orientée processus. Un analyste métier apparaît là plus indiqué qu’un analyste sécurité, par exemple.

Dans plans de réaction sur étagère

Aussi incroyable que cela puisse paraître, il existe un marché considérable pour les packs de règles sur étagère. Les entreprises peuvent simplement télécharger un framework complet de gouvernance de la sécurité de l’information et un pack de règles, lancer un « trouver/remplacer » et voilà ! Elles sont conformes PCI DSS ou ISO 27001. Les auditeurs peuvent généralement dire aisément d’où viennent ces packs de règles. Mais certaines entreprises vont même jusqu’à laisser le nom de son créateur sur le pack, pour montrer qu’il a été acheté, comme si c’était un gage de qualité…

Construire un plan de qualité

Voilà plus ou moins pour ce qu’il faut éviter de faire. Mais définir un plan de réaction n’est facile. Chaque entreprise est différente. Toutefois, Tim Holman suggère de suivre quelques recommandations. A commencer par la création d’une équipe dédiée à la réaction, disponible à tout moment, pour coordonner la réaction. Mais cette équipe doit être formée, et sensibilisée à l’idée qu’un incident coûte de l’argent à l’entreprise : une réaction cohérente est donc impérative. Et au moins un membre du conseil d’administration doit faire partie de l’équipe de réaction. Il convient ensuite de conduire une analyse des processus métiers, pour identifier les points critiques et, ainsi, les types d’incidents de sécurité nécessitant de réagir, ou encore les systèmes clés pour la continuité de l’activité, et ceux contenant des données méritant d’être supervisées afin d’identifier des signes d’attaque. Dès lors, tous les employés devraient être mis en courant d’un plan de réaction, résumé sur une seule page. Avant d’être formés, et sensibilisés à l’importance du sujet. 

Et Tim Holman de recommander alors la création de processus spécifiques à la réaction aux incidents de sécurité, définissant la manière dont les personnels doivent agir pour contenir les incidents et ramener les systèmes concernés en conditions opérationnelles - après qu’une image de leur état compromis a été réalisée. Ces plans et processus doivent ensuite être testés, de manière pratique, en installant des logiciels malveillants sur des systèmes critiques pour voir ce qui se produit. Tim Holman insiste là sur les apports de la virtualisation : « si vous ne l’avez pas encore essayé, jetez-y un oeil. C’est la reprise d’activité clés en main. » Enfin, de manière radicale, Holman recommande…  de licencier « toute personne qui pense que l’approche réactive, en mode pompier, est la meilleure pour l’entreprise. »

Mais au final, il relève surtout que toutes les recommandations formelles existantes - ISO 27001, PCI DSS, NIST, SANS, etc. - ne sont in fine que des recommandations : « elles n’ont pas vocation à être copiées/collées. Mais elles vont alimenter largement votre réflexion. Lisez-les et conduisez votre propres recherches. »

Adapté de l’anglais par la rédaction.