# Préparation
Pour une réponse rapide et efficace aux incidents, la préparation est essentielle. La préparation couvre trois domaines :
+ **Personnel :** pour préparer votre personnel à un incident de sécurité, vous devez identifier les parties prenantes et les former à la réponse aux incidents et aux technologies cloud.
+ **Processus :** la préparation de vos processus en cas d’incident de sécurité implique de documenter les architectures, d’élaborer des stratégies de réponse complètes aux incidents et de créer des guides pour un gestion cohérente des événements de sécurité.
+ **Technologie :** pour préparer votre technologie à un incident de sécurité, vous devez configurer l’accès, agréger et surveiller les journaux nécessaires, mettre en œuvre des mécanismes d’alerte efficaces et développer des fonctionnalités de réponse et d’investigation.
Chacun de ces domaines joue un rôle tout aussi important pour une réponse efficace aux incidents. Aucun programme de réponse aux incidents n’est complet ou efficace sans ces trois aspects. Au cours de la préparation, vous devez intégrer étroitement le personnel, les processus et la technologie afin de pouvoir faire face aux incidents.
**Topics**
+ [SEC10-BP01 Identifier les postes clés internes ainsi que les principales ressources externes](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Développer des plans de gestion des incidents](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Préparer les fonctionnalités d’analyse poussée](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Développer et tester des playbooks de réponse aux incidents de sécurité](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Préallouer les accès](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Prédéployer les outils](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Exécuter des simulations](sec_incident_response_run_game_days.md)
# SEC10-BP01 Identifier les postes clés internes ainsi que les principales ressources externes
Identifiez les postes clés internes et externes, les ressources et les obligations légales qui aideront votre organisation à réagir en cas d’incident.
**Résultat escompté :** vous disposez d’une liste des principaux membres du personnel, de leurs coordonnées et des rôles qu’ils jouent lorsqu’ils répondent à un événement de sécurité. Vous consultez régulièrement ces informations et vous les mettez à jour de façon à refléter les changements de personnel du point de vue des outils internes et externes. Lorsque vous documentez ces informations, vous tenez compte de tous les fournisseurs de services et fournisseurs tiers, y compris les partenaires de sécurité, les fournisseurs de cloud et les applications de logiciel en tant que service (SaaS). Lors d’un événement de sécurité, le personnel est disponible avec le niveau de responsabilité, de contexte et d’accès approprié pour être en mesure de réagir et de récupérer.
**Anti-modèles courants :**
+ Ne pas gérer une liste actualisée des principaux membres du personnel avec leurs coordonnées, leurs rôles et leurs responsabilités lorsqu’ils répondent à des événements de sécurité.
+ Supposer que tout le monde comprend les personnes, les dépendances, l’infrastructure et les solutions lors de la réponse et de la reprise après un événement.
+ Ne pas disposer d’un document ou d’un référentiel de connaissances représentant la conception d’une infrastructure ou d’une application clé.
+ Ne pas disposer de processus d’intégration appropriés permettant aux nouveaux employés de contribuer efficacement à la réponse à un événement de sécurité, par exemple en effectuant des simulations d’événements.
+ Aucune procédure de remontée n’est en place lorsque le personnel clé est temporairement indisponible ou s’il ne répond pas lors d’événements de sécurité.
**Avantages liés au respect de cette bonne pratique :** cette pratique réduit le temps de triage et de réponse consacré à l’identification du personnel approprié et de ses rôles lors d’un événement. Minimisez le temps perdu lors d’un événement en tenant à jour une liste des principaux membres du personnel et de leurs rôles afin de pouvoir faire le tri des personnes appropriées et de les aider à récupérer après un événement.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
**Identifier les postes clés au sein de votre organisation :** tenez à jour une liste des employés au sein de votre organisation que vous devez impliquer. Passez régulièrement en revue et mettez à jour ces informations en cas de changements au sein du personnel, par exemple des changements organisationnels, des promotions et des changements d’équipe. Cette étape est particulièrement importante pour les rôles clés tels que les gestionnaires d’incidents, les intervenants en cas d’incident et le responsable des communications.
+ **Gestionnaire d’incidents :** les gestionnaires d’incidents ont une autorité globale lors de la réponse à l’événement.
+ **Intervenants en cas d’incidents :** les intervenants en cas d’incidents sont responsables des activités d’enquête et de correction. Ces personnes peuvent varier en fonction du type d’événement, mais il s’agit généralement de développeurs et d’équipes opérationnelles responsables de l’application concernée.
+ **Responsable des communications :** le responsable des communications est responsable des communications internes et externes, en particulier avec les agences publiques, les régulateurs et les clients.
+ **Processus d’intégration :** formez et intégrez régulièrement les nouveaux employés afin de les doter des compétences et des connaissances nécessaires pour contribuer efficacement aux efforts de réponse aux incidents. Incorporez des simulations et des exercices pratiques dans le cadre du processus d’intégration afin de faciliter leur préparation.
+ **Experts en la matière (PME) :** dans le cas d’équipes distribuées et autonomes, nous vous recommandons d’identifier une PME pour les charges de travail critiques. Ils fournissent des informations sur le fonctionnement et la classification des données des charges de travail critiques impliquées dans l’événement.
Exemple de format de table :
```
| Role | Name | Contact Information | Responsibilities |
1 | ——– | ——- | ——- | ——- |
2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response |
3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation |
4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications |
5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads |
```
Envisagez d’utiliser la fonctionnalité [AWSSystems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) pour capturer les contacts clés, définir un plan d’intervention, automatiser les plannings d’astreinte et définir des plans d’escalade. Automatisez et alternez tout le personnel grâce à un calendrier d’astreinte, de sorte que la responsabilité de la charge de travail soit partagée entre ses propriétaires. Cela favorise les bonnes pratiques, telles que l’émission de métriques et de journaux pertinents, ainsi que la définition de seuils d’alarme importants pour la charge de travail.
**Identifier les partenaires externes :** les entreprises utilisent des outils conçus par des fournisseurs indépendants de logiciels (ISV), des partenaires et des sous-traitants pour créer des solutions différenciantes pour leurs clients. Impliquez le personnel clé de ces parties qui peut vous aider à répondre à un incident et à récupérer après un incident. Nous vous recommandons de vous inscrire au niveau approprié d’Support afin d’accéder rapidement à des experts AWS en la matière par le biais d’une demande d’assistance. Envisagez des agencements similaires avec tous les fournisseurs de solutions critiques pour les charges de travail. Certains événements de sécurité obligent les entreprises cotées en bourse à informer les agences publiques et les régulateurs concernés de l’événement et de ses impacts. Dressez une liste avec les coordonnées des départements concernés et des personnes responsables, et veillez à ce qu’elle reste à jour.
## Étapes d’implémentation
1. Mettez en place une solution de gestion des incidents.
1. Envisagez de déployer Incident Manager dans votre compte d’outils de sécurité.
1. Définissez les contacts dans votre solution de gestion des incidents.
1. Définissez au moins deux types de canaux de communication pour chaque contact (SMS, téléphone ou e-mail, par exemple), afin de pouvoir avec certitude joindre les personnes concernées lors d’un incident.
1. Définissez un plan d’intervention.
1. Identifiez les contacts les plus appropriés à impliquer lors d’un incident. Définissez des plans de remontée en fonction des rôles du personnel à impliquer, plutôt que des contacts individuels. Envisagez d’inclure des contacts susceptibles d’être chargés d’informer les entités externes, même s’ils ne sont pas directement impliqués dans la résolution de l’incident.
## Ressources
**Bonnes pratiques associées:**
+ [OPS02-BP03 Les activités opérationnelles ont des propriétaires identifiés responsables de leurs performances](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html)
**Documents connexes:**
+ [AWS Guide d’intervention en cas d’incident de sécurité](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Exemples connexes:**
+ [AWS Cadre du playbook du client](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Prepare for and respond to security incidents in your environment AWS](https://youtu.be/8uiO0Z5meCs)
**Outils associés:**
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**Vidéos connexes:**
+ [L’approche d’Amazon en matière de sécurité pendant le développement](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 Développer des plans de gestion des incidents
Le premier document à élaborer pour la réponse aux incidents est le plan d’intervention en cas d’incident. 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.
**Avantages liés au respect de cette bonne pratique :** le développement de processus de réponse aux incidents complets et clairement définis est essentiel à la réussite d’un programme de réponse aux incidents évolutif. Lorsqu’un incident de sécurité se produit, des étapes et des flux de travail clairs peuvent vous aider à réagir rapidement. Vous disposez peut-être déjà de 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.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Un plan de gestion des incidents est essentiel pour réagir, atténuer et se remettre des répercussions potentielles des incidents de sécurité. Un plan de gestion des incidents est un processus structuré qui permet d’identifier les incidents de sécurité, d’y remédier et d’y répondre rapidement.
Le cloud comporte un grand nombre de rôles et exigences opérationnels identiques à ceux d’un environnement sur site. Lorsque vous créez un plan de gestion des incidents, il est important de tenir compte des stratégies d’intervention et de récupération qui correspondent le mieux aux résultats métier et aux exigences de conformité. Par exemple, si vous exécutez des charges de travail dans AWS qui sont conformes à FedRAMP aux États-Unis, suivez les recommandations fournies dans le document [NIST SP 800-61 Guide relatif à la gestion de la sécurité informatique](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). De la même manière, lorsque vous exécutez des charges de travail qui stockent des données d’identification personnelle (PII), réfléchissez à la façon de protéger ces données et de résoudre les problèmes liés à la résidence et à l’utilisation des données.
Lorsque vous élaborez un plan de gestion des incidents pour vos charges de travail dans AWS, commencez par le [modèle de responsabilité partagée AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) pour élaborer une approche de défense approfondie en matière d’intervention en cas d’incidents. Dans le cadre de ce modèle, AWS gère la sécurité du cloud et vous êtes responsable de la sécurité dans le cloud. Cela signifie que vous conservez le contrôle et que vous êtes responsable des contrôles de sécurité que vous choisissez d’implémenter. Le [Guide sur les interventions en cas d’incident de sécurité AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) détaille les concepts clés et les conseils de base pour l’élaboration d’un plan de gestion des incidents axé sur le cloud.
Un plan de gestion des incidents efficace doit être répété constamment, tout en poursuivant votre objectif d’opérations dans le cloud. Envisagez d’utiliser les plans d’implémentation décrits ci-dessous pour créer et faire évoluer votre plan de gestion des incidents.
### Étapes d’implémentation
1. Définissez les rôles et les responsabilités au sein de votre organisation pour gérer les événements de sécurité. Cela devrait impliquer des représentants de différents départements, notamment :
+ Ressources humaines (RH)
+ Équipe de direction
+ Département juridique
+ Propriétaires et développeurs d’applications (experts spécifiques ou SME)
1. Désignez clairement les intervenants responsables, redevables, consultés et informés (RACI, Responsible, Accountable, Consulted, Informed) lors d’un incident. Créez une matrice RACI pour faciliter une communication rapide et directe, et désignez clairement le leadership aux différentes étapes d’un événement.
1. Impliquez les propriétaires et les développeurs d’applications (SME) lors d’un incident, car ils peuvent fournir des informations et un contexte précieux pour la mesure de l’impact. Établissez des relations avec ces SME et mettez en pratique des scénarios de réponse aux incidents avec elles avant qu’un véritable incident se produise.
1. Impliquez des partenaires de confiance ou des experts externes dans le processus d’enquête ou de réponse, car ils peuvent apporter une expertise et un point de vue supplémentaires.
1. Alignez vos rôles et plans de gestion des incidents sur les réglementations locales ou les exigences de conformité qui régissent votre organisation.
1. Mettez en pratique et testez régulièrement vos plans de réponse aux incidents, et impliquez tous les rôles et responsabilités définis. Cela contribue à rationaliser le processus et à vérifier que vous disposez d’une réponse coordonnée et efficace aux incidents de sécurité.
1. Passez en revue et mettez à jour les rôles, les responsabilités et la matrice RACI régulièrement ou à mesure que votre structure organisationnelle ou vos exigences changent.
**Comprenez les équipes d’intervention et le support AWS**
+ **AWS Support**
+ [Support](https://aws.amazon.com/premiumsupport/) propose un large choix de formules qui vous permettent d’accéder aux outils et aux compétences nécessaires pour garantir la réussite et la santé opérationnelle de vos solutions AWS. Si vous avez besoin d’un support technique et de ressources supplémentaires pour planifier, déployer et optimiser votre environnement AWS, vous pouvez sélectionner le plan de support le plus adapté à votre cas d’utilisation AWS.
+ Considérez le [Centre d’assistance](https://console.aws.amazon.com/support) dans AWS Management Console (connexion requise) en tant que point de contact central pour obtenir de l’aide en cas de problèmes affectant vos ressources AWS. L’accès à Support est contrôlé par Gestion des identités et des accès AWS. Pour plus d’informations sur l’accès aux fonctionnalités Support, consultez [Démarrer avec Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
+ **AWS Équipe de réponse aux incidents clients (CIRT)**
+ L’équipe de réponse aux incidents clients (CIRT) AWS est une équipe AWS internationale spécialisée et disponible 24 heures sur 24, 7 jours sur 7, qui fournit une assistance aux clients lors d’événements de sécurité actifs côté client du [ Modèle de responsabilité partagée AWS](https://aws.amazon.com/compliance/shared-responsibility-model/).
+ Lorsque la CIRT AWS vous accompagne, elle fournit une assistance en matière de triage et de récupération en cas d’événement de sécurité actif sur AWS. Elle peut vous aider à analyser les causes profondes à l’aide des journaux de service AWS et vous fournir des recommandations pour la récupération. Elle peut également fournir des recommandations de sécurité et des bonnes pratiques pour vous aider à éviter des incidents de sécurité à l’avenir.
+ Les clients AWS peuvent contacter la CIRT AWS par le biais d’un [cas Support](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)
+ Annoncé à l’occasion de re:Invent 2024, Réponse aux incidents de sécurité AWS est un service géré de réponse aux incidents de sécurité qui associe la technologie de triage moderne et une intervention humaine. Le service ingère tous les résultats de GuardDuty et les résultats tiers envoyés à AWS Security Hub CSPM pour triage afin d’avertir le client uniquement des résultats nécessitant une enquête. Le service fournit également un portail permettant de soumettre des cas réactifs en cas d’événement de sécurité remarqué par le client et de bénéficier de l’assistance d’une équipe AWS avancée de réponse aux incidents.
+ **Support de réponse aux attaques DDoS**
+ AWS propose [AWS Shield](https://aws.amazon.com/shield/), qui est un service de protection DDoS (Distributed Denial of Service) géré qui protège les applications Web s’exécutant sous AWS. Shield assure une détection continue et une atténuation automatique des risques pour minimiser les temps d’arrêt et la latence des applications, afin qu’il ne soit pas nécessaire d’avoir recours à Support pour bénéficier de la protection DDoS. Il existe deux niveaux de Shield : AWS Shield Standard et AWS Shield Advanced. Pour en savoir plus sur les différences entre ces deux niveaux, consultez la [documentation relative aux fonctionnalités Shield](https://aws.amazon.com/shield/features/).
+ **AWS Managed Services (AMS)**
+ [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) fournit une gestion continue de votre infrastructure AWS afin que vous puissiez vous concentrer sur vos applications. En appliquant les bonnes pratiques pour gérer votre infrastructure, AMS permet de réduire les coûts et risques de fonctionnement. AMS automatise les activités courantes telles que les demandes de modification, la surveillance, la gestion des correctifs, la sécurité et les services de sauvegarde, et fournit des services pour l’intégralité du cycle de vie pour mettre en service, exécuter et soutenir votre infrastructure.
+ AMS prend la responsabilité de déployer une suite de contrôles de sécurité et fournit une réponse de première ligne 24 heures sur 24, 7 jours sur 7 aux alertes. Lorsqu’une alerte est déclenchée, AMS suit un ensemble standard de playbooks automatisés et manuels pour vérifier une réponse cohérente. Ces playbooks sont partagés avec les clients AMS lors de l’intégration afin qu’ils puissent développer et coordonner une réponse avec AMS.
**Élaborez le plan d’intervention en cas d’incident**
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. Le plan d’intervention en cas d’incident doit figurer dans un document formel. Un plan d’intervention en cas d’incident comprend généralement les sections suivantes :
+ **Présentation de l’équipe d’intervention en cas d’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.
+ **Plan de communication :** détaille les coordonnées et la manière dont vous communiquez lors d’un incident.
+ **Méthodes de communication relative à la sauvegarde :** il est recommandé d’utiliser une communication hors bande comme solution de secours pour les communications en cas d’incident. Un exemple d’application qui fournit un canal de communication hors bande sécurisé est AWS Wickr.
+ **Phases de l’intervention en cas d’incident et mesures à prendre :** énumère les phases de la réponse aux incidents (par exemple, détection, analyse, éradication, maîtrise et récupération), y compris les mesures de haut niveau à prendre au cours de ces phases.
+ **Définitions de la gravité et de la priorité des incidents :** décrit en détail comment classer la gravité d’un incident, comment hiérarchiser l’incident, puis comment les définitions de gravité affectent les procédures de remontée.
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 devez élaborer un plan d’intervention en cas d’incident qui convient le mieux à votre organisation.
## Ressources
**Bonnes pratiques associées :**
+ [SEC04 Détection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documents connexes :**
+ [Guide d’intervention en cas d’incident de sécurité AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [NIST: Computer Security Incident Handling Guide](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)
# SEC10-BP03 Préparer les fonctionnalités d’analyse poussée
Pour anticiper un incident de sécurité, envisagez de développer des fonctionnalités d’analyse poussée pour faciliter les enquêtes sur les événements de sécurité.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
Les concepts issus de l’analyse poussée traditionnelle sur site s’appliquent à AWS. Pour obtenir des informations clés permettant de commencer à renforcer les capacités de criminalistique dans le AWS Cloud, consultez [Stratégies relatives à l’environnement d’investigation judiciaire dans le AWS Cloud](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/).
Une fois que vous avez configuré la structure de votre environnement et de votre compte Compte AWS en vue de l’analyse poussée, définissez les technologies requises pour appliquer efficacement les méthodologies d’analyse poussée en quatre phases :
+ **Collecte :** collectez des journaux AWS pertinents, tels que AWS CloudTrail, AWS Config, les journaux de flux VPC et les journaux au niveau de l’hôte. Collectez des instantanés, des sauvegardes et des fichiers de vidage de mémoire des ressources AWS concernées, le cas échéant.
+ **Examen :** examinez les données collectées en extrayant et en évaluant les informations pertinentes.
+ **Analyse :** analysez les données collectées afin de comprendre l’incident et d’en tirer des conclusions.
+ **Production de rapports :** présentez les informations issues de la phase d’analyse.
## Étapes d’implémentation
**Préparer votre environnement d’analyse poussée**
[AWS Organizations](https://aws.amazon.com/organizations/) vous permet de gérer et de gouverner de manière centralisée un environnement AWS à mesure que vous vous développez et que vous mettez à l’échelle vos ressources AWS. Une organisation AWS consolide vos Comptes AWS pour que vous puissiez les administrer en tant qu’unité unique. Vous pouvez utiliser des unités d’organisation (UO) pour regrouper des comptes afin de les administrer en tant qu’unité unique.
Pour intervenir en cas d’incident, il est utile de disposer d’une structure de Compte AWS prenant en charge les fonctions de réponse aux incidents, qui comprend une *unité d’organisation de sécurité* et une *unité d’organisation d’analyse poussée*. Au sein de l’unité d’organisation de sécurité, vous devez disposer de comptes pour :
+ **Archivage des journaux :** regroupez les journaux dans un d’archivage de journaux Compte AWS avec des autorisations limitées.
+ **Outils de sécurité :** centralisez les services de sécurité dans un Compte AWS d’outil de sécurité. Ce compte joue le rôle d’administrateur délégué pour les services de sécurité.
Au sein de l’unité d’organisation d’analyse poussée, vous avez la possibilité de mettre en place un ou plusieurs comptes d’analyse poussée pour chaque région dans laquelle vous opérez, selon ce qui convient le mieux à votre entreprise et à votre modèle opérationnel. Si vous créez un compte d’analyse poussée par région, vous pouvez bloquer la création des ressources AWS en dehors de cette région et réduire le risque que les ressources soient copiées vers une région non prévue. Par exemple, si vous opérez uniquement dans les régions USA Est (Virginie du Nord) (`us-east-1`) et USA Ouest (Oregon) (`us-west-2`), vous aurez deux comptes dans l’unité d’organisation médico-légale : un pour `us-east-1` et un pour `us-west-2`.
Vous pouvez créer un Compte AWS d’analyse poussée pour plusieurs régions. Soyez prudent lorsque vous copiez des ressources AWS sur ce compte afin de vérifier que vous respectez vos exigences en matière de souveraineté des données. Étant donné que la mise en place de nouveaux comptes prend du temps, il est impératif de créer et d’instrumenter les comptes d’analyse poussée bien avant un incident afin que les intervenants puissent être prêts à les utiliser efficacement pour intervenir.
Le diagramme suivant présente un exemple de structure de compte, y compris une unité d’organisation d’analyse poussée avec des comptes d’analyse poussée par région :
![\[Organigramme illustrant une structure de compte par région pour la réponse aux incidents, bifurquée dans une unité d’organisation de sécurité et de criminalistique.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**Conservez les sauvegardes et les instantanés**
La configuration de sauvegardes des systèmes et des bases de données clés s’avère essentielle pour récupérer d’un incident de sécurité et à des fins d’analyse poussée. Une fois les sauvegardes en place, vous pouvez restaurer vos systèmes à leur état stable antérieur. Sur AWS, vous pouvez prendre des instantanés de différentes ressources. Les instantanés fournissent des sauvegardes ponctuelles de ces ressources. De nombreux services AWS peuvent vous aider en matière de sauvegarde et de restauration. Pour en savoir plus sur ces services et approches de la sauvegarde et de la récupération, reportez-vous au [Recommandation en matière de sauvegarde et de récupération](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) et à [Utiliser les sauvegardes pour récupérer après un incident de sécurité](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/).
Il est essentiel que vos sauvegardes soient bien protégées, en particulier dans le cas de rançongiciels. Pour obtenir des conseils sur la sécurisation de vos sauvegardes, reportez-vous aux [10 meilleures pratiques de sécurité en matière de sauvegarde dans AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Outre la sécurisation de vos sauvegardes, vous devez régulièrement tester vos processus de sauvegarde et de restauration pour vérifier que la technologie et les processus que vous avez mis en place fonctionnent comme prévu.
**Automatisez la criminalistique**
Lors d’un événement de sécurité, votre équipe de réponse aux incidents doit être en mesure de collecter et d’analyser rapidement les preuves tout en préservant l’exactitude de la période pendant laquelle s’est produit l’événement (par exemple, en capturant les journaux relatifs à un événement ou à une ressource spécifique ou en collectant les fichiers de vidage de mémoire d’une instance Amazon EC2). Il est à la fois difficile et fastidieux pour l’équipe de réponse aux incidents de collecter manuellement les preuves pertinentes, en particulier sur un grand nombre d’instances et de comptes. De plus, la collecte manuelle peut faire l’objet d’erreurs humaines. Pour ces raisons, vous devez développer et mettre en œuvre autant que possible l’automatisation de l’analyse poussée.
AWS propose un certain nombre de ressources d’automatisation pour l’analyse poussée, qui sont répertoriées dans la section Ressources suivante. Ces ressources sont des exemples de modèles d’analyse poussée que nous avons développés et que les clients ont mis en œuvre. Bien qu’elles puissent constituer une architecture de référence utile au départ, envisagez de les modifier ou de créer de nouveaux modèles d’automatisation de l’analyse poussée en fonction de votre environnement, de vos exigences, de vos outils et de vos processus d’analyse poussée.
## Ressources
**Documents connexes :**
+ [Guide AWS de réponse aux incidents de sécurité - Développement des fonctionnalités d’analyse poussée (langue française non garantie)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [Guide AWS de réponse aux incidents de sécurité - Ressources d’analyse poussée (langue française non garantie)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Stratégies d’environnement d’enquête pour les analyses poussées dans le AWS Cloud](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) (langue française non garantie)
+ [Comment automatiser la collecte de disques d’analyse dans AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [Recommandations AWS – Automatiser la réponse aux incidents et l’analyse poussée (langue française non garantie)](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**Vidéos connexes :**
+ [Automatisation de la réponse aux incidents et investigations](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**Exemples connexes :**
+ [Cadre de réponse automatique aux incidents et de criminalistique](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [Orchestrateur d’analyse poussée automatisée pour for Amazon EC2 (langue française non garantie)](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)
# SEC10-BP04 Développer et tester des playbooks de réponse aux incidents de sécurité
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 des recommandations et les é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.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Il est recommandé de créer des playbooks dans les scénarios d’incidents suivants :
+ **Incidents prévus :** créez des playbooks pour les incidents que vous anticipez. Cela inclut des menaces telles que le déni de service (DoS), les rançongiciels et la compromission des informations d’identification.
+ **Constatations ou alertes de sécurité connues :** créez des playbooks pour vos résultats et alertes de sécurité connus, tels que les résultats d’Amazon GuardDuty. Lorsque vous recevez un résultat de GuardDuty, le playbook doit indiquer des étapes claires pour éviter de mal gérer ou d’ignorer l’alerte. Pour plus de détails et de conseils de correction, consultez [Correction des problèmes de sécurité découverts par GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html).
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é.
L’équipe AWS de réponse aux incidents client (CIRT) a publié un [référentiel GitHub contenant des guides opérationnels de réponse aux incidents](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs), organisés par scénario de menace, type et ressource. Ces guides opérationnels peuvent être adaptés pour s’aligner sur vos procédures de réponse aux incidents existantes ou servir de base à l’élaboration de nouvelles procédures.
### Étapes d’implémentation
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 ?
+ **Préréquis :** quels journaux, mécanismes de détection et outils automatisés sont requis pour ce scénario d’incident ? Quelle est la notification attendue ?
+ **Informations de communication et d’escalade** : qui est impliqué et quelles sont ses coordonnées ? Quelles sont les responsabilités de chacune des parties prenantes ?
+ **Étapes d’intervention :** quelles sont les mesures tactiques à prendre au cours des différentes phases de la réponse à un incident ? Quelles requêtes un analyste doit-il exécuter ? Quel code doit être exécuté pour obtenir le résultat souhaité ?
+ **Détection :** comment l’incident sera-t-il détecté ?
+ **Analyse :** comment l’étendue de l’impact sera-t-elle déterminée ?
+ **Contenu :** comment l’incident sera-t-il isolé pour en limiter la portée ?
+ **Éradication :** comment éliminer la menace de l’environnement ?
+ **Remise :** comment le système ou la ressource concernés seront-ils remis en production ?
+ **Résultats escomptés :** une fois les requêtes et le code exécutés, quel est le résultat attendu du playbook ?
## Ressources
**Bonnes pratiques Well-Architected connexes :**
+ [SEC10-BP02 – Développer des plans de gestion des incidents](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
**Documents connexes :**
+ [Cadre pour les playbooks d’intervention en cas d’incident](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Élaborer vos propres playbooks d’intervention en cas d’incident](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [Modèles de guides d’intervention en cas d’incident](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [Création d’un runbook de réponse aux incidents AWS à l’aide de playbooks Jupyter et Lake (langue française non garantie)](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 Préallouer les accès
Vérifiez que les intervenants en cas d’incident disposent du bon accès préalablement alloué dans AWS afin de réduire le temps d’investigation jusqu’à la reprise.
**Anti-modèles courants :**
+ Utilisation du compte racine pour la réponse aux incidents.
+ Modification des comptes existants.
+ Manipulation des autorisations IAM directement lors de la fourniture d’une élévation de privilèges juste-à-temps.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
AWS recommande de réduire ou de supprimer l’utilisation des informations d’identification durables dans la mesure du possible et de privilégier les informations d’identification temporaire à la place, ainsi que des mécanismes d’escalade des privilèges *juste à temps*. Les informations d’identification durables sont sujettes aux risques de sécurité et augmentent les frais généraux opérationnels. Pour la plupart des tâches de gestion, ainsi que pour les tâches de réponse aux incidents, nous vous recommandons de mettre en œuvre [la fédération d’identités](https://aws.amazon.com/identity/federation/) et [l’escalade temporaire pour l’accès administratif](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). Dans le cadre de ce modèle, un utilisateur demande une élévation à un niveau de privilège plus élevé (par exemple un rôle de réponse aux incidents) et, si l’utilisateur est admissible à cette élévation, une demande est envoyée à un approbateur. Si la demande est approuvée, l’utilisateur reçoit un ensemble [d’informations d’identification AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) temporaires qui peuvent être utilisées pour effectuer ses tâches. Une fois que ces informations d’identification ont expiré, l’utilisateur doit soumettre une nouvelle demande d’élévation.
Nous vous recommandons d’utiliser une élévation temporaire des privilèges dans la plupart des cas de réponse aux incidents. La bonne façon de procéder consiste à utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) et les [politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) pour délimiter l’accès.
Dans certains cas, les identités fédérées ne sont pas disponibles, par exemple :
+ Panne liée à la compromission d’un fournisseur d’identité (IdP).
+ Mauvaise configuration ou erreur humaine entraînant la panne d’un système de gestion d’accès fédéré.
+ Activité malveillante, par exemple un déni de service distribué (DDoS) ou une indisponibilité du système.
Dans les cas précédents, un accès d’urgence aux *bris de verre* doit être configuré pour permettre une enquête et une résolution rapide des incidents. Nous vous recommandons d’utiliser un [utilisateur, un groupe ou un rôle doté des autorisations appropriées](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) pour effectuer des tâches et accéder aux ressources AWS. Utiliser l’utilisateur racine uniquement pour les [tâches qui nécessitent des informations d’identification](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Pour vérifier que les intervenants en cas d’incident disposent d’un niveau d’accès approprié à AWS et aux autres systèmes pertinents, nous vous recommandons de pré-allouer des comptes dédiés. Les comptes requièrent un accès privilégié et doivent être étroitement contrôlés et surveillés. Les comptes doivent être créés avec le moins de privilèges requis pour effectuer les tâches nécessaires et le niveau d’accès doit être basé sur les playbooks créés dans le cadre du plan de gestion des incidents.
Utilisez des utilisateurs et des rôles spécialement conçus et dédiés au titre de bonne pratique. L’élévation temporaire de l’accès des utilisateurs ou des rôles via l’ajout de politiques IAM ne permet pas de savoir clairement de quel type d’accès bénéficiaient les utilisateurs pendant l’incident et peut empêcher la révocation des privilèges élevés au niveau supérieur.
Il est important de supprimer autant de dépendances que possible afin de vérifier que l’accès peut être obtenu dans le plus grand nombre possible de scénarios de défaillance. Afin de vous faciliter la tâche, créez un playbook permettant de vérifier que les utilisateurs chargés des réponses en cas d’incident ont été créés en tant qu’utilisateurs dans un compte de sécurité dédié et qu’ils ne sont pas gérés via une solution d’authentification unique ou de fédération existante. Chaque intervenant en cas d’incident doit avoir son propre compte nommé. La configuration du compte doit appliquer des [stratégies de mot de passe d’un niveau de sécurité élevé](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) à l’authentification multifactorielle (MFA). Si les playbooks de réponse aux incidents ne nécessitent qu’un accès à la AWS Management Console, l’utilisateur ne doit pas avoir de clés d’accès configurées et il doit lui être explicitement interdit de créer des clés d’accès. Cela peut être configuré avec des politiques IAM ou des politiques de contrôle des services (SCP), comme mentionné dans les bonnes pratiques de sécurité AWS pour les [AWS Organizations SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Les utilisateurs ne doivent pas avoir d’autres privilèges que la capacité d’assumer des rôles de réponse aux incidents dans d’autres comptes.
Pendant un incident, il peut être nécessaire d’accorder l’accès à d’autres personnes internes ou externes afin de prendre en charge les activités d’analyse, de correction ou de reprise. Dans ce cas, utilisez le mécanisme de playbook mentionné précédemment. Celui-ci doit comporter un processus permettant de s’assurer que tout accès supplémentaire est révoqué immédiatement après l’incident.
Pour s’assurer que l’utilisation des rôles de réponse aux incidents peut être correctement surveillée et vérifiée, il est essentiel que les comptes utilisateur IAM créés à cette fin ne soient pas partagés entre les personnes et que l’Utilisateur racine d'un compte AWS ne soit pas utilisé, à moins qu’ils ne soient [nécessaires pour une tâche spécifique](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Si l’utilisateur root est requis (par exemple, l’accès IAM à un compte spécifique n’est pas disponible), utilisez un processus distinct avec un playbook disponible afin de vérifier la disponibilité des informations d’identification de l’utilisateur racine et du jeton d’authentification multifactorielle.
Pour configurer les politiques IAM pour les rôles de réponse aux incidents, pensez à utiliser [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) pour générer des politiques basées sur les journaux AWS CloudTrail. Pour cela, accordez à l’administrateur l’accès au rôle de réponse aux incidents sur un compte hors production et exécutez vos playbooks. Une fois que vous aurez terminé, vous pourrez créer une politique autorisant uniquement les mesures prises. Cette politique peut ensuite être appliquée à tous les rôles de réponse aux incidents dans tous les comptes. Vous pouvez éventuellement créer une politique IAM distincte pour chaque playbook afin de faciliter la gestion et la vérification. Les exemples de playbooks peuvent comprendre des plans d’intervention pour les rançongiciels, les atteintes à la protection des données, la perte d’accès à la production et d’autres scénarios.
Utilisez les comptes de réponse aux incidents pour assumer des [rôles IAM d’intervention en cas d’incident dans d’autres Comptes AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Ces rôles doivent être configurés de façon à pouvoir être assumés uniquement par les utilisateurs du compte de sécurité et la relation de confiance doit exiger que le principal appelant ait été authentifié au moyen de l’authentification multifactorielle. Les rôles doivent utiliser des politiques IAM à portée limitée afin de contrôler l’accès. Veillez à ce que toutes les demandes de `AssumeRole` pour ces rôles soient enregistrées dans CloudTrail et fassent l’objet d’une alerte, et à ce que toutes les actions effectuées à l’aide de ces rôles soient enregistrées.
Il est vivement recommandé de nommer les comptes utilisateur et rôles IAM afin d’en faciliter la recherche dans les journaux CloudTrail. Un exemple serait de nommer les comptes IAM `-BREAK-GLASS` et les rôles IAM `BREAK-GLASS-ROLE`.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) est utilisé pour enregistrer l’activité des API dans vos comptes AWS et doit être utilisé pour [configurer les alertes relatives à l’utilisation des rôles d’ntervention en cas d’incidents](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Consultez la publication de blog sur la configuration des alertes lorsque les clés racine sont utilisées. Les instructions peuvent être modifiées pour configurer le filtre métrique [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) afin de filtrer les événements `AssumeRole` liés au rôle IAM de réponse aux incidents :
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
Dans la mesure où les rôles de réponse aux incidents sont susceptibles d’avoir un niveau d’accès élevé, il est important que ces alertes soient transmises à un vaste groupe et qui y donnera suite rapidement.
Lors d’un incident, il est possible qu’un intervenant ait besoin d’accéder à des systèmes qui ne sont pas sécurisés directement par IAM. Celle-ci peut inclure des instances Amazon Elastic Compute Cloud, des bases de données Amazon Relational Database Service ou des plateformes de logiciel en tant que service (SaaS). Il est fortement recommandé d’utiliser [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) pour tous les accès administratifs aux instances Amazon EC2 plutôt que d’utiliser les protocoles natifs tels que SSH ou RDP. Cet accès peut être contrôlé à l’aide d’IAM, qui est sécurisé et vérifié. Il est également possible d’automatiser certaines parties de vos playbooks à l’aide des [documents AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), qui peuvent réduire les erreurs des utilisateurs et accélérer le temps de restauration. Pour accéder aux bases de données et aux outils tiers, nous recommandons de stocker les informations d’identification dans AWS Secrets Manager et d’accorder l’accès aux rôles des intervenants en cas d’incident.
Enfin, la gestion des comptes IAM de réponse aux incidents doit être ajoutée à vos [processus Joiners, Movers et Leavers](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) et revue et testée périodiquement pour vérifier que seul l’accès prévu est autorisé.
## Ressources
**Documents connexes :**
+ [Gérer les accès temporaires à votre environnement AWS](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [Guide d’intervention en cas d’incident de sécurité AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [Définition d’une politique de mot de passe du compte pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Utilisation de l’authentification multifactorielle (MFA) dans l’interface AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [Configuration d’accès inter-compte pour MFA](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [Utilisation de l’analyseur d’accès IAM pour générer des politiques IAM](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [Comment recevoir des notifications lorsque les clés d’accès racine de votre AWS sont utilisées](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [Create fine-grained session permissions using IAM managed policies](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [Accès en mode « bris de glace »](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Vidéos connexes :**
+ [Automatisation de la réponse aux incidents et de l’analyse poussée dans AWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [DIY guide to runbooks, incident reports, and incident response](https://youtu.be/E1NaYN_fJUo)
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
# SEC10-BP06 Prédéployer les outils
Vérifiez que le personnel de sécurité dispose des outils appropriés préalablement déployés pour accélérer l’enquête jusqu’à la récupération.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Pour automatiser les fonctions de réponse et d’exploitation de la sécurité, vous pouvez utiliser un ensemble complet d’API et d’outils d’AWS. Vous pouvez automatiser entièrement la gestion des identités, la sécurité des réseaux, la protection des données et les fonctionnalités de surveillance, et les mettre en œuvre en utilisant les méthodes de développement de logiciel les plus courantes que vous avez déjà mises en place. Lorsque vous automatisez la sécurité, votre système peut surveiller, examiner et déclencher une réponse, plutôt que d’avoir à demander à des personnes de surveiller votre niveau de sécurité et de réagir manuellement aux événements.
Si vos équipes de réponse aux incidents continuent de répondre aux alertes de la même manière, elles risquent de se lasser des alertes. Au fil du temps, l’équipe peut faire moins attention aux alertes et soit faire des erreurs en gérant des situations ordinaires, soit manquer des alertes inhabituelles. L’automatisation permet d’éliminer la lassitude liée aux alertes en utilisant des fonctions qui traitent les alertes répétitives et ordinaires, laissant aux personnes le soin de gérer les incidents sensibles et uniques. L’intégration de systèmes de détection d’anomalies, comme Amazon GuardDuty, AWS CloudTrail Insights et Amazon CloudWatch, peut alléger les alertes courantes basées sur des seuils.
Vous pouvez améliorer les processus manuels en automatisant par programmation les étapes du processus. Une fois que vous avez défini le modèle de correction d’un événement, vous pouvez le décomposer en logique exploitable et écrire le code pour exécuter cette logique. Les intervenants peuvent ensuite exécuter ce code pour corriger le problème. Au fil du temps, vous pouvez automatiser un nombre croissant d’étapes et, enfin, gérer automatiquement des catégories entières d’incidents courants.
Au cours d’une enquête de sécurité, vous devez être en mesure d’examiner les journaux pertinents pour consigner et comprendre la portée et la chronologie complètes de l’incident. Des journaux sont également requis pour la génération d’alertes, indiquant que certaines actions intéressantes ont eu lieu. Il est essentiel de sélectionner, d’activer, de stocker et de configurer les mécanismes d’interrogation et de récupération et de configurer les alertes. En outre, une solution efficace qui fournit des outils de recherche dans les données des journaux est [Amazon Detective](https://aws.amazon.com/detective/).
AWS propose plus de 200 services cloud et des milliers de fonctionnalités. Nous vous recommandons de passer en revue les services susceptibles de prendre en charge et de simplifier votre stratégie de réponse aux incidents.
Outre la journalisation, vous devez développer et mettre en œuvre une [stratégie de balisage](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). Le balisage peut aider à mettre en contexte l’objectif d’une ressource AWS. Le balisage peut également être utilisé à des fins d’automatisation.
### Étapes d’implémentation
**Sélection et configuration de journaux à des fins d’analyse et d’alerte**
Consultez la documentation suivante relative à la configuration de la journalisation pour la réponse aux incidents :
+ [Stratégies de journalisation pour l’intervention en cas d’incidents de sécurité](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [SEC04-BP01 Configurer une journalisation de service et d’application](sec_detect_investigate_events_app_service_logging.md)
**Permettre aux services de sécurité de prendre en charge la détection et l’intervention**
AWS fournit des fonctionnalités de détection, de prévention et de réponse et d’autres services peuvent être utilisés pour concevoir des solutions de sécurité personnalisées. Pour obtenir la liste des services les plus pertinents en matière de réponse aux incidents de sécurité, consultez [Définitions des fonctionnalités du cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html) et la [page d’accueil de réponse aux incidents de sécurité](https://aws.amazon.com/security-incident-response/).
**Élaboration et mise en œuvre d’une stratégie de marquage**
Il peut être difficile d’obtenir des informations contextuelles sur le cas d’utilisation métier et les parties prenantes internes pertinentes concernant une ressource AWS. Pour ce faire, vous pouvez utiliser des balises qui attribuent des métadonnées à vos ressources AWS. Ces balises comprennent une clé et une valeur définies par l’utilisateur. Vous pouvez créer des balises pour classer les ressources par objectif, propriétaire, environnement, type de données traitées et d’autres critères de votre choix.
Le fait de disposer d’une stratégie de balisage cohérente peut accélérer les temps de réponse et réduire le temps consacré au contexte organisationnel en vous permettant d’identifier et de discerner rapidement les informations contextuelles relatives à une ressource AWS. Les balises peuvent également servir de mécanisme pour initier l’automatisation des réponses. Pour plus de détails sur les éléments à étiqueter, consultez la section [Marquage de vos ressourcesAWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Vous devez d’abord définir les balises que vous souhaitez implémenter dans votre organisation. Ensuite, vous mettez en œuvre et appliquez cette stratégie de balisage. Pour en savoir plus sur la mise en œuvre et l’application, reportez-vous à [Mettre en œuvre une stratégie de balisage AWS des ressources à l’aide de politiques de balises AWS et de politiques de contrôle des services (SCP)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
## Ressources
**Bonnes pratiques Well-Architected connexes:**
+ [SEC04-BP01 Configurer une journalisation de service et d’application](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Capturer les journaux, les résultats et les métriques dans des emplacements standardisés](sec_detect_investigate_events_logs.md)
**Documents connexes:**
+ [ Stratégies de journalisation pour l’intervention en cas d’incidents de sécurité ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Définitions des fonctionnalités cloud de réponse aux incidents ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)
**Exemples connexes:**
+ [ Détection des menaces et réponse avec Amazon GuardDuty et Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Atelier Security Hub ](https://catalog.workshops.aws/security)
+ [ Gestion des vulnérabilités avec Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 Exécuter des simulations
À mesure que les organisations se développent et évoluent au fil du temps, le paysage des menaces change. Il est donc important de revoir en permanence vos capacités de réponse aux incidents. L’organisation de simulations (également appelées « tests de simulation de panne ») est une méthode qui peut être utilisée pour effectuer cette évaluation. Les simulations utilisent des scénarios d’événements de sécurité réels conçus pour imiter les tactiques, techniques et procédures (TTP) d’un acteur de la menace et permettre à une organisation d’exercer et d’évaluer ses capacités de réponse aux incidents en réagissant à ces cyberévénements fictifs tels qu’ils peuvent se produire dans la réalité.
**Avantages liés au respect de cette bonne pratique :** les simulations présentent de nombreux avantages :
+ 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.
**Niveau de risque encouru si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Il existe trois principaux types de simulations :
+ **Exercices sur table :** l’approche théorique des simulations est une session basée sur des discussions auxquelles participent les différentes parties prenantes de la réponse aux incidents afin de mettre en pratique leurs rôles et leurs responsabilités et d’utiliser des outils de communication et des manuels établis. L’animation d’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. Dans la mesure où il repose sur la discussion, l’exercice théorique met l’accent sur les processus, les personnes et la collaboration. La technologie fait partie intégrante de la discussion, mais l’utilisation effective d’outils ou de scripts de réponse aux incidents ne fait généralement pas partie de l’exercice théorique.
+ **Exercices de l’équipe violette :** les exercices de l’équipe violette augmentent le niveau de collaboration entre les intervenants en cas d’incident (équipe bleue) et les acteurs de menaces simulées (équipe rouge). L’équipe bleue est composée de membres du centre des opérations de sécurité (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 composée d’une équipe de tests de pénétration 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. Lors des exercices de l’équipe violette, l’accent est principalement mis sur les mécanismes de détection, les outils et les procédures opérationnelles standard (SOP) qui soutiennent les efforts de réponse aux incidents.
+ **Exercces de l’équipe rouge :** au cours d’un exercice de l’équipe rouge, l’attaque (l’équipe rouge) effectue une simulation pour atteindre un objectif donné ou un ensemble d’objectifs à partir d’une portée prédéterminée. Les défenseurs (équipe bleue) ne seront pas nécessairement au courant de la portée ni de la durée de l’exercice, ce qui permet d’évaluer de manière plus réaliste la manière dont ils réagiraient en cas d’incident réel. Étant donné que les exercices de l’équipe rouge peuvent être des tests invasifs, soyez prudent et mettez en œuvre des contrôles pour vérifier que l’exercice ne cause pas de dommages réels à votre environnement.
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 théoriques) et de passer ensuite à des types de simulation plus complexes (exercices de l’équipe rouge). 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 décider de ne pas effectuer les exercices de l’équipe rouge en raison de leur complexité et de leur coût.
## Étapes d’implémentation
Quel que soit le type de simulation que vous choisissez, les simulations suivent généralement les étapes de mise en œuvre suivantes :
1. **Définir les éléments essentiels 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 :** un exercice nécessite au minimum 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. **Concevoir et tester le scénario :** le scénario devra peut-être être redéfini au fur et à mesure de sa création si des éléments spécifiques 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 l’animation utilisée (un 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) :** identifier 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.
## Ressources
**Documents connexes :**
+ [Réponse aux incidents dans AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Vidéos connexes :**
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs)
+ [Exécution de simulations de réponses efficaces aux incidents de sécurité](https://www.youtube.com/watch?v=63EdzHT25_A)