Comment construire un plan de réponse aux incidents autour du processus de réponse aux incidents SANS, des exemples pour vous aider à démarrer, et un aperçu de l’automatisation de la réponse aux incidents.
Vous avez besoin d’une solution de réponse aux incidents ? Cliquez ici pour une démonstration de réponse aux incidents.
Dans ce post, vous apprendrez :
- Qu’est-ce qu’un plan de réponse aux incidents et pourquoi en avez-vous besoin ?
- Le cycle de réponse aux incidents
- Pourquoi un plan de réponse aux incidents est-il important ?
- Plan de réponse aux incidents Vs un plan de reprise après sinistre
- Les six étapes de la réponse aux incidents
- Modèle de plan de réponse aux incidents
- Exemples de plan de réponse aux incidents
- La prochaine génération de réponse aux incidents
Qu’est-ce qu’un plan de réponse aux incidents et pourquoi en avez-vous besoin ?
Un plan de réponse aux incidents est un ensemble d’outils et de procédures que votre équipe de sécurité peut utiliser pour identifier, éliminer et récupérer les menaces de cybersécurité. Il est conçu pour aider votre équipe à réagir rapidement et uniformément contre tout type de menace externe.
Les plans de réponse aux incidents garantissent que les réponses sont aussi efficaces que possible. Ces plans sont nécessaires pour minimiser les dommages causés par les menaces, notamment la perte de données, l’abus de ressources et la perte de confiance des clients.
Un plan de réponse aux incidents constitue la base de votre cycle de réponse aux incidents :
Figure 1 : Les éléments d’un cycle de réponse aux incidents
Un plan de réponse aux incidents n’est pas complet sans une équipe capable de l’exécuter – l’équipe de réponse aux incidents de sécurité informatique (CSIRT). Une équipe d’intervention en cas d’incident est un groupe de personnes – soit du personnel informatique ayant une certaine formation en sécurité, soit du personnel de sécurité à plein temps dans les grandes organisations – qui recueillent, analysent et agissent sur les informations provenant d’un incident.
Elles sont le point central de l’incident et sont responsables de la communication avec les autres parties prenantes au sein de l’organisation, et les parties externes telles que les conseillers juridiques, la presse, les forces de l’ordre, les clients affectés, etc.
Pourquoi un plan de réponse aux incidents est-il important ?
L’étude 2017 sur le coût de la cybercriminalité du Ponemon Institute a montré que l’organisation moyenne perd 11,7 millions de dollars par an en raison des dommages causés par les cyber-attaques. Un processus de réponse efficace peut agir pour réduire considérablement ces coûts.
Les plans de réponse aux incidents sont également importants pour protéger vos données. La protection des actifs de données tout au long du processus de réponse aux incidents comprend des sauvegardes sécurisées, l’exploitation des journaux et des alertes de sécurité pour détecter les activités malveillantes, une bonne gestion des identités et des accès pour éviter les menaces internes et une forte attention à la gestion des correctifs.
En dernier lieu, le plan de réponse aux incidents protège la réputation de votre entreprise. IDC a constaté que 80 % des consommateurs iraient voir ailleurs s’ils étaient directement touchés par une violation de données. Si une faille de sécurité n’est pas correctement traitée rapidement, l’entreprise risque de perdre des affaires. La confiance des investisseurs et des actionnaires peut diminuer considérablement après une violation de données rendue publique.
Un plan de réponse aux incidents (IRP) vous aide à vous préparer aux incidents de sécurité et, idéalement, à les prévenir. Les réponses que les IRP dictent peuvent également avoir des effets positifs moins évidents sur votre organisation, notamment :
- La protection des données – la protection des données et des systèmes est au cœur de l’IRP. La protection est obtenue en sécurisant les sauvegardes, en assurant une gestion suffisante des identités et des accès, et en corrigeant les vulnérabilités en temps opportun. Ces mesures sont soutenues par une réponse rapide aux alertes et une analyse minutieuse des journaux et des données d’événements.
- Renforcement de la réputation-une réponse efficace aux incidents montre l’engagement d’une marque envers la sécurité et la confidentialité. Les attaques entraînant une perte de données peuvent amener les clients à douter de la compétence d’une organisation, ce qui conduit à l’abandon de la marque. De même, les actionnaires et les investisseurs peuvent abandonner une entreprise qui a subi une violation. L’IRP peut prévenir ou minimiser ces pertes.
- Réduit les coûts – les brèches sont coûteuses, en raison des amendes réglementaires, de l’indemnisation des clients, ou simplement du coût de l’enquête et de la restauration des systèmes. Selon une étude réalisée en 2019 par IBM, le coût moyen d’une violation est de près de 4 millions de dollars. Les PRI peuvent contribuer à réduire votre risque de brèche et à limiter les dommages causés par les attaques, limitant ainsi vos coûts.
Quelle est la relation entre un plan de réponse aux incidents et un plan de reprise après sinistre ?
Un plan de réponse aux incidents doit être complété par un plan de reprise après sinistre. Ce dernier prescrit la manière dont une organisation gère un événement catastrophique tel qu’une catastrophe naturelle ou une perte accidentelle de données. Alors qu’un plan de réponse aux incidents se concentre sur l’identification d’un événement de sécurité et sa clôture, la reprise après sinistre vise à remettre les systèmes en ligne, sous réserve d’un objectif de temps de récupération (RTO).
Principaux éléments à prendre en compte pour la planification de la réponse aux incidents
Pour être efficace, un plan de réponse aux incidents doit inclure les éléments suivants :
- Soutien de la haute direction – le soutien de la direction vous permettra de recruter les membres les plus qualifiés pour votre équipe de réponse et de créer des processus et des flux d’informations qui vous aideront à gérer efficacement un incident.
- Tests constants – un plan de réponse aux incidents ne vaut pas grand-chose s’il n’existe que sur papier, il doit être mis à l’épreuve. Effectuer un exercice de sécurité planifié (ou encore mieux, non planifié), passer en revue le plan et identifier les points faibles contribuera grandement à valider que l’équipe est prête à faire face à un véritable incident.
- Équilibre entre détails et flexibilité-le plan doit comporter des étapes spécifiques et exploitables que l’équipe peut suivre rapidement lorsqu’un incident se produit. Dans le même temps, la création de processus rigides entraîne une complexité et une incapacité à faire face à des scénarios inattendus. Créez un plan détaillé, mais prévoyez une certaine souplesse pour prendre en charge un large éventail d’incidents. La mise à jour fréquente du plan peut également contribuer à la flexibilité – revoir le plan tous les six mois environ peut vous aider à prendre en compte les nouveaux types de problèmes de sécurité et d’attaques qui affectent votre secteur d’activité.
- Clarifier les canaux de communication – le plan doit indiquer clairement avec qui l’équipe d’intervention doit communiquer, via quels canaux de communication, et quelles informations doivent être transmises. Il s’agit d’une partie essentielle et parfois négligée du processus d’intervention. Par exemple, il devrait y avoir des directives claires sur le niveau de détail à communiquer à la direction informatique, à la direction générale, aux départements concernés, aux clients concernés et à la presse.
- Connaissez vos parties prenantes – quels sont les rôles clés au sein de l’organisation qui devraient se soucier et être impliqués dans un incident de sécurité ? Ceux-ci pourraient changer en fonction du type d’incident et des ressources organisationnelles visées. Les parties prenantes pourraient inclure les responsables de service, la haute direction, les partenaires, les clients et le service juridique.
- Faire en sorte que le plan reste simple – un principe de gestion bien connu, » Keep it Simple Stupid » (KISS), devrait également être appliqué aux plans d’intervention. Un plan compliqué, même s’il est très bien pensé, a peu de chances d’être suivi avec précision en temps réel. Réduisez les détails, les étapes et les procédures à un minimum absolu, afin que l’équipe puisse les traiter et les appliquer à l’incident lorsqu’elle entre dans le » brouillard de la guerre « .
Les 6 étapes de la réponse aux incidents du SANS Institute
Selon le manuel des gestionnaires d’incidents du SANS Institute, il existe six étapes qui doivent être suivies par l’équipe de réponse aux incidents, afin de traiter efficacement les incidents de sécurité. Votre plan d’intervention doit aborder et fournir un processus structuré pour chacune de ces étapes.
1. Préparation
Au stade de la préparation, vous devez examiner et codifier la politique de sécurité sous-jacente qui informe votre plan de réponse aux incidents. Effectuez une évaluation des risques et hiérarchisez les problèmes de sécurité, identifiez quels sont les actifs les plus sensibles et, par extension, quels sont les incidents de sécurité critiques sur lesquels l’équipe doit se concentrer. Créez un plan de communication, et préparez une documentation qui énonce clairement, et brièvement, les rôles, les responsabilités et les processus.
La planification ne suffit pas – vous devez également recruter des membres pour la CIRT, les former, vous assurer qu’ils ont accès à tous les systèmes pertinents, ainsi qu’aux outils et technologies dont ils ont besoin pour identifier les incidents et y répondre.
2. Identification
L’équipe doit pouvoir détecter efficacement les écarts par rapport aux opérations normales dans les systèmes organisationnels et identifier si ces écarts représentent des incidents de sécurité réels.
Lorsqu’un incident potentiel est découvert, l’équipe doit immédiatement recueillir des preuves supplémentaires, décider du type et de la gravité de l’incident et documenter tout ce qu’elle fait. La documentation doit répondre aux questions » Qui, quoi, où, pourquoi et comment » pour permettre aux attaquants d’être poursuivis en justice à un stade ultérieur.
3. Confinement
Une fois que l’équipe identifie un incident de sécurité, l’objectif immédiat est de contenir l’incident et d’empêcher que d’autres dommages ne se produisent. Cela implique :
- Le confinement à court terme – cela peut être aussi simple que d’isoler un segment de réseau qui est attaqué ou de mettre hors service les serveurs de production qui ont été piratés et qui détournent le trafic vers des serveurs de secours.
- Confinement à long terme-application de correctifs temporaires aux systèmes affectés pour leur permettre d’être utilisés en production, tout en reconstruisant des systèmes propres, en se préparant à les mettre en ligne dans la phase de récupération.
4. Éradication
L’équipe doit identifier la cause profonde de l’attaque, la suppression des logiciels malveillants ou des menaces, et la prévention d’attaques similaires à l’avenir. Par exemple, si un mécanisme d’authentification faible a été le point d’entrée de l’attaque, il doit être remplacé par une authentification forte ; si une vulnérabilité a été exploitée, elle doit être immédiatement corrigée.
5. Récupération
L’équipe remet en ligne les systèmes de production affectés avec précaution, pour s’assurer qu’un autre incident ne se produise pas. Les décisions importantes à ce stade sont de savoir à partir de quelle heure et de quelle date rétablir les opérations, comment tester et vérifier que les systèmes affectés sont de retour à la normale, et combien de temps surveiller les systèmes pour s’assurer que l’activité est de retour à la normale.
6. Leçons apprises
Cette phase devrait être effectuée au plus tard deux semaines après la fin de l’incident, pour s’assurer que les informations sont fraîches dans l’esprit de l’équipe. L’objectif de cette phase est de compléter la documentation qui n’a pas pu être préparée pendant le processus d’intervention et d’enquêter davantage sur l’incident afin d’identifier toute sa portée, comment il a été contenu et éradiqué, ce qui a été fait pour récupérer les systèmes attaqués, les domaines dans lesquels l’équipe d’intervention a été efficace et les domaines qui nécessitent une amélioration.
Modèle de plan d’intervention en cas d’incident
Voici quatre modèles détaillés que vous pouvez utiliser pour donner le coup d’envoi de votre planification d’intervention en cas d’incident :
Le modèle de plan d’intervention en cas d’incident deTechTarget (14 pages) comprend la portée, les scénarios de planification et les objectifs de récupération ; une séquence logique d’événements pour l’intervention en cas d’incident et les rôles et responsabilités de l’équipe ; des procédures de notification, d’escalade et de déclaration ; et des listes de contrôle de l’intervention en cas d’incident.
>> Télécharger le modèle
Le modèle d’intervention en cas d’incident de Thycotic (19 pages) comprend les rôles, les responsabilités et les coordonnées, la classification des menaces, les mesures à prendre lors de l’intervention en cas d’incident, les réglementations spécifiques au secteur et dépendantes de la géographie, et un processus d’intervention, ainsi que des instructions sur la façon de personnaliser le modèle en fonction de vos besoins spécifiques.
>> Télécharger le modèle (nécessite une inscription)
Le plan d’intervention en cas d’incident de sécurité de Sysnet (11 pages) comprend la façon de reconnaître un incident, les rôles et les responsabilités, les contacts externes, les étapes de réponse initiales et les instructions pour répondre à plusieurs types d’incidents courants, tels que les logiciels malveillants et les accès sans fil non autorisés.
>> Télécharger le modèle (nécessite une inscription)
Le plan d’intervention en cas d’incident du ministère de la Technologie du gouvernement de la Californie (4 pages) comprend une liste de contrôle en 17 étapes que les membres de l’équipe d’intervention doivent suivre, avec des références à des procédures plus détaillées pour des types d’incidents spécifiques (que vous devrez créer vous-même).
>> Télécharger le modèle
Exemples de plan d’intervention en cas d’incident
Lorsque vous élaborez un plan d’intervention en cas d’incident, il est précieux de voir des exemples réels de plans créés par d’autres organisations. Certains de ces exemples ne seront pas applicables aux scénarios d’incidents de votre secteur, mais peuvent vous donner de l’inspiration.
Voyez des exemples de plans des organisations suivantes :
- Université Carnegie Mellon – y compris les définitions, les rôles et les responsabilités, la méthodologie, les phases de réponse aux incidents, les directives pour les menaces d’initiés et l’interaction avec les forces de l’ordre, et la documentation.
- Université de Tulane-incluant le champ d’application, les rôles et les responsabilités, les définitions des incidents, les niveaux d’escalade et les étapes de réponse par niveau de criticité.
- Université d’État d’écriture-incluant le champ d’application, les étapes de réponse, l’utilisation des outils de sécurité et une liste de contrôle des intrusions.
La nouvelle génération de réponse aux incidents : L’orchestration et l’automatisation de la sécurité (SOAR)
Rien ne remplace l’élaboration d’un plan de réponse aux incidents et la désignation de personnes dédiées pour en être responsables. Cependant, pour rendre la réponse aux incidents plus efficace et permettre de traiter davantage d’incidents de sécurité, une nouvelle catégorie d’outils a évolué et permet d’automatiser la réponse aux incidents de sécurité.
Les outils d’orchestration et d’automatisation de la sécurité (SOAR) peuvent :
- Intégrer d’autres outils de sécurité, en les orchestrant pour permettre une réponse complexe à une attaque
- Automatiser des procédures de réponse en plusieurs étapes à l’aide de playbooks de sécurité
- Soutenir la gestion des cas en enregistrant toutes les informations liées à un incident de sécurité spécifique, en créant une chronologie complète des événements, et en aidant les analystes à collaborer et à ajouter des données et des informations à l’événement
Pour voir un exemple de solution de sécurité intégrée qui comprend SOAR ainsi que des fonctionnalités d’analyse comportementale des entités utilisateur (UEBA) et de gestion des informations et des événements de sécurité (SIEM), consultez Incident Responder d’Exabeam.
Vous voulez en savoir plus sur la réponse aux incidents ?
Regardez ces articles :
- Les trois éléments de la réponse aux incidents : Plan, équipe et outils
- Le guide complet de l’organisation CSIRT : Comment créer une équipe de réponse aux incidents
- 10 meilleures pratiques pour créer une équipe de réponse aux incidents de sécurité informatique (CSIRT) efficace
- Comment déployer rapidement une politique de réponse aux incidents efficace
- Sécurité informatique : Ce que vous devez savoir
- Étapes de la réponse aux incidents : 6 conseils pour répondre aux incidents de sécurité
- Battre les cybermenaces avec l’automatisation de la sécurité
- Sécurité IPS : comment la sécurité active fait gagner du temps et stoppe les attaques dans leur élan
Vous avez besoin d’une solution de réponse aux incidents ? Cliquez ici pour une démonstration de réponse aux incidents.