MISE À JOUR : Cet article, initialement publié sur 12 février 2021, a été mis à jour afin de refléter la situation actuelle du PICERL, des cadres de cybersécurité et de l'évolution radicale du paysage des menaces.
Dans un contexte où les menaces numériques ne cessent d’évoluer, il est essentiel pour toute organisation souhaitant renforcer ses défenses en matière de cybersécurité et réagir efficacement aux incidents de comprendre et de mettre en œuvre des plans d’intervention en cas d’ s (IR) . L'une de ces méthodologies est le PICERL, un cadre de cybersécurité que les organisations peuvent adopter pour renforcer leur capacité à réagir aux incidents de sécurité actuels et consolider leurs défenses face aux incidents susceptibles de se produire à l'avenir.
La gestion d'un incident de cybersécurité, qu'il s'agisse d'une fuite de données, d'une attaque par rançongiciel ou de toute autre cyberattaque, peut gravement perturber les activités courantes d'une organisation.
En l'absence d'une réponse efficace aux incidents, ceux-ci peuvent ébranler la confiance du public, nuire à la valeur de la marque et entraîner une perte considérable de chiffre d'affaires.
Dans cet article, nous abordons tous les aspects du modèle PICERL, notamment un bref historique de son origine, nous comparons le PICERL à d'autres modèles courants de cybersécurité et nous vous proposons des conseils concrets sur la gestion des incidents, qui peuvent vous aider à mettre en œuvre avec succès, au sein de votre organisation, un processus tel que le PICERL ou d'autres cadres de sécurité « » .
Qu'est-ce que le PICERL dans le domaine de la cybersécurité ?
PICERL est un processus d'intervention en cas d'incident en six étapes : P (), repare ( ), I (), dentify ( ), C (), ontain ( ), E (), radicate ( ), R () et ().
Créé par SANS, un organisme privé fondé en 1989 afin de mener des recherches et de dispenser des formations en matière de sécurité, le modèle PICERL est devenu une norme du secteur en matière de gestion des incidents. Beaucoup considèrent que le PICERL est un cadre efficace, car il offre une approche structurée et exhaustive de la gestion des incidents de sécurité.
Le respect du modèle PICERL garantit que les organisations sont bien préparées à faire face aux incidents (Préparation), sont en mesure de les identifier rapidement (Identification), de contenir la menace afin d’éviter tout dommage supplémentaire (Confinement), d’éliminer la menace du système (Élimination), de revenir à un fonctionnement normal après l’incident (Rétablissement) et de tirer les leçons de l’incident afin d’améliorer leurs interventions futures (Leçons tirées).
Examinons plus en détail les étapes du modèle PICERL, tout en mettant en avant les conseils concrets que vous pouvez mettre en pratique dès aujourd'hui pour vous aider à minimiser l'impact des incidents et à renforcer le niveau de sécurité global de votre organisation.
Étape 1. Préparez-vous
La préparation permet de s'assurer que les bonnes personnes, issues des équipes appropriées, sont mobilisées, qu'elles comprennent leur rôle et qu'elles savent comment réagir lorsqu'un incident survient.
La phase de préparation doit déboucher sur un plan permettant aux membres de l'équipe d'intervention en cas d' de s'entraîner, à l'instar de la manière dont les organisations s'entraînent à mettre en œuvre leurs procédures de sauvegarde et de reprise après sinistre (DR).
Les plans d'intervention en cas d'urgence doivent faire l'objet d'exercices réguliers afin de pallier leurs éventuelles faiblesses. Les exercices de simulation de gestion des incidents donnent aux membres de l'équipe la confiance nécessaire pour agir efficacement sous la pression d'un incident réel.
Les équipes chargées de la réponse aux incidents informatiques qui participent à des exercices de simulation devraient être en mesure de répondre à des questions telles que :
- Qui informe l'équipe des relations publiques (RP) ?
- Qui en informe le service juridique ?
- Qui en informe le service des finances ?
- Dans quels cas faut-il avertir les forces de l'ordre ou les autorités de régulation ?
La phase de préparation permet également de vérifier si vous disposez des outils adéquats. Sinon, disposez-vous des moyens financiers nécessaires pour les acquérir et assurer la formation des membres de l'équipe ? Il est important qu’une fois le plan d’intervention en cas d’incident élaboré, la direction générale l’examine et l’approuve, y compris le budget nécessaire à sa mise en œuvre.
Étape 2. Identifier
Une fois que vous avez établi qu'il s'agit bien d'un incident, la phase d'identification consiste à commencer à effectuer un triage en répondant à des questions telles que :
- Quand cela a-t-il commencé, et comment cela s'est-il produit ?
- Quel était le point d'entrée ?
- S'agissait-il d'une vulnérabilité non corrigée de ?
- Qui l'a trouvé, et comment l'avons-nous trouvé ?
- Connaissez-vous l'étendue du problème ? S'agit-il d'un cas isolé, limité à une ou deux personnes ou à un ou deux actifs, ou bien s'agit-il d'un phénomène généralisé ?
- Pouvons-nous poursuivre notre collaboration ?
- Les mesures que nous prendrons auront-elles une incidence sur l'un de nos secteurs d'activité ?
Très souvent, ce sont les identifiants piratés qui constituent le point d'entrée. À partir de là, un incident s'aggrave, et les acteurs malveillants tirent parti de toutes les failles présentes dans votre environnement.
Tanium s'appuie sur une analyse approfondie de vos terminaux pour mener une enquête approfondie sur les menaces
Afin d'améliorer leur capacité à identifier les menaces, les organisations ont commencé à gamifier la préparation et les tests de leurs procédures d'intervention. Par exemple, vous pouvez décerner des récompenses à l'équipe qui repère le courriel de hameçonnage ou qui applique son plan de vérification de la manière la plus rapide et la plus claire. La gamification est particulièrement utile pour les professionnels de la sécurité débutants.
Étape 3. Contenir
Une fois qu'un incident a été signalé, la maîtrise consiste à mettre en œuvre votre plan afin d'empêcher la propagation du comportement indésirable. Il existe deux courants de pensée courants concernant les méthodologies de confinement, chacun présentant des avantages et des inconvénients :
Une stratégie de confinement à court terme pourrait se résumer à émettre une commande de quarantaine afin d'empêcher les systèmes, ressources ou applications compromis de communiquer avec quoi que ce soit d'autre qu'un outil de sécurité. Cela implique des mesures rapides telles que l'isolation des systèmes affectés, le blocage du trafic malveillant ou la désactivation des comptes compromis afin d'empêcher toute aggravation de la situation pendant qu'une solution plus durable est mise au point.
La mise en place d'une stratégie de confinement à court terme constitue une étape cruciale pour limiter l'impact immédiat d'un incident de sécurité. Cela permet d'assurer la continuité des activités et de limiter au maximum les perturbations au cours des premières étapes de la gestion des incidents.
[À lire également : Qu'est-ce que la gestion des actifs informatiques ? [L'ITAM expliqué]
L' de confinement à long terme constitue une mesure corrective mise en œuvre à l'échelle de l'entreprise, mais elle pourrait être considérée comme ne permettant pas de remédier entièrement à la cause profonde de l'incident. Une stratégie de confinement à long terme dans le cadre de la gestion des incidents vise à apporter une solution durable aux failles de sécurité, en veillant non seulement à maîtriser temporairement la menace, mais aussi à empêcher qu'elle ne se reproduise. Cela peut impliquer des mises à niveau du système, la gestion des correctifs, la segmentation du réseau ou la mise en œuvre de protocoles de sécurité avancés.
Par exemple, présentez-vous des vulnérabilités non corrigées liées à un incident ? Si tel est le cas, l'accélération du calendrier de mise à jour du logiciel en question — qu'il s'agisse d'une application ou d'un système d'exploitation — devrait faire partie intégrante d'une stratégie de confinement à long terme.
Une autre tâche essentielle à inclure dans le processus de confinement consiste à réexaminer quels utilisateurs disposent d'un accès administrateur et à quels systèmes, par exemple :
- Quelle est votre surface d'attaque par rapport à Active Directory ?
- Avez-vous activé l'authentification à plusieurs facteurs ?
Il est judicieux de mettre en place des stratégies de confinement à long terme associées à vos systèmes de sauvegarde et de restauration des données, car cela peut contribuer à augmenter la probabilité que vos données aient été correctement dupliquées et puissent être facilement restaurées dans l'état où elles se trouvaient avant la survenue de l'incident.
Étape 4. Éradiquer
Vous essayez désormais d'éliminer la cause de la faille — à la racine, comme on dit. Qu'est-ce que cela signifie ? Cela signifie, par exemple, que dans le cas d'un logiciel malveillant que vous avez détecté, vous pouvez supprimer en toute sécurité toutes les instances de ce logiciel que vous parvenez à identifier. Vous avez renforcé la sécurité et appliqué les correctifs nécessaires aux systèmes concernés. Vous avez réinstallé des systèmes que vous ne pouvez pas sécuriser. Vous avez mis à jour vos informations sur les menaces afin de pouvoir identifier les éléments liés à cette violation de données.
Au fur et à mesure que le processus de gestion des incidents se déroule, il se peut que la portée de vos interventions évolue. À la suite d'une attaque par ransomware, par exemple, vous pourriez vous retrouver avec un grand nombre de systèmes devant être réinstallés et restaurés à partir de leur dernière sauvegarde valide connue. Et si vous ne repérez pas tous les éléments liés à l'attaque ou si vous n'avez pas corrigé la faille exploitée pour s'introduire dans votre système, vous pourriez être à nouveau victime d'une attaque.
La clé de l'éradication réside dans la rigueur. La question fondamentale est de savoir si vous avez tout trouvé — quoi que « cela » puisse être. Un partenaire ou un tiers disposant d'une expertise spécifique peut souvent vous aider à mener à bien le nettoyage.
Étape 5. Récupérer
Passer de l'éradication à la guérison, c'est comme sortir d'une opération chirurgicale. Le mal est fait, et il est désormais temps de se concentrer sur la guérison.
Du point de vue de la gestion des incidents, il est temps de faire preuve d'une grande honnêteté envers vous-même en répondant aux questions suivantes :
- Quand pourrez-vous remettre les systèmes concernés en production ?
- Les avez-vous mises à jour, sécurisées et testées ?
- Avez-vous fait appel à votre équipe « red team » interne pour mener une simulation d'attaque contre ces systèmes en utilisant les mêmes techniques que les pirates ?
La capacité de reprise s'évalue en fonction de la rapidité avec laquelle vous pouvez rétablir le fonctionnement des systèmes et des processus affectés, tel qu'il était avant l'incident. La reprise implique également de définir comment vous allez modifier le périmètre de votre surveillance après l'incident. Déterminez la durée pendant laquelle vous allez surveiller l'activité à l'origine de la violation (par exemple, 30 jours, trois mois ou six mois) et ce que vous recherchez précisément.
Là encore, les tests effectués par l'équipe rouge et les éléments de preuve recueillis pendant la phase de confinement seront utiles à cet égard. À la fin de la phase de remise en état, vous souhaitez pouvoir dire : « Nous avons corrigé les vulnérabilités, et en voici la preuve. »
On observe une forte tendance chez les professionnels de la sécurité à réduire le temps moyen de réparation (MTTR), c'est-à-dire le temps nécessaire pour passer par les phases d'identification, de confinement et d'éradication. À mesure que les plans d'intervention en cas d'incident (IR) gagnent en maturité et que les équipes perfectionnent leur mise en œuvre, les indicateurs MTTR (temps moyen de réparation) et MTTD (temps moyen de détection) devraient diminuer. Le suivi de ces indicateurs au fil du temps peut vous aider à déterminer si le cadre PICERL constitue un modèle efficace de gestion des incidents pour votre organisation.
Étape 6. Enseignements tirés
Cette étape devrait débuter par une réunion de bilan à laquelle participent tous les membres de l'équipe d'intervention en cas d'incident ainsi que les services concernés, tels que la sécurité de l'information, la conformité, le service juridique, les relations publiques, etc. C'est ici que vous pouvez passer en revue et consigner ce que vous avez appris au sujet de l'incident, notamment :
- Quels aspects de votre plan de relations avec les investisseurs ont bien fonctionné ? Qu'est-ce qui n'a pas fonctionné ?
- Y avait-il des postes à pourvoir qui nécessitaient du personnel supplémentaire ? Aviez-vous besoin de contacter un tiers ou une équipe interne ne figurant pas sur votre liste de ressources ?
- Au vu de cet incident, devons-nous modifier notre mode de fonctionnement ?
- Utilisions-nous efficacement les outils dont nous disposions ? Ont-ils été correctement configurés ?
- Comment s'est passée la communication entre les équipes ? Pourrait-on l'améliorer ?
- Cette violation comportait-elle un aspect lié au personnel, tel qu'une attaque par ingénierie sociale de type « » ou un traitement inapproprié des données ? Est-ce que la formation permet de remédier à ce problème ?
- Cette faille de sécurité a-t-elle été exploitée uniquement au sein d'un secteur d'activité particulier ou était-elle généralisée à l'ensemble de l'organisation ?
- Pourrions-nous remédier à cette vulnérabilité en recourant à une structure ou à un processus opérationnel différent ?
Plus le plan de gestion des incidents est souple, plus vous en tirerez des enseignements lorsqu'un incident se produira. Ensuite, tout ce que vous apprenez doit être réintégré dans votre phase de préparation afin d'être affiné et amélioré.
Le PICERL est-il différent du NIST ?
Le PICERL et le cadre de cybersécurité du NIST ( , ) constituent des méthodologies couramment utilisées pour la gestion des incidents, mais elles diffèrent par leur structure et leurs priorités.
[Read also: Operationalizing the NIST Cybersecurity Framework 2,0 with Tanium]
PICERL propose une approche séquentielle de la gestion d'un incident de sécurité, articulée en six phases. En revanche, le NIST propose un ensemble de lignes directrices plus large et plus souple, articulé autour de cinq fonctions essentielles (Identifier, Protéger, Détecter, Réagir et Restaurer) afin d'aider les organisations à gérer les risques liés à la cybersécurité.
PICERL est un guide détaillé consacré à la réponse aux incidents, tandis que le cadre du NIST constitue un guide plus complet pour la gestion globale des risques liés à la cybersécurité au sein de l' . Toutefois, le cadre du NIST est généralement considéré comme non normatif et ne propose qu'une taxonomie des résultats de cybersécurité de haut niveau ainsi que des liens vers des ressources permettant d'atteindre ces résultats.
Quelles sont les implications pour votre plan d'intervention en cas d'incident ? Les organisations ont généralement recours au PICERL pour la gestion des incidents dans le cadre plus large du référentiel du NIST, afin de gérer efficacement les risques liés à la cybersécurité.
Le modèle PICERL est-il le meilleur modèle de gestion des incidents ?
PICERL propose une approche détaillée et structurée de la gestion des incidents, qui peut s'avérer utile pour les grandes organisations ou celles dont les environnements informatiques sont plus complexes. Toutefois, le cadre PICERL peut également poser certains défis, tels que la nécessité d'une préparation approfondie, la complexité potentielle liée à l'identification et à la maîtrise des incidents, ainsi que la nécessité de veiller à ce que l'ensemble du personnel soit correctement formé.
Ces défis ont ouvert la voie à de nouveaux modèles de gestion des incidents, conçus pour offrir des approches plus souples que les cadres reposant sur des processus agiles tels que PICERL – et marquent un tournant décisif dans la manière dont les organisations doivent repenser les stratégies nécessaires à une gestion efficace des incidents.
L'un de ces modèles est le SOAR, c'est-à-dire « Security Orchestration, Automation» et « Response». SOAR est axé sur l'automatisation des réponses et peut s'avérer particulièrement utile pour les organisations disposant de ressources limitées pour gérer les incidents nécessitant une intervention immédiate.
De même, l’approche « » (DAIR), ou « D» (ynamic A) Incident Response, gagne également en popularité car elle met l’accent sur une approche de la réponse aux incidents s’appuyant sur des points de repère, ou étapes clés, qui ne doivent pas nécessairement se succéder dans un ordre séquentiel comme dans le modèle PICERL. Le modèle DAIR vous aide à vous concentrer sur les résultats et les activités qui permettent d'atteindre ces résultats, plutôt que de suivre une approche par étapes.
Compte tenu de la nature chaotique des cybermenaces, la capacité à faire face rapidement à des attaques de plus en plus sophistiquées implique que les plans modernes de réponse aux incidents et les outils utilisés pour les soutenir doivent être capables de s'adapter et de remédier rapidement aux menaces, et ce malgré des budgets plus serrés et une pénurie de talents dans le domaine de la cybersécurité..
Puisque les incidents de sécurité d’aujourd’hui ne suivent pas de règles établies, pourquoi votre plan d’intervention en cas d’incident devrait-il en suivre ?
Comment choisir un cadre de gestion des incidents
Dans cet article, nous avons découvert comment PICERL s'est toujours démarqué dans le domaine des modèles de sécurité en proposant une feuille de route détaillée pour la gestion des incidents. Toutefois, chaque modèle d'intervention en cas d'incident présente ses atouts et ses défis.
En fin de compte, les plans d'intervention en cas d'incident auxquels votre organisation se conforme doivent être adaptés aux enjeux spécifiques de votre secteur en matière de cybersécurité. Pour que les plans de relations avec les investisseurs soient efficaces, ils doivent également tirer parti de manière optimale des ressources, des outils et du personnel disponibles, tout en s'avérant applicables dans des situations concrètes et adaptables pour faire face aux nouvelles menaces à mesure qu'elles apparaissent.
L'amélioration et l'évolution continues de votre plan d'intervention en cas d'incident sont essentielles pour garder une longueur d'avance en matière de cybersécurité. Qu'il s'agisse de PICERL, de DAIR ou d'un autre modèle spécialement conçu pour répondre aux besoins de votre organisation, l'essentiel est d'élaborer un plan qui réponde aux besoins actuels en matière de sécurité et qui permette à votre organisation d'affronter les futures cybermenaces en toute confiance.
Tanium offre une assistance inégalée en matière de cybersécurité pour l’ensemble des environnements grâce à « Tanium Incident Response », qui remplace les outils ponctuels disparates par une solution unifiée permettant aux organisations d’identifier, de gérer et de corriger rapidement les vulnérabilités.
Tanium renforce les capacités de vos outils SIEM et EDR actuels, transformant ainsi les efforts de détection des menaces et de réponse aux incidents en mesures de défense proactives qui garantissent une perturbation minimale de la productivité des utilisateurs et renforcent votre cyber-résilience.
En tirant parti d'une visibilité en temps réel et de données complètes sur les terminaux, ainsi que de la solution « Tanium Automate » d', notre technologie de pointe conçue pour automatiser à grande échelle des tâches complexes ne nécessitant que peu, voire aucune expertise en programmation, les équipes de toute taille et de tout niveau de compétence peuvent gagner en efficacité, en productivité et en performance.
Prenez rendez-vous pour une démonstration personnalisée en direct afin de découvrir Tanium dans votre environnement.
