Comment constituer son équipe de réponse à incident

Pourquoi une équipe est nécessaire

Toute réponse à incident nécessite une équipe aux compétences multiples : aucun individu ou domaine fonctionnel ne peut porter cela seul. Il y a deux raisons à cela. Tout d’abord, l’équipe doit être habilitée à prendre des mesures – déposer une plainte, informer partenaires et médias, interrompre des services techniques, mais également engager des dépenses exceptionnelles pour des spécialistes externes, par exemple. Pour cela, il faut faire appel aux parties prenantes qui contribuent à ces décisions et aux décideurs qui les influenceront. Il est important de faire participer ces personnes dès le début ou de pouvoir les mobiliser rapidement.

Vient ensuite la question de la diversité des compétences.

La seule chose qu’il est possible de prévoir au sujet d’un incident avant qu’il ne se produise, c’est qu’il ne sera pas possible de le prévoir.

Chaque incident est différent et les détails n’en sont pas connus avant qu’il ne se produise. Il est ainsi impossible de savoir avec précision quelles seront les compétences nécessaires durant l’incident. Il est donc prudent d’avoir une base de compétences diversifiée au départ – et d’être en mesure de faire venir rapidement des personnes ayant les connaissances complémentaires qui pourraient s’avérer nécessaires.

Création d’une équipe transverse

Partant de ces principes, il est clair qu’il y a un besoin de disposer d’un personnel et de compétences variées lors d’un incident. Mais comment les organiser ? Comment préparer à l’avance la manière de les joindre ?

En pratique, il est presque toujours bon de commencer par un petit groupe agile comme équipe de base. Ce groupe représente les personnes directement responsables de la gestion de l’incident au fur et à mesure qu’il se développe. Une petite équipe peut être plus agile et réagir plus promptement qu’un grand comité encombrant : elle peut prendre des décisions et communiquer des mises à jour rapidement, tandis qu’un groupe plus important met plus de temps à rassembler les ressources et à mettre tout le monde au diapason. Il peut donc s’avérer judicieux de maintenir une petite équipe agile au centre et d’établir des liens externes avec d’autres groupes pour les moments où des compétences, des intervenants et des décideurs supplémentaires sont nécessaires.

Il n’y a pas de règles strictes concernant les personnes à impliquer. Le métier, la culture d’entreprise et la structure interne peuvent fortement influencer le choix. Mais de manière générale, il est recommandé d’impliquer la direction, l’informatique, la sécurité de l’information physique comme juridique, les ressources humaines, et encore les relations publiques.

Rôles et responsabilités

La question suivante touche à l’organisation interne de l’équipe elle-même. Une stratégie efficace consiste à créer une matrice d’attribution des responsabilités identifiées. Le faire de manière formelle, collective, collaborative et par écrit peut constituer un avantage considérable. Puisqu’un certain temps peut s’écouler entre la préparation du plan de réponse et la survenue de l’incident, disposer d’une base écrite formelle permet de rappeler aux participants leurs responsabilités.

Lors de l’établissement de cette matrice, il convient de décider qui dirige le groupe. Les frictions au sein de l’équipe n’ont pas leur place lors d’un incident. Et ce rôle de chef d’équipe offre un point de contact sans ambiguïté aux cadres, permettant une prise de décision rapide et un arbitrage clair des différends.

De même, il est important de disposer de personnes possédant les compétences nécessaires pour comprendre la technologie, les applications et les environnements de l’organisation, ainsi que de personnes capables de faire des recherches sur les indicateurs de compromission. Toutefois, il faut être en mesure de faire appel rapidement à des consultants ou à des spécialistes externes.

Des facteurs aidant

Il faut ensuite réfléchir à la manière de permettre à l’équipe de travailler le plus efficacement possible. Pour cela, il faut considérer le modèle d’opération : l’équipe sera-t-elle convoquée seulement lorsqu’un incident est officiellement déclaré, ou existera-t-elle sous une forme permanente, avec plus ou moins de personnel à temps complet ?

Certaines organisations pourraient choisir de maintenir des ressources au sein d’un centre opérationnel de sécurité (SOC), tandis que d’autres préfèrent une équipe d’intervention en cas d’urgence informatique (CERT) ou une équipe d’intervention en cas d’incident de sécurité informatique (CSIRT).

Quelle est la différence ? Les missions du SOC peuvent recouvrir la réponse aux incidents, mais incluent généralement d’autres aspects des opérations de sécurité, par exemple, comme la gestion des événements de sécurité ou des vulnérabilités. Les CSIRT et CERT se concentrent spécifiquement sur la réponse aux incidents.
Ils peuvent fonctionner dans le cadre du SOC, s’il y en a un, ou exister indépendamment de celui-ci. Ils peuvent également être permanents ou éphémères, mobilisés uniquement lors de certains événements. Le choix de l’approche dépend notamment de la taille de l’organisation et de son contexte opérationnel. Mais de ce choix pourront en retour dépendre – au moins partiellement – la manière dont le groupe fonctionnera et les outils auxquels il aura accès.

L’important est de réfléchir à l’avance de manière systématique et professionnelle afin de ne pas avoir de surprises au milieu d’un événement critique.

Il faut donc déterminer le modèle d’organisation et les méthodes de communication les plus judicieuses compte tenu du nombre de personnes impliquées, du contexte et du budget disponibles, des besoins de l’organisation, du paysage des menaces, etc.

En réfléchissant à l’avance à toutes ces questions, il est possible de gagner un temps précieux lorsque survient l’incident, tout en limitant les risques de frustration et de précipitation.