Qu’est-ce qu’un plan de réponse aux incidents et comment en créer un

Un plan de réponse aux incidents garantit qu’en cas de violation de la sécurité, le personnel et les procédures appropriés sont en place pour traiter efficacement une menace. La mise en place d’un plan de réponse aux incidents permet de s’assurer qu’une enquête structurée peut avoir lieu afin de fournir une réponse ciblée pour contenir et remédier à la menace.

C’est vendredi après-midi et après une semaine stable à travailler pour le service d’assistance informatique de votre entreprise, vos pensées sont sur cette bouteille de vin froid que vous avez au frais dans le réfrigérateur, l’accompagnement parfait pour une nuit tranquille à regarder Netflix. Cette pensée est interrompue lorsque votre téléphone de bureau sonne, probablement un autre employé qui demande une réinitialisation de mot de passe.

Cependant, la panique dans la voix de l’appelant devient rapidement évidente, ils ne peuvent ouvrir aucun de leurs fichiers et demandent si vous savez ce qu’est un paiement en bitcoins ? Ce n’est probablement pas grave, un logiciel malveillant sur un seul ordinateur portable n’est pas la fin du monde. Cependant, lorsque vous vous retournez et que vous apercevez que plusieurs téléphones sonnent dans le bureau, la situation semble un peu plus grave qu’un simple ordinateur portable infecté par un logiciel malveillant. Pour aggraver les choses, un collègue se penche vers vous pour vous dire qu’un serveur contenant des données clients a également été infecté par un ransomware.

Ce scénario s’est joué de nombreuses fois dans le monde, l’efficacité de votre réponse à cette situation dépend de la réponse à une question :  » Avez-vous un plan de réponse aux incidents ? »

Pourquoi vous avez besoin d’un plan de réponse aux incidents

Il est crucial qu’une entreprise dispose d’un plan de réponse aux incidents afin que, sous la pression d’un incident, les bonnes décisions puissent être prises pour ramener la situation sous contrôle. Un incident de cybersécurité peut être une situation très intimidante, si la réponse n’est pas menée de manière orchestrée alors le résultat potentiel pourrait entraîner de graves dommages à la réputation d’une marque.

Pour gérer efficacement un incident de cybersécurité, votre entreprise aura besoin d’une équipe spécialisée dans la réponse aux incidents. Certaines organisations appellent cette équipe l’équipe de réponse aux incidents de sécurité informatique (CSIRT) – il existe d’autres permutations de cet acronyme comme Security Incident Response Team (SIRT) ou Computer Incident Response Team (CIRT). La mission de cette équipe est la même, quel que soit le nom que vous lui donnez : mettre en œuvre le plan de réponse aux incidents établi par l’entreprise lorsque le bat-signal se déclenche.

Si vous travaillez dans la sécurité des données, vous êtes confronté à des incidents de sécurité au quotidien. Occasionnellement, un problème de sécurité mineur se révèle être une véritable situation de panique en direct. Lorsque le bat-signal s’allume, tout le monde saura-t-il quoi faire ? Chaque membre du CSIRT connaîtra-t-il son rôle et ses responsabilités et suivra-t-il le plan approuvé ?

Lorsque les enjeux deviennent élevés et que la pression s’intensifie, le CSIRT s’exécutera comme il s’est exercé. S’il n’y a pas de plan en place, rien ne garantit qu’ils seront en mesure de répondre correctement à un incident de cybersécurité.

Cependant, le simple fait d’avoir un plan de RI ne suffit pas : l’équipe CSIRT doit avoir les compétences et l’expérience nécessaires pour faire face à une situation potentiellement très stressante comme celle-ci. Les experts en criminalistique numérique, les analystes de logiciels malveillants, les gestionnaires d’incidents et les analystes SOC seront tous fortement impliqués et seront les bottes sur le terrain qui s’occupent de la situation Cela implique de prendre des décisions clés, de mener une enquête approfondie, de fournir un retour d’information aux principales parties prenantes et, finalement, de donner l’assurance à la haute direction que la situation est sous contrôle.

