# SEC 10 Comment anticiper les incidents, y répondre et reprendre les activités par la suite ?
La préparation est essentielle pour une enquête rapide et efficace, une réponse et une reprise en cas d'incidents de sécurité, afin de minimiser les perturbations pour votre organisation.
**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 Automatiser la fonctionnalité de confinement](sec_incident_response_auto_contain.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 Organiser des jeux de rôle](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.
Lorsque vous définissez votre approche de la réponse aux incidents dans le cloud, à l'unisson avec d'autres équipes (telles que votre conseiller juridique, vos dirigeants, les parties prenantes de l'entreprise, les services AWS Support, etc.), vous devez identifier le personnel clé, les parties prenantes et les contacts pertinents. Pour réduire la dépendance et le temps de réponse, veillez à ce que votre équipe, les équipes de sécurité spécialisées et les intervenants soient formés aux services que vous utilisez et aient la possibilité d'effectuer des exercices pratiques.
Nous vous encourageons à identifier des partenaires de sécurité AWS externes qui peuvent vous fournir une expertise extérieure et une perspective différente pour augmenter vos capacités d'intervention. Vos partenaires de sécurité de confiance peuvent vous aider à identifier des risques ou des menaces potentiels que vous ne connaissez peut-être pas.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## 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 pour réagir et vous remettre après un incident.
+ Identifier les partenaires externes : collaborez le cas échéant avec des partenaires externes qui pourront vous aider à réagir et à reprendre après un incident.
## Ressources
**Documents connexes :**
+ [Guide de réponse aux incidents AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Vidéos connexes :**
+ [Prepare for and respond to security incidents in your AWS environment ](https://youtu.be/8uiO0Z5meCs)
**Exemples connexes :**
# SEC10-BP02 Développer des plans de gestion des incidents
Créez des plans pour vous aider à réagir, à communiquer pendant un incident et rétablir les opérations. À titre d'exemple, vous pouvez lancer un plan d'intervention en cas d'incident avec les scénarios les plus probables pour votre charge de travail et votre organisation. Incluez la façon dont vous devez communiquer et transmettre les situations aux paliers supérieurs en interne et en externe.
**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 opérationnels et aux exigences de conformité. Par exemple, si vous exécutez des charges de travail dans AWS qui sont conformes à FedRAMP aux États-Unis, il est utile de respecter [NIST SP 800-61 Computer Security Handling Guide](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 avec des données européennes personnellement identifiables, envisagez des scénarios tels que la façon dont vous pourriez protéger les données et résoudre des problèmes liés à la résidence des données, comme l'exige [le Règlement Général sur la Protection des Données (RGPD)](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en).
Lorsque vous élaborez un plan de gestion des incidents pour vos charges de travail exécutées dans AWS, commencez par le [Modèle de responsabilité partagée AWS,](https://aws.amazon.com/compliance/shared-responsibility-model/)afin de créer une approche de défense en profondeur en matière de réponse aux incidents. Dans le cadre de ce modèle, AWS gère la sécurité du cloud et vous êtes responsables 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. L' [AWS Security Incident Response Guide](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.
+ **Éduquez et formez aux réponses aux incidents :** en cas d'écart par rapport à votre base de référence définie (par exemple, un déploiement erroné ou une mauvaise configuration), il est possible que vous ayez besoin d'intervenir et d'analyser. Pour y parvenir, vous devez comprendre les contrôles et les capacités que vous pouvez utiliser afin d'intervenir en cas d'incident de sécurité dans votre environnement AWS, ainsi que les processus que vous devez envisager pour préparer, éduquer et former vos équipes cloud participant à une réponse face à un incident.
+ [Les playbooks](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) et [les runbooks](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) sont des mécanismes efficaces pour assurer l'uniformité de la formation sur les réponses aux incidents. Commencez par dresser une liste initiale des procédures fréquemment exécutées lors d'une réponse aux incidents, puis continuez à itérer à mesure que vous apprenez ou utilisez de nouvelles procédures.
+ Socialisez les playbooks et les runbooks via des [tests de simulation de pannes planifiés](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html). Pendant les test de simulation de pannes, simulez la réponse à un incident dans un environnement contrôlé afin que votre équipe puisse se rappeler les mesures à prendre et pour vérifier que les équipes impliquées dans la réponse aux incidents connaissent bien les flux de travail. Examinez les résultats de l'événement simulé afin d'identifier les améliorations et de déterminer le besoin en formation complémentaire ou en outils supplémentaires.
+ Chacun doit se sentir responsable de la sécurité. Créez une connaissance collective du processus de gestion des incidents en faisant appel à tout le personnel qui exécute normalement vos charges de travail. Cela inclut tous les aspects de votre activité : les opérations, les tests, le développement, la sécurité, les opérations métier et les responsables.
+ **Documentez le plan de gestion des incidents :** documentez les outils et le processus pour consigner les incidents actifs, les corriger, communiquer les progrès réalisés et transmettre des notifications à leur sujet. L'objectif du plan de gestion des incidents est de vérifier que le fonctionnement normal est rétabli le plus rapidement possible, que les répercussions sur les activités sont réduites au minimum et que toutes les parties concernées sont informées. Les exemples d'incidents incluent notamment la perte ou la dégradation de la connectivité du réseau, un processus ou une API non réactif(ve), une tâche planifiée non exécutée (par exemple, un correctif défaillant), l'indisponibilité des données ou du service de l'application, une interruption de service imprévue en raison d'événements de sécurité, des fuites d'informations d'identification ou des erreurs de configuration.
+ Identifiez le propriétaire principal responsable de la résolution des incidents, par exemple le propriétaire de la charge de travail. Établissez des directives claires relatives à la personne chargée de diriger l'incident et à la gestion de la communication. Lorsque plusieurs intervenants participent au processus de résolution des incidents, par exemple un fournisseur externe, pensez à créer une *matrice des responsabilités (RACI)*décrivant les rôles et les responsabilités de diverses équipes ou personnes nécessaires à la résolution des incidents.
Une matrice RACI explore les points suivants :
+ **R :** *un tiers responsable* qui fait le travail pour accomplir la tâche.
+ **A :** *un tiers ou une partie prenante ayant l'autorité* finale en ce qui concerne la réussite de la tâche spécifique.
+ **C :** *un tiers consulté* dont les opinions sont sollicitées, généralement à titre d'expert en la matière.
+ **I :** *un tiers informé* de la progression, généralement une fois la tâche ou le produit livrable terminé(e).
+ **Catégorisez les incidents :** la définition et la catégorisation des incidents en fonction de leur gravité et de leur incidence permettent d'adopter une approche structurée pour trier et résoudre les incidents. Les recommandations suivantes illustrent une *matrice d'urgence de l'impact à la résolution* afin de quantifier un incident. Par exemple, un incident dont l'impact et l'urgence sont faibles est considéré comme un incident de faible gravité.
+ **Élevé (H) :** l'impact sur votre entreprise est important. Des fonctions critiques de votre application liées aux ressources AWS ne sont pas disponibles. Réservé aux événements les plus critiques affectant les systèmes de production. L'impact de l'incident augmente rapidement, les mesures correctives étant urgentes.
+ **Moyen (M) :** un service ou une application d'entreprise lié aux ressources AWS est modérément touché et fonctionne dans un état dégradé. Les applications qui contribuent aux objectifs de niveau de service (SLO) sont touchées dans les limites du contrat de niveau de service (SLA). Les systèmes peuvent fonctionner avec une capacité réduite sans que cela ait un impact important du point de vue financier et de la réputation.
+ **Faible (L) :** des fonctions non-critiques de votre application ou service métier en lien avec les ressources AWS sont impactées. Les systèmes peuvent fonctionner avec une capacité réduite et un impact minimal du point de vue financier et de la réputation.
+ **Standardisez les contrôles de sécurité :** la standardisation des contrôles de sécurité vise à garantir l'uniformité, la traçabilité et la répétabilité des résultats opérationnels. Standardisez les principales activités qui jouent un rôle essentiel dans la réponse aux incidents, notamment :
+ **Gestion des identités et des accès :** mettez en place des mécanismes de contrôle de l'accès à vos données et de gestion des privilèges pour les identités humaines et machine. Étendez votre propre gestion des identités et des accès au cloud en utilisant une sécurité fédérée avec une authentification unique et des privilèges basés sur les rôles pour optimiser la gestion des accès. Pour obtenir des recommandations en matière de bonnes pratiques et des plans d'amélioration visant à standardiser la gestion des accès, consultez la [section consacrée à la gestion des identités et des accès](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) dans le livre blanc du pilier Sécurité
+ **Gestion des vulnérabilités :** mettez en place des mécanismes pour identifier les vulnérabilités dans votre environnement AWS qui sont susceptibles d'être utilisées par les attaquants afin de compromettre votre système et de l'utiliser à mauvais escient. Implémentez des contrôles matures en matière de prévention et de détection en tant que mécanismes de sécurité permettant de répondre aux incidents de sécurité et d'en atténuer l'impact potentiel. Standardisez les processus tels que la modélisation des menaces dans le cadre de la création de votre infrastructure et du cycle de vie de la livraison des applications.
+ **Gestion de la configuration :** définissez des configurations standard et automatisez les procédures de déploiement des ressources dans le AWS Cloud. La standardisation de l'infrastructure et de la mise en service des ressources permet d'atténuer le risque d'erreurs de configuration dues à des déploiements erronés ou à des erreurs humaines accidentelles. Reportez-vous à [la section sur les principes de conception](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) du livre blanc Pilier de l'excellence opérationnelle afin de consulter des conseils et des plans d'amélioration relatifs à l'implémentation de ce contrôle.
+ **Journalisation et surveillance pour le contrôle d'audit :** implémentez des mécanismes permettant de surveiller vos ressources en cas de défaillances, de dégradation des performances et de problèmes de sécurité. La standardisation de ces contrôles fournit également des pistes d'audit des activités qui se déroulent dans votre système, ce qui facilite le triage et la résolution rapides des problèmes. Les bonnes pratiques conformément à [SEC04 Comment détecter et enquêter sur les événements de sécurité ?](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) fournissent des conseils pour implémenter ce contrôle.
+ **Utilisez l'automatisation :** L'automatisation permet de résoudre rapidement les incidents à grande échelle. AWS fournit plusieurs services à automatiser dans le contexte de la stratégie de réponse aux incidents. Concentrez-vous sur la recherche d'un équilibre approprié entre l'automatisation et l'intervention manuelle. Lorsque vous créez votre réponse aux incidents dans des playbooks et des runbooks, automatisez les étapes reproductibles. Utilisez des services AWS tels qu'AWS Systems Manager Incident Manager pour [résoudre des incidents informatiques plus rapidement](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/). Utilisez [les outils pour développeurs](https://aws.amazon.com/devops/) afin de fournir le contrôle des versions et d'automatiser [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) et les déploiements d'infrastructure en tant que code (IaC) sans intervention humaine. Lorsque c'est possible, automatisez la détection et l'évaluation de la conformité à l'aide de services gérés tels qu'Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, AWS Config et Amazon Macie. Optimisez les capacités de détection grâce au machine learning comme Amazon DevOps Guru qui permet de détecter les problèmes de modèles de fonctionnement anormal avant qu'ils ne surviennent.
+ **Effectuez une analyse des causes racines et tirez des leçons :** implémentez des mécanismes pour tirer des enseignements dans le cadre d'un examen de la réponse après l'incident. Lorsque la cause racine d'un incident révèle un défaut plus important, un défaut de conception, une mauvaise configuration ou une possibilité de récidive, l'incident est classé dans la catégorie des problèmes. Dans ces cas de figure, analysez et résolvez le problème afin de minimiser la perturbation des opérations normales.
## Ressources
**Documents connexes :**
+ [AWS Security Incident Response Guide](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)
**Vidéos connexes :**
+ [Automating Incident Response and Forensics in AWS](https://youtu.be/f_EcwmmXkXk)
+ [ DIY guide to runbooks, incident reports, and incident response ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
**Exemples connexes :**
+ [Atelier : playbook de réponse aux incidents avec Jupyter - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
+ [ Atelier : Incident Response with AWS Console and CLI ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)
# SEC10-BP03 Préparer les fonctionnalités d'analyse poussée
Il est important que ceux qui traitent les incidents comprennent quand et comment l'analyse poussée s'intègre dans votre plan d'intervention. Votre organisation doit définir quelles preuves sont collectées et quels outils sont utilisés dans le processus. Identifiez et préparez les capacités de mener des enquêtes pointues qui conviennent, y compris les spécialistes externes, les outils et l'automatisation. Parmi les décisions clés que vous devez prendre dès le départ, déterminez si vous collecterez les données à partir d'un système en direct. Certaines données, telles que le contenu de la mémoire volatile ou les connexions réseau actives, seront perdues si le système est éteint ou redémarré.
Votre équipe d'intervention peut combiner des outils, comme AWS Systems Manager, Amazon EventBridge et AWS Lambda, pour exécuter automatiquement des outils d'analyse dans un système d'exploitation et la mise en miroir du trafic VPC pour obtenir une capture des paquets réseau, afin de recueillir des preuves non persistantes. Effectuez d'autres activités, telles que l'analyse des journaux ou l'analyse des images de disque, dans un compte de sécurité dédié avec des postes de travail et des outils d'analyse personnalisés accessibles aux intervenants.
Expédiez régulièrement les journaux pertinents vers un magasin de données offrant une durabilité et une intégrité élevées. Les intervenants doivent avoir accès à ces journaux. AWS propose plusieurs outils qui peuvent faciliter l'examen des journaux, tels qu'Amazon Athena, Amazon OpenSearch Service (OpenSearch Service) et Amazon CloudWatch Logs Insights. De plus, conservez les preuves en sécurité à l'aide d'Amazon Simple Storage Service (Amazon S3) Object Lock. Ce service suit le modèle WORM (write-once-read-many) et empêche la suppression ou l'écrasement d'objets pendant une période définie. Étant donné que les techniques d'investigation nécessitent une formation spécialisée, vous devrez peut-être engager des spécialistes externes.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Identifier les fonctionnalités d'analyse : recherchez les fonctionnalités d'analyse poussée de votre organisation, les outils disponibles et les spécialistes externes.
+ [Automatisation de la réponse aux incidents et investigations ](https://youtu.be/f_EcwmmXkXk)
## Ressources
**Documents connexes :**
+ [Comment automatiser la collecte de disques d'analyse dans AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
# SEC10-BP04 Automatiser la fonctionnalité de confinement
Automatisez le confinement d'un incident et la reprise pour réduire les temps de réponse et l'impact sur votre organisation.
Une fois que vous avez créé et mis en pratique les processus et les outils de vos playbooks, vous pouvez déconstruire la logique en une solution basée sur le code, qui peut être utilisée comme outil par de nombreux intervenants pour automatiser la réponse et supprimer les écarts ou les conjectures de vos intervenants. Cela peut accélérer le cycle de vie d'une réponse. L'objectif suivant est de permettre à ce code d'être entièrement automatisé en étant appelé par les alertes ou les événements eux-mêmes, plutôt que par un intervenant humain, pour créer une réponse déclenchée par l'événement. Ces processus doivent également ajouter automatiquement des données pertinentes à vos systèmes de sécurité. Par exemple, un incident impliquant du trafic provenant d'une adresse IP indésirable peut renseigner automatiquement une liste de blocage AWS WAF ou un groupe de règles de pare-feu réseau pour empêcher toute activité similaire ultérieure.
![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)
*Figure 3 : AWS WAF automatise le blocage des adresses IP malveillantes connues*
Avec un système de réponse déclenché par l'événement, un mécanisme de détection déclenche un mécanisme réactif pour répondre automatiquement à l'événement. Vous pouvez utiliser des fonctionnalités de réaction déclenchées par des événements pour réduire le délai entre les mécanismes de détection et les mécanismes de réaction. Pour créer cette architecture événementielle, vous pouvez utiliser AWS Lambda, un service de calcul sans serveur qui exécute votre code en réponse à des événements et gère automatiquement les ressources de calcul sous-jacentes. Supposons que disposez d'un compte AWS avec le service AWS CloudTrail activé. Si AWS CloudTrail est désactivé (via l'appel d'API `cloudtrail:StopLogging` ), vous pouvez utiliser Amazon EventBridge pour surveiller l'événement `cloudtrail:StopLogging` et appeler une fonction AWS Lambda pour appeler `cloudtrail:StartLogging` afin de redémarrer la journalisation.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
Automatisez la fonctionnalité de confinement.
## Ressources
**Documents connexes :**
+ [ Guide de réponse aux incidents AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Vidéos connexes :**
+ [Prepare for and respond to security incidents in your AWS environment](https://youtu.be/8uiO0Z5meCs)
# 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 utilisateur 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 *les mécanismes d'élévation* 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 et de réponse aux incidents, nous vous recommandons de mettre en œuvre [la fédération d'identité](https://docs.aws.amazon.com/identity/federation/) parallèlement [à l'élévation 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 temporaires](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) qui peuvent être utilisées afin d'exécuter les 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. Dans cette optique, la meilleure solution 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) afin de 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, il doit y avoir un accès d'urgence *de type Break Glass* configuré afin de permettre l'analyse et la correction rapide des incidents. Nous vous recommandons également d'utiliser [un utilisateur IAM disposant 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. Utilisez des informations d'identification racine uniquement pour [les tâches qui requièrent un accès en tant qu'utilisateur root](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 utilisateur dédiés. Les comptes utilisateur 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 Gestion des identités et des accès AWS 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 [une politique stricte de gestion des mots de passe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) et une 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 politiquesIAM ou des politiques de contrôle de service (SCP), comme mentionné dans les bonnes pratiques de sécurité AWS pour [les SCP AWS Organizations](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 root Compte AWS ne soit pas utilisé, sauf si [cela s'avère nécessaire 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é du mot de passe utilisateur root et du jeton d'authentification multifactorielle.
Pour configurer les politiques IAM des 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 utilisateur de réponse aux incidents pour assumer les rôles [IAM dédiés de réponse aux incidents 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. Assurez-vous que toutes les demandes `AssumeRole` pour ces rôles sont consignées dans CloudTrail et font l'objet d'une alerte, et que toutes les mesures prises en utilisant ces rôles sont consignées.
Il est vivement recommandé de nommer les comptes utilisateur IAM et les rôles IAM afin d'en faciliter la recherche dans les journaux CloudTrail. Par exemple, les comptes IAM pourraient être nommés `-BREAK-GLASS` et les rôles IAM pourraient être nommés `BREAK-GLASS-ROLE`.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) est utilisé pour consigner l'activité de l'API dans vos comptes AWS et doit être utilisé pour [configurer les alertes sur l'utilisation des rôles de réponse aux 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 de façon à configurer la [métrique Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) de filtre à filtre sur 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. Il peut notamment s'agir d'instances Amazon Elastic Compute Cloud, de bases de données Amazon Relational Database Service ou de plateformes de logiciel en tant que service (SaaS). Il est vivement recommandé d'utiliser [AWS Systems Manager Session Manager plutôt que des protocoles natifs tels que SSH ou RDP](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) pour tous les accès administratifs aux instances Amazon EC2. 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 en utilisant [des documents AWS Systems Manager,](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)qui permettent de réduire les erreurs utilisateur et d'améliorer le temps de récupération. 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.
En dernier lieu, la gestion des comptes utilisateur IAM de réponse aux incidents doit être ajoutée à vos processus [d'entrées, de changements et de sorties.](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) Elle doit également être vérifiée et testée régulièrement afin de vous assurer que seul l'accès prévu est autorisé.
## Ressources
**Documents connexes :**
+ [Managing temporary elevated access to your AWS environment](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [AWS Security Incident Response Guide ](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)
+ [ Configuring Cross-Account Access with MFA ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies ](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/)
+ [ How to Receive Notifications When Your AWS Account's Root Access Keys Are Used ](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/)
**Vidéos connexes :**
+ [ Automating Incident Response and Forensics in 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)
**Exemples connexes :**
+ [ Atelier : AWS Account Setup and Root User ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Atelier : Incident Response with AWS Console and CLI ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)
# SEC10-BP06 Prédéployer les outils
assurez-vous que le personnel de sécurité dispose des outils appropriés préalablement déployés dans AWS pour accélérer les investigations jusqu'à la reprise.
Pour automatiser les fonctions d'ingénierie 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. Un moyen efficace de fournir automatiquement des données de journal consultables et pertinentes sur les services AWS à vos intervenants en cas d'incident est d'activer [Amazon Detective](https://aws.amazon.com/detective/).
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 Anomaly Detection, 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.
Pour les outils qui s'exécutent dans le système d'exploitation de votre instance Amazon Elastic Compute Cloud (Amazon EC2), vous devez les évaluer à l'aide d'AWS Systems Manager Run Command, qui vous permet d'administrer des instances à distance et en toute sécurité à l'aide d'un agent que vous installez sur le système d'exploitation de votre instance Amazon EC2. Cela nécessite l'agent AWS Systems Manager (agent SSM) qui est installé par défaut sur de nombreuses Amazon Machine Images (AMI). Notez, cependant, qu'une fois qu'une instance a été compromise, aucune réponse des outils ou des agents qui s'y exécutent ne doit être considérée comme fiable.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Faible
## Directives d'implémentation
+ Prédéployer les outils : assurez-vous que les outils appropriés ont été préalablement déployés pour le personnel de sécurité dans AWS afin que les mesures adéquates puissent être prises en cas d'incident.
+ [Atelier : gestion des incidents avec AWS Management Console et l'interface de ligne de commande (CLI) ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
+ [ Playbook de réponse aux incidents avec Jupyter - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
+ [ Automatisation de la sécurité AWS](https://github.com/awslabs/aws-security-automation)
+ Implémenter le balisage des ressources : balisez les ressources avec des informations comme un code pour la ressource soumises à une enquête afin que vous puissiez identifier les ressources pendant un incident.
+ [ Stratégies de balisage AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
## Ressources
**Documents connexes :**
+ [ Guide de réponse aux incidents AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Vidéos connexes :**
+ [ Mode d'emploi pour les runbooks, les rapports d'incidents et les réponses aux incidents ](https://youtu.be/E1NaYN_fJUo)
# SEC10-BP07 Organiser des jeux de rôle
les simulations ou exercices sont des événements internes qui permettent de mettre en pratique de manière structurée vos plans et procédures de gestion des incidents au cours d'un scénario réaliste. Ces événements doivent entraîner les intervenants à utiliser les mêmes outils et techniques que ceux qui seraient utilisés dans un scénario réel, et même à imiter des environnements réels. Ces simulations consistent principalement en la préparation et en l'amélioration itérative de vos capacités de réponse. Voici quelques-unes des raisons pour lesquelles des activités de simulation peuvent s'avérer utiles :
+ Validation de l'état de préparation
+ Développer la confiance : apprendre grâce aux simulations et à la formation du personnel
+ Respect des obligations contractuelles ou de conformité
+ Génération d'artefacts pour l'accréditation
+ Être agile : amélioration incrémentielle
+ Être plus rapide et améliorer les outils
+ Affiner la communication et les remontées
+ Savoir faire face sereinement aux scénarios extraordinaires et inattendus
Pour ces raisons, la valeur tirée de la participation à une activité de simulation augmente l'efficacité d'une organisation lors d'événements stressants. Il peut s'avérer difficile de développer une activité de simulation à la fois réaliste et bénéfique. Bien que les tests de vos procédures ou l'automatisation qui gère des événements déjà connus présentent certains avantages, il est tout aussi important de participer à des activités créatives [de simulation de la gestion des incidents de sécurité](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) pour déterminer où vous vous situez par rapport à des événements inattendus et pour renforcer vos compétences en permanence.
Créez des simulations personnalisées adaptées à votre environnement, votre équipe et vos outils. Identifiez un problème et concevez votre simulation autour de celui-ci. Il peut s'agit d'une fuite d'informations d'identification, d'un serveur communiquant avec des systèmes indésirables ou d'une mauvaise configuration qui entraîne une exposition non autorisée. Identifiez les ingénieurs qui connaissent votre organisation pour créer le scénario et un autre groupe pour y participer. Pour être utile, le scénario doit être suffisamment réaliste et stimulant. Il doit permettre de se familiariser avec la journalisation, les notifications, les remontées d'informations et l'exécution de runbooks ou l'automatisation. Pendant la simulation, les intervenants doivent exercer leurs compétences techniques et organisationnelles, tandis que les dirigeants doivent être impliqués pour développer leurs compétences en gestion des incidents. À la fin de la simulation, célébrez les efforts de l'équipe et cherchez des moyens d'itérer, de répéter et de développer d'autres simulations.
[AWS a créé des modèles de runbooks de gestion des incidents](https://github.com/aws-samples/aws-incident-response-playbooks) que vous pouvez utiliser non seulement pour préparer vos actions correctives, mais aussi comme base pour une simulation. Lors de la planification, une simulation peut être divisée en cinq phases.
**Collecte des preuves : **Au cours de cette phase, une équipe reçoit des alertes par divers moyens, tels qu'un système interne de demandes d'assistance, des alertes provenant d'outils de surveillance, des conseils anonymes, voire des informations publiques. Les équipes se mettent ensuite à examiner les journaux d'infrastructure et d'application pour déterminer la source de la compromission. Cette étape devrait également impliquer les équipes internes de remontées d'informations et les responsables de la gestion des incidents. Une fois la source de la compromission identifiée, les équipes passent à la maîtrise de l'incident.
**Maîtrise de l'incident : **Les équipes ont déterminé l'existence d'un incident et ont établi la source de la compromission. Elles doivent maintenant prendre des mesures nécessaires pour le contenir, par exemple en désactivant les informations d'identification compromises, en isolant une ressource de calcul ou en révoquant l'autorisation d'un rôle.
**Éradication de l'incident : **Maintenant qu'elles ont maîtrisé l'incident, les équipes s'efforceront d'atténuer les vulnérabilités des applications ou des configurations d'infrastructure susceptibles d'être compromises. Cela peut inclure la rotation de toutes les informations d'identification utilisées pour une charge de travail, la modification des listes de contrôle d'accès (ACL) ou la modification des configurations réseau.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Exécuter [tests de simulation de pannes](https://wa.aws.amazon.com/wat.concept.gameday.en.html) : organisez des événements simulés [de réponse](https://wa.aws.amazon.com/wat.concept.incident.en.html) face aux incidents [(jeux de rôle)](https://wa.aws.amazon.com/wat.concept.event.en.html) pour différentes menaces qui impliquent des membres clés du personnel et la direction.
+ Capturer les leçons apprises : les leçons tirées des [tests de simulation de pannes](https://wa.aws.amazon.com/wat.concept.gameday.en.html) doivent faire partie d'une boucle de rétroaction pour améliorer vos processus.
## Ressources
**Documents connexes :**
+ [ Guide de réponse aux incidents AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
**Vidéos connexes :**
+ [ Mode d'emploi pour les runbooks, les rapports d'incidents et les réponses aux incidents ](https://youtu.be/E1NaYN_fJUo)