Cadres de réponse à incident
Les deux cadres de réponse à incident les plus réputés ont été développés par le NIST et le SANS. Ils offrent aux équipes informatiques les bases nécessaires à l’élaboration de leurs plans de réponse à incident. Les étapes propres à chaque cadre sont présentées ci-dessous :
Procédure de réponse à incident du NIST | Procédure de réponse à incident du SANS |
---|---|
Étape 1. Préparation | Étape 1. Préparation |
Étape 2. Détection et analyse | Étape 2. Identification |
Étape 3. Confinement, éradication et reprise | Étape 3. Confinement |
Étape 4. Activité après incident | Étape 4. Éradication |
Étape 5. Reprise | |
Étape 6. Enseignements tirés |
Une comparaison des cadres NIST et SANS révèle des étapes pratiquement identiques, avec toutefois de légères différences au niveau des termes utilisés et de leur regroupement. C’est à l’étape 3 que l’on observe la principale différence. Selon le NIST, le confinement, l’éradication et la reprise se chevauchent. En d’autres termes, il ne faut pas attendre d’avoir confiné toutes les menaces avant de commencer à les éradiquer.
Fondamentalement, les deux cadres se valent et, au bout du compte, le choix dépendra de vos préférences et de vos ressources. Comme l’équipe de réponse à incident de CrowdStrike suit le cadre NIST, cet article se concentre sur les quatre étapes de ce cadre et explique le rôle de chacune dans votre plan de réponse à incident.
Étape 1. Préparation
Aucune entreprise n’est à même d’élaborer un plan de réponse à incident efficace en un clin d’œil. Celui-ci doit être pensé au préalable de façon à prévenir les événements et à pouvoir intervenir en cas de besoin.
Mise en place de l’équipe de réponse à un incident de sécurité informatique (CSIRT, Computer Security Incident Response Team)
Pour agir vite et bien en cas d’incident, chaque membre de l’équipe CSIRT doit connaître ses responsabilités et les décisions qu’il est censé prendre.
L’équipe CSIRT doit comprendre un échantillon représentatif d’experts techniques et en gestion, investis de l’autorité nécessaire pour prendre des mesures destinées à aider l’entreprise. Il doit s’agir d’une équipe pluridisciplinaire, incluant des représentants de la direction et de différents services (juridique, technique et communication), ainsi que des chargés de liaison du comité de sécurité. Tous les départements internes concernés par l’incident doivent être tenus informés et tous doivent avoir une grille de décisions pour guider leurs actions pendant et après l’incident.
Le plan doit également identifier les responsables et les personnes habilitées à prendre certaines décisions critiques. Ce sont là des aspects importants, qui doivent être réglés bien avant que l’entreprise se retrouve prise dans la « tourmente ».
Élaboration et actualisation du plan
Les plans et autres documents connexes doivent être créés au préalable et être régulièrement actualisés afin de rester à jour. Toutes les personnes concernées doivent avoir accès aux parties du plan qui relèvent de leur responsabilité et doivent être averties à chaque révision du plan. Une boucle de rétroaction doit être mise en place après chaque incident majeur afin d’améliorer continuellement le plan.
Acquisition et maintenance de l’infrastructure et des outils appropriés
Dotez-vous des fonctionnalités nécessaires pour détecter et analyser les incidents, mais aussi pour collecter et conserver les preuves. Pour identifier la présence d’un cyberattaquant dans un environnement, il est essentiel de disposer d’une technologie de protection des endpoints qui offre une visibilité complète sur les endpoints de l’entreprise et collecte les données relatives aux incidents.
Sans les outils adéquats, et les processus destinés à guider leur utilisation, vous serez bien en peine de déterminer comment les cyberattaquants s’introduisent dans votre environnement, comment limiter leur accès existant ou encore comment prévenir les tentatives d’infiltration futures.
Amélioration continue des compétences et aide à la formation
Assurez-vous que l’équipe de réponse à incident possède les compétences et la formation nécessaires. À cette fin, il est utile d’organiser de temps à autre des sessions « d’entraînement » pour mettre en pratique le plan de réponse à incident. Il convient également de pourvoir l’équipe de réponse à incident en personnel (collaborateurs internes ou d’un prestataire tiers), de dégager les jours nécessaires à l’obtention de certifications et à leur renouvellement, et de mettre sur pied d’autres initiatives de formation.
Capacité de cyberveille à jour
Les fonctionnalités de cyberveille aident les entreprises à comprendre les types de menaces auxquels elles doivent s’attendre et se préparer. La cyberveille doit s’intégrer en toute transparence à la protection des endpoints, et avoir recours à des investigations automatisées des incidents pour accélérer la réponse. Comme l’automatisation permet d’analyser les menaces de façon plus approfondie en quelques minutes et non en plusieurs heures, une entreprise peut neutraliser plus rapidement les menaces persistantes avancées grâce à des réponses mieux ciblées.
Étape 2. Détection et analyse
La deuxième étape de la réponse à incident consiste à déterminer si un incident a eu lieu, sa gravité et sa nature. Le NIST décompose cette étape en cinq parties :
- Identification des signes d’un incident (signes précurseurs et indicateurs) : les signes précurseurs et les indicateurs sont des signaux spécifiques indiquant qu’un incident est sur le point de se produire ou est déjà survenu.
- Analyse des indices découverts : une fois ces signaux identifiés, l’équipe de réponse à incident doit déterminer si le signe précurseur ou l’indicateur fait partie d’une attaque ou s’il s’agit d’un faux positif.
- Documentation de l’incident : s’il s’agit d’une attaque avérée, l’équipe doit commencer à documenter tous les faits en rapport avec l’incident et continuer à consigner toutes les mesures prises tout au long de l’intervention.
- Priorisation de l’incident : cette étape est, selon le NIST, la décision la plus importante du processus de réponse à incident. L’équipe de réponse à incident ne peut pas se contenter de prioriser les incidents par ordre chronologique. Elle doit plutôt leur attribuer un score en fonction de leur impact sur les fonctions métier, la confidentialité des informations concernées et la capacité à se remettre de l’incident.
- Notification de l’incident : après analyse et priorisation de l’incident, l’équipe doit avertir les personnes / départements internes concernés. Un plan de réponse à incident consciencieux doit contenir des exigences précises en matière de rapports.
Ne vous laissez pas abuser par la simplicité de la liste ci-dessus. La phase de détection et d’analyse peut s’avérer extrêmement compliquée, et ce pour les raisons suivantes (liste non exhaustive) :
- Les incidents peuvent être détectés par de nombreux moyens, allant des systèmes de détection automatisés aux rapports utilisateur. Le niveau de fidélité et de détail varie selon les moyens utilisés pour produire le rapport ou la personne à l’origine de celui-ci, et certains incidents sont presque impossibles à détecter, indépendamment du processus de signalement.
- Le nombre d’indicateurs de compromission potentielle peut être très élevé. Certaines entreprises peuvent en recevoir plusieurs millions par jour. Identifier les vrais signaux parmi la multitude d’informations parasites représente une tâche colossale.
- Une analyse précise et rigoureuse des données liées aux incidents exige des connaissances techniques spécialisées et approfondies, de même qu’une grande expérience. L’automatisation facilite la tâche, mais au bout du compte, c’est aux individus qu’il revient de déterminer si l’entreprise est confrontée ou non à un véritable incident. De nombreuses entreprises éprouvent bien des difficultés à acquérir l’expertise nécessaire pour identifier les incidents en cours.
La plateforme CrowdStrike Falcon est fortement mise à contribution pour la réponse aux incidents, en particulier pendant la phase de détection et d’analyse. Son architecture cloud lui permet d’accélérer la réponse et les délais de correction, et offre une visibilité à distance sur tous les endpoints de l’environnement, ce qui permet d’identifier immédiatement qui est à l’origine d’une attaque, en quoi elle consiste, et où et comment elle s’est produite. Des services comme Falcon Complete simplifient la phase de détection et d’analyse en alliant la technologie de protection des endpoints de CrowdStrike aux spécialistes, à l’expertise et aux processus nécessaires à la correction rapide d’un incident.
Étape 3. Confinement, éradication et reprise
L’objectif ici est de stopper les effets d’un incident avant que celui-ci ne cause d’autres dommages. Une fois l’incident circonscrit, l’équipe de réponse à incident peut prendre le temps nécessaire pour peaufiner les étapes suivantes. Cela consiste notamment à prendre les mesures requises pour résoudre la cause de l’incident et rétablir le fonctionnement normal des systèmes.
Ces décisions étant susceptibles d’impacter la productivité, les équipes de réponse à incident doivent faire preuve de prudence dans leur approche. Un plan de réponse à incident facilite le processus décisionnel en incluant une série de stratégies et procédures de confinement prédéfinies, basées sur le niveau de risque acceptable pour l’entreprise en question.
Élaborez des stratégies de confinement, d’éradication et de reprise basées, entre autres, sur les critères suivants :
- Criticité des ressources impactées
- Type et gravité de l’incident
- Nécessité de conserver les preuves
- Importance des systèmes touchés pour les processus métier critiques
- Ressources nécessaires pour mettre en œuvre la stratégie
Ces processus doivent être documentés et les preuves collectées en permanence. Deux raisons justifient une telle démarche : d’une part, pour en savoir plus sur l’attaque et améliorer l’expertise de l’équipe de sécurité et, d’autre part, pour se préparer à d’éventuels litiges.
Étape 4. Activité après incident
Chaque incident devrait être l’occasion d’apprendre et de s’améliorer, mais les entreprises font souvent peu de cas de cette étape. Les cyberadversaires ne cessent d’évoluer et les équipes de réponse à incident doivent rester au fait des dernières tactiques, techniques et procédures.
Chaque incident majeur devrait donner lieu à une réunion regroupant toutes les parties intéressées afin de tirer les leçons qui s’imposent de l’incident. Une telle réunion devrait également être encouragée en cas d’incident de moindre gravité, avec pour objectif d’améliorer la sécurité en général et la prise en charge des incidents en particulier. Dans le cas d’attaques majeures, n’hésitez pas à faire intervenir tous les acteurs de l’entreprise concernés par l’incident et pensez tout particulièrement à inviter ceux dont la coopération sera nécessaire lors d’incidents futurs.
Au cours de cette réunion, passez en revue les points suivants :
- Ce qui s’est produit et quand
- Quelle a été la réactivité et l’efficacité de l’équipe de réponse à incident
- Si les procédures documentées ont été respectées
- Si ces procédures étaient adaptées
- Quelles informations manquaient, et dans quelles circonstances
- Quelles actions ont retardé la reprise
- Ce qui aurait pu être fait différemment
- Quelles sont les mesures à prendre pour prévenir de futurs incidents
- Quels sont les signes précurseurs ou indicateurs à rechercher
Consignez les points importants de la réunion, attribuez les tâches à accomplir ou les mesures à prendre et envoyez par la suite un procès-verbal de la réunion par e-mail à ceux qui n’ont pas pu y assister.
Les conclusions de ces réunions peuvent devenir un outil de formation important pour les nouvelles recrues. Elles peuvent également servir à actualiser les politiques et les procédures, ainsi qu’à créer une base de connaissances formelle qui peut être utile pour gérer des incidents ultérieurs.