En plus de tout cela, il y a souvent un manque de temps. Les lois sur la notification des violations de données sont de plus en plus courantes : le GDPR, par exemple, exige que les entreprises signalent les incidents de sécurité des données dans les 72 heures suivant leur découverte.

Mon expérience de travail sur les incidents de cybersécurité m’a montré l’intérêt de disposer d’un plan de réponse aux incidents. J’ai été appelé aux premières heures du matin sur un incident pour découvrir qu’une violation de la cybersécurité a eu lieu, le PDG se tourne vers le CSIRT pour obtenir des réponses et des conseils sur la façon d’éviter le désastre. Le plan d’intervention en cas d’incident signifie que les bonnes personnes, dotées des compétences et de l’expérience adéquates, seront présentes lors de cet appel, qu’elles savent toutes ce que l’on attend d’elles et quelles procédures doivent être suivies pour réussir à contenir la menace et à y remédier. Avoir cette structure en place s’est toujours avéré inestimable.

Considérations pour la planification de la réponse aux incidents

Le plan de réponse aux incidents sera composé de critères clés qui peuvent être développés à mesure que la posture de sécurité d’une entreprise mûrit. Plusieurs considérations doivent être prises en compte lors de la construction d’un plan de réponse aux incidents.

L’appui de la haute direction est primordial. La construction d’un plan de réponse aux incidents ne doit pas être un exercice de case à cocher. S’il n’est pas soutenu par la haute direction, alors il risque d’être classé jusqu’à ce qu’il soit nécessaire. La haute direction doit souligner ce qui est nécessaire du point de vue des processus et des personnes et s’assurer que tout soutien nécessaire est fourni.

Définir les principales parties prenantes. Les coordonnées des personnes et des équipes clés pendant et en dehors des heures de travail doivent être documentées.

Communiquer clairement. La propriété de l’envoi des communications, de l’attribution des tâches et des actions appropriées doit être établie. En outre, considérez qui doit être inclus dans toute communication d’incident et combien de détails sont nécessaires en fonction de l’audience. Les tâches assignées aux équipes de sécurité doivent être précises et techniques tandis que les mises à jour destinées au conseil d’administration devront être claires et exemptes de tout jargon technique.

Définissez ce qui constitue un incident. Précisez quels sont les événements qui peuvent être traités comme des affaires courantes ou lorsque tout le monde est sur le pont et qu’un appel à incident doit être lancé.

• Clé : une matrice de triage permettra de comprendre la gravité d’un incident afin de pouvoir le hiérarchiser rapidement et correctement.

Les plans et les procédures sont importants. Cependant, c’est le CSIRT qui va exécuter le plan de réponse aux incidents et effectuer la récupération des incidents. Les bonnes personnes et les bons ensembles de compétences doivent être en place pour que le PRI soit exécuté avec succès.

Le CSIRT sera composé de différentes équipes et chaque rôle est essentiel pour transformer un incident d’un désastre potentiel en une histoire à succès. Le CSIRT est un mélange de personnel expérimenté, technique et non technique qui travaille ensemble pour comprendre la portée de l’incident, comment il peut être atténué et finalement remédié. Les bonnes personnes doivent être embauchées et mises en place.

L’automatisation est également essentielle à la planification de la réponse aux incidents, comprendre quels outils de sécurité sont en place ainsi que leur capacité et leur couverture signifie qu’un certain niveau d’automatisation sera possible. Des contrôles de sécurité finement réglés garantissent que votre première ligne de défense, le centre des opérations de sécurité (SOC), répond aux alertes qui sont significatives et légitimes. Le fait de disposer d’alertes fiables et bien réglées signifie que certaines parties du processus de réponse aux incidents peuvent être lancées automatiquement et qu’il est possible que le triage initial et la collecte des preuves d’un incident soient générés automatiquement. Si votre automatisation génère un grand nombre de faux positifs, non seulement cela entraînera une fatigue dans un domaine clé de votre IRP, mais vous êtes également plus susceptible de manquer une alerte clé si elle est perdue parmi le bruit des faux positifs.

