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