Un plan de réponse aux incidents s’assure qu’en cas de faille de sécurité, le personnel et les procédures appropriés soient en place pour s’attaquer efficacement à la menace. Lorsqu’un plan de réponse aux incidents est en place, une enquête structurée a lieu pour fournir une réponse ciblée permettant de contenir et de remédier à la menace.
Découvrez vos points faibles et renforcez votre résilience : Effectuez un Test de Préparation à la Ransomware Gratuit
C’est vendredi après-midi et après une longue semaine de travail au support informatique de votre entreprise, vous ne pensez qu’à une chose : la bouteille de vin qui accompagnera parfaitement une soirée tranquille devant une série sur Netflix. Mais vos rêveries sont interrompues par un coup de téléphone, probablement un employé qui demande une réinitialisation de son mot de passe.
Vous vous rendez rapidement compte de la panique dans la voix de votre interlocuteur qui n’arrive plus à ouvrir ses fichiers et vous demande ce qu’est un paiement en bitcoins. Ce n’est probablement pas très grave, un malware sur un seul ordinateur n’est pas très difficile à régler. C’est là que vous réalisez que, loin d’être un cas isolé, de nombreux téléphones se mettent à sonner dans le bureau, et la gravité de la situation prend une tout autre ampleur. Pour couronner le tout, l’un de vos collègues vous informe qu’un serveur contenant des données clients a également été infecté par un ransomware.
Ce scénario a déjà été vécu de nombreuses fois dans le monde entier, votre degré d’efficacité face à la situation dépend de votre réponse à une question très précise : « Avez-vous un plan de réponse aux incidents ? »
Pourquoi il vous faut un plan de réponse aux incidents
Une entreprise doit avoir un plan de réponse aux incidents pour prendre les bonnes décisions malgré l’urgence de la situation et récupérer le contrôle. Un incident de cybersécurité peut être très difficile à gérer. Si la réponse n’est pas menée de manière structurée, elle peut sévèrement affecter la réputation d’une marque.
Pour gérer efficacement un incident de cybersécurité, votre entreprise a besoin d’une équipe spécialisée pour réagir aux incidents. Certaines organisations appellent cette équipe – l’Équipe de réponse aux incidents de sécurité informatique (CSIRT), Équipe de réponse aux incidents de sécurité (SIRT) ou Équipe de réponse aux incidents informatiques (CIRT). Quel que soit son nom, l’équipe a la même mission : mettre en œuvre le plan de réponse aux incidents établi par l’entreprise lorsque l’alerte est donnée. Si vous travaillez dans la sécurité des données, vous êtes confronté tous les jours à des incidents de sécurité.
Il arrive qu’un problème mineur se transforme en véritable catastrophe. Lorsque l’alerte est donnée, chacun sait-il ce qu’il doit faire ? Chaque membre de l’équipe CSIRT connaît-il son rôle et ses responsabilités, et suivra-t-il le plan validé ? Lorsque les enjeux sont importants et que la pression monte, l’équipe CSIRT interviendra comme elle s’est entraînée à le faire. Si aucun plan n’a été mis en place, il n’existe aucune garantie qu’elle pourra faire face efficacement à un incident de cybersécurité.
Cependant, il ne suffit pas d’avoir un plan de réponse aux incidents : l’équipe CSIRT doit avoir les compétences et l’expérience nécessaires pour savoir gérer ce genre de situation potentiellement très stressante. Les experts en analyses, les analystes en malwares, les incident managers et les analystes SOC seront tous activement impliqués et en première ligne. Ils devront prendre des décisions clés, mener une enquête approfondie, informer les parties prenantes majeures et, enfin, donner la garantie à l’équipe dirigeante que la situation est sous contrôle. Qui plus est, ces équipes doivent souvent travailler dans l’urgence.
Les lois régissant le signalement des fuites de données deviennent monnaie courante : à titre d’exemple, le RGPD exige des entreprises qu’elles signalent les incidents de sécurité des données dans les 72 heures qui suivent leur identification.
Mon expérience des incidents de cybersécurité m’a montré l’intérêt d’avoir un plan de réponse aux incidents. J’ai déjà été informé très tôt le matin d’un incident pour me rendre compte qu’une faille de cybersécurité avait eu lieu. Le PDG demandait des réponses à l’équipe CSIRT et des conseils pour éviter la catastrophe. Avec un plan de réponse aux incidents, les bonnes personnes, dotées des compétences et de l’expérience appropriées, seront informées, chacun(e) saura ce qu’on attend de lui/d’elle et quelles procédures suivre pour bien contenir et remédier à la menace. Cela s’est toujours avéré capital d’avoir ce type de structure en place.
Ce qu’il faut prendre en compte pour planifier la réponse en cas d’incident
Le plan de réponse aux incidents est composé de critères essentiels qui peuvent être développés au fil de l’évolution de la structure de sécurité d’une entreprise. Lorsque vous vous attelez à la tâche de concevoir votre plan de réponse aux incidents, plusieurs choses sont à prendre en compte. Tout d’abord, il est capital d’être soutenu par votre équipe dirigeante. L’élaboration d’un plan de réponse aux incidents n’est pas un simple exercice consistant à cocher une check-list. Si l’équipe dirigeante ne vous accompagne pas dans cette mission, votre plan de réponse aux incidents risque d’être jeté aux oubliettes jusqu’à ce que vous en ayez besoin. L’équipe dirigeante devrait décrire ce dont elle a besoin du point de vue des processus et du personnel et s’assurer qu’elle fournit tout le soutien nécessaire. Définissez vos parties prenantes majeures. Les coordonnées des personnes et équipes clés, pendant les horaires de travail et en dehors, doivent être fournies. Communiquez de façon claire. Décidez qui devra communiquer, attribuer des tâches et quelles seront les actions appropriées. De plus, déterminez qui doit être inclus dans les messages à propos de l’incident et quel niveau de détail doit être fourni selon l’audience. Les tâches attribuées aux équipes de sécurité doivent être précises et techniques tandis que les mises à jour envoyées à l’équipe dirigeante doivent être claires et sans jargon. Définissez ce que vous entendez par incident. Spécifiez quels événements peuvent être gérés dans le cadre des activités quotidiennes et quand une alerte incident doit être lancée et que toute l’équipe doit être appelée en renfort.
- CONSEIL DE PRO : une grille de triage vous permettra de déterminer plus rapidement la gravité de l’incident pour qu’il soit pris en charge en priorité et corrigé rapidement.
Les plans et les procédures sont très importants. Cependant, c’est l’équipe CSIRT qui exécutera le plan de réponse aux incidents et qui effectuera la reprise post-incident. Les bonnes personnes et les bonnes compétences doivent être en place pour que le plan de réponse réussisse.
L’équipe CSIRT sera composée de plusieurs équipes et chaque poste joue un rôle clé pour transformer un incident de catastrophe potentielle à success-story. L’équipe CSIRT est une combinaison de personnel expérimenté, technique et non-technique qui travaillent ensemble pour comprendre l’étendue de l’incident, comment il peut être atténué et au final, comment y remédier. Il faut recruter et mettre en place les bonnes personnes.
L’automatisation est aussi essentielle dans la planification des réponses aux incidents, quand vous savez quels outils de sécurité sont en place, quelle est leur capacité et leur couverture, un certain niveau d’automatisation est possible.
Grâce à des contrôles de sécurité réglés précisément, votre première ligne de défense, le centre opérationnel de sécurité (SOC) répond à des alertes pertinentes et légitimes. Lorsque vos alertes sont fiables et réglées de façon précise, certaines parties du processus de réponse à l’incident peuvent être lancées automatiquement. Il est aussi possible que le triage initial et le recueil de traces de l’incident soient automatiquement générés. Si votre outil d’automatisation génère un grand nombre de faux positifs, non seulement cela encombrera une partie essentielle de votre plan de réponse aux incidents pour rien, mais vous pourriez également passer à côté d’une alerte importante si elle se retrouve noyée dans les faux positifs.
Outre le plan de réponse aux incidents, une entreprise devrait également songer à avoir un plan de reprise après sinistre. Tandis que le plan de réponse aux incidents est conçu pour remédier à la menace d’un incident, un plan de reprise après sinistre est fait pour restaurer l’activité d’une entreprise et restaurer ses systèmes informatiques suite à une catastrophe d’origine naturelle ou humaine. Si l’entreprise ne peut plus fonctionner, le plan de reprise après sinistre décrira les étapes requises pour restaurer ses systèmes informatiques. Autre point à ne pas négliger : l’entreprise devra peut-être vérifier si elle est concernée par d’autres réglementations locales (dûes à son implantation géographique), ou sectorielles (secteur d’activité). Le Payment Card Industry Data Security Standard (PCI DSS) s’applique par exemple dès lors qu’une entreprise traite, stocke ou transmet des enregistrements de cartes bancaires de ses clients.
Qui est responsable dans le plan de réponse aux incidents ?
L’équipe CSIRT est composée d’équipes spécialisées qui ont chacune un rôle important dans la réaction face à un incident. Le Centre opérationnel de sécurité (SOC) est la première ligne de défense. Ce sont des opérateurs qui travaillent sur le terrain, 24 h/24 et 7 j/7. Ils trient chaque alerte de sécurité, recueillent les traces et déterminent les mesures appropriées. Travaillant à tour de rôle tout au long de la journée, les analystes SOC doivent avoir une très vaste compréhension des menaces de cybersécurité.
Ils auront accès à plusieurs outils et plateformes de sécurité comme le SIEM (Security Incident Event Manager) et l’EDR (Endpoint Detection & Response). Ces outils peuvent générer des alertes très variées, des attaques DDoS aux commandes malveillantes exécutées sur un appareil, les analystes SOC doivent être capables de comprendre et interpréter ces données. Si un incident est déclaré ultra prioritaire ou exige des compétences autres que celles des analystes SOC, ceux-ci le transfèrent à l’équipe de Gestion des incidents.
Un collègue m’avait décrit le rôle d’Incident manager comme l’« art de rassembler un troupeau de chats ». L’Incident manager doit réunir tout ce qui concerne l’incident, rassembler les principales parties prenantes et animer les échanges pour déterminer le meilleur plan d’action. L’équipe de gestion des incidents sont les Généraux, on leur fournit les faits accompagnés de différents conseils et points de vue, et ils donnent le ton sur la gestion de l’incident. Ils identifient les tâches devant être accomplies, qui doit les accomplir et dans quels délais. Les messages et appels devant être programmés sont tous effectués par l’équipe de gestion des incidents.
L’équipe CIRT sont les soldats des Forces spéciales. On ne fait appel à eux que pour les incidents à priorité élevée et fort impact. Lorsqu’ils ne travaillent pas sur des incidents, ils peaufinent et développent leurs compétences. Tandis que les analystes SOC ont un vaste éventail de compétences, l’équipe CIRT est composée de personnes aux compétences et intérêts spécifiques, tels que des analystes en malwares ou des experts en analyse numérique. Cette équipe fournit des conseils techniques et des analyses. L’équipe de gestion des incidents lui attribue des tâches qui ne peuvent être menées par le SOC. L’équipe de veille sur les menaces sont des éclaireurs qui évaluent et comprennent l’environnement des cybermenaces. Si l’incident est lié à un serveur compromis contenant des données sensibles, cette équipe parcourt alors le dark Web à la recherche de traces que ces données ont été mises en vente. Si l’incident est lié à une infection par un malware, cette équipe de cyber-renseignement mène des recherches OSINT (Opensource Intelligence) sur la famille du malware et renseigne votre entreprise sur la probabilité qu’elle ait été victime d’une attaque ciblée.
6 étapes pour créer un plan de réponse aux incidents
SANS a publié son Incident Handler’s Handbook (Manuel de prise en charge des incidents) il y a quelques années. Il reste la référence en matière de plans de réponse aux incidents. Il s’agit d’un cadre en 6 étapes que vous pouvez utiliser pour établir un plan adapté à votre propre entreprise.
1. Préparation
Pour garantir une réponse réussie à un incident, il est essentiel de s’y préparer. Je recommande vivement d’élaborer des playbooks contenant des directives pour les équipes SOC lorsqu’elles effectuent le triage d’un incident. Elles recevront des instructions claires, par exemple comment prioriser un incident et quand un incident doit-il être remonté à l’échelon supérieur ? Il doit s’agir d’incidents de haut niveau, comme les attaques DDoS, les malwares, les menaces internes, les accès non autorisés et le phishing. Les playbooks et les procédures devraient être testés sur les personnes et les équipes qui s’en serviront plus tard. Les exercices de simulation sont un très bon moyen de consolider les connaissances et de voir s’il y a des améliorations à apporter.
2. Identification
Vous ne pouvez réellement mettre fin à une menace de sécurité qu’une fois que vous connaissez la taille et la portée de l’incident. Commencez avec le « patient zéro », le premier appareil à avoir été compromis. Le but est d’en comprendre la cause première. Mais ne vous focalisez pas seulement sur cet appareil. Se pourrait-il que la menace se soit répandue latéralement ? Un incident n’est réellement identifié que lorsque l’on recueille des signes d’infection (IOC) utiles. Plutôt que de réinitialiser le premier appareil infecté, cherchez à identifier tout signe d’infection unique, pouvant être utilisé ensuite pour analyser votre infrastructure à la recherche d’autres signes d’infection. Si l’incident est lié à une infection de malware, posez-vous les questions suivantes : quelles connexions réseau le malware génère-t-il ? Le malware s’est-il connecté à des domaines en particulier ? Quels fichiers ont été créés sur le disque ? Quels processus d’exécution ont été créés ? Des clés de registre uniques ont-elles été créées ? Ces données peuvent ensuite être utilisées pour rechercher d’autres traces d’infection et identifier les autres machines infectées sur votre réseau.
3. Confinement
Une fois que la portée de l’incident a bien été identifiée, le processus de confinement peut démarrer. Les appareils compromis dans l’infrastructure sont alors isolés du reste du réseau pour arrêter la progression de l’attaque. Un confinement à court terme peut être utilisé pour isoler un appareil ciblé par le trafic de l’attaque. Le confinement à long terme peut être nécessaire lorsqu’une analyse approfondie est requise, ce qui peut prendre du temps. Cela peut vouloir dire faire une sauvegarde d’image système de l’appareil et analyser le disque dur en profondeur. Ces recherches sont susceptibles de révéler d’autres signes d’infection, ce qui signifie répéter l’étape d’identification.
4. Éradication
Quand vous avez réussi à contenir l’incident, alors la phase d’éradication de la menace peut commencer. Celle-ci dépend de la cause d’infection de l’appareil. Appliquer des correctifs sur les appareils, désarmer un malware, désactiver les comptes compromis, sont des exemples de mesures à prendre dans cette phase.
5. Retour à la normale
Le but de cette phase est de ramener tous les services de l’entreprise à un fonctionnement normal. Si des sauvegardes propres sont disponibles, elles peuvent être utilisées pour restaurer le service. Autrement, tout appareil compromis devra être réinitialisé pour assurer une restauration propre. Vous devrez peut-être mettre en place une surveillance supplémentaire des appareils affectés.
6. Enseignements
Une fois que vous avez entièrement remédié à la menace, la phase suivante consiste à répondre à la question : « comment fait-on pour éviter que cela ne se reproduise ? » Une réunion qu’on appelle Post Incident Review (analyse post-incident) doit avoir lieu avec les représentants de toutes les équipes concernées. C’est le moment d’aborder ce qui s’est bien passé pendant la réponse à l’incident et ce qui peut être amélioré. Le plan de réponse aux incidents peut alors être modifié suite aux conclusions de cette réunion. Les procédures et les playbooks sont également modifiés pour refléter tout changement validé.
Bonnes pratiques pour l’élaboration de plans de réponse aux incidents
Créez des playbooks. Avec un playbook, vous orientez l’équipe SOC sur le triage d’incidents variés et vous les aidez à recueillir les traces pertinentes. Concentrez-vous sur les principaux scénarios d’attaque auxquels peuvent faire face les entreprises : malwares, DDoS, accès non autorisés, phishing et menaces internes. Ces documents doivent expliquer ce qui peut déclencher une remontée de l’incident à l’équipe de gestion des incidents et conseiller le SOC sur les traces à recueillir. Restez à un niveau général, ne rentrez pas trop dans les détails pour éviter de complexifier le tout.
Réalisez des exercices de cybermenaces. Préparez-vous aux conditions réelles en simulant des scénarios d’attaque. Il peut s’agir tout simplement de quelques exercices sur table. Créer des scénarios d’attaque qui peuvent être passés en revue par les équipes pertinentes est un bon moyen de tester un playbook déjà mis en place. Cela permettra également d’identifier les failles dans le plan de réponse aux incidents et devrait être examiné au moins une fois par an.
Partez à la chasse aux menaces. Attendre qu’une alerte se déclenche sur une toute nouvelle plateforme est une chose, mais c’est en recherchant activement les activités suspectes que l’on voit l’évolution des équipes de réponse aux incidents. Non seulement cela permettra de détecter une infection potentielle plus tôt, mais les personnes qui effectuent ces enquêtes ad hoc vont aussi développer un état d’esprit de « détective ». Ces compétences et ce type d’état d’esprit sont exactement ce dont vous avez besoin pendant la phase d’identification d’un incident : interroger le trafic réseau, examiner les ports utilisés de façon inhabituelle et les processus peu courants pour comprendre la taille d’un incident. Si l’équipe SOC sait à quoi ressemble un état « normal », il devient beaucoup plus facile pour elle de détecter des activités malveillantes.
Modèles de plans de réponse aux incidents
Créer un plan de réponse aux incidents peut faire peur de prime abord. Mais si vous utilisez un modèle, vous bénéficierez déjà d’une structure et de conseils.
Guide de planification du NCSC – Le NCSC (National Cyber Security Centre) est un organisme gouvernemental britannique qui aide des organisations britanniques majeures dans le domaine de la cybersécurité. En tant qu’autorité majeure dans ce domaine, leurs recommandations sont très précieuses pour la planification d’un plan de réponse aux incidents.
Modèle de réponse aux incidents de Sysnet – Ce modèle décrit comment reconnaître un incident de sécurité, les rôles et responsabilités des parties prenantes, les étapes du plan de réponse et les choses à prendre en compte selon le type d’incident.
Le site Incidentresponse.com propose plusieurs modèles de playbooks qui couvrent différents scénarios, comme les malwares, le phishing et les accès non autorisés. Ils correspondent tous au cadre NIST de réponse aux incidents. Ce sont des documents séparés qui devraient être mentionnés dans le plan de réponse aux incidents.
Pour vous aider à comprendre dans quels cas utiliser un plan de réponse aux incidents, le webinaire de Varonis sur la réponse aux incidents illustre une simulation d’attaque en temps réel. Pendant ce webinaire, nos analystes en sécurité présentent rapidement Varonis pour Office 365, exécutent l’attaque, de l’intrusion à l’augmentation des privilèges jusqu’à l’exfiltration des données, puis vous montrent comment utiliser DatAlert pour la détecter et y répondre.
Que faire après un cyber-incident ?
Le calme est revenu, les méchants ont été vaincus et l’équipe CSIRT a appliqué à la lettre le plan de réponse aux incidents.
Et maintenant ? Faites le bilan et préparez-vous à l’attaque suivante. Renforcez votre plan de réponse aux incidents ou cherchez à améliorer la surveillance déjà en place. Avez-vous d’autres logs qui n’étaient pas disponibles pendant l’incident et qui doivent être activés ? Existe-t-il des lacunes dans certaines compétences de votre équipe de sécurité ? La politique de correctifs de l’entreprise doit-elle être revue ? C’est en révisant et en affinant constamment le processus de réponse aux incidents que vous améliorerez votre approche et que vous réduirez votre surface d’exposition aux attaques. Quand des contrôles supplémentaires et des améliorations sont apportés à la stratégie de sécurité d’une entreprise, cela se traduit par une baisse des incidents de sécurité. Cet article devrait vous donner les connaissances et les ressources pour développer et déployer un plan réussi de réponse aux incidents. Pour garantir la protection de vos données, commencez par un essai de la Plateforme Varonis de sécurité des données pour ajouter une analyse comportementale de pointe à tous vos dépôts de données et votre infrastructure critique.