A côté d’un plan de réponse aux incidents, une entreprise doit également envisager de mettre en place un plan de reprise après sinistre. Alors qu’un PIR est conçu pour remédier à la menace d’un incident, un PRD est conçu pour restaurer la fonctionnalité d’une entreprise et la remettre en ligne après une catastrophe naturelle ou humaine majeure. Si l’entreprise ne peut pas fonctionner, alors le DRP décrira les étapes nécessaires pour remettre l’entreprise en ligne.

Une entreprise peut également avoir besoin de considérer si elle est impactée par la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS). Celle-ci est applicable si une entreprise traite, stocke ou transmet des enregistrements de détails de cartes de crédit de clients.

Qui est responsable au sein d’un plan de réponse aux incidents

Le CSIRT est composé d’équipes spécialisées qui ont chacune un rôle important à jouer lors de la gestion d’un incident.

Les centres d’opérations de sécurité (SOC) constituent la première ligne de défense. Ce sont les soldats sur le terrain qui opèrent 24 heures sur 24, 7 jours sur 7. C’est leur rôle de trier chaque alerte de sécurité, de rassembler les preuves et de déterminer l’action appropriée. Travaillant par roulement, les analystes SOC doivent avoir une large compréhension des menaces de cybersécurité, ils auront accès à diverses plateformes et outils de sécurité tels que les solutions SIEM (Security Incident Event Manager) et EDR (Endpoint Detection & Response). Ces outils peuvent générer un large éventail d’alertes qui peuvent varier des attaques DDoS aux commandes malveillantes exécutées sur un appareil, les analystes SOC doivent être capables de comprendre et d’interpréter ces données. Si un incident est jugé hautement prioritaire ou ne relève pas des compétences du SOC, alors leur point d’escalade est l’équipe de gestion des incidents.

Le rôle d’un gestionnaire d’incidents m’a été décrit par un collègue comme « l’art de rassembler les chats. » C’est leur travail de mettre leurs bras autour d’un incident, de rassembler les principales parties prenantes et de conduire la discussion pour déterminer le meilleur plan d’action. Les membres de l’équipe de gestion des incidents sont les généraux, ils reçoivent des preuves, des conseils et des opinions et déterminent le rythme d’un incident. Elle identifie les tâches à accomplir, les personnes qui doivent les accomplir et la date à laquelle elles doivent l’être. Tous les appels et communications d’incident qui doivent être planifiés sont complétés par la gestion des incidents.

L’équipe CIRT est les soldats des opérations spéciales, ils ne sont impliqués que dans des incidents de haut profil et de haute priorité et lorsqu’ils ne sont pas impliqués dans des incidents, ils affinent et développent leurs compétences. Alors que les analystes SOC auront un large éventail de compétences, l’équipe CIRT sera composée de personnes ayant des compétences et des intérêts spécialisés, comme des analystes de logiciels malveillants et des experts en criminalistique numérique. Cette équipe fournit des conseils et des analyses techniques d’experts et se voit confier des tâches par la gestion des incidents qui ne peuvent pas être menées par le SOC.

L’équipe de renseignement sur les menaces est l’éclaireur qui évalue et comprend le paysage des cybermenaces. Si l’incident concerne un serveur compromis contenant des données sensibles, alors ils parcourront le dark web à la recherche de preuves de la mise en vente de ces données. Si l’incident concerne une infection par un logiciel malveillant, l’équipe de renseignement effectuera des recherches OSINT (Opensource Intelligence) sur la famille de logiciels malveillants et donnera son avis sur la probabilité qu’il s’agisse d’une attaque ciblée contre votre organisation.

6 étapes pour créer un plan de réponse aux incidents

Le SANS a publié son Incident Handler’s Handbook il y a quelques années, et il reste la norme pour les plans de RI. C’est un cadre en 6 étapes que vous pouvez utiliser pour construire le plan spécifique de votre entreprise autour.

Préparation

