Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Processus L'élaboration de processus de réponse aux incidents complets et clairement définis est essentielle à la réussite et à l'évolutivité du programme de réponse aux incidents. Lorsqu'un événement de sécurité survient, des étapes et des flux de travail clairs vous aideront à réagir rapidement. Il se peut que vous disposiez déjà d'un processus de réponse aux incidents. Quel que soit votre état actuel, il est important de mettre à jour, d’itérer et de tester régulièrement vos processus de réponse aux incidents. # Élaboration et test d'un plan de réponse aux incidents Le premier document à développer pour la réponse aux incidents est le *plan de réponse aux incidents*. Le plan d’intervention en cas d’incident est conçu pour servir de base à votre programme et à votre stratégie de réponse aux incidents. Un plan de réponse aux incidents est un document de haut niveau qui comprend généralement les sections suivantes : + **Vue d'ensemble de l'équipe de réponse aux incidents** : décrit les objectifs et les fonctions de l'équipe de réponse aux incidents + **Rôles et responsabilités** — Répertorie les parties prenantes de la réponse aux incidents et détaille leurs rôles en cas d'incident + **Un plan de communication** — Détaille les informations de contact et la manière dont vous communiquerez lors d'un incident Il est recommandé d'utiliser la out-of-band communication comme solution de rechange à la communication en cas d'incident. [AWS Wickr](https://aws.amazon.com/wickr/) est un exemple d'application fournissant un canal de out-of-band communication sécurisé. + **Phases de réponse aux incidents et mesures à prendre** — Énumère les phases de réponse aux incidents (par exemple, détecter, analyser, éradiquer, contenir et rétablir), y compris les actions de haut niveau à prendre au cours de ces phases + **Définitions de la gravité et de la hiérarchisation des incidents** : explique comment classer la gravité d'un incident, comment hiérarchiser l'incident, puis comment les définitions de gravité affectent les procédures d'escalade Bien que ces sections soient communes à des entreprises de tailles et de secteurs différents, le plan d’intervention en cas d’incident de chaque organisation est unique. Vous devrez élaborer un plan de réponse aux incidents qui convient le mieux à votre organisation. # Documenter et centraliser les diagrammes d'architecture Pour réagir rapidement et avec précision à un événement de sécurité, vous devez comprendre l'architecture de vos systèmes et réseaux. La compréhension de ces modèles internes est non seulement importante pour la réponse aux incidents, mais également pour vérifier la cohérence entre les applications avec lesquelles les modèles sont conçus, conformément aux meilleures pratiques. Vous devez également vérifier que cette documentation est à jour et régulièrement mise à jour conformément aux nouveaux modèles d'architecture. Vous devez développer une documentation et des référentiels internes détaillant des éléments tels que : + **AWS structure du compte** - Vous devez savoir : + Combien de AWS comptes possèdes-tu ? + Comment sont organisés ces AWS comptes ? + Qui sont les propriétaires commerciaux des AWS comptes ? + Utilisez-vous les politiques de contrôle des services (SCPs) ? Dans l'affirmative, quels sont les garde-fous organisationnels mis en œuvre en utilisant ? SCPs + Limitez-vous les régions et les services qui peuvent être utilisés ? + Quelles sont les différences entre les unités commerciales et les environnements (dev/test/prod) ? + **AWS modèles de service** + Quels sont AWS les services que vous utilisez ? + Quels sont les AWS services les plus utilisés ? + **Modèles d'architecture** + Quelles architectures cloud utilisez-vous ? + **AWS modèles d'authentification** + Comment vos développeurs s'authentifient-ils généralement ? AWS + Utilisez-vous des rôles ou des utilisateurs IAM (ou les deux) ? Votre système d'authentification est-il AWS connecté à un fournisseur d'identité (IdP) ? + Comment associer un rôle ou un utilisateur IAM à un employé ou à un système ? + Comment l'accès est-il révoqué lorsqu'une personne n'est plus autorisée ? + **AWS modèles d'autorisation** + Quelles sont les politiques IAM utilisées par vos développeurs ? + Utilisez-vous des politiques basées sur les ressources ? + **Journalisation et surveillance** + Quelles sources de journalisation utilisez-vous et où sont-elles stockées ? + Agrégez-vous AWS CloudTrail les journaux ? Dans l'affirmative, où sont-ils conservés ? + Comment interrogez-vous CloudTrail les journaux ? + Amazon est-il GuardDuty activé ? + Comment accèdez-vous aux GuardDuty résultats (par exemple, console, système de billetterie, SIEM) ? + Les résultats ou les événements sont-ils agrégés dans un SIEM ? + Les tickets sont-ils créés automatiquement ? + Quels sont les outils mis en place pour analyser les journaux dans le cadre d'une enquête ? + **Topologie du réseau** + Comment les appareils, les points de terminaison et les connexions de votre réseau sont-ils organisés physiquement ou logiquement ? + Comment se connecte votre réseau AWS ? + Comment le trafic réseau est-il filtré entre les environnements ? + **Infrastructures externes** + Comment sont déployées les applications orientées vers l'extérieur ? + Quelles AWS ressources sont accessibles au public ? + Quels AWS comptes contiennent des infrastructures orientées vers l'extérieur ? + Quel DDo type de filtrage S ou externe existe-t-il ? La documentation des schémas techniques et des processus internes facilite le travail de l'analyste de réponse aux incidents, en l'aidant à acquérir rapidement les connaissances institutionnelles nécessaires pour répondre à un événement de sécurité. Une documentation complète des processus techniques internes simplifie non seulement les enquêtes de sécurité, mais permet également de rationaliser et d'évaluer les processus. # Élaborez des manuels de réponse aux incidents L’élaboration de playbooks est une étape clé de la préparation de vos processus de réponse aux incidents. Les playbooks de réponse aux incidents fournissent une série de recommandations et d’étapes à suivre en cas d’événement de sécurité. Le fait de disposer d’une structure et d’étapes claires simplifie la réponse et réduit le risque d’erreur humaine. # Pour quoi créer des playbooks Il est recommandé de créer des playbooks dans les scénarios d’incidents suivants : + **Incidents attendus** — Des playbooks doivent être créés pour les incidents que vous anticipez. Cela inclut des menaces telles que le déni de service (DoS), les rançongiciels et la mise en péril des informations d’identification. + **Constatations ou alertes de sécurité connues** — Des playbooks doivent être créés pour vos découvertes et alertes de sécurité connues, telles que GuardDuty les découvertes. Vous pourriez recevoir une GuardDuty découverte et vous demander : « Et maintenant ? » Pour éviter de mal gérer un GuardDuty résultat ou de l'ignorer, créez un manuel pour chaque résultat potentiel GuardDuty. Vous trouverez des informations et des conseils sur les mesures correctives dans la [GuardDutydocumentation](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Il convient de noter que cela n' GuardDuty est pas activé par défaut et qu'il entraîne un coût. GuardDuty Vous trouverez plus de détails à ce sujet dans l'annexe A : Définitions des fonctionnalités cloud -[Visibilité et alertes](visibility-and-alerting.md). # Ce qu'il faut inclure dans les playbooks Les playbooks doivent contenir les étapes techniques qu’un analyste de sécurité doit suivre afin d’enquêter de manière adéquate et de répondre à un éventuel incident de sécurité. Les éléments à inclure dans un playbook incluent : + **Présentation du playbook** — Quel scénario de risque ou d'incident ce playbook aborde-t-il ? Quel est l’objectif du playbook ? + **Conditions préalables** — Quels journaux et mécanismes de détection sont nécessaires pour ce scénario d'incident ? Quelle est la notification attendue ? + **Informations sur les parties prenantes** — Qui est impliqué et quelles sont ses coordonnées ? Quelles sont les responsabilités de chacune des parties prenantes ? + **Étapes de réponse** — Quelles mesures tactiques devraient être prises au cours des différentes phases de la réponse aux incidents ? Quelles requêtes un analyste doit-il exécuter ? Quel code doit être exécuté pour obtenir le résultat souhaité ? + **Détecter** — Comment l'incident sera-t-il détecté ? + **Analyser** — Comment l'ampleur de l'impact sera-t-elle déterminée ? + **Contenir** — Comment l'incident sera-t-il isolé pour en limiter la portée ? + **Éradiquer** — Comment la menace sera-t-elle éliminée de l'environnement ? + **Restaurer** — Comment le système ou la ressource concernés seront-ils remis en production ? + **Résultats attendus** — Une fois les requêtes et le code exécutés, quel est le résultat attendu du playbook ? Pour vérifier la cohérence des informations contenues dans chaque playbook, il peut être utile de créer un modèle de playbook à utiliser dans vos autres playbooks de sécurité. Certains des éléments listés précédemment, tels que les informations sur les parties prenantes, peuvent être partagés entre plusieurs playbooks. Si tel est le cas, vous pouvez créer une documentation centralisée pour ces informations et la référencer dans le playbook, puis énumérer les différences explicites dans le playbook. Cela vous évitera d'avoir à mettre à jour les mêmes informations dans tous vos playbooks individuels. En créant un modèle et en identifiant les informations communes ou partagées dans les playbooks, vous pouvez simplifier et accélérer le développement des playbooks. Enfin, vos playbooks évolueront probablement au fil du temps ; une fois que vous aurez confirmé que les étapes sont cohérentes, cela constitue la condition requise pour l'automatisation. # Exemples de playbooks Vous trouverez un certain nombre d'exemples de playbooks à l'annexe B dans[Ressources du Playbook](appendix-b-incident-response-resources.md#playbook-resources). Les exemples présentés ici peuvent vous aider à choisir les playbooks à créer et les éléments à inclure dans vos playbooks. Cependant, il est important que vous élaboriez des stratégies qui intègrent les risques les plus pertinents pour votre entreprise. Vous devez vérifier que les étapes et les flux de travail de vos playbooks incluent vos technologies et processus. # Exécutez des simulations régulières Organisations grandissent et évoluent au fil du temps, tout comme le paysage des menaces. C'est pourquoi il est important de revoir en permanence vos capacités de réponse aux incidents. Les simulations sont l'une des méthodes qui peuvent être utilisées pour effectuer cette évaluation. Les simulations utilisent des scénarios d'événements de sécurité réels conçus pour imiter les tactiques, les techniques et les procédures d'un acteur menaçant (TTPs) et permettre à une organisation d'exercer et d'évaluer ses capacités de réponse aux incidents en réagissant à ces cyberévénements simulés tels qu'ils peuvent se produire dans la réalité. Les simulations présentent de nombreux avantages, notamment : + Validation de l’état de préparation à la cybersécurité et renforcement de la confiance de vos intervenants en cas d’incident. + Test de la précision et de l’efficacité des outils et des flux de travail. + Amélioration des méthodes de communication et de remontées en fonction de votre plan d’intervention en cas d’incident. + Possibilité de répondre à des vecteurs moins courants. # Types de simulations Il existe trois principaux types de simulations : + **Exercices sur table** — L'approche théorique des simulations est strictement une session basée sur des discussions impliquant les différents acteurs de la réponse aux incidents afin de mettre en pratique leurs rôles et responsabilités et d'utiliser les outils de communication et les manuels de stratégie établis. La facilitation des exercices peut généralement être réalisée en une journée complète dans un lieu virtuel, un lieu physique ou une combinaison des deux. En raison de sa nature basée sur la discussion, l'exercice sur table met l'accent sur les processus, les personnes et la collaboration. La technologie fait partie intégrante de la discussion ; toutefois, l'utilisation réelle d'outils ou de scripts de réponse aux incidents ne fait généralement pas partie de l'exercice théorique. + **Exercices Purple Team** — Les exercices Purple Team augmentent le niveau de collaboration entre les intervenants en cas d'incident (*équipe bleue*) et les acteurs de menaces simulés (*équipe rouge*). L'équipe bleue est généralement composée de membres du Security Operations Center (SOC), mais peut également inclure d'autres parties prenantes qui seraient impliquées lors d'un véritable cyberévénement. L'équipe rouge est généralement composée d'une équipe de tests d'intrusion ou de parties prenantes clés formées à la sécurité offensive. L'équipe rouge travaille en collaboration avec les animateurs de l'exercice lors de la conception d'un scénario afin que celui-ci soit précis et réalisable. Au cours des exercices Purple Team, l'accent est mis principalement sur les mécanismes de détection, les outils et les procédures opérationnelles standard (SOPs) qui soutiennent les efforts de réponse aux incidents. + **Exercices de l'équipe rouge** — Au cours d'un exercice de l'*équipe rouge, l'attaque (l'équipe rouge*) effectue une simulation pour atteindre un certain objectif ou un ensemble d'objectifs dans un cadre prédéterminé. Les défenseurs (*Blue Team*) ne connaîtront pas nécessairement la portée et la durée de l'exercice, ce qui permet une évaluation plus réaliste de la manière dont ils réagiraient en cas d'incident réel. Comme les exercices Red Team peuvent être des tests invasifs, vous devez faire preuve de prudence et mettre en place des contrôles pour vérifier que l'exercice ne cause pas de dommages réels à votre environnement. **Note** AWS demande aux clients de consulter la politique relative aux tests d'intrusion disponible sur le [site Web des tests de pénétration](https://aws.amazon.com/security/penetration-testing/) avant d'effectuer des exercices Purple Team ou Red Team. Le tableau 1 résume quelques différences clés entre ces types de simulations. Il est important de noter que les définitions sont généralement considérées comme des définitions vagues et peuvent être personnalisées pour répondre aux besoins de votre organisation. *Tableau 1 — Types de simulations* | | Exercice sur table | Exercice Purple Team | Exercice Red Team | | --- | --- | --- | --- | | Résumé | Des exercices sur support papier qui se concentrent sur un scénario d'incident de sécurité spécifique. Ils peuvent être de haut niveau ou techniques et sont entraînés par une série d'injections de papier. | Une offre plus réaliste que les exercices sur table. Au cours des exercices Purple Team, les animateurs travaillent en collaboration avec les participants pour accroître leur engagement et proposer des formations si nécessaire. | Il s'agit généralement d'une offre de simulation plus avancée. Il y a généralement un niveau élevé de discrétion, les participants ne connaissant peut-être pas tous les détails de l'exercice. | | Ressources nécessaires | Ressources techniques limitées requises | Diverses parties prenantes sont requises et des ressources techniques de haut niveau sont nécessaires | Diverses parties prenantes sont requises et des ressources techniques de haut niveau sont nécessaires | | Complexité | Faible | Medium | Élevée | Envisagez d’animer des simulations cybernétiques à intervalles réguliers. Chaque type d'exercice peut apporter des avantages uniques aux participants et à l'organisation dans son ensemble. Vous pouvez donc choisir de commencer par des types de simulation moins complexes (tels que des exercices sur table) et de passer à des types de simulation plus complexes (exercices Red Team). Vous devez sélectionner un type de simulation en fonction de la maturité de votre sécurité, de vos ressources et des résultats souhaités. Certains clients peuvent choisir de ne pas effectuer les exercices Red Team en raison de leur complexité et de leur coût. # Cycle de vie des exercices Quel que soit le type de simulation que vous choisissez, les simulations suivent généralement les étapes suivantes : 1. **Définir les principaux éléments de l'exercice** : définissez le scénario de simulation et les objectifs de la simulation. Les deux doivent être acceptés par les dirigeants. 1. **Identifier les principales parties prenantes** — À tout le moins, un exercice nécessite des animateurs et des participants. Selon le scénario, d’autres parties prenantes telles que les services juridiques, l’équipe de communication ou la direction, peuvent être impliquées. 1. **Élaborez et testez le scénario** : le scénario devra peut-être être redéfini au fur et à mesure de sa création si certains éléments ne sont pas réalisables. Un scénario finalisé est attendu à l’issue de cette étape. 1. **Faciliter la simulation** — Le type de simulation détermine la facilitation utilisée (scénario papier par rapport à un scénario simulé hautement technique). Les animateurs doivent adapter leurs tactiques d’animation aux objectifs de l’exercice et impliquer tous les participants dans l’exercice dans la mesure du possible afin d’en tirer le meilleur parti. 1. **Élaborer le rapport après action (AAR)** — Identifiez les domaines qui se sont bien déroulés, ceux qui peuvent être améliorés et les lacunes potentielles. L’AAR doit mesurer l’efficacité de la simulation ainsi que la réponse de l’équipe à l’événement simulé afin que les progrès puissent être suivis au fil du temps lors de futures simulations.