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.
Validation de votre Réponse aux incidents de sécurité AWS configuration
Une fois l'intégration terminée, vous pouvez vérifier que l'inscription, les sources de détection, les autorisations Gestion des identités et des accès AWS (IAM), le confinement et les notifications sont correctement configurés avant qu'un véritable événement de sécurité ne se produise. Cette section fournit des procédures de vérification étape par étape à l'aide de la CLI Console de gestion AWS et de la AWS CLI.
Rubriques
Avant de valider
Conditions préalables à la validation de votre configuration de réponse aux incidents de sécurité
Pour effectuer ces étapes de validation, assurez-vous que vous disposez des éléments suivants :
Console ou AWS Command Line Interface (AWS CLI) accès à votre compte d'administrateur délégué (le compte que vous avez désigné lors de l'intégration)
L' Région AWS endroit où vous avez activé votre abonnement
Votre numéro de membre (si vous validez à l'aide du AWS CLI)
Confirmer la disponibilité du journal
Réponse aux incidents de sécurité AWS n'active pas les sources de journalisation en votre nom. Au cours d'une investigation, les ingénieurs s'appuient sur des journaux déjà présents dans votre environnement. Avant de valider votre configuration, vérifiez que les journaux suivants sont activés dans tous les comptes couverts et Régions AWS. Sans ces journaux, les ingénieurs de réponse aux incidents de sécurité ont une visibilité limitée pendant les enquêtes. Activez-les avant de continuer.
AWS CloudTrail: parcours des événements de gestion (obligatoire)
Journaux de flux Amazon VPC (recommandé)
Journalisation des accès au serveur Amazon S3 pour les compartiments sensibles (recommandé)
Enregistrement des requêtes DNS Amazon Route 53 Resolver (recommandé)
Vérifier GuardDuty est activé
Utilisez la commande suivante pour vérifier qu'Amazon GuardDuty est actif sur vos comptes :
aws guardduty list-detectors
Une réponse non vide confirme que l'option GuardDuty est activée dans le courant Région AWS. Répétez cette étape pour chaque région active ou vérifiez l'ensemble de votre organisation via le compte d'administrateur GuardDuty délégué.
Note
Réponse aux incidents de sécurité AWS les coûts n'incluent pas les coûts GuardDuty d'utilisation. Consultez la page de GuardDuty tarification
Étape 1 : vérifier l'inscription et l'adhésion
Utilisation de Réponse aux incidents de sécurité AWS console
Connectez-vous au compte d'administrateur délégué.
Vérifiez que votre statut de membre indique Actif. Le statut En attente indique que l'intégration est incomplète.
Sous Périmètre du compte, vérifiez que les UO que vous vouliez couvrir sont répertoriées. La couverture est sélectionnée au niveau de l'unité organisationnelle (UO), et non au niveau du compte individuel. Tous les comptes d'une unité d'organisation sélectionnée (y compris les unités d'organisation enfants) sont couverts.
Vérifiez que la région répertoriée correspond à l'endroit où s'exécutent vos charges de travail. La sélection de la région est verrouillée lors de l'enregistrement et ne peut pas être modifiée après la configuration.
Utilisation de AWS CLI
Exécutez la commande suivante depuis votre compte d'administrateur délégué :
aws security-ir list-memberships
La commande précédente renvoie votre numéro de membre et votre statut.
Pour obtenir les détails complets de votre adhésion, y compris la configuration de votre équipe de réponse aux incidents, exécutez la commande suivante :
aws security-ir get-membership --membership-idmembership-id
Utilisez le résultat de la commande pour vérifier les informations suivantes.
Le statut de membre est
ActiveLes membres de l'équipe de réponse aux incidents répertoriés correspondent aux parties prenantes que vous souhaitez
Au moins deux membres de l'équipe de réponse aux incidents sont configurés (obligatoire)
Vérifiez l'administrateur délégué
Pour vérifier que le bon compte est enregistré en tant qu'administrateur délégué pour Security Incident Response, exécutez la commande suivante :
aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com
Note
Bonne pratique : utilisez le même compte d'administrateur délégué que celui que vous avez défini pour les autres services de AWS sécurité (tels que AWS Security Hub CSPM et GuardDuty). L'architecture AWS de référence de sécurité recommande d'utiliser le compte Security Tooling.
Étape 2 : vérification des sources de détection et triage
Réponse aux incidents de sécurité AWS surveille les résultats de sécurité fournis par GuardDuty des outils tiers via Security Hub CSPM. Le service utilise un rôle lié au service pour ingérer les résultats via les EventBridge règles Amazon déployées sur vos comptes lors de l'intégration.
Vérifier le rôle lié au service de triage
Le rôle AWSServiceRoleForSecurityIncidentResponse_Triage lié au service doit exister dans votre compte de gestion et dans tous les comptes de membres concernés.
Pour vérifier, exécutez la commande suivante dans les comptes de gestion et de membre concernés :
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Une réponse positive confirme l'existence du rôle. Si un message d'NoSuchEntityerreur s'affiche, effectuez l'une des opérations suivantes :
Si vous avez effectué l'intégration à l'aide de la console : le rôle doit avoir été créé automatiquement. Contacter AWS Support.
Si vous avez effectué l'intégration à l'aide de l'API ou AWS CLI : voir Activer la réponse aux incidents de sécurité à l'aide du API/CLI pour obtenir des instructions sur la création manuelle du rôle.
Vérifiez le rôle principal lié au service
Le AWSServiceRoleForSecurityIncidentResponse rôle doit également exister dans votre compte d'administrateur délégué. Pour vérifier que le rôle existe, exécutez la commande suivante :
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse
Vérifiez les réponses et les EventBridge règles proactives
Dans la Réponse aux incidents de sécurité AWS console, vérifiez que la réponse proactive est activée. Lorsqu'il est activé, le service effectue les opérations suivantes :
Ingère les résultats du GuardDuty Security Hub CSPM par le biais de règles EventBridge
Trie automatiquement les résultats en fonction du contexte spécifique du client (adresses IP connues, entités IAM attendues)
Crée des cas d'investigation proactifs lorsque des problèmes de sécurité confirmés sont identifiés
GuardDuty Les résultats des archives ont été jugés inoffensifs (consultables dans la GuardDuty console sous Résultats archivés)
Vérifier que EventBridge les règles sont déployées dans les comptes des membres
Pour vérifier que EventBridge les règles sont déployées dans les comptes des membres, procédez comme suit.
Ouvrez la EventBridge console Amazon sur un compte de membre couvert.
Choisissez Rules (Règles).
Vérifiez que les règles dont
SecurityIncidentResponsele nom est indiqué sont présentes et activées.
Si les règles sont absentes, réexécutez la configuration de réponse proactive à partir de la console Security Incident Response ou contactez AWS Support.
Vérifiez les intégrations tierces (le cas échéant)
Si vous utilisez des outils de détection tiers (tels que CrowdStrike Falçon, Trend Micro Cloud One ou Fortinet Lacework ForticNapp), vérifiez que leurs résultats sont transmis via Security Hub CSPM :
Ouvrez la AWS Security Hub CSPM console
. Accédez à Intégrations.
Vérifiez que l'intégration de votre fournisseur tiers s'affiche comme Accepting findings.
Note
Il n'est pas nécessaire d'activer les normes ou les contrôles CSPM du Security Hub. Seules les intégrations des fournisseurs sont requises pour que Security Incident Response intègre aux conclusions de tiers.
Étape 3 : vérifier le pipeline de recherche automatique
Cette étape confirme que le EventBridge pipeline est actif et que les résultats sont triés automatiquement.
À propos des résultats des GuardDuty échantillons
GuardDutyla fonction intégrée Générer des résultats d'échantillons produit des résultats marqués comme des échantillons. Le triage automatique filtre les résultats des échantillons pour éviter le bruit ; ils ne sont pas transmis à l'ensemble du pipeline de triage et ne peuvent pas être utilisés pour valider votre configuration de réponse aux incidents de sécurité. Ne les utilisez pas pour cette étape.
Valider avec le domaine GuardDuty de test
La GuardDuty documentation fournit un domaine de test (guarddutyc2activityb.com) qui génère un résultat réel sans nécessiter d'événements de sécurité réels. L'interrogation de ce domaine à partir d'une instance Amazon EC2 sur un compte couvert produit un résultat que Security Incident Response ingère et traite.
Pour générer un résultat de test :
Connectez-vous à une instance Amazon EC2 sur un compte couvert à l'aide du gestionnaire de session Systems Manager ou de SSH.
-
Exécutez la commande suivante :
dig guarddutyc2activityb.com Ouvrez la GuardDuty console, puis choisissez Findings. Le résultat apparaît dans un délai d'environ 5 minutes.
À quoi s'attendre :
Le triage automatisé traite les résultats et détermine qu'ils ne sont pas révélateurs d'un véritable événement de sécurité.
Le résultat est archivé dans GuardDuty. Pour l'afficher, sélectionnez Archivé dans le filtre d'état.
Si vous utilisez Security Hub CSPM, le statut du flux de travail du résultat passe à.
SUPPRESSEDAucun dossier proactif n'est créé : il s'agit d'un comportement correct. Un dossier n'est ouvert que lorsque le triage automatique identifie une activité justifiant une enquête humaine.
Note
Si le résultat du test n'apparaît pas dans la liste GuardDuty archivée dans les 15 minutes, consultezRésolution des problèmes. Si aucune instance Amazon EC2 n'est disponible, passez à l'étape 4 et revenez à ce test lorsque votre environnement sera prêt.
Étape 4 : Vérifier les notifications et l'équipe de réponse aux incidents
Vérifiez votre équipe de réponse aux incidents
Dans la console Security Incident Response, passez en revue les membres de votre équipe de réponse aux incidents configurés. Chaque membre reçoit des notifications par e-mail immédiates lorsqu'un dossier est créé.
Vous pouvez également exécuter la commande suivante pour vérifier à l'aide de AWS CLI :
aws security-ir get-membership --membership-idmembership-id
Confirmez que :
Toutes les parties prenantes visées sont répertoriées
Les adresses e-mail sont correctes
Les préférences de communication de chaque membre sont définies de manière appropriée (toutes les options de communication sont activées par défaut. Si un membre ne reçoit pas de notifications, vérifiez que ses préférences n'ont pas été effacées)
Comprendre les observateurs de cas
Les observateurs de cas sont des parties prenantes autorisées à consulter un cas spécifique. Principaux détails :
Les observateurs le sont par cas, pas par compte. L'ajout d'un observateur à un dossier ne lui donne accès à aucun autre dossier. Vous devez explicitement ajouter des observateurs dans chaque cas où vous souhaitez qu'ils aient de la visibilité.
Les observateurs ont un accès en lecture seule. Ils peuvent consulter les détails des dossiers et recevoir des notifications pour les mises à jour des dossiers, mais ne peuvent pas effectuer de mesures de confinement ou de correction sur les ressources.
Jusqu'à 30 parties prenantes peuvent être ajoutées par cas individuel.
Chaque cas inclut une politique IAM prédéfinie qui n'accorde l'accès qu'à ce cas spécifique, en maintenant l'accès avec le moindre privilège.
Ce cadrage au cas par cas est particulièrement important lorsque vous accordez l'accès à des parties externes, telles que des partenaires de détection et de réponse gérées (MDR) ou des équipes d'enquête tierces qui ne devraient consulter que le cas spécifique dans lequel ils sont impliqués.
Vérifiez l'envoi des notifications à l'aide d'un cas de test
Le moyen le plus efficace de valider le flux de notifications de bout en bout consiste à créer un scénario de test réactif (autogéré) :
Dans la console Security Incident Response, créez un nouveau dossier autogéré.
Dans le titre et la description du dossier, indiquez clairement : « Il s'agit d'un test de validation de configuration, il n'y a pas de véritable événement de sécurité ».
Vérifiez que tous les membres de l'équipe de réponse aux incidents configurée reçoivent la notification par e-mail.
Fermez le dossier après avoir confirmé la réception des notifications.
Important
La création d'un scénario de test peut déclencher une réponse de la part des ingénieurs de réponse aux incidents de sécurité si vous demandez un engagement AWS soutenu. Marquez clairement votre cas comme un test pour éviter une escalade inutile. Utilisez cette étape une fois pour confirmer que le canal fonctionne, puis fermez rapidement le boîtier.
À quoi s'attendre des notifications de cas
Lorsqu'un dossier est créé (soit de manière proactive par le service, soit de manière réactive par votre équipe), tous les membres de l'équipe de réponse aux incidents configurée reçoivent une notification par e-mail contenant les détails du dossier.
Vérifier EventBridge l'intégration (si elle est configurée)
Si vous avez configuré EventBridge pour acheminer les événements du cas vers des plateformes tierces (telles que ServiceNow Jira, Slack ou PagerDuty), vérifiez que votre scénario de test déclenche la notification attendue dans ces systèmes.
Étape 5 : Vérifier l'état de préparation du confinement (facultatif)
Note
Le confinement est facultatif et n'est pas activé par défaut. L'infrastructure de confinement décrite dans cette section n'est requise que si vous choisissez d'activer le confinement ; elle n'est pas nécessaire pour que Security Incident Response surveille votre environnement, étudie les résultats ou ouvre des dossiers.
Si vous n'avez pas activé le confinement
Rien à valider ici. Security Incident Response fournit des conseils et des enquêtes lors d'événements de sécurité, mais ne prend pas de mesures de confinement automatisées à moins que vous ne l'autorisiez explicitement.
Si vous avez activé le confinement
Vérifiez l'état du confinement dans la console. Vérifiez si les actions de confinement sont affichées comme autorisées. Les actions de confinement prises en charge incluent les runbooks pour :
Compartiments Amazon S3 concernés
Instances Amazon EC2 concernées
Principaux IAM concernés
Vérifiez qu' CloudFormation StackSet il est déployé. Le confinement nécessite des rôles IAM (AWSSecurityIncidentResponseContainmentetAWSSecurityIncidentResponseContainmentExecution) dans vos comptes couverts :
Ouvrez AWS CloudFormation dans votre compte de gestion.
Sélectionnez StackSets.
Vérifiez que le confinement de la réponse aux incidents de sécurité StackSet apparaît
SUCCEEDEDdans tous les comptes cibles.
Si le StackSet n'est pas déployé, l'autorisation de confinement dans la console n'entraîne pas la prise de mesures de confinement réelles.
Confirmez vos préférences en matière de confinement. La réponse aux incidents de sécurité prend en charge trois niveaux de confinement :
Approbation requise (par défaut) : aucune action de confinement sans votre autorisation explicite au cas par cas.
Contenir les ressources confirmées : confinement proactif des ressources dont il est confirmé qu'elles sont affectées.
Contenir les ressources suspectes : confinement proactif des ressources présentant une forte probabilité d'être affectées.
Pour soumettre ou mettre à jour vos préférences, créez un AWS Support dossier de type Technique : Service de réponse aux incidents de sécurité/Autre.
Si vous souhaitez un triage EC2 : déployez le modèle de confinement avec le modèle de triage EC2. CloudFormation Cela permet aux ingénieurs de réponse aux incidents de sécurité de collecter des données d'investigation à partir d'instances Amazon EC2 à l'aide de. AWS Systems Manager
Étape 6 : Confirmer le fonctionnement en cours
Une fois la validation initiale terminée, utilisez ces indicateurs pour confirmer que Security Incident Response fonctionne en permanence comme prévu.
L'absence de cas est normale
La réponse aux incidents de sécurité crée un dossier proactif uniquement lorsque le triage automatique identifie une activité justifiant une enquête humaine. Lorsque le triage détermine qu'un résultat est bénin, il archive le résultat sans créer de dossier ni contacter votre équipe. Un déploiement sans dossiers ouverts et avec un flux constant de GuardDuty résultats archivés fonctionne comme prévu.
Si vous ne voyez aucun cas ni aucun résultat archivé après plusieurs jours d'activité de votre environnement, il est possible que le pipeline ne soit pas connecté ; vérifiez les étapes 2 et 3.
Note
Les dossiers proactifs sans réponse du client pendant 5 jours sont automatiquement clôturés.
Résultats archivés et règles de suppression en tant que signaux de santé
Au fur et à mesure que la réponse aux incidents de sécurité traite les résultats au fil du temps, elle crée deux artefacts observables :
Résultats archivés : résultats jugés bénins par le triage automatique. Ils s'accumulent au fil du temps et sont visibles dans la GuardDuty console sous Résultats, puis sélectionnez Archivé.
GuardDuty règles de suppression : pour trouver les types d'activité attendus confirmés dans votre environnement, Security Incident Response déploie des règles de suppression nommées (préfixées par
SIRTriage-). Il s'agit du signal permanent le plus clair indiquant que le triage automatique fonctionne activement. Consultez-les dans la GuardDuty console sous Règles de suppression.
Votre équipe de réponse aux incidents est informée lorsqu'une règle de suppression est créée. Si une règle a été créée par erreur, contactez AWS Support pour demander une annulation. Les résultats archivés sont conservés GuardDuty pendant 90 jours.
Rapport d'activité mensuel
Security Incident Response envoie un rapport d'activité mensuel à votre équipe de réponse aux incidents résumant les résultats traités, les résultats du triage et tous les dossiers ouverts. Si votre équipe n'a pas reçu de rapport après votre premier mois civil complet d'activité, vérifiez que les membres de l'équipe de réponse aux incidents ont activé les communications. Pour tout autre problème lié au rapport mensuel, contactez l'équipe chargée de votre compte ou ouvrez un dossier de support avec le type de dossier : Technique : Service de réponse aux incidents de sécurité/Autre et incluez les informations suivantes :
Le nom de votre organisation
Le rapport month/year que vous attendiez (par exemple, « mai 2026 »)
Votre numéro de membre de Security Incident Response (s'il est connu)
Les identifiants de compte couverts par votre adhésion à Security Incident Response
À quoi s'attendre de la part des ingénieurs de réponse aux incidents de sécurité
Lorsque vous créez un dossier AWS pris en charge ou que le service en crée un de manière proactive, les ingénieurs de réponse aux incidents de sécurité accusent réception des nouveaux cas dans les 15 minutes. Ce SLO d'accusé de réception de 15 minutes s'applique à tous les types de cas AWS pris en charge, qu'il s'agisse d'événements de sécurité actifs ou d'enquêtes. L'accusé de réception initial confirme que votre dossier est en cours d'examen ; le calendrier d'évaluation complet peut varier en fonction de la gravité et de la complexité du cas.
Pour les cas proactifs (créés automatiquement lorsque le service de triage identifie un problème de sécurité confirmé), le service crée le dossier une fois que le triage automatique confirme le problème, et votre équipe de réponse aux incidents est informée lorsque le dossier est ouvert.
Liste de contrôle pour la validation
Utilisez cette liste de contrôle pour confirmer que votre configuration est terminée :
Sources de journaux activées : événements CloudTrail de gestion (obligatoire), journaux de flux Amazon VPC, journalisation des accès Amazon S3, journalisation des requêtes DNS (recommandée)
GuardDuty est activé dans tous les comptes et régions actives
Le statut d'adhésion est actif dans la console Security Incident Response
La région est correcte (verrouillée lors de l'inscription)
Le compte d'administrateur délégué est correct (compte Security Tooling recommandé)
L'étendue du compte couvre les unités d'organisation prévues
AWSServiceRoleForSecurityIncidentResponse_Triageexiste dans le compte de gestionAWSServiceRoleForSecurityIncidentResponse_Triageexiste dans les comptes des membres concernésAWSServiceRoleForSecurityIncidentResponseexiste dans un compte d'administrateur déléguéThird-party les intégrations (le cas échéant) apparaissent comme des résultats acceptables dans Security Hub CSPM
EventBridge les règles dont
SecurityIncidentResponsele nom est indiqué sont présentes et activées dans les comptes des membresLes membres de l'équipe de réponse aux incidents sont configurés avec des informations de contact correctes et les communications sont activées
Scénario de test créé et notifications par e-mail reçues par tous les membres de l'équipe
Recherche de domaine de test (
guarddutyc2activityb.com) archivée en 15 minutesStackSet Déploiement réussi du confinement (si le confinement est activé)
Préférence de confinement soumise (si le confinement est activé)
EventBridge les intégrations (si configurées) fournissent des événements à des plateformes tierces
Les résultats archivés sont visibles GuardDuty après la première semaine d'exploitation
Vérification de la facturation
Clients du support aux entreprises et des opérations unifiées : la réponse aux incidents de sécurité est incluse sans frais supplémentaires dans le cadre de votre plan de support. Les frais de réponse aux incidents de sécurité ne figurent pas dans AWS Cost Explorer ni dans le rapport sur les AWS coûts et l'utilisation.
Tous les autres clients : la tarification est basée sur le nombre de résultats de sécurité ingérés. Les 10 000 premiers résultats par mois sont gratuits. Pour de plus amples informations, veuillez consulter Tarification Réponse aux incidents de sécurité AWS
Résolution des problèmes
| Symptôme | Cause probable | Résolution |
|---|---|---|
| Le statut de membre est en attente | Intégration non terminée | Effectuez toutes les étapes de configuration. Consultez la section Mise en route. |
list-membershipsrenvoie vide |
La région CLI ne correspond pas à la région d'abonnement | Spécifiez la région dans laquelle vous avez activé : --region |
| SLR de triage introuvable dans le compte de gestion | Intégré via API/CLI sans le créer | Créez manuellement : aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Comptes de membres absents de la couverture | Le SLR n'est pas déployé sur le compte du membre | Re-run configuration de réponse proactive depuis la console Security Incident Response |
| EventBridge règles absentes d'un compte | Configuration de la réponse proactive incomplète | Re-run configurer ou vérifier les StackSet défaillances dans CloudFormation |
| GuardDuty les résultats des échantillons n'ont pas été traités | Les résultats des échantillons sont filtrés par triage automatique (prévu) | Consultez les résultats archivés dans GuardDuty |
| La recherche du domaine de test n'est pas archivée après 15 minutes | EventBridge règles manquantes ou désactivées ; GuardDuty non activées | Vérifiez les étapes 2 et 3 |
| Aucun cas après une période prolongée | Tous les résultats sont archivés par triage (prévu) ou pipeline non connecté | Consultez les résultats archivés dans GuardDuty. S'il n'en existe aucune, vérifiez EventBridge les règles et répondez de manière proactive. |
| Aucun GuardDuty résultat n'est trié | GuardDuty non activé ou ne générant pas de résultats | Vérifiez que GuardDuty c'est activé : aws guardduty list-detectors |
| Le service ne traite pas les résultats | Le triage automatique a déterminé que l'activité détectée est attendue | Consultez les résultats GuardDuty archivés et les résultats du Security Hub CSPM SUPPRESSED |
| Les membres de l'équipe ne reçoivent pas de notifications | E-mail incorrect, communications désactivées ou courrier indésirable | Vérifiez les adresses e-mail et les préférences de communication ; vérifiez les dossiers de spam |
| Les actions de confinement ne s'exécutent pas | StackSet non déployée ou préférence non soumise | Vérifiez StackSet le statut CloudFormation et confirmez la préférence soumise via AWS Support |
Ressources connexes