La préparation à tout incident de sécurité potentiel est la clé d’une réponse réussie. Je recommande fortement de développer quelques playbooks qui fournissent des conseils au SOC lors du triage d’un incident, ceux-ci donneront des instructions claires sur la façon de prioriser un incident et quand ils doivent être escaladés. Ils doivent être de haut niveau et se concentrer sur des domaines spécifiques tels que les attaques de type DDoS, les logiciels malveillants, les menaces internes, les accès non autorisés et le phishing. Les manuels et les procédures doivent être testés par les personnes et les équipes qui les utiliseront. Les exercices sur table sont un excellent moyen de solidifier les connaissances et de voir si des améliorations peuvent être apportées.

Identification

Vous ne pouvez réussir à éliminer une menace de sécurité que lorsque vous connaissez la taille et la portée d’un incident. Commencez par le  » patient zéro « , le dispositif initial compromis. L’objectif est de comprendre la cause profonde de la compromission, cependant ne vous concentrez pas uniquement sur ce seul appareil, la menace aurait-elle pu se propager et se déplacer latéralement ?

La véritable identification d’un incident vient de la collecte d’indicateurs de compromission (IOC) utiles. Plutôt que de se contenter de reconstruire l’appareil infecté d’origine, cherchez à identifier tout IOC unique qui peut être utilisé pour rechercher dans l’ensemble de votre patrimoine d’autres preuves de compromission. Si l’incident est lié à une infection par un logiciel malveillant, posez les questions suivantes : quelles connexions réseau le logiciel malveillant génère-t-il ? Le malware se connecte-t-il à des domaines ? Quels fichiers sont créés sur le disque ? Quels processus en cours d’exécution sont créés ? Y a-t-il des clés de registre uniques qui ont été créées ? Ces données peuvent ensuite être utilisées pour rechercher d’autres preuves de compromission et identifier toute autre machine infectée dans votre domaine.

Contenu

Une fois que la portée d’un incident a été identifiée avec succès, le processus de confinement peut alors commencer. C’est là que les appareils compromis au sein du domaine sont isolés du reste du réseau pour arrêter la propagation d’une attaque.

Le confinement à court terme peut être utilisé pour isoler un appareil qui est ciblé par le trafic d’attaque. Le confinement à long terme peut être nécessaire lorsqu’une analyse en profondeur est requise, ce qui peut prendre beaucoup de temps. Cela peut impliquer de prendre une image de l’appareil et de procéder à l’analyse du disque dur. Cela peut générer d’autres COI et la phase d’identification peut devoir être revue.

Eradication

Une fois que l’incident est contenu avec succès, alors l’éradication de la menace peut commencer. Cela variera en fonction de ce qui a provoqué la compromission d’un appareil. Patching des appareils, désarmement des logiciels malveillants, désactivation des comptes compromis sont autant d’exemples de ce qui peut être nécessaire dans la phase d’éradication d’un incident.

Récupération

Le but de la phase de récupération d’un incident est de rétablir un service normal pour l’entreprise. Si des sauvegardes propres sont disponibles, alors celles-ci peuvent être utilisées pour rétablir le service. Sinon, tout dispositif compromis devra être reconstruit pour assurer une récupération propre. Une surveillance supplémentaire des appareils affectés peut devoir être mise en œuvre.

Les leçons apprises

Une fois que la menace a été entièrement remédiée, la prochaine étape consistera à répondre à la question  » comment empêcher que cela ne se reproduise ? « . Une réunion connue sous le nom de Post Incident Review (PIR) devrait avoir lieu et impliquer des représentants de toutes les équipes impliquées dans l’incident. C’est l’occasion de discuter de ce qui s’est bien passé pendant l’incident et de ce qui peut être amélioré. C’est à ce moment-là que le plan de réponse aux incidents est affiné en fonction des résultats de la PIR, et que les procédures et les playbooks sont modifiés pour refléter les changements convenus.

Bonnes pratiques du plan de réponse aux incidents

Créer des playbooks. La création de playbooks guidera le SOC sur la façon de trier les différents incidents et de rassembler les preuves pertinentes. Concentrez-vous sur les principaux scénarios d’attaque auxquels les entreprises sont confrontées – logiciels malveillants, DDoS, accès non autorisé, phishing et menace interne. Ces documents doivent décrire ce qui déclenche une escalade vers l’équipe de gestion des incidents et indiquer quelles preuves doivent être recueillies. Gardez-les à un haut niveau, ils ne doivent pas être trop granulaires au point de devenir trop complexes.

