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.
# 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.*