Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Réponse aux incidents de sécurité AWS Guide technique
**Topics**
+ [Résumé](#abstract)
+ [Êtes-vous Well-Architected ?](#are-you-well-architected)
+ [Introduction](introduction.md)
+ [Préparation](preparation.md)
+ [Opérations](operations.md)
+ [Activité postérieure à l’incident](post-incident-activity.md)
+ [Conclusion](conclusion.md)
+ [Collaborateurs](contributors.md)
+ [Annexe A : Définitions des fonctionnalités du cloud](appendix-a-cloud-capability-definitions.md)
+ [Annexe B : ressources de réponse aux AWS incidents](appendix-b-incident-response-resources.md)
+ [Notifications](notices.md)
## Résumé
Ce guide présente un aperçu des principes fondamentaux de la réponse aux incidents de sécurité dans l'environnement cloud Amazon Web Services (AWS) d'un client. Il fournit une vue d’ensemble des concepts de sécurité du cloud et de réponse aux incidents, et il identifie les fonctionnalités, les services et les mécanismes du cloud mis à la disposition des clients qui répondent à des problèmes de sécurité.
Ce guide est destiné aux personnes occupant des postes techniques et suppose que vous connaissez les principes généraux de la sécurité de l'information, que vous avez une compréhension de base de la réponse aux incidents de sécurité dans vos environnements sur site actuels et que vous êtes familiarisé avec les services cloud.
## Êtes-vous Well-Architected ?
Le [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/) Framework vous aide à comprendre les avantages et les inconvénients des décisions que vous prenez lors de la création de systèmes dans le cloud. Les six piliers du Framework vous permettent d'apprendre les meilleures pratiques architecturales pour concevoir et exploiter des systèmes fiables, sécurisés, efficaces, rentables et durables. À l'aide du [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/), disponible gratuitement dans la [AWS Well-Architected Tool console](https://console.aws.amazon.com/wellarchitected), vous pouvez évaluer vos charges de travail par rapport à ces meilleures pratiques en répondant à une série de questions pour chaque pilier.
[Pour obtenir des conseils d'experts supplémentaires et les meilleures pratiques relatives à votre architecture cloud (déploiements d'architecture de référence, diagrammes et livres blancs), consultez le Centre d'architecture.AWS](https://aws.amazon.com/architecture/)
# Introduction
La sécurité est la priorité absolue de AWS. AWS les clients bénéficient de centres de données et d'une architecture réseau conçus pour répondre aux besoins des entreprises les plus sensibles en matière de sécurité. AWS a un modèle de responsabilité partagée : AWS gère la sécurité *du* cloud, et les clients sont responsables de la sécurité *dans* le cloud. Cela signifie que vous avez le contrôle total de la mise en œuvre de votre sécurité, y compris l'accès à plusieurs outils et services pour vous aider à atteindre vos objectifs de sécurité. Ces fonctionnalités vous aident à établir une base de sécurité pour les applications exécutées dans le AWS Cloud.
Lorsqu'un écart par rapport à la base de référence se produit, par exemple en raison d'une mauvaise configuration ou de l'évolution de facteurs externes, vous devez réagir et enquêter. Pour y parvenir, vous devez comprendre les concepts de base de la réponse aux incidents de sécurité dans votre AWS environnement et les exigences relatives à la préparation, à la formation et à la formation des équipes cloud avant que des problèmes de sécurité ne surviennent. Il est important de connaître les contrôles et les fonctionnalités que vous pouvez utiliser, de consulter des exemples thématiques pour résoudre les problèmes potentiels et d'identifier les méthodes de correction qui utilisent l'automatisation pour améliorer la vitesse et la cohérence des réponses. En outre, vous devez comprendre vos exigences en matière de conformité et de réglementation en ce qui concerne l'élaboration d'un programme de réponse aux incidents de sécurité pour répondre à ces exigences.
La réponse aux incidents de sécurité peut être complexe, c'est pourquoi nous vous encourageons à mettre en œuvre une approche itérative : commencez par les principaux services de sécurité, développez les capacités de détection et de réponse de base, puis élaborez des manuels pour créer une bibliothèque initiale de mécanismes de réponse aux incidents sur laquelle vous pourrez itérer et améliorer.
## Avant de commencer
Avant de commencer à vous renseigner sur la réponse aux incidents liés aux événements de sécurité AWS, familiarisez-vous avec les normes et cadres pertinents en matière de AWS sécurité et de réponse aux incidents. Ces bases vous aideront à comprendre les concepts et les meilleures pratiques présentés dans ce guide.
### AWS normes et cadres de sécurité
Pour commencer, nous vous encourageons à consulter les [meilleures pratiques en matière de sécurité, d'identité et de conformité, le framework Security Pillar - AWS Well-Architected](https://aws.amazon.com/architecture/security-identity-compliance/) et [la perspective de sécurité du livre blanc Overview of AWS the Cloud Adoption Framework AWS (](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)CAF).
La AWS CAF fournit des conseils pour faciliter la coordination entre les différents services des organisations qui migrent vers le cloud. Les directives AWS de la CAF sont divisées en plusieurs domaines d'intérêt, appelés perspectives, qui sont pertinents pour la création de systèmes informatiques basés sur le cloud. Le point de vue de la sécurité décrit comment mettre en œuvre un programme de sécurité dans tous les flux de travail, notamment la réponse aux incidents. Ce document est le fruit de nos expériences de travail avec les clients pour les aider à mettre en place des programmes et des capacités de réponse aux incidents de sécurité efficaces et efficients.
### Normes et cadres de réponse aux incidents du secteur
Ce livre blanc suit les normes de réponse aux incidents et les meilleures pratiques du [Guide de gestion des incidents de sécurité informatique SP 800-61 r3](https://csrc.nist.gov/pubs/sp/800/61/r3/final), créé par le National Institute of Standards and Technology (NIST). Lire et comprendre les concepts introduits par le NIST est une condition préalable utile. Les concepts et les meilleures pratiques de ce guide du NIST seront appliqués aux AWS technologies décrites dans ce paper. Toutefois, les scénarios d'incidents sur site ne sont pas couverts par ce guide.
## AWS aperçu de la réponse aux incidents
Pour commencer, il est important de comprendre en quoi les opérations de sécurité et la réponse aux incidents sont différentes dans le cloud. Pour créer des capacités de réponse efficaces AWS, vous devez comprendre les écarts par rapport à la réponse sur site traditionnelle et leur impact sur votre programme de réponse aux incidents. Chacune de ces différences, ainsi que les principes fondamentaux de conception de la réponse aux AWS incidents, sont détaillés dans cette section.
### Aspects de la réponse aux AWS incidents
Tous les AWS utilisateurs d'une organisation doivent avoir une connaissance de base des processus de réponse aux incidents de sécurité, et le personnel de sécurité doit savoir comment répondre aux problèmes de sécurité. L’éducation, la formation et l’expérience sont essentielles à la réussite d’un programme de réponse aux incidents dans le cloud et sont idéalement mises en œuvre bien avant de devoir gérer un éventuel incident de sécurité. La base d'un programme de réponse aux incidents réussi dans le cloud repose sur la *préparation*, *les opérations* et *l'activité post-incident*.
Pour comprendre chacun de ces aspects, tenez compte des descriptions suivantes :
+ **Préparation** — Préparez votre équipe de réponse aux incidents à détecter les incidents et à y répondre AWS en interne en activant des contrôles de détection et en vérifiant l'accès approprié aux outils et services cloud nécessaires. De plus, préparez les playbooks nécessaires (manuels et automatisés) pour garantir des réponses fiables et cohérentes.
+ **Opérations** — Gérez les événements de sécurité et les incidents potentiels en suivant les phases de réponse aux incidents du NIST : détecter, analyser, contenir, éradiquer et récupérer.
+ **Activité après un incident** : répétez les résultats de vos événements de sécurité et de vos simulations pour améliorer l'efficacité de votre réponse, augmenter la valeur dérivée de la réponse et de l'enquête, et réduire davantage les risques. Vous devez tirer les leçons des incidents et vous impliquer pleinement dans les activités d’amélioration.
Chacun de ces aspects est exploré et détaillé dans ce guide. Le schéma suivant montre le flux de ces aspects, en s'alignant sur le cycle de vie de réponse aux incidents du NIST mentionné précédemment, mais avec des opérations comprenant la détection et l'analyse avec le confinement, l'éradication et le rétablissement.
![\[Schéma illustrant les différents aspects de la réponse aux AWS incidents\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/images/aspects-of-incident-response.png)
### AWS principes de réponse aux incidents et objectifs de conception
Bien que les processus et mécanismes généraux de réponse aux incidents tels que définis dans le [guide de gestion des incidents de sécurité informatique SP 800-61 du NIST](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) soient bons, nous vous encourageons également à prendre en compte ces objectifs de conception spécifiques qui sont pertinents pour répondre aux incidents de sécurité dans un environnement cloud :
+ **Établissez des objectifs de réponse** — Travaillez avec les parties prenantes, les conseillers juridiques et les dirigeants de l'organisation pour déterminer l'objectif de réponse à un incident. Parmi les objectifs communs, citons la maîtrise et l'atténuation du problème, le rétablissement des ressources affectées, la préservation des données à des fins de criminalistique, le retour à des opérations sûres connues et, en fin de compte, les leçons à tirer des incidents.
+ **Réagissez en utilisant le cloud** : implémentez des modèles de réponse dans le cloud, là où l'événement et les données se produisent.
+ **Sachez ce que vous avez et ce dont vous avez besoin** : préservez les journaux, les ressources, les instantanés et les autres preuves en les copiant et en les stockant dans un compte cloud centralisé dédié à la réponse. Utilisez des balises, des métadonnées et des mécanismes qui appliquent des stratégies de conservation. Vous devez comprendre quels services vous utilisez, puis identifier les exigences pour étudier ces services. Pour vous aider à comprendre votre environnement, vous pouvez également utiliser le balisage, dont il sera question plus loin dans la [Élaboration et mise en œuvre d’une stratégie de marquage](develop-and-implement-tagging-strategy.md) section de ce document.
+ **Utiliser des mécanismes de redéploiement** : si une anomalie de sécurité peut être attribuée à une mauvaise configuration, la correction peut consister simplement à supprimer la variation en redéployant les ressources avec la configuration appropriée. Si un compromis possible est identifié, vérifiez que votre redéploiement inclut une atténuation réussie et vérifiée des causes profondes.
+ **Automatisez dans la mesure du possible** : au fur et à mesure que les problèmes surviennent ou que les incidents se répètent, créez des mécanismes pour trier les événements courants et y répondre de manière programmatique. Utilisez des réponses humaines pour les incidents uniques, complexes ou sensibles pour lesquels les automatisations sont insuffisantes.
+ **Choisissez des solutions évolutives** : efforcez-vous de correspondre à l'évolutivité de l'approche de votre organisation en matière de cloud computing. Mettez en œuvre des mécanismes de détection et de réponse qui s'adaptent à l'ensemble de vos environnements afin de réduire efficacement le délai entre la détection et la réponse.
+ **Apprenez et améliorez votre processus** — Soyez proactif en identifiant les lacunes dans vos processus, vos outils ou votre personnel, et mettez en œuvre un plan pour les corriger. Les simulations sont des méthodes sûres pour identifier les lacunes et améliorer les processus. Reportez-vous à la [Activité postérieure à l’incident](post-incident-activity.md) section de ce document pour plus de détails sur la façon d'itérer vos processus.
Ces objectifs de conception vous rappellent que vous devez examiner la mise en œuvre de votre architecture afin de déterminer si elle est capable de répondre aux incidents et de détecter les menaces. Lorsque vous planifiez vos mises en œuvre dans le cloud, pensez à répondre à un incident, idéalement à l'aide d'une méthodologie de réponse fiable. Dans certains cas, cela signifie que plusieurs organisations, comptes et outils peuvent être spécifiquement configurés pour ces tâches de réponse. Ces outils et fonctions doivent être mis à la disposition du gestionnaire de l’incident par le biais d’un pipeline de déploiement. Ils ne doivent pas être statiques, car cela peut entraîner un risque plus important.
### Domaines d'incidents de sécurité dans le cloud
Pour vous préparer et réagir efficacement aux événements de sécurité dans votre AWS environnement, vous devez comprendre les types courants d'incidents de sécurité dans le cloud. Les incidents de sécurité peuvent survenir dans trois domaines relevant de la responsabilité du client : le service, l'infrastructure et les applications. Les différents domaines nécessitent des connaissances, des outils et des processus de réponse différents. Tenez compte des domaines suivants :
+ **Domaine de service** : les incidents dans le domaine des services peuvent affecter vos Compte AWS autorisations [Gestion des identités et des accès AWS](https://aws.amazon.com/iam/)(IAM), les métadonnées des ressources, la facturation ou d'autres domaines. Un événement de domaine de service est un événement auquel vous répondez exclusivement par le biais de mécanismes d' AWS API, ou dont les causes profondes sont associées à votre configuration ou à vos autorisations de ressources, et qui peut être associé à une journalisation axée sur les services.
+ **Domaine de l'infrastructure** — Les incidents dans le domaine de l'infrastructure incluent les données ou les activités liées au réseau, telles que les processus et les données sur vos instances [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2), le trafic vers vos instances Amazon EC2 au sein du cloud privé virtuel (VPC) et d'autres domaines, tels que les conteneurs ou autres services futurs. Votre réponse aux événements du domaine de l'infrastructure implique souvent l'acquisition de données relatives aux incidents à des fins d'analyse judiciaire. Cela inclut probablement une interaction avec le système d'exploitation d'une instance et, dans certains cas, peut également impliquer des mécanismes AWS d'API. Dans le domaine de l'infrastructure, vous pouvez utiliser une combinaison d' AWS API et d'outils de forensics/incident réponse numérique (DFIR) au sein d'un système d'exploitation client, comme une instance Amazon EC2 dédiée à l'analyse et aux enquêtes médico-légales. Les incidents liés au domaine de l'infrastructure peuvent impliquer l'analyse de captures de paquets réseau, de blocs de disque sur un volume [Amazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS) ou de mémoire volatile acquise à partir d'une instance.
+ **Domaine d'application** : les incidents dans le domaine d'application se produisent dans le code de l'application ou dans le logiciel déployé sur les services ou l'infrastructure. Ce domaine doit être inclus dans vos manuels de détection et de réponse aux menaces dans le cloud et peut intégrer des réponses similaires à celles du domaine de l'infrastructure. Avec une architecture d'application appropriée et réfléchie, vous pouvez gérer ce domaine à l'aide d'outils cloud en utilisant l'acquisition, la restauration et le déploiement automatisés.
Dans ces domaines, considérez les acteurs susceptibles d'agir contre AWS des comptes, des ressources ou des données. Que ce soit à l'interne ou à l'externe, utilisez un cadre de gestion des risques pour déterminer les risques spécifiques auxquels l'organisation est exposée et préparez-vous en conséquence. En outre, vous devez développer des modèles de menace, qui peuvent vous aider à planifier la réponse aux incidents et à élaborer une architecture réfléchie.
### Principales différences de réponse aux incidents dans AWS
La réponse aux incidents fait partie intégrante d'une stratégie de cybersécurité, que ce soit sur site ou dans le cloud. Les principes de sécurité tels que le moindre privilège et la défense en profondeur visent à protéger la confidentialité, l'intégrité et la disponibilité des données sur site et dans le cloud. Plusieurs modèles de réponse aux incidents qui soutiennent ces principes de sécurité emboîtent le pas, notamment la conservation des journaux, la sélection des alertes dérivée de la modélisation des menaces, le développement de playbooks et l'intégration de la gestion des informations et des événements de sécurité (SIEM). Les différences commencent lorsque les clients commencent à concevoir et à concevoir ces modèles dans le cloud. Voici les principales différences entre la réponse aux incidents dans AWS.
#### Différence \$11 : la sécurité en tant que responsabilité partagée
La responsabilité de la sécurité et de la conformité est partagée entre AWS et ses clients. Ce modèle de responsabilité partagée allège une partie de la charge opérationnelle du client en AWS exploitant, en gérant et en contrôlant les composants, depuis le système d'exploitation hôte et la couche de virtualisation jusqu'à la sécurité physique des installations dans lesquelles le service fonctionne. Pour plus de détails sur le modèle de responsabilité partagée, reportez-vous à la documentation du [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/).
À mesure que votre responsabilité partagée dans le cloud évolue, vos options de réponse aux incidents changent également. Planifier et comprendre ces compromis et les adapter à vos besoins de gouvernance est une étape cruciale de la réponse aux incidents.
Outre la relation directe que vous entretenez avec vous AWS, il se peut que d'autres entités aient des responsabilités dans votre modèle de responsabilité particulier. Par exemple, vous pouvez avoir des unités organisationnelles internes qui sont responsables de certains aspects de vos opérations. Vous pouvez également avoir des relations avec d'autres parties qui développent, gèrent ou exploitent certaines de vos technologies cloud.
Il est extrêmement important de créer et de tester un plan de réponse aux incidents approprié et des playbooks adaptés à votre modèle opérationnel.
#### Différence \$12 : domaine de service cloud
En raison des différences de responsabilité en matière de sécurité qui existent dans les services cloud, un nouveau domaine pour les incidents de sécurité a été introduit : le domaine des services, qui a été expliqué plus haut dans la section [Domaine des incidents](#cloud-security-incident-domains). Le domaine de service englobe le AWS compte d'un client, les autorisations IAM, les métadonnées des ressources, la facturation et d'autres domaines. Ce domaine est différent pour la réponse aux incidents en raison de la façon dont vous réagissez. La réponse au sein du domaine de service se fait généralement en examinant et en émettant des appels d'API, plutôt que des réponses traditionnelles basées sur l'hôte et sur le réseau. Dans le domaine des services, vous n'interagirez pas avec le système d'exploitation d'une ressource affectée.
Le schéma suivant montre un exemple d'événement de sécurité dans le domaine des services basé sur un anti-modèle architectural. Dans ce cas, un utilisateur non autorisé obtient les informations d'identification de sécurité à long terme d'un utilisateur IAM. L'utilisateur IAM dispose d'une politique IAM qui lui permet de récupérer des objets depuis un compartiment [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3). Pour répondre à cet événement de sécurité, vous AWS APIs devez analyser AWS des journaux tels que [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)les journaux d'accès Amazon S3. Vous l'utiliseriez également AWS APIs pour contenir l'incident et vous en remettre.
![\[Exemple de schéma d'un domaine de service\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/images/service-domain-example.png)
#### Différence \$13 : APIs pour le provisionnement de l'infrastructure
Une autre différence réside dans la [caractéristique cloud du libre-service à la demande](https://csrc.nist.gov/publications/detail/sp/800-145/final). Le principal établissement avec lequel les clients interagissent AWS Cloud en utilisant une RESTful API via des points de terminaison publics et privés disponibles dans de nombreuses zones géographiques du monde entier. Les clients peuvent y accéder à l' APIs aide d' AWS informations d'identification. Contrairement au contrôle d'accès sur site, ces informations d'identification ne sont pas nécessairement liées à un réseau ou à un domaine Microsoft Active Directory. Les informations d'identification sont plutôt associées à un principal IAM au sein d'un AWS compte. Ces points de terminaison d'API sont accessibles en dehors du réseau de votre entreprise, ce qui sera important à comprendre lorsque vous répondez à un incident au cours duquel les informations d'identification sont utilisées en dehors du réseau ou de la zone géographique auxquels vous vous attendez.
En raison de sa nature basée sur les API AWS, une source de journal importante pour répondre aux événements de sécurité est celle AWS CloudTrail qui suit les appels d'API de gestion effectués dans vos AWS comptes et où vous pouvez trouver des informations sur l'emplacement de la source des appels d'API.
#### Différence \$14 : nature dynamique du cloud
Le cloud est dynamique ; il permet de créer et de supprimer rapidement des ressources. Grâce à la mise à l'échelle automatique, les ressources peuvent être augmentées ou diminuées en fonction de l'augmentation du trafic. Avec une infrastructure éphémère et des changements rapides, il est possible qu'une ressource que vous étudiez n'existe plus ou ait été modifiée. Pour l'analyse des incidents, il sera important de AWS comprendre la nature éphémère des AWS ressources et de savoir comment suivre leur création et leur suppression. Vous pouvez l'utiliser [AWS Config](https://aws.amazon.com/config/)pour suivre l'historique de configuration de vos AWS ressources.
#### Différence \$15 : Accès aux données
L'accès aux données est également différent dans le cloud. Vous ne pouvez pas vous connecter à un serveur pour collecter les données dont vous avez besoin pour une enquête de sécurité. Les données sont collectées par câble et par le biais d'appels d'API. Vous devrez vous entraîner et comprendre comment effectuer la collecte de données afin de APIs vous préparer à ce changement, et vérifier que le stockage est approprié pour une collecte et un accès efficaces.
#### Différence \$16 : Importance de l'automatisation
Pour que les clients puissent pleinement tirer parti des avantages de l'adoption du cloud, leur stratégie opérationnelle doit intégrer l'automatisation. L'infrastructure en tant que code (IaC) est un modèle d'environnements automatisés hautement efficaces dans lesquels les AWS services sont déployés, configurés, reconfigurés et détruits à l'aide de code facilité par des services iAc natifs tels que [AWS CloudFormation](https://aws.amazon.com/cloudformation/)des solutions tierces. Cela pousse la mise en œuvre de la réponse aux incidents à être hautement automatisée, ce qui est souhaitable pour éviter les erreurs humaines, en particulier lors du traitement des preuves. Bien que l'automatisation soit utilisée sur site, elle est essentielle et plus simple dans le AWS Cloud.
#### Aborder ces différences
Pour remédier à ces différences, suivez les étapes décrites dans la section suivante pour vérifier que votre programme de réponse aux incidents en termes de personnel, de processus et de technologie est bien préparé.
# 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 concernées par la réponse aux incidents 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 plans de réponse aux incidents complets et de créer des guides pour une réponse cohérente aux é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 capacité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.
# Personnes
Pour répondre à un événement de sécurité, vous devez identifier les parties prenantes susceptibles de soutenir la réponse à un événement de sécurité. En outre, il est essentiel pour une réponse efficace de les former aux AWS technologies et à votre AWS environnement.
# Définition des rôles et des responsabilités
La gestion des événements de sécurité exige une discipline interorganisationnelle et une volonté d’action. Au sein de votre structure organisationnelle, de nombreuses personnes doivent être responsables, tenues de rendre des comptes, consultées ou tenues informées lors d’un incident. Il peut notamment s’agir de représentants des ressources humaines (RH), de l’équipe de direction et du service juridique. Tenez compte de ces rôles et responsabilités et déterminez si des tiers doivent être impliqués. Notez que dans de nombreuses zones géographiques, des lois locales régissent ce qui doit être fait et ce qui ne doit pas être fait. Bien qu'il puisse sembler bureaucratique de créer un tableau RACI responsable, responsable, consulté et informé (RACI) pour vos plans d'intervention en matière de sécurité, cela permet une communication rapide et directe et décrit clairement le leadership aux différentes étapes de l'événement.
Lors d'un incident, il est essentiel owners/developers d'inclure les applications et les ressources touchées, car ce sont des experts en la matière (SMEs) qui peuvent fournir des informations et un contexte pour aider à mesurer l'impact. Assurez-vous d’établir et de maintenir des relations avec les développeurs et les propriétaires d’applications avant de vous fier à leur expertise pour répondre aux incidents. Les propriétaires d'applications ou SMEs, tels que vos administrateurs ou ingénieurs cloud, peuvent avoir besoin d'agir dans des situations où l'environnement n'est pas familier ou complexe, ou lorsque les intervenants n'y ont pas accès.
Enfin, des relations de confiance peuvent être impliquées dans l'enquête ou l'intervention, car elles peuvent apporter une expertise supplémentaire et un examen minutieux. Si vous ne possédez pas ces compétences au sein de votre propre équipe, vous pouvez faire appel à un tiers pour obtenir de l’aide.
# Former le personnel de réponse aux incidents
Il sera essentiel de former votre personnel de réponse aux incidents aux technologies utilisées par leur organisation pour qu'il puisse réagir de manière adéquate à un événement de sécurité. Les réponses peuvent être prolongées si les membres de votre personnel ne comprennent pas les technologies sous-jacentes. Outre les concepts traditionnels de réponse aux incidents, il est également important qu'ils comprennent les AWS services et leur AWS environnement. Il existe un certain nombre de mécanismes traditionnels pour former le personnel chargé de votre incident, tels que la formation en ligne et la formation en classe. Vous devriez également envisager d'organiser des journées de jeu ou des simulations comme mécanisme d'entraînement. Pour plus de détails sur la façon d'exécuter des simulations, consultez la [Exécutez des simulations régulières](run-regular-simulations.md) section de ce document.
# Comprendre les AWS Cloud technologies
Pour réduire les dépendances et réduire le temps de réponse, assurez-vous que vos équipes de sécurité et les intervenants sont formés aux services cloud et qu'ils ont la possibilité de s'entraîner sur le terrain avec l'environnement cloud spécifique utilisé par votre entreprise. Pour que les intervenants en cas d'incident soient efficaces, il est important de comprendre AWS les fondements, l'IAM, les services de AWS journalisation et de surveillance AWS Organizations, ainsi que les services AWS de sécurité.
AWS propose des ateliers de sécurité en ligne (voir [Ateliers de AWS sécurité](https://workshops.aws/categories/Security)) où vous pouvez acquérir une expérience pratique des services AWS de sécurité et de surveillance. AWS propose également un certain nombre d'options de formation et de parcours d'apprentissage par le biais de la formation numérique, de la formation en classe, de partenaires de AWS formation et de certifications. Pour en savoir plus, reportez-vous à la section [AWS Formation et certification](https://aws.amazon.com/training/).
AWS propose des formations gratuites et sur abonnement destinées à plusieurs personnes et domaines d'intérêt. Visitez [AWS Skillbuilder](https://skillbuilder.aws/) pour en savoir plus.
# Comprenez votre AWS environnement
Outre la compréhension AWS des services, de leurs cas d'utilisation et de la manière dont ils s'intègrent les uns aux autres, il est tout aussi important de comprendre comment l' AWS environnement de votre organisation est réellement conçu et quels sont les processus opérationnels en place. Souvent, de telles connaissances internes ne sont pas documentées et ne sont comprises que par quelques experts du domaine, ce qui peut créer des dépendances, entraver l'innovation et ralentir le temps de réponse.
Pour éviter ces dépendances et accélérer les temps de réponse, les connaissances internes de votre AWS environnement doivent être documentées, accessibles et comprises par vos analystes de sécurité. Comprendre l'ensemble de votre empreinte cloud nécessitera une collaboration entre les acteurs de sécurité concernés et les administrateurs du cloud. La préparation de vos processus de réponse aux incidents inclut notamment la documentation et la centralisation des diagrammes d'architecture, dont il sera question [Documenter et centraliser les diagrammes d'architecture](document-and-centralize-architecture-diagrams.md) plus loin dans ce livre blanc. Cependant, du point de vue des personnes, il est important que vos analystes puissent accéder aux diagrammes et aux processus opérationnels liés à votre AWS environnement et les comprendre.
# Comprenez les équipes d' AWS intervention et le support
## Support
[Support](https://aws.amazon.com/premiumsupport/)propose une gamme de plans qui donnent accès à des outils et à une expertise qui favorisent le succès et la santé opérationnelle de vos AWS solutions. Si vous avez besoin d'un support technique et de ressources supplémentaires pour planifier, déployer et optimiser votre AWS environnement, vous pouvez sélectionner le plan de support le mieux adapté à votre cas AWS d'utilisation.
Considérez le [Centre de support situé](https://console.aws.amazon.com/support) dans le AWS Management Console (connexion requise) comme point de contact central pour obtenir de l'aide en cas de problème affectant vos AWS ressources. L'accès à Support est contrôlé par IAM. Pour plus d'informations sur l'accès aux fonctionnalités de AWS Support, reportez-vous à la section [Mise en route avec Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
De plus, si vous devez signaler un abus, contactez l'[équipe AWS Tust and Safety](https://aws.amazon.com/forms/report-abuse).
## Ingénieurs de réponse aux incidents de sécurité
Les ingénieurs de réponse aux incidents de sécurité constituent une AWS équipe mondiale spécialisée toujours disponible qui fournit une assistance aux clients lors d'événements de sécurité actifs du côté client dans le cadre du [modèle de responsabilitéAWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/).
Lorsque les ingénieurs de réponse aux incidents de sécurité vous aident, vous bénéficiez d'une assistance pour le triage et le rétablissement en cas d'événement de sécurité actif. AWS Ils vous aideront à analyser les causes profondes grâce à l'utilisation des journaux de AWS service et vous fourniront des recommandations pour le rétablissement. Ils fourniront également des recommandations de sécurité et les meilleures pratiques pour vous aider à éviter les événements de sécurité à l'avenir.
AWS les clients peuvent faire appel à des ingénieurs de réponse aux incidents de sécurité par le biais d'un [dossier d'AWS assistance](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ **Tous les clients** :
1. Account and billing (Compte et facturation)
1. Service : Compte
1. Catégorie : Sécurité
1. Gravité : question générale
+ **Clients disposant de Support forfaits pour développeurs** :
1. Account and billing (Compte et facturation)
1. Service : Compte
1. Catégorie : Sécurité
1. Gravité : question importante
+ **Clients disposant de Support plans d'affaires** :
1. Account and billing (Compte et facturation)
1. Service : Compte
1. Catégorie : Sécurité
1. Sévérité : question urgente ayant un impact sur les activités
+ **Clients disposant d'un Support forfait Enterprise** :
1. Account and billing (Compte et facturation)
1. Service : Compte
1. Catégorie : Sécurité
1. Gravité : question critique du risque commercial
+ **Clients Réponse aux incidents de sécurité AWS abonnés** : ouvrez la console Security Incident Response à l'adresse https://console.aws.amazon.com/security-ir/
## DDoSupport de réponse
AWS offres [AWS Shield](https://aws.amazon.com/shield/), qui fournit un service géré de protection par déni de service (DDoS) distribué qui protège les applications Web exécutées sur AWS. AWS Shield fournit une détection permanente et des mesures d'atténuation automatiques en ligne qui peuvent minimiser les temps d'arrêt et la latence des applications. Il n'est donc pas nécessaire de s'engager Support pour bénéficier de la protection S. DDo Il existe deux niveaux AWS Shield : Shield Standard et Shield Advanced. Pour en savoir plus sur les différences entre ces deux niveaux, consultez la [documentation des fonctionnalités du Shield](https://aws.amazon.com/shield/features/).
## AWS Managed Services (AMS)
[AWS Managed Services](https://aws.amazon.com/managed-services/)(AMS) assure la gestion continue de votre AWS infrastructure 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 est responsable du déploiement d'une suite de contrôles de sécurité et fournit une première ligne de réponse quotidienne 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.
# Processus
L'élaboration de processus de réponse aux incidents complets et clairement définis est essentielle à la réussite et à l'évolutivité du programme de réponse aux incidents. Lorsqu'un événement de sécurité survient, des étapes et des flux de travail clairs vous aideront à réagir rapidement. Il se peut que vous disposiez déjà d'un processus de réponse aux incidents. Quel que soit votre état actuel, il est important de mettre à jour, d’itérer et de tester régulièrement vos processus de réponse aux incidents.
# Élaboration et test d'un plan de réponse aux incidents
Le premier document à développer pour la réponse aux incidents est le *plan de réponse aux incidents*. Le plan d’intervention en cas d’incident est conçu pour servir de base à votre programme et à votre stratégie de réponse aux incidents. Un plan de réponse aux incidents est un document de haut niveau qui comprend généralement les sections suivantes :
+ **Vue d'ensemble de l'équipe de réponse aux incidents** : décrit les objectifs et les fonctions de l'équipe de réponse aux incidents
+ **Rôles et responsabilités** — Répertorie les parties prenantes de la réponse aux incidents et détaille leurs rôles en cas d'incident
+ **Un plan de communication** — Détaille les informations de contact et la manière dont vous communiquerez lors d'un incident
Il est recommandé d'utiliser la out-of-band communication comme solution de rechange à la communication en cas d'incident. [AWS Wickr](https://aws.amazon.com/wickr/) est un exemple d'application fournissant un canal de out-of-band communication sécurisé.
+ **Phases de réponse aux incidents et mesures à prendre** — Énumère les phases de réponse aux incidents (par exemple, détecter, analyser, éradiquer, contenir et rétablir), y compris les actions de haut niveau à prendre au cours de ces phases
+ **Définitions de la gravité et de la hiérarchisation des incidents** : explique comment classer la gravité d'un incident, comment hiérarchiser l'incident, puis comment les définitions de gravité affectent les procédures d'escalade
Bien que ces sections soient communes à des entreprises de tailles et de secteurs différents, le plan d’intervention en cas d’incident de chaque organisation est unique. Vous devrez élaborer un plan de réponse aux incidents qui convient le mieux à votre organisation.
# Documenter et centraliser les diagrammes d'architecture
Pour réagir rapidement et avec précision à un événement de sécurité, vous devez comprendre l'architecture de vos systèmes et réseaux. La compréhension de ces modèles internes est non seulement importante pour la réponse aux incidents, mais également pour vérifier la cohérence entre les applications avec lesquelles les modèles sont conçus, conformément aux meilleures pratiques. Vous devez également vérifier que cette documentation est à jour et régulièrement mise à jour conformément aux nouveaux modèles d'architecture. Vous devez développer une documentation et des référentiels internes détaillant des éléments tels que :
+ **AWS structure du compte** - Vous devez savoir :
+ Combien de AWS comptes possèdes-tu ?
+ Comment sont organisés ces AWS comptes ?
+ Qui sont les propriétaires commerciaux des AWS comptes ?
+ Utilisez-vous les politiques de contrôle des services (SCPs) ? Dans l'affirmative, quels sont les garde-fous organisationnels mis en œuvre en utilisant ? SCPs
+ Limitez-vous les régions et les services qui peuvent être utilisés ?
+ Quelles sont les différences entre les unités commerciales et les environnements (dev/test/prod) ?
+ **AWS modèles de service**
+ Quels sont AWS les services que vous utilisez ?
+ Quels sont les AWS services les plus utilisés ?
+ **Modèles d'architecture**
+ Quelles architectures cloud utilisez-vous ?
+ **AWS modèles d'authentification**
+ Comment vos développeurs s'authentifient-ils généralement ? AWS
+ Utilisez-vous des rôles ou des utilisateurs IAM (ou les deux) ? Votre système d'authentification est-il AWS connecté à un fournisseur d'identité (IdP) ?
+ Comment associer un rôle ou un utilisateur IAM à un employé ou à un système ?
+ Comment l'accès est-il révoqué lorsqu'une personne n'est plus autorisée ?
+ **AWS modèles d'autorisation**
+ Quelles sont les politiques IAM utilisées par vos développeurs ?
+ Utilisez-vous des politiques basées sur les ressources ?
+ **Journalisation et surveillance**
+ Quelles sources de journalisation utilisez-vous et où sont-elles stockées ?
+ Agrégez-vous AWS CloudTrail les journaux ? Dans l'affirmative, où sont-ils conservés ?
+ Comment interrogez-vous CloudTrail les journaux ?
+ Amazon est-il GuardDuty activé ?
+ Comment accèdez-vous aux GuardDuty résultats (par exemple, console, système de billetterie, SIEM) ?
+ Les résultats ou les événements sont-ils agrégés dans un SIEM ?
+ Les tickets sont-ils créés automatiquement ?
+ Quels sont les outils mis en place pour analyser les journaux dans le cadre d'une enquête ?
+ **Topologie du réseau**
+ Comment les appareils, les points de terminaison et les connexions de votre réseau sont-ils organisés physiquement ou logiquement ?
+ Comment se connecte votre réseau AWS ?
+ Comment le trafic réseau est-il filtré entre les environnements ?
+ **Infrastructures externes**
+ Comment sont déployées les applications orientées vers l'extérieur ?
+ Quelles AWS ressources sont accessibles au public ?
+ Quels AWS comptes contiennent des infrastructures orientées vers l'extérieur ?
+ Quel DDo type de filtrage S ou externe existe-t-il ?
La documentation des schémas techniques et des processus internes facilite le travail de l'analyste de réponse aux incidents, en l'aidant à acquérir rapidement les connaissances institutionnelles nécessaires pour répondre à un événement de sécurité. Une documentation complète des processus techniques internes simplifie non seulement les enquêtes de sécurité, mais permet également de rationaliser et d'évaluer les processus.
# Élaborez des manuels de réponse aux incidents
L’élaboration de playbooks est une étape clé de la préparation de vos processus de réponse aux incidents. Les playbooks de réponse aux incidents fournissent une série de recommandations et d’étapes à suivre en cas d’événement de sécurité. Le fait de disposer d’une structure et d’étapes claires simplifie la réponse et réduit le risque d’erreur humaine.
# Pour quoi créer des playbooks
Il est recommandé de créer des playbooks dans les scénarios d’incidents suivants :
+ **Incidents attendus** — Des playbooks doivent être créés pour les incidents que vous anticipez. Cela inclut des menaces telles que le déni de service (DoS), les rançongiciels et la mise en péril des informations d’identification.
+ **Constatations ou alertes de sécurité connues** — Des playbooks doivent être créés pour vos découvertes et alertes de sécurité connues, telles que GuardDuty les découvertes. Vous pourriez recevoir une GuardDuty découverte et vous demander : « Et maintenant ? » Pour éviter de mal gérer un GuardDuty résultat ou de l'ignorer, créez un manuel pour chaque résultat potentiel GuardDuty. Vous trouverez des informations et des conseils sur les mesures correctives dans la [GuardDutydocumentation](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Il convient de noter que cela n' GuardDuty est pas activé par défaut et qu'il entraîne un coût. GuardDuty Vous trouverez plus de détails à ce sujet dans l'annexe A : Définitions des fonctionnalités cloud -[Visibilité et alertes](visibility-and-alerting.md).
# Ce qu'il faut inclure dans les playbooks
Les playbooks doivent contenir les étapes techniques qu’un analyste de sécurité doit suivre afin d’enquêter de manière adéquate et de répondre à un éventuel incident de sécurité.
Les éléments à inclure dans un playbook incluent :
+ **Présentation du playbook** — Quel scénario de risque ou d'incident ce playbook aborde-t-il ? Quel est l’objectif du playbook ?
+ **Conditions préalables** — Quels journaux et mécanismes de détection sont nécessaires pour ce scénario d'incident ? Quelle est la notification attendue ?
+ **Informations sur les parties prenantes** — Qui est impliqué et quelles sont ses coordonnées ? Quelles sont les responsabilités de chacune des parties prenantes ?
+ **Étapes de réponse** — Quelles mesures tactiques devraient être prises au cours des différentes phases de la réponse aux incidents ? Quelles requêtes un analyste doit-il exécuter ? Quel code doit être exécuté pour obtenir le résultat souhaité ?
+ **Détecter** — Comment l'incident sera-t-il détecté ?
+ **Analyser** — Comment l'ampleur de l'impact sera-t-elle déterminée ?
+ **Contenir** — Comment l'incident sera-t-il isolé pour en limiter la portée ?
+ **Éradiquer** — Comment la menace sera-t-elle éliminée de l'environnement ?
+ **Restaurer** — Comment le système ou la ressource concernés seront-ils remis en production ?
+ **Résultats attendus** — Une fois les requêtes et le code exécutés, quel est le résultat attendu du playbook ?
Pour vérifier la cohérence des informations contenues dans chaque playbook, il peut être utile de créer un modèle de playbook à utiliser dans vos autres playbooks de sécurité. Certains des éléments listés précédemment, tels que les informations sur les parties prenantes, peuvent être partagés entre plusieurs playbooks. Si tel est le cas, vous pouvez créer une documentation centralisée pour ces informations et la référencer dans le playbook, puis énumérer les différences explicites dans le playbook. Cela vous évitera d'avoir à mettre à jour les mêmes informations dans tous vos playbooks individuels. En créant un modèle et en identifiant les informations communes ou partagées dans les playbooks, vous pouvez simplifier et accélérer le développement des playbooks. Enfin, vos playbooks évolueront probablement au fil du temps ; une fois que vous aurez confirmé que les étapes sont cohérentes, cela constitue la condition requise pour l'automatisation.
# Exemples de playbooks
Vous trouverez un certain nombre d'exemples de playbooks à l'annexe B dans[Ressources du Playbook](appendix-b-incident-response-resources.md#playbook-resources). Les exemples présentés ici peuvent vous aider à choisir les playbooks à créer et les éléments à inclure dans vos playbooks. Cependant, il est important que vous élaboriez des stratégies qui intègrent les risques les plus pertinents pour votre entreprise. Vous devez vérifier que les étapes et les flux de travail de vos playbooks incluent vos technologies et processus.
# Exécutez des simulations régulières
Organisations grandissent et évoluent au fil du temps, tout comme le paysage des menaces. C'est pourquoi il est important de revoir en permanence vos capacités de réponse aux incidents. Les simulations sont l'une des méthodes qui peuvent être utilisées pour effectuer cette évaluation. Les simulations utilisent des scénarios d'événements de sécurité réels conçus pour imiter les tactiques, les techniques et les procédures d'un acteur menaçant (TTPs) et permettre à une organisation d'exercer et d'évaluer ses capacités de réponse aux incidents en réagissant à ces cyberévénements simulés tels qu'ils peuvent se produire dans la réalité.
Les simulations présentent de nombreux avantages, notamment :
+ Validation de l’état de préparation à la cybersécurité et renforcement de la confiance de vos intervenants en cas d’incident.
+ Test de la précision et de l’efficacité des outils et des flux de travail.
+ Amélioration des méthodes de communication et de remontées en fonction de votre plan d’intervention en cas d’incident.
+ Possibilité de répondre à des vecteurs moins courants.
# Types de simulations
Il existe trois principaux types de simulations :
+ **Exercices sur table** — L'approche théorique des simulations est strictement une session basée sur des discussions impliquant les différents acteurs de la réponse aux incidents afin de mettre en pratique leurs rôles et responsabilités et d'utiliser les outils de communication et les manuels de stratégie établis. La facilitation des exercices peut généralement être réalisée en une journée complète dans un lieu virtuel, un lieu physique ou une combinaison des deux. En raison de sa nature basée sur la discussion, l'exercice sur table met l'accent sur les processus, les personnes et la collaboration. La technologie fait partie intégrante de la discussion ; toutefois, l'utilisation réelle d'outils ou de scripts de réponse aux incidents ne fait généralement pas partie de l'exercice théorique.
+ **Exercices Purple Team** — Les exercices Purple Team augmentent le niveau de collaboration entre les intervenants en cas d'incident (*équipe bleue*) et les acteurs de menaces simulés (*équipe rouge*). L'équipe bleue est généralement composée de membres du Security Operations Center (SOC), mais peut également inclure d'autres parties prenantes qui seraient impliquées lors d'un véritable cyberévénement. L'équipe rouge est généralement composée d'une équipe de tests d'intrusion ou de parties prenantes clés formées à la sécurité offensive. L'équipe rouge travaille en collaboration avec les animateurs de l'exercice lors de la conception d'un scénario afin que celui-ci soit précis et réalisable. Au cours des exercices Purple Team, l'accent est mis principalement sur les mécanismes de détection, les outils et les procédures opérationnelles standard (SOPs) qui soutiennent les efforts de réponse aux incidents.
+ **Exercices de l'équipe rouge** — Au cours d'un exercice de l'*équipe rouge, l'attaque (l'équipe rouge*) effectue une simulation pour atteindre un certain objectif ou un ensemble d'objectifs dans un cadre prédéterminé. Les défenseurs (*Blue Team*) ne connaîtront pas nécessairement la portée et la durée de l'exercice, ce qui permet une évaluation plus réaliste de la manière dont ils réagiraient en cas d'incident réel. Comme les exercices Red Team peuvent être des tests invasifs, vous devez faire preuve de prudence et mettre en place des contrôles pour vérifier que l'exercice ne cause pas de dommages réels à votre environnement.
**Note**
AWS demande aux clients de consulter la politique relative aux tests d'intrusion disponible sur le [site Web des tests de pénétration](https://aws.amazon.com/security/penetration-testing/) avant d'effectuer des exercices Purple Team ou Red Team.
Le tableau 1 résume quelques différences clés entre ces types de simulations. Il est important de noter que les définitions sont généralement considérées comme des définitions vagues et peuvent être personnalisées pour répondre aux besoins de votre organisation.
*Tableau 1 — Types de simulations*
| | Exercice sur table | Exercice Purple Team | Exercice Red Team |
| --- | --- | --- | --- |
| Résumé | Des exercices sur support papier qui se concentrent sur un scénario d'incident de sécurité spécifique. Ils peuvent être de haut niveau ou techniques et sont entraînés par une série d'injections de papier. | Une offre plus réaliste que les exercices sur table. Au cours des exercices Purple Team, les animateurs travaillent en collaboration avec les participants pour accroître leur engagement et proposer des formations si nécessaire. | Il s'agit généralement d'une offre de simulation plus avancée. Il y a généralement un niveau élevé de discrétion, les participants ne connaissant peut-être pas tous les détails de l'exercice. |
| Ressources nécessaires | Ressources techniques limitées requises | Diverses parties prenantes sont requises et des ressources techniques de haut niveau sont nécessaires | Diverses parties prenantes sont requises et des ressources techniques de haut niveau sont nécessaires |
| Complexité | Faible | Medium | Élevée |
Envisagez d’animer des simulations cybernétiques à intervalles réguliers. Chaque type d'exercice peut apporter des avantages uniques aux participants et à l'organisation dans son ensemble. Vous pouvez donc choisir de commencer par des types de simulation moins complexes (tels que des exercices sur table) et de passer à des types de simulation plus complexes (exercices Red Team). Vous devez sélectionner un type de simulation en fonction de la maturité de votre sécurité, de vos ressources et des résultats souhaités. Certains clients peuvent choisir de ne pas effectuer les exercices Red Team en raison de leur complexité et de leur coût.
# Cycle de vie des exercices
Quel que soit le type de simulation que vous choisissez, les simulations suivent généralement les étapes suivantes :
1. **Définir les principaux éléments de l'exercice** : définissez le scénario de simulation et les objectifs de la simulation. Les deux doivent être acceptés par les dirigeants.
1. **Identifier les principales parties prenantes** — À tout le moins, un exercice nécessite des animateurs et des participants. Selon le scénario, d’autres parties prenantes telles que les services juridiques, l’équipe de communication ou la direction, peuvent être impliquées.
1. **Élaborez et testez le scénario** : le scénario devra peut-être être redéfini au fur et à mesure de sa création si certains éléments ne sont pas réalisables. Un scénario finalisé est attendu à l’issue de cette étape.
1. **Faciliter la simulation** — Le type de simulation détermine la facilitation utilisée (scénario papier par rapport à un scénario simulé hautement technique). Les animateurs doivent adapter leurs tactiques d’animation aux objectifs de l’exercice et impliquer tous les participants dans l’exercice dans la mesure du possible afin d’en tirer le meilleur parti.
1. **Élaborer le rapport après action (AAR)** — Identifiez les domaines qui se sont bien déroulés, ceux qui peuvent être améliorés et les lacunes potentielles. L’AAR doit mesurer l’efficacité de la simulation ainsi que la réponse de l’équipe à l’événement simulé afin que les progrès puissent être suivis au fil du temps lors de futures simulations.
# Technologie
Si vous développez et mettez en œuvre les technologies appropriées avant un incident de sécurité, votre personnel de réponse aux incidents sera en mesure d'enquêter, d'en comprendre la portée et de prendre des mesures en temps opportun.
# Développer la structure des AWS comptes
[AWS Organizations](https://aws.amazon.com/organizations/)permet de gérer et de gouverner de manière centralisée un AWS environnement à mesure que vous développez et augmentez AWS les ressources. Une AWS organisation consolide vos AWS comptes afin que vous puissiez les administrer en tant qu'unité unique. Vous pouvez utiliser les unités organisationnelles (OUs) pour regrouper les comptes afin de les administrer en tant qu'unité unique.
Pour la réponse aux incidents, il est utile de disposer d'une structure de AWS compte prenant en charge les fonctions de réponse aux incidents, qui comprend une unité d'organisation de *sécurité et une* unité d'organisation *médico-légale*. Au sein de l’unité d’organisation de sécurité, vous devez disposer de comptes pour :
+ **Archivage des journaux** — Regroupez les journaux dans un compte d'archivage des AWS journaux.
+ **Outils de sécurité —** Centralisez les services de sécurité dans un compte d'outil AWS 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. Par exemple, si vous opérez uniquement dans l'est des États-Unis (Virginie du Nord) (us-east-1) et dans l'ouest des États-Unis (Oregon) (us-west-2), vous aurez deux comptes dans l'unité d'organisation forensics : un pour us-east-1 et un pour us-west-2. É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 :
![\[Schéma d'une structure de compte par région pour la réponse aux incidents\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/images/incident-response-account-structure.png)
# É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 concernées par une AWS ressource. Pour ce faire, vous pouvez notamment utiliser des balises, qui attribuent des métadonnées à vos AWS ressources et consistent en 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.
Une stratégie de balisage cohérente peut accélérer les temps de réponse 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 d'informations sur les éléments à étiqueter, reportez-vous à la [documentation sur le balisage AWS des ressources](https://docs.aws.amazon.com/general/latest/gr/aws_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. Vous trouverez des détails sur la mise en œuvre et l'application dans le AWS blog [Implémenter une stratégie de balisage AWS des ressources à l'aide des politiques de AWS balise et des politiques de contrôle des services (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
# Mettre à jour les informations de contact du AWS compte
Pour chacun de vos AWS comptes, il est important de disposer d'informations et de up-to-date coordonnées précises afin que les parties prenantes concernées reçoivent des notifications importantes AWS sur des sujets tels que la sécurité, la facturation et les opérations. Pour chaque AWS compte, vous avez un contact principal et des contacts alternatifs pour la sécurité, la facturation et les opérations. Les différences entre ces contacts peuvent être trouvées dans le [Guide de référence AWS sur la gestion des comptes](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate).
Pour plus de détails sur la gestion des contacts alternatifs, reportez-vous à la [AWS documentation sur l'ajout, la modification ou la suppression de contacts alternatifs](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-alternate-contacts). Il est recommandé d'utiliser une liste de distribution d'e-mails si votre équipe gère les problèmes liés à la facturation, aux opérations et à la sécurité. Une liste de distribution d'e-mails supprime les dépendances à l'égard d'une seule personne, ce qui peut entraîner des blocages si cette personne n'est pas au bureau ou quitte l'entreprise. Vous devez également vérifier que l'adresse e-mail et les coordonnées du compte, y compris le numéro de téléphone, sont bien protégés pour empêcher la réinitialisation du mot de passe du compte root et la réinitialisation de l'authentification multifactorielle (MFA).
Pour les clients utilisateurs AWS Organizations, les administrateurs de l'organisation peuvent gérer de manière centralisée les contacts alternatifs pour les comptes des membres à l'aide du compte de gestion ou d'un compte d'administrateur délégué sans avoir besoin d'informations d'identification pour chaque AWS compte. Vous devrez également vérifier que les informations de contact des comptes nouvellement créés sont exactes. Reportez-vous à la section [Mettre à jour automatiquement les contacts alternatifs pour les articles de Comptes AWS blog nouvellement créés](https://aws.amazon.com/blogs/mt/automatically-update-alternate-contacts-for-newly-created-aws-accounts/).
# Préparez l'accès à Comptes AWS
Lors d'un incident, vos équipes de réponse aux incidents doivent avoir accès aux environnements et aux ressources impliqués dans l'incident. Assurez-vous que vos équipes disposent d'un accès approprié pour accomplir leurs tâches avant qu'un événement ne se produise. Pour ce faire, vous devez connaître le niveau d'accès dont les membres de votre équipe ont besoin (par exemple, les types d'actions qu'ils sont susceptibles d'entreprendre) et vous devez prévoir à l'avance un accès avec le moindre privilège.
Pour mettre en œuvre et fournir cet accès, vous devez identifier et discuter de la stratégie de AWS compte et de la stratégie d'identité cloud avec les architectes cloud de votre entreprise afin de comprendre quelles méthodes d'authentification et d'autorisation sont configurées. En raison de la nature privilégiée de ces informations d'identification, vous devez envisager d'utiliser des flux d'approbation ou de récupérer des informations d'identification dans un coffre-fort ou un coffre-fort dans le cadre de votre implémentation. Après la mise en œuvre, vous devez documenter et tester l'accès des membres de l'équipe bien avant qu'un événement ne se produise afin de vous assurer qu'ils peuvent réagir sans délai.
Enfin, les utilisateurs créés spécifiquement pour répondre à un incident de sécurité sont souvent privilégiés afin de fournir un accès suffisant. Par conséquent, l'utilisation de ces informations d'identification doit être restreinte, surveillée et ne pas être utilisée pour les activités quotidiennes.
# Comprenez le paysage des menaces
## Développez des modèles de menaces
En développant des modèles de menaces, les entreprises peuvent identifier les menaces et les mesures d'atténuation avant qu'un utilisateur non autorisé ne le fasse. Il existe un certain nombre de stratégies et d'approches en matière de modélisation des menaces ; consultez le billet de blog [Comment aborder la modélisation des menaces](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/). Pour la réponse aux incidents, un modèle de menace peut aider à identifier les vecteurs d'attaque qu'un acteur de la menace aurait pu utiliser lors d'un incident. Il sera essentiel de comprendre contre quoi vous vous défendez afin de réagir rapidement. Vous pouvez également utiliser an AWS Partner pour la modélisation des menaces. Pour rechercher un AWS partenaire, utilisez le [AWS Partner Network](https://partners.amazonaws.com/).
## Intégrer et utiliser les renseignements sur les cybermenaces
Les renseignements sur les cybermenaces sont les données et l'analyse de l'intention, de l'opportunité et des capacités d'un acteur menaçant. L'obtention et l'utilisation de renseignements sur les menaces sont utiles pour détecter un incident à un stade précoce et pour mieux comprendre le comportement des auteurs de menaces. Les informations sur les cybermenaces incluent des indicateurs statiques tels que les adresses IP ou les hachages de fichiers contenant des logiciels malveillants. Il comprend également des informations de haut niveau, telles que les modèles de comportement et les intentions. Vous pouvez collecter des informations sur les menaces auprès d'un certain nombre de fournisseurs de cybersécurité et de référentiels open source.
Pour intégrer et optimiser les informations sur les menaces pour votre AWS environnement, vous pouvez utiliser certaines out-of-the-box fonctionnalités et intégrer vos propres listes de renseignements sur les menaces. Amazon GuardDuty utilise des sources AWS internes et tierces de renseignements sur les menaces. D'autres AWS services, tels qu'un pare-feu DNS et des AWS WAF règles, prennent également en compte les informations d'un AWS« groupe avancé de renseignement sur les menaces ». Certains GuardDuty résultats sont mis en correspondance avec le [cadre MITRE ATT&CK](https://attack.mitre.org/), qui fournit des informations sur des observations réelles sur les tactiques et techniques de l'adversaire.
# Sélection et configuration de journaux à des fins d’analyse et d’alerte
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. Chacune de ces actions est examinée dans cette section. Pour plus de détails, consultez le billet de AWS blog sur les [stratégies de journalisation pour la réponse aux incidents de sécurité](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/).
# Sélection et activation des sources de journalisation
Avant une enquête de sécurité, vous devez capturer les journaux pertinents afin de reconstituer rétroactivement l'activité d'un AWS compte. Sélectionnez et activez les sources de journal adaptées à la charge de travail de leur AWS compte.
AWS CloudTrail est un service de journalisation qui suit les appels d'API effectués par rapport à un AWS compte capturant l'activité AWS du service. Il est activé par défaut avec une conservation de 90 jours des événements de gestion qui peuvent être [récupérés via CloudTrail la fonction d'historique des événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) à l'aide AWS Management Console du AWS CLI SDK ou d'un AWS SDK. Pour une conservation et une visibilité plus longues des événements liés aux données, vous devez [créer un CloudTrail Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) associé à un compartiment Amazon S3, et éventuellement à un groupe de CloudWatch journaux. Vous pouvez également créer un [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), qui conserve les CloudTrail journaux pendant sept ans au maximum et fournit une fonction de requête basée sur SQL.
AWS recommande aux clients utilisant un VPC d'activer le trafic réseau et les journaux DNS à l'aide, respectivement, des journaux de flux [VPC et des journaux](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) de [requêtes du résolveur Amazon Route 53, en les diffusant soit vers un compartiment Amazon S3, soit vers un groupe de journaux](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html). CloudWatch Vous pouvez créer un journal de flux VPC pour un VPC, un sous-réseau ou une interface réseau. Pour les journaux de flux VPC, vous pouvez choisir comment et où activer les journaux de flux afin de réduire les coûts.
AWS CloudTrail Les journaux, les journaux de flux VPC et les journaux de requêtes du résolveur Route 53 constituent les *trois éléments de journalisation de base nécessaires aux enquêtes de sécurité*. AWS
AWS les services peuvent générer des journaux qui ne sont pas capturés par les trifectas de journalisation de base, tels que les journaux Elastic Load Balancing, les journaux, les AWS WAF journaux des AWS Config enregistreurs, les GuardDuty résultats d'Amazon, les journaux d'audit Amazon Elastic Kubernetes Service (Amazon EKS) et les journaux du système d'exploitation et des applications des instances Amazon EC2. Consultez la liste complète [Annexe A : Définitions des fonctionnalités du cloud](appendix-a-cloud-capability-definitions.md) des options de journalisation et de surveillance.
# Sélectionnez le stockage des journaux
Le choix du stockage des journaux dépend généralement de l'outil de requête que vous utilisez, des capacités de rétention, de la familiarité et du coût. Lorsque vous activez les journaux de AWS service, fournissez une installation de stockage, généralement un compartiment ou un groupe de CloudWatch journaux Amazon S3.
Un compartiment Amazon S3 fournit un stockage durable et rentable avec une politique de cycle de vie facultative. Les journaux stockés dans des compartiments Amazon S3 peuvent être interrogés de manière native à l'aide de services tels qu'Amazon Athena. Un groupe de CloudWatch journaux fournit un stockage durable et une fonction de requête intégrée via CloudWatch Logs Insights.
# Identifier la conservation appropriée des journaux
Lorsque vous utilisez un compartiment ou un groupe de CloudWatch journaux S3 pour stocker des journaux, vous devez établir des cycles de vie adéquats pour chaque source de journaux afin d'optimiser les coûts de stockage et de récupération. Les clients disposent généralement de 3 à 12 mois de journaux facilement disponibles pour les requêtes, avec une durée de conservation pouvant aller jusqu'à sept ans. Le choix de la disponibilité et de la conservation doit correspondre à vos exigences en matière de sécurité et à un ensemble d’obligations statutaires, réglementaires et opérationnelles.
# Sélection et mise en œuvre de mécanismes d'interrogation pour les journaux
Dans AWS, les principaux services que vous pouvez utiliser pour interroger les [CloudWatch journaux sont Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) pour les données stockées dans des groupes de CloudWatch journaux, et [Amazon Athena](https://aws.amazon.com/athena/) et [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) pour les données stockées dans Amazon S3. Vous pouvez également utiliser des outils de requête tiers tels que la gestion des informations et des événements de sécurité (SIEM).
Le processus de sélection d’un outil d’interrogation de journaux doit tenir compte des aspects humains, technologiques et de processus de vos opérations de sécurité. Choisissez un outil qui répond aux exigences opérationnelles, commerciales et de sécurité, et qui est à la fois accessible et maintenable à long terme. Gardez à l’esprit que les outils d’interrogation de journaux fonctionnent de manière optimale lorsque le nombre de journaux à analyser est maintenu dans les limites de l’outil. Il n'est pas rare que les clients disposent de plusieurs outils de requête en raison de contraintes financières ou techniques. Par exemple, les clients peuvent utiliser un SIEM tiers pour effectuer des requêtes portant sur les données des 90 derniers jours, et Athena pour effectuer des requêtes au-delà de 90 jours en raison du coût d'ingestion des journaux d'un SIEM. Quelle que soit la mise en œuvre, vérifiez que votre approche minimise le nombre d'outils nécessaires pour optimiser l'efficacité opérationnelle, en particulier lors d'une enquête sur un événement de sécurité.
# Utiliser les journaux pour les alertes
AWS fournit nativement des alertes via des services de sécurité, tels qu'Amazon GuardDuty [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), et. AWS Config Vous pouvez également utiliser des moteurs de génération d'alertes personnalisés pour les alertes de sécurité non couvertes par ces services ou pour les alertes spécifiques à votre environnement. La création de ces alertes et détections est abordée dans la section intitulée [Détection](detection.md) dans ce document.
# Développer les capacités de criminalistique
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é. Le [guide du NIST sur l'intégration des techniques de criminalistique dans la réponse aux incidents](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf) fournit de tels conseils.
# Forensics sur AWS
Les concepts issus de la criminalistique traditionnelle sur site s'appliquent à. AWS Les [stratégies relatives à l'environnement d'investigation médico-légale présentées dans le](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) billet de AWS Cloud blog vous fournissent des informations clés vers lesquelles commencer à migrer leur expertise médico-légale. AWS
Une fois que vous aurez configuré votre environnement et votre structure de AWS compte pour la criminalistique, vous devrez définir les technologies nécessaires pour appliquer efficacement des méthodologies fiables sur le plan médico-légal au cours des quatre phases :
+ **Collecte** : collectez les AWS journaux pertinents AWS CloudTrail AWS Config, tels que les journaux de flux VPC et les journaux au niveau de l'hôte. Collectez des instantanés, des sauvegardes et des vidages de mémoire des ressources concernées AWS .
+ **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.
+ **Rapports** — Présentez les informations issues de la phase d'analyse.
# 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. AWS Activé, vous pouvez prendre des instantanés de différentes ressources. Les instantanés vous fournissent des point-in-time copies de sauvegarde de ces ressources. De nombreux services AWS peuvent vous aider en matière de sauvegarde et de restauration. Reportez-vous au [guide prescriptif de sauvegarde et de restauration](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) pour plus de détails sur ces services et approches de sauvegarde et de restauration. Pour plus de détails, consultez le billet de blog [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. Reportez-vous aux [10 meilleures pratiques de sécurité pour sécuriser les sauvegardes dans](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/) le billet de AWS blog pour obtenir des conseils sur la sécurisation de vos sauvegardes. 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.
# Automatisation de la criminalistique sur AWS
Lors d'un événement de sécurité, votre équipe de réponse aux incidents doit être en mesure de recueillir et d'analyser les preuves rapidement tout en maintenant la précision pendant la période entourant l'événement. Il est à la fois difficile et chronophage pour l'équipe de réponse aux incidents de collecter manuellement les preuves pertinentes dans un environnement cloud, 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, les clients doivent développer et mettre en œuvre l'automatisation pour la criminalistique.
AWS propose un certain nombre de ressources d'automatisation pour la criminalistique, qui sont regroupées dans l'annexe ci-dessous. [Ressources médico-légales](appendix-b-incident-response-resources.md#forensic-resources) 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.
# Résumé des éléments de préparation
Une préparation minutieuse pour répondre aux événements de sécurité est essentielle pour une réponse rapide et efficace aux incidents. La préparation de la réponse aux incidents implique des personnes, des processus et des technologies. Ces trois domaines sont d'égale importance pour la préparation. Vous devez préparer et faire évoluer votre programme de réponse aux incidents dans les trois domaines.
Le tableau 2 résume les éléments de préparation détaillés dans cette section.
*Tableau 2 — Éléments de préparation à la réponse aux incidents*
| Domain | Article de préparation | Éléments d’action |
| --- | --- | --- |
| Gens | Définissez les rôles et les responsabilités. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Gens | Formez le personnel d'intervention en cas d'incident sur AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Gens | Comprenez AWS les options de support. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Procédé | Élaborez un plan de réponse aux incidents. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Procédé | Documentez et centralisez les diagrammes d'architecture. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Procédé | Développez des manuels de réponse aux incidents. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Procédé | Effectuez régulièrement des simulations. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Développez une structure de AWS compte. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Élaborez et mettez en œuvre une stratégie de marquage qui aide les intervenants à identifier la propriété et le contexte des résultats. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Mettez à jour les informations de contact du AWS compte. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Préparez l'accès aux AWS comptes. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Comprenez le paysage des menaces. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Sélectionnez et configurez les journaux. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
| Technologie | Développez des capacités de criminalistique. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/preparation-summary.html) |
Une approche itérative est recommandée pour la préparation de la réponse aux incidents. Tous ces éléments de préparation ne peuvent pas être effectués du jour au lendemain ; vous devez créer un plan pour commencer modestement et améliorer continuellement vos capacités de réponse aux incidents au fil du temps.
# Opérations
Les opérations sont au cœur de la réponse aux incidents. C’est à ce niveau que se déroulent les actions de réponse et de résolution des incidents de sécurité. Les opérations comprennent les cinq phases suivantes : *détection*, *analyse*, *confinement*, *éradication* et *rétablissement*. Les descriptions de ces phases et des objectifs se trouvent dans le tableau 3.
*Tableau 3 — Phases d'exploitation*
| Phase | Objectif |
| --- | --- |
| Détection | Identifiez un événement de sécurité potentiel. |
| Analyse | Déterminez si un événement de sécurité est un incident et évaluez l'ampleur de l'incident. |
| Confinement | Minimisez et limitez la portée de l’événement de sécurité. |
| Éradication | Éliminez les ressources ou artefacts non autorisés liés à l’événement de sécurité. Mettez en œuvre les mesures d’atténuation à l’origine de l’incident de sécurité. |
| Récupération | Restaurez les systèmes dans un état sûr connu et surveillez ces systèmes pour vérifier que la menace ne revient pas. |
Utilisez ces phases à titre de référence pour réagir de manière efficace et robuste aux incidents. Les actions que vous effectuerez varieront en fonction de l’incident lui-même. Un incident impliquant un rançongiciel, par exemple, nécessite un ensemble d’étapes de réponse différent de celui d’un incident impliquant un compartiment Amazon S3 public. De plus, ces phases ne se déroulent pas nécessairement de manière séquentielle. Après la maîtrise et l’éradication, vous devrez peut-être revenir à l’analyse pour déterminer si vos actions ont été efficaces.
# Détection
L'alerte est l'élément principal de la phase de détection. Il génère une notification pour lancer le processus de réponse aux incidents en fonction de l'activité de menace du AWS compte présentant un intérêt.
La précision des alertes est un défi ; il n'est pas toujours possible de déterminer avec une certitude absolue si un incident s'est produit, est en cours ou s'il se produira dans le futur. Voici quelques raisons :
+ Les mécanismes de détection sont basés sur l'écart de référence, les modèles connus et les notifications émanant d'entités internes ou externes.
+ En raison de la nature imprévisible de la technologie et des personnes, respectivement *des moyens* et des *acteurs des* incidents de sécurité, les données de référence changent au fil du temps. Des modèles malhonnêtes apparaissent grâce à des *tactiques*, *techniques* et *procédures* nouvelles ou modifiées utilisées par les auteurs de menaces (TTPs).
+ Les modifications apportées aux personnes, aux technologies et aux processus ne sont pas immédiatement intégrées dans le processus de réponse aux incidents. Certains sont découverts au cours d'une enquête.
# Sources d'alerte
Vous devriez envisager d'utiliser les sources suivantes pour définir les alertes :
+ **Résultats** : AWS des services tels qu'[Amazon GuardDuty [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)](https://aws.amazon.com/guardduty/), [Amazon Macie](https://aws.amazon.com/macie/), [Amazon Inspector [AWS Config](https://aws.amazon.com/config/)](https://aws.amazon.com/inspector/), [IAM Access Analyzer et [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html)](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) génèrent des résultats qui peuvent être utilisés pour créer des alertes.
+ **Journaux : les journaux** de AWS service, d'infrastructure et d'application stockés dans des compartiments et des groupes de CloudWatch journaux Amazon S3 peuvent être analysés et corrélés pour générer des alertes.
+ **Activité de facturation** — Une modification soudaine de l'activité de facturation peut indiquer un événement de sécurité. Suivez la documentation sur la [création d'une alarme de facturation pour surveiller vos AWS frais estimés](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) afin de contrôler cela.
+ **Renseignements sur les cybermenaces** — Si vous vous abonnez à un flux de renseignements tiers sur les cybermenaces, vous pouvez corréler ces informations avec d'autres outils de journalisation et de surveillance afin d'identifier les indicateurs potentiels d'événements.
+ **Outils** destinés aux partenaires : les partenaires AWS Partner Network (APN) proposent des produits haut de gamme qui peuvent vous aider à atteindre vos objectifs de sécurité. En ce qui concerne la réponse aux incidents, les produits partenaires dotés de la technologie EDR (Endpoint Detection and Response) ou du SIEM peuvent vous aider à atteindre vos objectifs de réponse aux incidents. Pour plus d'informations, consultez les [sections Solutions pour partenaires](https://aws.amazon.com/security/partner-solutions/) de [sécurité et Solutions de sécurité dans le AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security).
+ **AWS confiance et sécurité** : nous Support pouvons contacter les clients si nous détectons une activité abusive ou malveillante.
+ **Contact ponctuel** : comme ce sont peut-être vos clients, développeurs ou autres membres du personnel de votre entreprise qui remarquent quelque chose d'inhabituel, il est important de disposer d'une méthode connue et largement diffusée pour contacter votre équipe de sécurité. Les choix les plus populaires incluent les systèmes de billetterie, les adresses e-mail de contact et les formulaires Web. Si votre organisation travaille avec le grand public, vous pourriez également avoir besoin d'un mécanisme de contact de sécurité destiné au public.
Pour plus d'informations sur les fonctionnalités du cloud que vous pouvez utiliser lors de vos enquêtes, reportez-vous [Annexe A : Définitions des fonctionnalités du cloud](appendix-a-cloud-capability-definitions.md) à ce document.
# Détection dans le cadre de l'ingénierie des contrôles de sécurité
Les mécanismes de détection font partie intégrante du développement des contrôles de sécurité. Au fur et à mesure que les contrôles *directifs* et *préventifs* sont définis, des contrôles *détectifs* *et réactifs* connexes doivent être mis en place. Par exemple, une organisation établit un contrôle directif relatif à l'utilisateur root d'un AWS compte, qui ne doit être utilisé que pour des activités spécifiques et très bien définies. Ils l'associent à un contrôle préventif mis en œuvre en utilisant la politique de contrôle des services (SCP) d'une AWS organisation. Si l'activité de l'utilisateur root dépasse le niveau de référence attendu, un contrôle de détection implémenté avec une EventBridge règle et un sujet SNS alertera le centre des opérations de sécurité (SOC). Le contrôle réactif implique que le SOC sélectionne le playbook approprié, effectue une analyse et travaille jusqu'à ce que l'incident soit résolu.
La meilleure façon de définir les contrôles de sécurité est de modéliser les menaces associées aux charges de travail. AWS La criticité des contrôles de détection sera définie en examinant l'analyse d'impact sur l'entreprise (BIA) pour la charge de travail particulière. Les alertes générées par les contrôles de détection ne sont pas traitées telles qu'elles arrivent, mais plutôt en fonction de leur criticité initiale, à ajuster lors de l'analyse. L'ensemble de criticité initial est une aide à la priorisation ; le contexte dans lequel l'alerte s'est produite déterminera sa véritable criticité. Par exemple, une organisation utilise Amazon GuardDuty comme composant du contrôle de détection utilisé pour les instances EC2 faisant partie d'une charge de travail. Le résultat `Impact:EC2/SuspiciousDomainRequest.Reputation` est généré pour vous informer que l'instance Amazon EC2 répertoriée dans votre charge de travail interroge un nom de domaine soupçonné d'être malveillant. Cette alerte est définie par défaut comme étant de faible gravité et, au fur et à mesure que la phase d'analyse progresse, il a été déterminé que plusieurs centaines d'instances EC2 de ce type `p4d.24xlarge` avaient été déployées par un acteur non autorisé, ce qui augmentait considérablement les coûts d'exploitation de l'organisation. À ce stade, l'équipe de réponse aux incidents prend la décision d'ajuster le niveau de criticité de cette alerte à un *niveau élevé*, ce qui accroît le sentiment d'urgence et accélère les mesures à prendre. Notez que la sévérité du GuardDuty résultat ne peut pas être modifiée.
# Implémentations de Detective Control
Il est important de comprendre comment les contrôles de détection sont mis en œuvre, car ils permettent de déterminer comment l'alerte sera utilisée pour un événement donné. Il existe deux principales implémentations des contrôles techniques de détection :
+ **La détection comportementale** repose sur des modèles mathématiques communément appelés apprentissage automatique (ML) ou intelligence artificielle (IA). La détection se fait par inférence ; par conséquent, l'alerte ne reflète pas nécessairement un événement réel.
+ **La détection basée sur des règles** est déterministe ; les clients peuvent définir les paramètres exacts de l'activité pour laquelle ils doivent être alertés, et c'est certain.
Les mises en œuvre modernes de systèmes de détection, tels qu'un système de détection d'intrusion (IDS), sont généralement équipées des deux mécanismes. Voici quelques exemples de détections basées sur des règles et comportementales avec. GuardDuty
+ Lorsque le résultat `Exfiltration:IAMUser/AnomalousBehavior` est généré, il vous informe qu' « une demande d'API anormale a été observée dans votre compte ». En parcourant la documentation, vous découvrirez que « le modèle ML évalue toutes les demandes d'API de votre compte et identifie les événements anormaux associés aux techniques utilisées par les adversaires », ce qui indique que cette constatation est de nature comportementale.
+ Pour le résultat`Impact:S3/MaliciousIPCaller`, GuardDuty il analyse les appels d'API provenant du service Amazon S3 en CloudTrail comparant l'élément du `SourceIPAddress` journal avec un tableau d'adresses IP publiques qui inclut des flux de renseignements sur les menaces. Une fois qu'il trouve une correspondance directe avec une entrée, il génère le résultat.
Nous vous recommandons de mettre en œuvre une combinaison d'alertes comportementales et basées sur des règles, car il n'est pas toujours possible de mettre en œuvre des alertes basées sur des règles pour chaque activité de votre modèle de menace.
# Détection basée sur les personnes
Jusqu'à présent, nous avons discuté de la détection basée sur la technologie. L'autre source importante de détection provient des personnes internes ou externes à l'organisation du client. *Les initiés* peuvent être définis comme un employé ou un sous-traitant, et les *étrangers sont des* entités telles que les chercheurs en sécurité, les forces de l'ordre, les actualités et les réseaux sociaux.
Bien que la détection basée sur la technologie puisse être configurée de manière systématique, la détection basée sur les personnes se présente sous diverses formes, telles que les e-mails, les tickets, le courrier, les articles de presse, les appels téléphoniques et les interactions en personne. On peut s'attendre à ce que les notifications de détection basées sur la technologie soient transmises en temps quasi réel, mais aucun calendrier n'est prévu pour la détection basée sur les personnes. Il est impératif que la culture de sécurité intègre, facilite et renforce les mécanismes de détection basés sur les personnes pour une approche de défense approfondie en matière de sécurité.
# Résumé
En matière de détection, il est important de combiner des alertes basées sur des règles et des alertes basées sur le comportement. En outre, vous devez mettre en place des mécanismes permettant aux personnes internes et externes de soumettre un ticket concernant un problème de sécurité. Les humains peuvent être l'une des sources les plus précieuses d'incidents de sécurité. Il est donc important de mettre en place des processus permettant aux utilisateurs de faire part de leurs préoccupations. Vous devez utiliser les modèles de menace de votre environnement pour commencer à détecter les bâtiments. Les modèles de menaces vous aideront à créer des alertes basées sur les menaces les plus pertinentes pour votre environnement. Enfin, vous pouvez utiliser des frameworks tels que MITRE ATT&CK pour comprendre les tactiques, les techniques et les procédures des acteurs menaçants (). TTPs Le framework MITRE ATT&CK peut être utile à utiliser comme langage commun à vos différents mécanismes de détection.
# Analyse
Les journaux, les fonctionnalités de requête et les informations sur les menaces ne sont que quelques-uns des éléments de support nécessaires à la phase d'analyse. La plupart des journaux utilisés pour la détection sont également utilisés pour l'analyse et nécessiteront l'intégration et la configuration d'outils de requête.
# Valider, définir et évaluer l'impact de l'alerte
Au cours de la phase d'analyse, une analyse complète des journaux est effectuée dans le but de valider les alertes, de définir la portée et d'évaluer l'impact d'une éventuelle compromission.
+ *La validation* de l'alerte est le point d'entrée de la phase d'analyse. Les intervenants en cas d'incident rechercheront des entrées de journal provenant de diverses sources et dialogueront directement avec les responsables de la charge de travail concernée.
+ Le *cadrage* est l'étape suivante, lorsque toutes les ressources impliquées sont inventoriées et que la criticité des alertes est ajustée une fois que les parties prenantes ont convenu qu'il est peu probable qu'il s'agisse d'un faux positif.
+ Enfin, *l'analyse d'impact* détaille l'interruption réelle de l'activité.
Une fois que les composants de la charge de travail concernés sont identifiés, les résultats du cadrage peuvent être corrélés à l'objectif de point de reprise (RPO) et à l'objectif de temps de restauration (RTO) de la charge de travail correspondante, en ajustant la criticité des alertes, ce qui déclenchera l'allocation des ressources et toutes les activités suivantes. Tous les incidents ne perturberont pas directement le fonctionnement d'une charge de travail supportant un processus métier. Les incidents tels que la divulgation de données sensibles, le vol de propriété intellectuelle ou le détournement de ressources (comme dans le cas du minage de cryptomonnaies) peuvent ne pas arrêter ou affaiblir un processus métier immédiatement, mais peuvent avoir des conséquences ultérieurement.
# Enrichissez les journaux de sécurité et les résultats
## Enrichissement grâce aux renseignements sur les menaces et au contexte organisationnel
Au cours de l'analyse, les observables présentant un intérêt doivent être enrichis pour une meilleure contextualisation de l'alerte. Comme indiqué dans la section Préparation, l'intégration et l'exploitation des renseignements sur les cybermenaces peuvent être utiles pour mieux comprendre une constatation de sécurité. Les services de renseignement sur les menaces sont utilisés pour attribuer la réputation et la propriété aux adresses IP publiques, aux noms de domaine et aux hachages de fichiers. Ces outils sont disponibles sous forme de services payants et gratuits.
Les clients qui adoptent Amazon Athena comme outil de recherche de logs tirent parti des tâches AWS Glue pour charger les informations relatives aux menaces sous forme de tableaux. Les tables de renseignements sur les menaces peuvent être utilisées dans les requêtes SQL pour corréler les éléments du journal tels que les adresses IP et les noms de domaine, afin de fournir une vue enrichie des données à analyser.
AWS ne fournit pas de renseignements sur les menaces directement aux clients, mais des services tels qu'Amazon GuardDuty utilisent les renseignements sur les menaces pour les enrichir et générer des résultats. Vous pouvez également télécharger des listes de menaces personnalisées en GuardDuty fonction de vos propres informations sur les menaces.
## Enrichissement grâce à l'automatisation
L'automatisation fait partie intégrante de la AWS Cloud gouvernance. Il peut être utilisé tout au long des différentes phases du cycle de vie de la réponse aux incidents.
Pour la phase de détection, l'automatisation basée sur des règles fait correspondre les modèles intéressants issus du modèle de menace dans les journaux et prend les mesures appropriées, telles que l'envoi de notifications. La phase d'analyse peut tirer parti du mécanisme de détection et transmettre le corps de l'alerte à un moteur capable d'interroger les journaux et d'enrichir les observables pour contextualiser l'événement.
Le corps d'alerte, dans sa forme fondamentale, est composé d'une *ressource* et d'une *identité*. Par exemple, vous pouvez implémenter une automatisation CloudTrail pour demander l'activité de l' AWS API effectuée par l'identité ou la ressource de l'organisme d'alerte au moment de l'alerte, en fournissant des informations supplémentaires`eventSource`, notamment, `eventName``SourceIPAddress`, et sur l'activité `userAgent` d'API identifiée. En effectuant ces requêtes de manière automatisée, les intervenants peuvent gagner du temps lors du triage et obtenir un contexte supplémentaire pour prendre des décisions plus éclairées.
Consultez le billet de blog [How to enrich AWS Security Hub with account metadata (Comment enrichir les résultats](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/) du Security Hub avec les métadonnées des comptes) pour découvrir comment utiliser l'automatisation pour enrichir les résultats de sécurité et simplifier les analyses.
# Recueillir et analyser des preuves médico-légales
La criminalistique, comme indiqué dans la [Préparation](preparation.md) section de ce document, est le processus de collecte et d'analyse d'artefacts lors de la réponse à un incident. Activé AWS, il s'applique aux ressources du domaine de l'infrastructure telles que les captures de paquets de trafic réseau, le vidage de la mémoire du système d'exploitation et aux ressources du domaine de service telles que AWS CloudTrail les journaux.
Le processus de criminalistique présente les caractéristiques fondamentales suivantes :
+ **Cohérent** — Il suit exactement les étapes documentées, sans écarts.
+ **Répétable** — Il produit exactement les mêmes résultats lorsqu'il est répété sur le même artefact.
+ **Usuel** — Il est documenté publiquement et largement adopté.
Il est important de maintenir une chaîne de traçabilité pour les artefacts collectés lors de l'intervention en cas d'incident. L'automatisation et la génération automatique de la documentation de cette collection peuvent être utiles, en plus de stocker les artefacts dans des référentiels en lecture seule. L'analyse ne doit être effectuée que sur des répliques exactes des artefacts collectés afin de préserver l'intégrité.
# Collectez des artefacts pertinents
Compte tenu de ces caractéristiques, et sur la base des alertes pertinentes et de l'évaluation de l'impact et de la portée, vous devrez collecter les données qui seront pertinentes pour une enquête et une analyse plus approfondies. Différents types et sources de données susceptibles d'être pertinents pour l'investigation, notamment les journaux de service/control plans (CloudTrailévénements de données Amazon S3, journaux de flux VPC), les données (métadonnées et objets Amazon S3) et les ressources (bases de données, instances Amazon EC2).
Service/control les journaux d'avion peuvent être collectés pour une analyse locale ou, idéalement, directement interrogés à l'aide des AWS services natifs (le cas échéant). Les données (y compris les métadonnées) peuvent être directement consultées pour obtenir des informations pertinentes ou pour acquérir les objets sources ; par exemple, utilisez le AWS CLI pour acquérir les métadonnées du bucket et de l'objet Amazon S3 et acquérir directement les objets source. Les ressources doivent être collectées conformément au type de ressource et à la méthode d'analyse prévue. Par exemple, les bases de données peuvent être collectées en créant une copy/snapshot partie du système exécutant la base de données, en créant une copy/snapshot partie de la base de données complète ou en interrogeant et en extrayant certaines données et journaux de la base de données pertinents pour l'enquête.
Pour les instances Amazon EC2, un ensemble spécifique de données doit être collecté et un ordre de collecte spécifique doit être exécuté afin d'acquérir et de conserver le plus grand nombre de données à des fins d'analyse et d'investigation.
Plus précisément, l'ordre de réponse permettant d'acquérir et de conserver le plus grand nombre de données d'une instance Amazon EC2 est le suivant :
1. **Acquérir des métadonnées** d'instance : acquérez des métadonnées d'instance pertinentes pour l'investigation et les requêtes de données (ID d'instance, type, adresse IP, VPC/subnet ID, région, ID Amazon Machine Image (AMI), groupes de sécurité attachés, heure de lancement).
1. **Activez les protections et les balises** d'instance : activez des protections d'instance telles que la protection contre la résiliation, la définition du comportement d'arrêt (s'il est défini pour s'arrêter), la désactivation des attributs Supprimer en cas de résiliation pour les volumes EBS attachés et l'application de balises appropriées à la fois pour la dénotation visuelle et pour l'utilisation dans d'éventuelles automatisations de réponse (par exemple, lors de l'application d'une balise avec le nom `Status` et la valeur de`Quarantine`, effectuez une acquisition médico-légale des données et isolez l'instance).
1. **Acquérir un disque (instantanés EBS)** : obtenez un instantané EBS des volumes EBS attachés. Chaque instantané contient les informations dont vous avez besoin pour restaurer vos données (à partir du moment où le cliché a été pris) sur un nouveau volume EBS. Consultez l'étape à suivre pour effectuer une response/artifact collecte en direct si vous utilisez des volumes de stockage d'instance.
1. **Acquérir de la mémoire** : étant donné que les instantanés EBS ne capturent que les données écrites sur votre volume Amazon EBS, ce qui peut exclure les données stockées ou mises en cache en mémoire par vos applications ou votre système d'exploitation, il est impératif d'acquérir une image de mémoire système à l'aide d'un outil tiers open source ou commercial approprié afin d'acquérir les données disponibles auprès du système.
1. **(Facultatif) Réaliser une réponse en temps réel/collecte d'artefacts** : effectuez une collecte de données ciblée (disk/memory/logs) via une réponse en direct sur le système uniquement s'il est impossible d'acquérir le disque ou la mémoire autrement, ou pour une raison commerciale ou opérationnelle valide. Cela modifiera les données et artefacts précieux du système.
1. Mettez **l'instance hors service** : détachez l'instance des groupes Auto Scaling, annulez-la des équilibreurs de charge et ajustez ou appliquez un profil d'instance prédéfini avec des autorisations minimisées ou nulles.
1. **Isoler ou contenir l'instance** : vérifiez que l'instance est efficacement isolée des autres systèmes et ressources de l'environnement en mettant fin aux connexions actuelles et futures vers et depuis l'instance et en empêchant les connexions actuelles et futures. Reportez-vous à la [Maîtrise](containment.md) section de ce document pour plus de détails.
1. **Choix du répondant** — En fonction de la situation et des objectifs, sélectionnez l'une des options suivantes :
+ Mettez le système hors service et arrêtez le système (recommandé).
Arrêtez le système une fois que les preuves disponibles ont été recueillies afin de vérifier l'atténuation la plus efficace par rapport à un éventuel impact futur de l'instance sur l'environnement.
+ Continuez à exécuter l'instance dans un environnement isolé instrumenté pour la surveillance.
Bien que cette approche ne soit pas recommandée comme approche standard, si une situation nécessite une surveillance continue de l'instance (par exemple lorsque des données ou des indicateurs supplémentaires sont nécessaires pour effectuer une investigation et une analyse complètes de l'instance), vous pouvez envisager de fermer l'instance, de créer une AMI de l'instance et de relancer l'instance dans votre compte criminalistique dédié dans un environnement sandbox préinstrumenté pour être complètement isolé et configuré avec des instruments permettant une surveillance quasi continue de l'instance (pour (par exemple, journaux de flux VPC ou mise en miroir du trafic VPC).
**Note**
Il est essentiel de capturer la mémoire avant les activités de réponse en direct, l'isolation ou l'arrêt du système afin de capturer les données volatiles (et précieuses) disponibles.
# Développez des récits
Au cours de l'analyse et de l'investigation, documentez les mesures prises, les analyses effectuées et les informations identifiées, à utiliser lors des phases suivantes et, finalement, dans un rapport final. Ces récits doivent être succincts et précis, afin de confirmer que les informations pertinentes sont incluses afin de vérifier la bonne compréhension de l'incident et de maintenir un calendrier précis. Ils sont également utiles lorsque vous impliquez des personnes extérieures à l'équipe principale de réponse aux incidents. Voici un exemple :
****
*Le service marketing et commercial a reçu une demande de rançon le 15 mars 2022 demandant un paiement en cryptomonnaie afin d'éviter la publication d'éventuelles données sensibles. Le SOC a déterminé que la base de données Amazon RDS appartenant au marketing et aux ventes était accessible au public le 20 février 2022. Le SOC a interrogé les journaux d'accès RDS et a déterminé que l'adresse IP 198.51.100.23 avait été utilisée le 20 février 2022 avec les informations d'identification `mm03434` appartenant au *major* Mary, l'un des développeurs Web. Le SOC a interrogé les journaux de flux VPC et a déterminé qu'environ 256 Mo de données étaient sortis vers la même adresse IP à la même date (horodatage 22:02-20T 15:50\$100Z). Le SOC a déterminé, grâce à des informations sur les menaces open source, que les informations d'identification sont actuellement disponibles en texte brut dans le référentiel `https[:]//example[.]com/majormary/rds-utils` public.*
# Maîtrise
L'une des définitions du confinement, en ce qui concerne la réponse aux incidents, est le processus ou la mise en œuvre d'une stratégie lors de la gestion d'un événement de sécurité qui vise à minimiser la portée de l'événement de sécurité et à contenir les effets d'une utilisation non autorisée dans l'environnement.
Une stratégie de confinement dépend d'une multitude de facteurs et peut être différente d'une organisation à l'autre en termes d'application des tactiques de confinement, de calendrier et d'objectif. Le [guide de gestion des incidents de sécurité informatique SP 800-61 du NIST](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) décrit plusieurs critères pour déterminer la stratégie de confinement appropriée, notamment :
+ Dommages potentiels et vol de ressources
+ Nécessité de préserver les preuves
+ Disponibilité des services (connectivité réseau, services fournis à des tiers externes)
+ Temps et ressources nécessaires à la mise en œuvre de la stratégie
+ Efficacité de la stratégie (confinement partiel ou total)
+ Durée de la solution (solution d'urgence à supprimer dans quatre heures, solution temporaire à supprimer dans deux semaines, solution permanente)
En ce qui concerne les services AWS, toutefois, les étapes de confinement fondamentales peuvent être réparties en trois catégories :
+ **Confinement de la source** : utilisez le filtrage et le routage pour empêcher l'accès à partir d'une certaine source.
+ **Technique et limitation des accès** : supprimez l'accès pour empêcher tout accès non autorisé aux ressources concernées.
+ **Confinement des destinations** : utilisez le filtrage et le routage pour empêcher l'accès à une ressource cible.
# Confinement de la source
Le confinement des sources est l'utilisation et l'application du filtrage ou du routage au sein d'un environnement pour empêcher l'accès aux ressources provenant d'une adresse IP source ou d'une plage réseau spécifique. Des exemples de confinement des sources à l'aide de AWS services sont présentés ici :
+ **Groupes de sécurité** : la création et l'application de groupes de sécurité d'isolation aux instances Amazon EC2 ou la suppression de règles d'un groupe de sécurité existant peuvent contribuer à contenir le trafic non autorisé vers une instance ou une ressource Amazon EC2. AWS Il est important de noter que les connexions suivies existantes ne seront pas interrompues en cas de changement de groupe de sécurité. Seul le trafic futur sera effectivement bloqué par le nouveau groupe de sécurité (consultez [ce manuel de réponse aux incidents](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) et le [suivi des connexions des groupes de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) pour plus d'informations sur les connexions suivies et non suivies).
+ **Politiques** — Les politiques de compartiment Amazon S3 peuvent être configurées pour bloquer ou autoriser le trafic provenant d'une adresse IP, d'une plage réseau ou d'un point de terminaison VPC. Les politiques permettent de bloquer les adresses suspectes et l'accès au compartiment Amazon S3. Des informations supplémentaires sur les politiques de compartiment sont disponibles sur [Ajouter une politique de compartiment à l'aide de la console Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html).
+ **AWS WAF **— Les listes de contrôle d'accès Web (Web ACLs) peuvent être configurées AWS WAF pour fournir un contrôle précis des requêtes Web auxquelles les ressources répondent. Vous pouvez ajouter une adresse IP ou une plage réseau à un ensemble d'adresses IP configuré sur AWS WAF et appliquer des conditions de correspondance, telles que le blocage, à l'ensemble d'adresses IP. Cela bloquera les requêtes Web adressées à une ressource si l'adresse IP ou les plages de réseau du trafic d'origine correspondent à celles configurées dans les règles définies dans les règles IP définies.
Le schéma suivant illustre un exemple de confinement des sources dans lequel un analyste de réponse aux incidents modifie un groupe de sécurité d'une instance Amazon EC2 afin de limiter les nouvelles connexions à certaines adresses IP uniquement. Comme indiqué dans la bullet relative aux groupes de sécurité, les connexions suivies existantes ne seront pas interrompues suite à un changement de groupe de sécurité.
![\[Schéma illustrant un exemple de confinement de source\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/images/source-containment-example.png)
**Note**
Les groupes de sécurité et les ACL réseau ne filtrent pas le trafic vers Amazon Route 53. Lorsque vous conservez une instance EC2, si vous souhaitez l'empêcher de contacter des hôtes externes, assurez-vous également de bloquer explicitement les communications DNS.
# Technique et confinement des accès
Empêchez l'utilisation non autorisée d'une ressource en limitant les fonctions et les principaux IAM ayant accès à la ressource. Cela inclut la restriction des autorisations des principaux IAM qui ont accès à la ressource ; cela inclut également la révocation des informations d'identification de sécurité temporaires. Des exemples de techniques et de limitation d'accès à l'aide de AWS services sont présentés ici :
+ **Restreindre les autorisations** : les autorisations attribuées à un directeur IAM doivent respecter le [principe du moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Toutefois, lors d'un événement de sécurité actif, il se peut que vous deviez restreindre davantage l'accès à une ressource ciblée à partir d'un principal IAM spécifique. Dans ce cas, il est possible de limiter l'accès à une ressource en supprimant les autorisations du principal IAM à contenir. Cela se fait avec le service IAM et peut être appliqué à l'aide du AWS Management Console AWS CLI, du ou d'un AWS SDK.
+ **Révoquer les clés : les clés** d'accès IAM sont utilisées par les responsables IAM pour accéder aux ressources ou les gérer. Il s'agit d'informations d'identification statiques à long terme permettant de signer les demandes programmatiques adressées à l' AWS API AWS CLI or et commençant par le préfixe *AKIA* (pour plus d'informations, reportez-vous à la section *Comprendre les préfixes d'identification uniques* dans les identifiants [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)). Pour limiter l'accès d'un principal IAM lorsqu'une clé d'accès IAM a été compromise, la clé d'accès peut être désactivée ou supprimée. Il est important de noter ce qui suit :
+ Une clé d'accès peut être réactivée après avoir été désactivée.
+ Une clé d'accès n'est pas récupérable une fois qu'elle a été supprimée.
+ Un principal IAM peut avoir jusqu'à deux clés d'accès à la fois.
+ Les utilisateurs ou les applications utilisant la clé d'accès perdront l'accès une fois la clé désactivée ou supprimée.
+ **Révoquer les identifiants de sécurité temporaires** — Les identifiants de sécurité temporaires peuvent être utilisés par une organisation pour contrôler l'accès aux AWS ressources, en commençant par le préfixe *ASIA* (pour plus d'informations, consultez la section *Comprendre les préfixes d'identification uniques dans Identifiants* [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)). Les informations d'identification temporaires sont généralement utilisées par les rôles IAM et il n'est pas nécessaire de les modifier ou de les révoquer explicitement car leur durée de vie est limitée. Dans les cas où un événement de sécurité implique un identifiant de sécurité temporaire avant son expiration, vous devrez peut-être modifier les autorisations effectives des identifiants de sécurité temporaires existants. Cela peut être effectué [à l'aide du service IAM fourni. AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) Des informations d'identification de sécurité temporaires peuvent également être délivrées aux utilisateurs IAM (par opposition aux rôles IAM) ; toutefois, au moment de la rédaction de cet article, il n'existe aucune option permettant de révoquer les informations d'identification de sécurité temporaires pour un utilisateur IAM au sein du. AWS Management Console Pour les événements de sécurité dans lesquels la clé d'accès IAM d'un utilisateur est compromise par un utilisateur non autorisé qui a créé des informations d'identification de sécurité temporaires, les informations d'identification de sécurité temporaires peuvent être révoquées de deux manières :
+ Attachez une politique intégrée à l'utilisateur IAM qui empêche l'accès en fonction de l'heure d'émission du jeton de sécurité (reportez-vous à la section Refus d'*accès aux informations d'identification de sécurité temporaires émises avant une heure précise* dans [Désactivation des autorisations pour les informations d'identification de sécurité temporaires pour](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html) plus de détails).
+ Supprimez l'utilisateur IAM propriétaire des clés d'accès compromises. Recréez l'utilisateur si nécessaire.
+ **AWS WAF**- Certaines techniques utilisées par des utilisateurs non autorisés incluent des modèles de trafic malveillants courants, tels que les requêtes contenant une injection de code SQL et des scripts intersites (XSS). AWS WAF peut être configuré pour faire correspondre et refuser le trafic en utilisant ces techniques à l'aide des instructions de règles AWS WAF intégrées.
Le schéma suivant illustre un exemple de technique et de limitation des accès : un intervenant en cas d'incident fait pivoter les clés d'accès ou supprime une politique IAM pour empêcher un utilisateur IAM d'accéder à un compartiment Amazon S3.
![\[Schéma illustrant une technique et un exemple de confinement des accès\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/images/technique-and-access-containment.png)
# Confinement des destinations
Le confinement des destinations est l'application du filtrage ou du routage au sein d'un environnement pour empêcher l'accès à un hôte ou à une ressource ciblés. Dans certains cas, le confinement des destinations implique également une forme de résilience visant à vérifier que les ressources légitimes sont répliquées pour des raisons de disponibilité ; les ressources doivent être détachées de ces formes de résilience à des fins d'isolation et de confinement. Voici des exemples de confinement des destinations à l'aide de AWS services :
+ **Réseau ACLs ** — Des règles de refus peuvent être ajoutées aux réseaux ACLs (réseau ACLs) configurés sur des sous-réseaux contenant des AWS ressources. Ces règles de refus peuvent être appliquées pour empêcher l'accès à une AWS ressource particulière ; toutefois, l'application d'une liste de contrôle d'accès réseau (ACL réseau) affectera toutes les ressources du sous-réseau, et pas seulement les ressources auxquelles on accède sans autorisation. Les règles répertoriées dans une ACL réseau sont traitées du haut vers le bas, de sorte que la première règle d'une ACL réseau existante doit être configurée pour refuser le trafic non autorisé vers la ressource et le sous-réseau ciblés. Une toute nouvelle ACL réseau peut également être créée avec une règle de refus unique pour le trafic entrant et sortant et associée au sous-réseau contenant la ressource ciblée pour empêcher l'accès au sous-réseau à l'aide de la nouvelle ACL réseau.
+ **Arrêt** — L'arrêt complet d'une ressource peut être efficace pour contenir les effets d'une utilisation non autorisée. La fermeture d'une ressource empêchera également tout accès légitime pour répondre aux besoins de l'entreprise et empêchera l'obtention de données médico-légales volatiles. Cette décision doit donc être réfléchie et doit être évaluée à la lumière des politiques de sécurité de l'entreprise.
+ **Isolation VPCs ** — Les VPC d'isolation peuvent être utilisés pour contenir efficacement les ressources tout en donnant accès au trafic légitime (comme les solutions antivirus (AV) ou EDR qui nécessitent un accès à Internet ou à une console de gestion externe). Les VPC d'isolation peuvent être préconfigurés avant un événement de sécurité pour autoriser des adresses IP et des ports valides, et les ressources ciblées peuvent être immédiatement déplacées vers ce VPC d'isolation lors d'un événement de sécurité actif afin de contenir la ressource tout en permettant à un trafic légitime d'être envoyé et reçu par la ressource ciblée lors des phases suivantes de réponse aux incidents. Un aspect important de l'utilisation d'un VPC d'isolation est que les ressources, telles que les instances EC2, doivent être arrêtées et relancées dans le nouveau VPC d'isolation avant leur utilisation. Les instances EC2 existantes ne peuvent pas être déplacées vers un autre VPC ou une autre zone de disponibilité. Pour ce faire, suivez les étapes décrites dans [Comment déplacer mon instance Amazon EC2 vers un autre sous-réseau, une autre zone de disponibilité ou](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/) un autre VPC ?
+ **Groupes Auto Scaling et équilibreurs de charge : les** AWS ressources associées aux groupes Auto Scaling et aux équilibreurs de charge doivent être détachées et désenregistrées dans le cadre des procédures de confinement des destinations. Le détachement et le désenregistrement des AWS ressources peuvent être effectués à l'aide du kit de développement logiciel (SDK AWS Management Console). AWS CLI AWS
Un exemple de confinement des destinations est illustré dans le schéma suivant : un analyste de réponse aux incidents ajoute une ACL réseau à un sous-réseau afin de bloquer une demande de connexion réseau provenant d'un hôte non autorisé.
![\[Schéma illustrant un exemple de confinement des destinations\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/images/destination-containment.png)
# Résumé
Le confinement est une étape du processus de réponse aux incidents et peut être manuel ou automatisé. La stratégie globale de confinement doit être alignée sur les politiques de sécurité et les besoins commerciaux de l'organisation, et vérifier que les effets négatifs sont atténués le plus efficacement possible avant l'éradication et le rétablissement.
# Éradication
L'éradication, en relation avec la réponse aux incidents de sécurité, consiste à supprimer les ressources suspectes ou non autorisées dans le but de rétablir le compte dans un état sûr connu. La stratégie d'éradication dépend de plusieurs facteurs, qui dépendent des exigences commerciales de votre organisation.
Le [guide de gestion des incidents de sécurité informatique SP 800-61 du NIST](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) propose plusieurs étapes pour les éradiquer :
1. Identifiez et atténuez toutes les vulnérabilités qui ont été exploitées.
1. Supprimez les logiciels malveillants, les contenus inappropriés et les autres composants.
1. Si d'autres hôtes affectés sont découverts (par exemple, de nouvelles infections par des logiciels malveillants), répétez les étapes de détection et d'analyse pour identifier tous les autres hôtes concernés, puis contenir et éradiquer l'incident pour eux.
En ce qui concerne les AWS ressources, cela peut être affiné grâce aux événements détectés et analysés par le biais des journaux disponibles ou d'outils automatisés tels que CloudWatch Logs et Amazon GuardDuty. Ces événements devraient servir de base pour déterminer les mesures correctives à effectuer pour rétablir correctement l'environnement dans un état sûr connu.
La première étape de l'éradication consiste à déterminer quelles ressources ont été affectées au sein du AWS compte. Cela se fait grâce à l'analyse de vos sources de données de journal disponibles, de vos ressources et de vos outils automatisés.
+ Identifiez les actions non autorisées effectuées par les identités IAM de votre compte.
+ Identifiez les accès non autorisés ou les modifications apportées à votre compte.
+ Identifiez la création de ressources ou d'utilisateurs IAM non autorisés.
+ Identifiez les systèmes ou les ressources dont les modifications ne sont pas autorisées.
Une fois la liste des ressources identifiée, vous devez évaluer chacune d'elles afin de déterminer l'impact commercial de la suppression ou de la restauration de la ressource. Par exemple, si un serveur Web héberge votre application professionnelle et que sa suppression entraîne une interruption de service, vous devez envisager de récupérer la ressource à partir de sauvegardes sécurisées vérifiées ou de relancer le système à partir d'une AMI propre avant de supprimer le serveur concerné.
Une fois que vous avez terminé votre analyse d'impact commercial, vous devez, à l'aide des événements de votre analyse des journaux, accéder aux comptes et effectuer les mesures correctives appropriées, telles que :
+ Faire pivoter ou supprimer les touches : cette étape empêche l'acteur de continuer à effectuer des activités dans le compte.
+ Alternez les informations d'identification des utilisateurs IAM potentiellement non autorisés.
+ Supprimez les ressources non reconnues ou non autorisées.
**Important**
Si vous devez conserver des ressources pour votre enquête, pensez à les sauvegarder. Par exemple, si vous devez conserver une instance Amazon EC2 pour des raisons légales, réglementaires ou de conformité, [créez un instantané Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) avant de supprimer l'instance.
+ Pour les infections par des logiciels malveillants, vous devrez peut-être contacter l'un AWS Partner ou l'autre fournisseur. AWS ne propose pas d'outils natifs pour l'analyse ou la suppression des malwares. Toutefois, si vous utilisez le module GuardDuty Malware pour Amazon EBS, des recommandations peuvent être disponibles pour les résultats fournis.
Une fois que vous avez éradiqué les ressources affectées identifiées, il vous AWS recommande de procéder à un examen de sécurité de votre compte. Cela peut être fait en utilisant des AWS Config règles, en utilisant des solutions open source telles que Prowler et/ou par le biais d' ScoutSuiteautres fournisseurs. Vous devriez également envisager d'effectuer des analyses de vulnérabilité sur vos ressources accessibles au public (Internet) afin d'évaluer le risque résiduel.
L'éradication est une étape du processus de réponse aux incidents et peut être manuelle ou automatisée, en fonction de l'incident et des ressources concernées. La stratégie globale doit être alignée sur les politiques de sécurité et les besoins commerciaux de l'entreprise, et vérifier que les effets négatifs sont atténués lorsque des ressources ou des configurations inappropriées sont supprimées.
# Récupération
La restauration est le processus qui consiste à restaurer les systèmes dans un état sûr connu, à valider que les sauvegardes sont sûres ou non affectées par l'incident avant la restauration, à tester pour vérifier que les systèmes fonctionnent correctement après la restauration et à corriger les vulnérabilités associées à l'événement de sécurité.
L'ordre de reprise dépend des exigences de votre organisation. Dans le cadre du processus de reprise, vous devez effectuer une analyse de l'impact commercial afin de déterminer, au minimum :
+ Priorités commerciales ou de dépendance
+ Le plan de restauration
+ Authentification et autorisation
Le guide de gestion des incidents de sécurité informatique SP 800-61 du NIST fournit plusieurs étapes pour restaurer les systèmes, notamment :
+ Restauration des systèmes à partir de sauvegardes propres.
+ Vérifiez que les sauvegardes sont évaluées avant de les restaurer sur les systèmes afin de vous assurer de l'absence d'infection et d'empêcher la résurgence de l'événement de sécurité.
Les sauvegardes doivent être évaluées régulièrement dans le cadre des tests de reprise après sinistre afin de vérifier que le mécanisme de sauvegarde fonctionne correctement et que l'intégrité des données répond aux objectifs du point de reprise.
+ Si possible, utilisez des sauvegardes antérieures à l'horodatage du premier événement identifié dans le cadre de l'analyse des causes premières.
+ Reconstruire les systèmes à partir de zéro, y compris le redéploiement à partir d'une source fiable à l'aide de l'automatisation, parfois dans un nouveau AWS compte.
+ Remplacement des fichiers compromis par des versions propres.
Vous devez faire preuve d'une grande prudence en procédant ainsi. Vous devez être absolument certain que le fichier que vous récupérez est connu, sûr et non affecté par l'incident.
+ Installation de correctifs.
+ Modification des mots de passe.
+ Cela inclut les mots de passe des principaux IAM susceptibles d'avoir été utilisés de manière abusive.
+ Dans la mesure du possible, nous recommandons d'utiliser des rôles pour les principaux IAM et la fédération dans le cadre d'une stratégie de moindre privilège.
+ Renforcement de la sécurité du périmètre du réseau (ensembles de règles de pare-feu, listes de contrôle d'accès aux routeurs périphériques).
Une fois les ressources récupérées, il est important de tirer les leçons apprises afin de mettre à jour les politiques, les procédures et les guides de réponse aux incidents.
En résumé, il est impératif de mettre en œuvre un processus de rétablissement qui facilite le retour à des opérations sûres connues. Le rétablissement peut prendre du temps et nécessite un lien étroit avec les stratégies de confinement afin de trouver un équilibre entre l'impact commercial et le risque de réinfection. Les procédures de recouvrement doivent inclure des étapes pour restaurer les ressources et les services, les principes IAM et effectuer un examen de sécurité du compte afin d'évaluer le risque résiduel.
# Conclusion
Chaque phase des opérations comporte des objectifs, des techniques, des méthodologies et des stratégies uniques. Le tableau 4 résume ces phases ainsi que certaines des techniques et méthodologies abordées dans cette section.
*Tableau 4 — Phases des opérations : objectifs, techniques et méthodologies*
| Phase | Objectif | Techniques et méthodologies |
| --- | --- | --- |
| Détection | Identifiez un événement de sécurité potentiel. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/operations-conclusion.html) |
| Analyse | Déterminez si l'événement de sécurité est un incident et évaluez l'ampleur de l'incident. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/operations-conclusion.html) |
| Confinement | Minimisez et limitez l'impact de l'événement de sécurité. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/operations-conclusion.html) |
| Éradication | Éliminez les ressources ou artefacts non autorisés liés à l’événement de sécurité. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/operations-conclusion.html) |
| Récupération | Restaurez les systèmes dans un état dont le bon état a été vérifié et surveillez ces systèmes pour vous assurer que la menace ne se reproduise pas. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/security-ir/latest/userguide/operations-conclusion.html) |
# Activité postérieure à l’incident
Les menaces existantes sont en constante évolution. La capacité de votre organisation à protéger efficacement vos environnements doit suivre le rythme. La clé de l'amélioration continue consiste à réitérer les résultats de vos incidents et de vos simulations afin d'améliorer vos capacités à détecter, à répondre et à enquêter efficacement sur les incidents de sécurité potentiels, en réduisant vos vulnérabilités éventuelles, les délais de réponse et le retour à des opérations sûres. Les mécanismes suivants peuvent vous aider à vérifier que votre organisation dispose de toutes les capacités et les connaissances les plus récentes nécessaires pour réagir efficacement, quelle que soit la situation.
# Établir un cadre pour tirer les leçons des incidents
La mise en œuvre d'un cadre et d'une méthodologie en matière de *leçons apprises* permettra non seulement d'améliorer les capacités de réponse aux incidents, mais également d'empêcher que l'incident ne se reproduise. En tirant les leçons de chaque incident, vous pouvez éviter de répéter les mêmes erreurs, expositions ou mauvaises configurations, non seulement en améliorant votre posture de sécurité, mais également en minimisant le temps perdu dans des situations évitables.
Il est important de mettre en œuvre un cadre des leçons apprises qui établit et atteint, à un niveau élevé, les points suivants :
+ Quand se déroule un processus des enseignements tirés ?
+ En quoi consiste le processus des enseignements tirés ?
+ Comment se déroule un processus des enseignements tirés ?
+ Qui est impliqué dans le processus et comment ?
+ Comment les domaines à améliorer seront-ils identifiés ?
+ Comment allez-vous vous assurer que les améliorations sont suivies et mises en œuvre de manière efficace ?
Outre ces résultats de haut niveau énumérés, il est important de vous assurer de poser les bonnes questions pour tirer le meilleur parti du processus (informations menant à des améliorations réalisables). Posez-vous les questions suivantes pour commencer à développer vos discussions sur les enseignements tirés :
+ Quel a été l’incident ?
+ Quand l’incident a-t-il été identifié pour la première fois ?
+ Comment a-t-il été identifié ?
+ Quels systèmes ont alerté sur l’activité ?
+ Quels systèmes, services et données étaient concernés ?
+ Que s’est-il passé précisément ?
+ Qu’est-ce qui a bien fonctionné ?
+ Qu’est-ce qui n’a pas bien fonctionné ?
+ Quels processus ou procédures ont échoué ou n’ont pas pu être mis à l’échelle pour répondre à l’incident ?
+ Qu’est-ce qui peut être amélioré dans les domaines suivants :
+ **Personnes**
+ Les personnes à contacter étaient-elles réellement disponibles et la liste de contacts était-elle à jour ?
+ Les personnes manquaient-elles de formation ou n’avaient-elles pas les capacités nécessaires pour intervenir et enquêter efficacement sur l’incident ?
+ Les ressources appropriées étaient-elles prêtes et disponibles ?
+ **Processus**
+ Les processus et procédures ont-ils été suivis ?
+ Les processus et procédures étaient-ils documentés et disponibles pour cet incident ou ce type d’incident ?
+ Les processus et procédures requis étaient-ils absents ?
+ Les intervenants ont-ils pu accéder en temps opportun aux informations requises pour répondre au problème ?
+ **Technologie**
+ Les systèmes d’alerte existants ont-ils identifié l’activité et ont-ils envoyé des alertes efficaces ?
+ Les alertes existantes doivent-elles être améliorées ou de nouvelles alertes doivent-elles être créées pour cet incident ou ce type d’incident ?
+ Les outils existants ont-ils permis une investigation efficace (recherche/analyse) de l'incident ?
+ Que peut-on faire pour identifier cet incident ou ce type d’incident plus rapidement ?
+ Que peut-on faire pour éviter que cet incident ou ce type d’incident ne se reproduise ?
+ À qui appartient le plan d’amélioration et comment allez-vous vérifier qu’il a été mis en œuvre ?
+ Quel est le calendrier de mise en œuvre et de test des monitoring/preventative contrôles/processus supplémentaires ?
Cette liste n'est pas exhaustive ; elle est destinée à servir de point de départ pour identifier les besoins de l'organisation et de l'entreprise et la manière dont vous pouvez les analyser afin de tirer le meilleur parti des incidents et d'améliorer continuellement votre posture de sécurité. Le plus important est de commencer par intégrer les enseignements tirés dans le cadre standard de votre processus de réponse aux incidents, de la documentation et des attentes des parties prenantes.
# Établissez des indicateurs de réussite
Les métriques sont nécessaires pour mesurer, évaluer et améliorer efficacement vos capacités de réponse aux incidents. Sans indicateurs, il n'existe aucune référence permettant de mesurer avec précision ou même d'identifier les performances (ou non) de votre organisation. Quelques indicateurs communs à la réponse aux incidents constituent un bon point de départ pour une organisation qui cherche à établir des attentes et des références pour atteindre l'excellence opérationnelle.
# Temps moyen de détection
Le *temps moyen de détection* est le temps moyen nécessaire pour découvrir un éventuel incident de sécurité. Plus précisément, il s'agit du délai entre l'apparition du premier indicateur de compromission et l'identification ou l'alerte initiale.
Vous pouvez utiliser cette métrique pour suivre l'efficacité de vos systèmes de détection et d'alerte. Des mécanismes de détection et d'alerte efficaces sont essentiels pour garantir que d'éventuels incidents de sécurité ne persistent pas dans vos environnements.
Plus le temps moyen de détection est long, plus il est nécessaire de créer des alertes et des mécanismes supplémentaires ou plus efficaces pour identifier et découvrir d'éventuels incidents de sécurité. Plus le temps moyen de détection est court, plus vos mécanismes de détection et d'alerte fonctionnent bien.
# Temps moyen pour accuser réception
Le *délai moyen de reconnaissance* est le temps moyen nécessaire pour reconnaître et hiérarchiser un éventuel incident de sécurité. Plus précisément, il s'agit du délai entre la génération d'une alerte et le moment où un membre de votre SOC ou du personnel de réponse aux incidents identifie et hiérarchise l'alerte à traiter.
Vous pouvez utiliser cette métrique pour suivre dans quelle mesure votre équipe traite et hiérarchise les alertes. Si votre équipe n'est pas en mesure d'identifier et de hiérarchiser efficacement les alertes, les réponses seront retardées et inefficaces.
Plus le délai moyen d'accusé de réception est long, plus il est nécessaire de vérifier que votre équipe dispose des ressources nécessaires et est formée pour reconnaître rapidement un éventuel incident de sécurité et prioriser sa réponse par ordre de priorité. Plus le délai moyen d'accusé de réception est court, plus votre équipe est en mesure de répondre aux alertes de sécurité, démontrant ainsi qu'elle est bien préparée et capable de bien les hiérarchiser.
# Temps moyen de réponse
Le temps moyen de réponse est le temps moyen nécessaire pour commencer la réponse initiale à un éventuel incident de sécurité. Plus précisément, il s'agit du délai entre l'alerte initiale ou la découverte d'un éventuel incident de sécurité et les premières mesures prises pour y répondre. Ce délai est similaire au délai moyen pour accuser réception, mais il s'agit de la mesure des actions réactives spécifiques (par exemple, acquérir des données du système, contenir le système) par rapport à la simple reconnaissance ou à la reconnaissance de la situation.
Vous pouvez utiliser cette métrique pour suivre votre niveau de préparation à répondre aux incidents de sécurité. Comme nous l'avons mentionné, la préparation est essentielle à une intervention efficace. Reportez-vous à la [Préparation](preparation.md) section de ce document.
Plus le délai moyen de réponse est long, plus il est nécessaire de vérifier que votre équipe est correctement formée à la manière de réagir afin que les processus de réponse soient documentés et utilisés efficacement. Plus le délai moyen de réponse est court, plus votre équipe est en mesure d'identifier une réponse appropriée aux alertes identifiées et de prendre les mesures nécessaires pour commencer le retour à des opérations sûres.
# Temps moyen de confinement
Le *temps moyen de* confinement est le temps moyen nécessaire pour contenir un éventuel incident de sécurité. Plus précisément, il s'agit du délai entre l'alerte initiale ou la découverte d'un éventuel incident de sécurité et l'exécution des actions réactives qui empêchent efficacement l'attaquant ou les systèmes compromis de causer des dommages supplémentaires.
Vous pouvez utiliser cet indicateur pour savoir dans quelle mesure votre équipe est capable d'atténuer ou de contenir les éventuels incidents de sécurité. L'incapacité à contenir rapidement et efficacement les éventuels incidents de sécurité augmente l'impact, la portée et l'exposition à d'éventuelles nouvelles compromissions.
Plus le délai moyen de confinement est long, plus il est nécessaire de développer à la fois les connaissances et les capacités nécessaires pour atténuer et contenir rapidement et efficacement les incidents de sécurité que vous rencontrez. Plus le délai moyen de confinement est court, plus votre équipe est en mesure de comprendre et de mettre en œuvre les mesures nécessaires pour atténuer et contenir les menaces identifiées afin de réduire l'impact, la portée et les risques pour l'entreprise.
# Temps moyen de rétablissement
Le *temps moyen de rétablissement* est le temps moyen nécessaire pour rétablir complètement les opérations afin de protéger les opérations contre un éventuel incident de sécurité. Plus précisément, il s'agit du délai entre l'alerte initiale ou la découverte d'un éventuel incident de sécurité et le moment où l'entreprise reprend ses activités normalement et en toute sécurité sans être affectée par l'incident.
Vous pouvez utiliser cet indicateur pour suivre l'efficacité de vos équipes lorsqu'il s'agit de rétablir la sécurité des systèmes, des comptes et des environnements après un incident de sécurité. L'incapacité de reprendre des activités sûres rapidement ou efficacement peut non seulement avoir un impact sur la sécurité, mais également augmenter l'impact et les dépenses de l'entreprise et de ses opérations.
Plus le temps moyen de restauration est long, plus il est nécessaire de préparer vos équipes et vos environnements à disposer des mécanismes appropriés (par exemple, des processus de basculement et des CI/CD pipelines pour redéployer en toute sécurité des systèmes propres) afin de minimiser l'impact des incidents de sécurité sur les opérations et l'entreprise. Plus le délai moyen de restauration est court, plus vos équipes sont efficaces pour minimiser l'impact des incidents de sécurité sur vos opérations et votre activité.
# Temps de séjour de l'attaquant
Le *temps d'attente d'un attaquant* est le temps moyen pendant lequel un utilisateur non autorisé a accès à un système ou à un environnement. Ce délai est similaire au délai moyen de confinement, sauf que le délai commence au moment où l'attaquant a accédé au système ou aux environnements, ce qui peut être antérieur à l'alerte ou à la découverte initiale.
Vous pouvez utiliser cette métrique pour déterminer dans quelle mesure vos systèmes et mécanismes fonctionnent ensemble afin de réduire le temps, l'accès et les opportunités d'impact d'un attaquant ou d'une menace sur votre environnement. La réduction du temps passé par les attaquants doit être une priorité absolue pour vos équipes et votre entreprise.
Plus le temps passé par les attaquants est long, plus il est nécessaire d'identifier les aspects du processus de réponse aux incidents qui doivent être améliorés afin de garantir la capacité de vos équipes à minimiser l'impact et la portée des menaces ou des attaques dans vos environnements. Plus le temps passé par les attaquants est faible, plus vos équipes sont en mesure de minimiser le temps et les opportunités que représente une menace ou un attaquant dans vos environnements, réduisant ainsi les risques et l'impact sur vos opérations et votre activité.
# Récapitulatif des métriques
L'établissement et le suivi de mesures de réponse aux incidents vous permettent de mesurer, d'évaluer et d'améliorer efficacement vos capacités de réponse aux incidents. Pour y parvenir, un certain nombre de mesures courantes de réponse aux incidents ont été mises en évidence dans cette section. Le tableau 5 résume ces indicateurs.
*Tableau 5 — Mesures de réponse aux incidents*
| Métrique | Description |
| --- | --- |
| Temps moyen de détection | Temps moyen nécessaire pour découvrir un éventuel incident de sécurité |
| Temps moyen pour accuser réception | Temps moyen nécessaire pour reconnaître (et hiérarchiser) un éventuel incident de sécurité |
| Temps moyen de réponse | Temps moyen nécessaire pour commencer la réponse initiale à un éventuel incident de sécurité |
| Temps moyen de confinement | Temps moyen nécessaire pour contenir un éventuel incident de sécurité |
| Temps moyen de rétablissement | Temps moyen nécessaire pour un retour complet afin de garantir la sécurité des opérations en cas d'incident de sécurité |
| Temps de séjour de l'attaquant | Durée moyenne pendant laquelle un attaquant a accès à un système ou à un environnement |
# Utiliser des indicateurs de compromis (IOCs)
Un *indicateur de compromission* (IOC) est un artefact observé dans ou sur un réseau, un système ou un environnement qui peut (avec un niveau de confiance élevé) identifier une activité malveillante ou un incident de sécurité. IOCs peuvent exister sous diverses formes, notamment des adresses IP, des domaines, des artefacts au niveau du réseau tels que des drapeaux TCP ou des charges utiles, des artefacts au niveau du système ou de l'hôte tels que des exécutables, des noms de fichiers et des hachages, des entrées de fichier journal ou de registre, etc. Il peut également s'agir d'une combinaison d'éléments ou d'activités, tels que l'existence d'éléments ou d'artefacts spécifiques sur un système (un certain fichier ou ensemble de fichiers et éléments de registre), des actions effectuées dans un certain ordre (connexion à un système depuis une certaine adresse IP suivie de commandes anormales spécifiques) ou une activité réseau (trafic entrant ou sortant anormal vers ou depuis certains domaines) qui peuvent indiquer une menace, une attaque ou une méthodologie d'attaque spécifique.
Alors que vous vous efforcez d'améliorer de manière itérative votre programme de réponse aux incidents, vous devez mettre en œuvre un cadre de collecte, de gestion et d'utilisation en IOCs tant que mécanisme permettant de créer et d'améliorer en permanence les détections et les alertes et d'améliorer la rapidité et l'efficacité des enquêtes. Vous pouvez commencer par intégrer la collecte et la gestion des IOCs dans les phases d'analyse et d'investigation de vos processus de réponse aux incidents. En identifiant, en collectant et en stockant IOCs de manière proactive dans le cadre de votre processus, vous pouvez créer un référentiel de données (dans le cadre d'un programme de renseignement sur les menaces plus complet) qui peut à son tour être utilisé pour améliorer les détections et alertes existantes, créer des détections et des alertes supplémentaires, identifier où et quand un artefact a déjà été vu, créer et référencer des documents sur la manière dont les enquêtes étaient précédemment effectuées impliquant des IOCs appariements, etc.
# Éducation et formation continues
L'éducation et la formation sont à la fois des efforts évolutifs et continus qui devraient être poursuivis et maintenus avec détermination. Il existe divers mécanismes permettant de vérifier que votre équipe est sensibilisée, informée et dotée de capacités adaptées à l'évolution de l'état de la technologie ainsi qu'au paysage des menaces.
L'un des mécanismes consiste à intégrer la formation continue dans le cadre des objectifs et des opérations de vos équipes. Comme indiqué dans la section Préparation, votre personnel de réponse aux incidents et les parties prenantes doivent être formés efficacement à la détection, à la réponse et à l'investigation des incidents internes AWS. Cependant, l'éducation n'est pas un effort « ponctuel ». La formation doit être poursuivie en permanence pour vérifier que votre équipe est au courant des dernières avancées technologiques, des mises à jour et des améliorations qui peuvent être mises à profit pour améliorer l'efficacité et l'efficience de la réponse, ainsi que des ajouts ou des mises à jour des données qui peuvent être exploités pour améliorer les enquêtes et les analyses.
Un autre mécanisme consiste à vérifier que les simulations sont effectuées régulièrement (par exemple, tous les trimestres) et axées sur des résultats spécifiques pour l'entreprise. Reportez-vous à la [Exécutez des simulations régulières](run-regular-simulations.md) section de ce document.
Bien que les exercices de simulation initiaux constituent un excellent moyen de générer une base initiale d'amélioration, les tests continus sont essentiels pour obtenir des améliorations durables up-to-date et refléter fidèlement l'état actuel des opérations. En effectuant des tests par rapport aux situations de sécurité les plus récentes et les plus critiques et en utilisant les capacités de réponse les plus importantes ou les plus récentes, et en intégrant les leçons apprises dans la formation et les opérations, vous processes/procedures vérifierez que vous êtes en mesure d'améliorer en permanence vos processus de réponse et votre programme dans son ensemble.
# Conclusion
Alors que vous poursuivez votre transition vers le cloud, il est important que vous preniez en compte les concepts fondamentaux de réponse aux incidents de sécurité pour votre AWS environnement. Vous pouvez combiner les contrôles disponibles, les fonctionnalités cloud et les options de correction pour vous aider à améliorer la sécurité de votre environnement cloud. Vous pouvez également commencer modestement et itérer au fur et à mesure que vous adoptez des fonctionnalités d'automatisation qui améliorent votre vitesse de réponse, afin d'être mieux préparé en cas d'événements de sécurité.
# Collaborateurs
Les contributeurs actuels et passés à ce document incluent :
+ Anna McAbee, architecte senior des solutions de sécurité, Amazon Web Services
+ Freddy Kasprzykowski, consultant senior en sécurité, Amazon Web Services
+ Jason Hurst, ingénieur en sécurité senior, Amazon Web Services
+ Jonathon Poling, consultant principal en sécurité, Amazon Web Services
+ Josh Du Lac, directeur principal de l'architecture des solutions de sécurité, Amazon Web Services
+ Paco Hope, ingénieur principal en sécurité, Amazon Web Services
+ Ryan Tick, ingénieur en sécurité senior, Amazon Web Services
+ Steve de Vera, ingénieur en sécurité senior, Amazon Web Services
# Annexe A : Définitions des fonctionnalités du cloud
AWS propose plus de 200 services cloud et des milliers de fonctionnalités. Nombre d'entre elles fournissent des fonctionnalités natives de détection, de prévention et de réactivité, tandis que d'autres peuvent être utilisées pour concevoir des solutions de sécurité personnalisées. Cette section inclut un sous-ensemble des services les plus pertinents pour la réponse aux incidents dans le cloud.
**Topics**
+ [Journalisation et événements](logging-and-events.md)
+ [Visibilité et alertes](visibility-and-alerting.md)
+ [ Automatisation](automation-1.md)
+ [Stockage sécurisé](secure-storage.md)
+ [Capacités de sécurité futures et personnalisées](custom.md)
# Journalisation et événements
[https://aws.amazon.com/cloudtrail/](https://aws.amazon.com/cloudtrail/)— AWS CloudTrail service permettant la gouvernance, la conformité, l'audit opérationnel et l'audit des risques des AWS comptes. Vous pouvez ainsi enregistrer CloudTrail, surveiller en permanence et conserver l'activité du compte liée aux actions menées dans l'ensemble AWS des services. CloudTrail fournit un historique des événements relatifs à l'activité de votre AWS compte, y compris les actions effectuées par le AWS Management Console biais des outils de ligne de commande et d'autres AWS services. AWS SDKs Cet historique des événements simplifie l'analyse de sécurité, le suivi des modifications des ressources et le dépannage. CloudTrail enregistre deux types différents d'actions d' AWS API :
+ **CloudTrail les événements de gestion** (également appelés opérations du plan de contrôle) indiquent les opérations de gestion effectuées sur les ressources de votre AWS compte. Cela inclut des actions telles que la création d'un compartiment Amazon S3 et la configuration de la journalisation.
+ ** CloudTrail les événements de données** (également appelés opérations du plan de données) indiquent les opérations de ressources effectuées sur ou au sein d'une ressource de votre AWS compte. Ces opérations sont souvent des activités à volume élevé. Cela inclut des actions telles que l'activité de l'API au niveau de l'objet Amazon S3 (par exemple, `GetObject``DeleteObject`, et les opérations d'`PutObject`API) et l'activité d'invocation de la fonction Lambda.
[https://aws.amazon.com/config/](https://aws.amazon.com/config/)— AWS Config est un service permettant aux clients d'évaluer, d'auditer et d'évaluer les configurations de vos AWS ressources. AWS Config surveille et enregistre en permanence les configurations de vos AWS ressources et vous permet d'automatiser l'évaluation des configurations enregistrées par rapport aux configurations souhaitées. Grâce à AWS Config, les clients peuvent consulter les modifications apportées aux configurations et aux relations entre les AWS ressources, manuellement ou automatiquement, l'historique détaillé de la configuration des ressources et déterminer la conformité globale par rapport aux configurations spécifiées dans les directives du client. Cela permet de simplifier l'audit de conformité, l'analyse de sécurité, la gestion des modifications et le dépannage opérationnel.
[https://aws.amazon.com/eventbridge/](https://aws.amazon.com/eventbridge/) — Amazon EventBridge fournit un flux quasi en temps réel d'événements système décrivant les modifications apportées aux AWS ressources ou lorsque des appels d'API sont publiés par AWS CloudTrail. À l'aide de règles simples que vous pouvez configurer rapidement, vous pouvez associer des événements et les acheminer vers une ou plusieurs fonctions ou flux cibles. EventBridge prend connaissance des changements opérationnels au fur et à mesure qu'ils se produisent. EventBridge peut répondre à ces changements opérationnels et prendre des mesures correctives si nécessaire, en envoyant des messages pour répondre à l'environnement, en activant des fonctions, en apportant des modifications et en capturant des informations d'état. Certains services de sécurité, tels qu'Amazon GuardDuty, produisent leurs résultats sous forme d' EventBridge événements. De nombreux services de sécurité proposent également la possibilité d'envoyer leurs résultats à Amazon S3.
**Journaux d'accès Amazon S3** : si des informations sensibles sont stockées dans un compartiment Amazon S3, les clients peuvent activer les journaux d'accès Amazon S3 pour enregistrer chaque chargement, téléchargement et modification de ces données. Ce journal est distinct des CloudTrail journaux qui enregistrent les modifications apportées au compartiment lui-même (telles que les modifications des politiques d'accès et des politiques de cycle de vie). Il convient de noter que les enregistrements des journaux d'accès sont fournis dans la mesure du possible. La plupart des demandes pour un compartiment correctement configuré pour l’enregistrement se traduisent par un enregistrement de journal distribué. L’exhaustivité et la disponibilité de la journalisation du serveur ne sont pas garanties.
[https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) : les clients peuvent utiliser Amazon CloudWatch Logs pour surveiller, stocker et accéder aux fichiers journaux provenant de systèmes d'exploitation, d'applications et d'autres sources s'exécutant sur des instances Amazon EC2 avec un agent CloudWatch Logs. CloudWatch Les journaux peuvent être une destination pour les AWS CloudTrail requêtes DNS Route 53, les journaux de flux VPC, les fonctions Lambda, etc. Les clients peuvent ensuite récupérer les données de journal associées dans CloudWatch Logs.
[https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) de flux VPC permettent aux clients de capturer des informations sur le trafic IP à destination et en provenance des interfaces réseau des VPC. Une fois les journaux de flux activés, ils peuvent être diffusés vers Amazon CloudWatch Logs et Amazon S3. Les journaux de flux VPC aident les clients à effectuer un certain nombre de tâches, telles que le dépannage des raisons pour lesquelles un trafic spécifique n'atteint pas une instance, le diagnostic des règles trop restrictives des groupes de sécurité et leur utilisation comme outil de sécurité pour surveiller le trafic vers les instances EC2. Utilisez la version la plus récente de la journalisation des flux VPC pour obtenir les champs les plus robustes.
[https://aws.amazon.com/waf/](https://aws.amazon.com/waf/) : AWS WAF prend en charge la journalisation complète de toutes les requêtes Web inspectées par le service. Les clients peuvent les stocker dans Amazon S3 pour répondre aux exigences de conformité et d'audit, ainsi qu'aux fins de débogage et de criminalistique. Ces journaux aident les clients à déterminer la cause première des règles initiées et des requêtes Web bloquées. Les journaux peuvent être intégrés à des outils SIEM et d'analyse de journaux tiers.
Journaux de [https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html) de requêtes Route 53 Resolver vous permettent de consigner toutes les requêtes DNS effectuées par les ressources d'Amazon Virtual Private Cloud (Amazon VPC). Qu'il s'agisse d'une instance, d'une AWS Lambda fonction ou d'un conteneur Amazon EC2, s'il réside dans votre Amazon VPC et envoie une requête DNS, cette fonctionnalité l'enregistre ; vous pouvez alors explorer et mieux comprendre le fonctionnement de vos applications.
**Autres AWS journaux** : publie AWS en permanence des fonctionnalités et des capacités de service pour les clients grâce à de nouvelles fonctionnalités de journalisation et de surveillance. Pour plus d'informations sur les fonctionnalités disponibles pour chaque AWS service, consultez notre documentation publique.
# Visibilité et alertes
[https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)— Réponse aux incidents de sécurité AWS est un service complet qui aide les entreprises à gérer les événements de sécurité tout au long de leur cycle de vie en combinant des fonctionnalités automatisées avec un support humain expert. Le service utilise des fonctionnalités de surveillance et d'investigation automatisées pour libérer les ressources de l'organisation tout en maintenant une surveillance vigilante de la sécurité. En cas d'événements liés à la sécurité, il facilite la communication et la coordination accélérées entre les parties prenantes pour des temps de réponse rapides. Le service prend en charge de nombreux cas d'utilisation, notamment la préparation et la simulation d'événements de sécurité, la réponse aux incidents actifs, ainsi que la rationalisation des rapports et des analyses après les incidents, afin de garantir que les entreprises sont bien équipées pour relever les défis de sécurité à chaque étape.
[https://aws.amazon.com/security-hub/](https://aws.amazon.com/security-hub/)— AWS Security Hub CSPM fournit aux clients une vue complète des alertes de sécurité prioritaires et de l'état de conformité des comptes. AWS Security Hub CSPM regroupe, organise et hiérarchise les menaces détectées par des services AWS tels qu'Amazon, Amazon GuardDuty Inspector, Amazon Macie et des solutions. AWS Partner Les résultats sont résumés visuellement sur des tableaux de bord intégrés avec des graphiques et des tableaux exploitables. Vous pouvez également surveiller en permanence votre environnement à l'aide de contrôles de conformité automatisés basés sur les AWS meilleures pratiques et les normes du secteur suivies par votre entreprise.
[https://aws.amazon.com/guardduty/](https://aws.amazon.com/guardduty/) GuardDuty est un service géré de détection des menaces qui surveille en permanence les comportements malveillants ou non autorisés afin d'aider les clients à protéger leurs AWS comptes et leurs charges de travail. Il surveille les activités telles que les appels d'API inhabituels ou les déploiements potentiellement non autorisés indiquant une possible compromission des comptes ou des ressources des instances Amazon EC2, des compartiments Amazon S3 ou des reconnaissances par des acteurs malveillants.
GuardDuty identifie les acteurs présumés malveillants grâce à des flux intégrés de renseignements sur les menaces utilisant l'apprentissage automatique pour détecter les anomalies dans l'activité des comptes et de la charge de travail. Lorsqu'une menace potentielle est détectée, le service envoie une alerte de sécurité détaillée à la GuardDuty console et aux CloudWatch événements. Cela rend les alertes exploitables et simples à intégrer dans les systèmes de gestion des événements et de flux de travail existants.
GuardDuty propose également deux modules complémentaires pour surveiller les menaces avec des services spécifiques : Amazon GuardDuty pour la protection Amazon S3 et Amazon GuardDuty pour la protection Amazon EKS. La protection Amazon S3 permet GuardDuty de surveiller les opérations d'API au niveau des objets afin d'identifier les risques de sécurité potentiels pour les données contenues dans les compartiments Amazon S3. La protection Kubernetes permet GuardDuty de détecter les activités suspectes et les compromissions potentielles des clusters Kubernetes au sein d'Amazon EKS.
[https://aws.amazon.com/macie/](https://aws.amazon.com/macie/) est un service de sécurité basé sur l'IA qui aide à prévenir les pertes de données en découvrant, en classant et en protégeant automatiquement les données sensibles qui y sont stockées. AWS Macie utilise l'apprentissage automatique (ML) pour reconnaître les données sensibles telles que les informations personnelles identifiables (PII) ou la propriété intellectuelle, attribuer une valeur commerciale et fournir une visibilité sur l'endroit où ces données sont stockées et comment elles sont utilisées dans votre organisation. Amazon Macie surveille en permanence les activités d'accès aux données pour détecter les anomalies et émet des alertes lorsqu'il détecte un risque d'accès non autorisé ou de fuite de données involontaire.
[https://aws.amazon.com/config/](https://aws.amazon.com/config/)— Une AWS Config règle représente les configurations préférées pour une ressource et est évaluée par rapport aux modifications de configuration apportées aux ressources pertinentes, telles qu'enregistrées par AWS Config. Vous pouvez consulter les résultats de l'évaluation d'une règle par rapport à la configuration d'une ressource sur un tableau de bord. À l'aide de AWS Config règles, vous pouvez évaluer votre état global de conformité et de risque du point de vue de la configuration, visualiser les tendances en matière de conformité au fil du temps et déterminer quel changement de configuration a entraîné la non-conformité d'une ressource à une règle.
[https://aws.amazon.com/premiumsupport/technology/trusted-advisor/](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)— AWS Trusted Advisor est une ressource en ligne qui vous aide à réduire les coûts, à augmenter les performances et à améliorer la sécurité en optimisant votre AWS environnement. Trusted Advisor fournit des conseils en temps réel pour vous aider à provisionner vos ressources en suivant les AWS meilleures pratiques. L'ensemble complet des Trusted Advisor contrôles, y compris l'intégration CloudWatch des événements, est disponible pour les clients des plans Business et Enterprise Support.
[https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/) — Amazon CloudWatch est un service de surveillance des AWS Cloud ressources et des applications que vous utilisez AWS. Vous pouvez l'utiliser CloudWatch pour collecter et suivre les métriques, collecter et surveiller les fichiers journaux, définir des alarmes et réagir automatiquement aux modifications de vos AWS ressources. CloudWatch peut surveiller les AWS ressources, telles que les instances Amazon EC2, les tables Amazon DynamoDB et les instances de base de données Amazon RDS, ainsi que les métriques personnalisées générées par vos applications et services, ainsi que tous les fichiers journaux générés par vos applications. Vous pouvez utiliser Amazon CloudWatch pour obtenir une visibilité à l'échelle du système sur l'utilisation des ressources, les performances des applications et la santé opérationnelle. Vous pouvez utiliser ces informations pour réagir en conséquence et assurer le bon fonctionnement de votre application.
[https://aws.amazon.com/inspector/](https://aws.amazon.com/inspector/) — Amazon Inspector est un service d'évaluation automatique de la sécurité qui permet d'améliorer la sécurité et la conformité des applications déployées sur AWS. Amazon Inspector évalue automatiquement les applications pour détecter les vulnérabilités ou les écarts par rapport aux meilleures pratiques. Après avoir effectué une évaluation, Amazon Inspector produit une liste détaillée des résultats de sécurité classés par niveau de gravité. Ces résultats peuvent être examinés directement ou dans le cadre de rapports d'évaluation détaillés disponibles via la console ou l'API Amazon Inspector.
[https://aws.amazon.com/detective/](https://aws.amazon.com/detective/) — Amazon Detective est un service de sécurité qui collecte automatiquement les données des journaux à partir de vos AWS ressources et utilise l'apprentissage automatique, l'analyse statistique et la théorie des graphes pour créer un ensemble de données liées qui vous permet de mener des enquêtes de sécurité plus rapides et plus efficaces. Detective peut analyser des milliards d'événements provenant de plusieurs sources de données, telles que les journaux de flux VPC CloudTrail GuardDuty, et crée automatiquement une vue unifiée et interactive de vos ressources, de vos utilisateurs et des interactions entre eux au fil du temps. Grâce à cette vue unifiée, vous pouvez visualiser tous les détails et le contexte en un seul endroit afin d'identifier les raisons sous-jacentes des résultats, d'explorer les activités historiques pertinentes et d'en déterminer rapidement la cause première.
# Automatisation
[https://aws.amazon.com/lambda](https://aws.amazon.com/lambda)— AWS Lambda est 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 pour vous. Vous pouvez utiliser Lambda pour étendre d'autres AWS services avec une logique personnalisée ou créer vos propres services principaux qui fonctionnent en termes d' AWS échelle, de performance et de sécurité. Lambda exécute votre code sur une infrastructure informatique à haute disponibilité et gère les ressources de calcul pour vous. Cela inclut la maintenance des serveurs et des systèmes d'exploitation, le provisionnement des capacités et le dimensionnement automatique, le déploiement du code et des correctifs de sécurité, ainsi que la surveillance et la journalisation du code. Tout ce que vous avez à faire est de fournir le code.
[https://aws.amazon.com/step-functions/](https://aws.amazon.com/step-functions/)— AWS Step Functions simplifie la coordination des composants des applications distribuées et des microservices à l'aide de flux de travail visuels. Step Functions fournit une console graphique qui vous permet d'organiser et de visualiser les composants de votre application sous la forme d'une série d'étapes. Cela facilite la création et l'exécution d'applications en plusieurs étapes. Step Functions démarre et suit automatiquement chaque étape, puis réessaie en cas d'erreur, afin que votre application s'exécute dans l'ordre et comme prévu.
Step Functions enregistre l'état de chaque étape. Ainsi, en cas de problème, vous pouvez diagnostiquer et corriger rapidement les problèmes. Vous pouvez modifier et ajouter des étapes sans écrire de code, afin de faire évoluer votre application et d'innover plus rapidement. AWS Step Functions fait partie de AWS Serverless et simplifie l'orchestration des AWS Lambda fonctions pour les applications sans serveur. Vous pouvez également utiliser Step Functions pour l'orchestration de microservices à l'aide de ressources de calcul telles qu'Amazon EC2 et Amazon ECS.
[https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) : vous AWS Systems Manager donne la visibilité et le contrôle de votre infrastructure sur AWS. Systems Manager fournit une interface utilisateur unifiée qui vous permet de visualiser les données opérationnelles de plusieurs AWS services et d'automatiser les tâches opérationnelles sur l'ensemble de vos AWS ressources. Avec Systems Manager, vous pouvez regrouper les ressources par application, consulter les données opérationnelles à des fins de surveillance et de dépannage, et agir sur vos groupes de ressources. Systems Manager peut maintenir vos instances dans leur état défini, effectuer des modifications à la demande, telles que la mise à jour d'applications ou l'exécution de scripts shell, et effectuer d'autres tâches d'automatisation et de correction.
# Stockage sécurisé
[https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) — Amazon S3 est un système de stockage d'objets conçu pour stocker et récupérer n'importe quel volume de données, où que vous soyez. Il est conçu pour offrir une durabilité de 99,999999999 % et stocke les données de millions d'applications utilisées par les leaders du marché dans tous les secteurs. Amazon S3 fournit une sécurité complète et est conçu pour vous aider à répondre à vos exigences réglementaires. Il offre aux clients une flexibilité dans les méthodes qu'ils utilisent pour gérer les données à des fins d'optimisation des coûts, de contrôle d'accès et de conformité. Amazon S3 fournit des query-in-place fonctionnalités qui vous permettent d'exécuter de puissantes analyses directement sur vos données au repos dans Amazon S3. Amazon S3 est un service de stockage dans le cloud hautement pris en charge, intégrant l'une des plus grandes communautés de solutions tierces, de partenaires intégrateurs de systèmes et d'autres AWS services.
[https://aws.amazon.com/s3/storage-classes/glacier/](https://aws.amazon.com/s3/storage-classes/glacier/) — Amazon Glacier est un service de stockage cloud sécurisé, durable et extrêmement économique pour l'archivage des données et la sauvegarde à long terme. Il est conçu pour offrir une durabilité de 99,999999999 %, fournit une sécurité complète et est conçu pour vous aider à répondre à vos exigences réglementaires. Amazon Glacier fournit des query-in-place fonctionnalités qui vous permettent d'exécuter de puissantes analyses directement sur vos données d'archive au repos. Pour réduire les coûts tout en répondant aux différents besoins de récupération, Amazon Glacier propose trois options d'accès aux archives, allant de quelques minutes à plusieurs heures.
# Capacités de sécurité futures et personnalisées
Les services et fonctionnalités mentionnés ci-dessus ne constituent pas une liste exhaustive. AWS ajoute continuellement de nouvelles fonctionnalités. Pour plus d'informations, nous vous invitons à consulter les pages [Nouveautés chez AWS](https://aws.amazon.com/new/) et [AWS Cloud Security](https://aws.amazon.com/security/). Outre les services de sécurité proposés en tant que AWS services cloud natifs, vous souhaiterez peut-être développer vos propres capacités en plus des AWS services.
Bien que nous vous recommandions d'activer un ensemble de services de sécurité de base au sein de vos comptes AWS CloudTrail, tels qu'Amazon et Amazon Macie, vous souhaiterez peut-être étendre ces fonctionnalités afin de tirer une valeur supplémentaire de vos ressources de journal. GuardDuty Un certain nombre d'outils destinés aux partenaires sont disponibles, tels que ceux répertoriés dans notre programme de compétences en matière de sécurité APN. Vous pouvez également écrire vos propres requêtes pour effectuer des recherches dans vos journaux. Avec le grand nombre de services gérés AWS proposés, cela n'a jamais été aussi simple. Il existe de nombreux AWS services supplémentaires qui peuvent vous aider dans vos recherches et qui sortent du cadre de ce paper, tels qu'Amazon Athena, Amazon OpenSearch Service, Amazon Quick, Amazon Machine Learning et Amazon EMR.
# Annexe B : ressources de réponse aux AWS incidents
AWS publie des ressources pour aider les clients à développer des capacités de réponse aux incidents. La plupart des exemples de code et de procédures se trouvent dans le référentiel GitHub public AWS externe. Vous trouverez ci-dessous quelques ressources qui fournissent des exemples de la manière de répondre aux incidents.
## Ressources du Playbook
+ [Framework pour les playbooks de réponse aux incidents](https://github.com/aws-samples/aws-customer-playbook-framework) : exemple de framework permettant aux clients de créer, développer et intégrer des playbooks de sécurité en prévision de scénarios d'attaque potentiels lors de l'utilisation AWS de services.
+ [Exemples de playbooks de réponse aux incidents](https://github.com/aws-samples/aws-incident-response-playbooks) - Playbooks abordant les scénarios courants auxquels AWS sont confrontés les clients.
+ [AWS annonce le lancement de cinq ateliers accessibles au public](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-release-of-five-publicly-available-workshops/).
## Ressources médico-légales
+ [Cadre de réponse automatique aux incidents et de criminalistique](https://github.com/awslabs/aws-automated-incident-response-and-forensics) : ce cadre et cette solution fournissent un processus d'investigation numérique standard, comprenant les phases suivantes : confinement, acquisition, examen et analyse. Il utilise les fonctions AWS λ pour déclencher le processus de réponse aux incidents de manière automatique et reproductible. Il permet de séparer les comptes pour exécuter les étapes d'automatisation, stocker les artefacts et créer des environnements de criminalistique.
+ [Automated Forensics Orchestrator pour Amazon EC2](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/) : ce guide de mise en œuvre fournit une solution en libre-service permettant de capturer et d'examiner les données des instances EC2 et des volumes attachés à des fins d'analyse judiciaire en cas de détection d'un problème de sécurité potentiel. Il existe un AWS CloudFormation modèle pour déployer la solution.
+ [Comment automatiser la collecte judiciaire des disques dans AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) — Ce AWS blog explique comment configurer un flux de travail automatisé pour capturer les preuves sur disque à des fins d'analyse afin de déterminer l'étendue et l'impact des incidents de sécurité potentiels. Un AWS CloudFormation modèle est également inclus pour déployer la solution.
# Notifications
Il incombe aux clients de procéder à une évaluation indépendante des informations contenues dans le présent document. Ce document : (a) est fourni à titre informatif uniquement, (b) représente les offres de AWS produits et les pratiques actuelles, qui sont susceptibles d'être modifiées sans préavis, et (c) ne crée aucun engagement ni aucune assurance de la part de AWS ses filiales, fournisseurs ou concédants de licence. AWS les produits ou services sont fournis « tels quels » sans garanties, déclarations ou conditions d'aucune sorte, qu'elles soient explicites ou implicites. Les responsabilités et obligations AWS de ses clients sont régies par AWS des accords, et ce document ne fait partie d'aucun accord conclu entre AWS et ses clients et ne les modifie pas.
© 2024 Amazon Web Services, Inc. ou ses filiales. Tous droits réservés.