Faites des exercices de cybermenace. Préparez-vous à la réalité en faisant des wargames de quelques scénarios d’attaque, cela peut même être aussi simple que d’organiser quelques exercices sur table. Créer quelques scénarios d’attaque qui peuvent être évoqués par les équipes concernées est un excellent moyen de tester les playbooks qui ont été mis en place, cela aidera également à identifier les lacunes d’un plan de réponse aux incidents et devrait être revu au moins une fois par an.

Démarrer la chasse aux menaces. Attendre qu’une alerte se déclenche sur une nouvelle plateforme rutilante est une chose, rechercher de manière proactive les activités suspectes est l’endroit où les équipes de réponse aux incidents commencent à mûrir. Non seulement une compromission potentielle est susceptible d’être trouvée plus tôt, mais les personnes qui effectuent ces enquêtes ad hoc développent leur état d’esprit d’investigation. Ces compétences et ce type d’état d’esprit sont exactement ce qui est nécessaire pendant la phase d’identification d’un incident, en interrogeant le trafic réseau, en examinant les ports utilisés de manière inhabituelle et les processus inhabituels pour comprendre l’ampleur d’un incident. Si le SOC a une forte compréhension de ce à quoi ressemble la  » normalité « , il devient beaucoup plus facile de repérer les activités malveillantes.

Modèles de plan de réponse aux incidents

Créer un plan d’incident peut sembler assez intimidant. Cependant, l’utilisation d’un modèle fournira une structure et une orientation sur la façon de développer un plan de réponse aux incidents réussi.

Guide de planification du NCSC – Le NCSC (National Cyber Security Centre) est une organisation du gouvernement britannique qui fournit un soutien en matière de cybersécurité aux organisations britanniques critiques. En tant qu’autorité majeure en matière de cybersécurité, leurs recommandations s’avéreront précieuses lors de la planification d’un plan de réponse aux incidents.

Modèle de réponse aux incidents de Sysnet – Décrit comment reconnaître un incident de sécurité, les rôles et responsabilités des principales parties prenantes, les étapes du plan de réponse aux incidents et ce qui doit être pris en compte pour différents types d’incidents.

Incidentresponse.com a fourni plusieurs modèles de livre de jeu qui couvrent des scénarios tels que les logiciels malveillants, le phishing, l’accès non autorisé, et sont tous mis en correspondance avec le cadre de réponse aux incidents du NIST. Il s’agira de documents autonomes distincts mais qui devront être référencés dans le plan de réponse aux incidents.

Pour aider à comprendre quand un plan de réponse aux incidents serait utilisé, le webinaire de Varonis sur la réponse aux incidents présente une simulation d’attaque en direct. Au cours de cette simulation, nos analystes de sécurité font une brève visite de Varonis for Office 365, exécutent l’attaque, de l’intrusion à l’exfiltration en passant par l’escalade de privilèges, puis vous montrent comment utiliser DatAlert pour détecter et répondre.

Que faire après un cyberincident ?

La poussière retombe, les méchants sont vaincus et l’équipe CSIRT a suivi le plan d’IR à la lettre. Et ensuite ? Faites le point et réapprovisionnez pour la prochaine rencontre.

Renforcez le plan de RI ou cherchez à améliorer la surveillance déjà en place, y a-t-il des journaux supplémentaires qui n’étaient pas disponibles pendant un incident et qui doivent être activés ? Y a-t-il un manque de compétences au sein de l’équipe de sécurité ? La politique de correction de l’entreprise doit-elle être revue ? Le fait de revoir et d’affiner constamment le processus d’incident permet non seulement d’améliorer la réponse à un incident, mais aussi de réduire la surface d’attaque. Si des contrôles et des améliorations supplémentaires sont apportés à la posture de sécurité d’une entreprise, alors cela se traduira en fin de compte par une diminution des incidents de sécurité.