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.
Valider 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 décrit les procédures de vérification étape par étape à l'aide de la AWS CLI Console de gestion AWS et de l'interface de ligne de commande.
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 :
Accès à la console ou AWS Command Line Interface (AWS CLI) à 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 que le journal est prêt
Réponse aux incidents de sécurité AWS n'active pas les sources de journaux en votre nom. Au cours d'une enquête, 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 chargés de la réponse aux incidents de sécurité disposent d'une visibilité limitée pendant les enquêtes. Activez-les avant de continuer.
AWS CloudTrail: parcours des événements de gestion (obligatoire)
Amazon VPC Flow Logs (recommandé)
Journalisation des accès au serveur Amazon S3 pour les compartiments sensibles (recommandé)
Enregistrement des requêtes DNS du résolveur Amazon Route 53 (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 qu'elle GuardDuty est activée dans le courant Région AWS. Répétez cette étape pour chaque région active ou vérifiez au sein de votre organisation via le compte 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 est actif. Le statut En attente indique que l'intégration est incomplète.
Dans la section Étendue du compte, vérifiez que les UO que vous souhaitiez couvrir sont répertoriées. La couverture est sélectionnée au niveau de l'unité organisationnelle (OU), 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 pour 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 bloqué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 des informations complètes sur les membres, 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 la sortie de 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é provenant GuardDuty d'outils tiers via Security Hub CSPM. Le service utilise un rôle lié au service pour intégrer les résultats via les EventBridge règles Amazon déployées sur vos comptes lors de l'intégration.
Vérifiez 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 des membres 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 vous êtes connecté à l'aide de la console : le rôle aurait dû être créé automatiquement. Contactez AWS Support.
Si vous vous êtes connecté à 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 la réponse proactive et EventBridge les règles
Dans la Réponse aux incidents de sécurité AWS console, vérifiez que la réponse proactive s'affiche comme étant 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 au 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
Archive GuardDuty les résultats jugés bénins (visibles 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 dans un compte membre couvert.
Choisissez Rules (Règles).
Vérifiez que les règles dont
SIRle nom est inscrit sont présentes et activées.
Si les règles sont manquantes, relancez la configuration de la réponse proactive à partir de la console de réponse aux incidents de sécurité ou du contact 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 passent par Security Hub CSPM :
Ouvrez la console AWS Security Hub CSPM
. Accédez à Intégrations.
Vérifiez que l'intégration de votre fournisseur tiers apparaît comme Acceptant les résultats.
Note
Il n'est pas nécessaire d'activer les normes ou les contrôles CSPM de Security Hub. Seules les intégrations des fournisseurs sont requises pour que la réponse aux incidents de sécurité puisse intégrer les résultats 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 font l'objet d'un triage automatique.
À 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 passent pas par le pipeline de triage complet 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.
Validez avec le domaine de GuardDuty 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 dans 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 dans un compte couvert à l'aide de Systems Manager Session Manager ou SSH.
-
Exécutez la commande suivante :
dig guarddutyc2activityb.com Ouvrez la GuardDuty console, puis choisissez Findings. La découverte apparaît dans un délai d'environ 5 minutes.
À quoi s'attendre :
Le triage automatique traite les résultats et détermine qu'ils ne sont pas révélateurs d'un véritable événement de sécurité.
La découverte est archivée dans GuardDuty. Pour l'afficher, sélectionnez Archivé dans le filtre d'état.
Si vous utilisez Security Hub CSPM, l'état du flux de travail de la recherche passe à.
SUPPRESSEDAucun cas proactif n'est créé : il s'agit d'un comportement correct. Un dossier n'est ouvert que lorsque le triage automatique identifie une activité qui justifie 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 est 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. Informations clés :
Les observateurs sont classés par cas et non par compte. L'ajout d'un observateur à une affaire ne lui donne pas accès à une autre affaire. Vous devez explicitement ajouter des observateurs à chaque cas pour lequel vous souhaitez qu'ils soient visibles.
Les observateurs ont un accès en lecture seule. Ils peuvent consulter les détails des cas et recevoir des notifications pour les mises à jour des cas, 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 accorde l'accès uniquement à ce cas spécifique, en maintenant l'accès avec le moindre privilège.
Ce cadrage au cas par cas est particulièrement important lorsqu'il s'agit d'accorder 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 voir que le cas spécifique dans lequel elles sont impliquées.
Vérifier l'envoi des notifications à l'aide d'un scénario de test
Le moyen le plus efficace de valider un 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 boîtier, 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és 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 la réponse aux incidents de sécurité si vous demandez un engagement AWS soutenu. Marquez clairement votre cas comme test pour éviter une escalade inutile. Utilisez cette étape une fois pour vérifier que la chaîne fonctionne, puis fermez le dossier rapidement.
À quoi s'attendre en ce qui concerne les 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és 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 l'avez configuré EventBridge pour acheminer les événements du dossier vers des plateformes tierces (telles que ServiceNow Jira, Slack ou PagerDuty), vérifiez que votre scénario de test déclenche la notification attendue sur ces systèmes.
Étape 5 : Vérifier l'état de préparation au 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 la réponse aux incidents de sécurité pour surveiller votre environnement, enquêter sur les résultats ou ouvrir des dossiers.
Si vous n'avez pas activé le confinement
Rien à valider ici. La réponse aux incidents de sécurité 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 des runbooks pour :
Compartiments Amazon S3 concernés
Instances Amazon EC2 concernées
Directeurs IAM concernés
Vérifiez CloudFormation StackSet qu'il est déployé. Le confinement nécessite des rôles IAM (AWSSecurityIncidentResponseContainmentetAWSSecurityIncidentResponseContainmentExecution) dans vos comptes couverts. Pour obtenir des instructions sur le déploiement de ces rôles, consultezDéployer des rôles de confinement et de triage EC2. Pour vérifier que le StackSet est déployé :
Ouvrez AWS CloudFormation dans votre compte de gestion.
Sélectionnez StackSets.
Vérifiez que le contenu de la réponse aux incidents de sécurité s' StackSet affiche
SUCCEEDEDdans tous les comptes cibles.
S'il 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.
Confinement confirmé : confinement proactif des ressources dont l'impact a été confirmé.
Contenir les activités 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 avec le type de dossier 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 EC2 Triage. CloudFormation Cela permet aux ingénieurs de la réponse aux incidents de sécurité de collecter des données d'investigation à partir d'instances Amazon EC2 à l'aide AWS Systems Manager de.
Étape 6 : Confirmer le fonctionnement en cours
Une fois la validation initiale terminée, utilisez ces indicateurs pour confirmer que la réponse aux incidents de sécurité fonctionne en permanence comme prévu.
L'absence de cas est normale
La réponse aux incidents de sécurité crée un cas proactif uniquement lorsque le triage automatique identifie les activités qui justifient 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 constatez aucun cas ni aucun résultat archivé alors que votre environnement a été actif pendant plusieurs jours, cela signifie peut-être que le pipeline n'est 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 dont l'activité est confirmée 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 continu 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 avertie lorsqu'une règle de suppression est créée. Si une règle a été créée par erreur, contactez-nous 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 communications sont activées pour les membres de l'équipe de réponse aux incidents. Pour tout autre problème lié au rapport mensuel, contactez l'équipe chargée de votre compte ou ouvrez un dossier d'assistance 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 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 en 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 la 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 complet de l'évaluation peut varier en fonction de la gravité et de la complexité du cas.
Pour les dossiers 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 a confirmé le problème, et votre équipe de réponse aux incidents est avertie lorsque le dossier est ouvert.
Liste de contrôle de 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 Amazon VPC Flow, 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 de membre est Actif dans la console Security Incident Response
La région est correcte (verrouillée lors de l'inscription)
Le compte administrateur délégué est correct (compte Security Tooling recommandé)
La portée 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 administrateur déléguéThird-party les intégrations (le cas échéant) apparaissent comme acceptant les résultats dans Security Hub CSPM
EventBridge les règles dont
SIRle nom est inscrit 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
Cas 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 minutesLe confinement StackSet a été déployé avec succès (si le confinement est activé)
Préférence de confinement soumise (si le confinement est activé)
EventBridge les intégrations (si configurées) proposent des événements à des plateformes tierces
Résultats archivés visibles GuardDuty après la première semaine d'opération
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 sont pas visibles dans AWS Cost Explorer ou 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 | L'intégration n'est pas 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 |
| Le SLR de triage est 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" |
| Les comptes des membres ne sont pas couverts | Le reflex n'a pas été déployé sur le compte du membre | Re-run configuration de la réponse proactive à partir de la console de réponse aux incidents de sécurité |
| EventBridge règles absentes d'un compte | Configuration de la réponse proactive incomplète | Re-run configurer ou vérifier s'il y a des StackSet défaillances dans CloudFormation |
| GuardDuty résultats de l'échantillon non traités | Les résultats des échantillons sont filtrés par triage automatique (prévu) | Consultez les résultats archivés dans GuardDuty |
| La découverte du domaine de test n'a pas été 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 ont été archivés par triage (prévu) ou par pipeline non raccordé | Consultez les résultats archivés dans GuardDuty. S'il n'en existe pas, vérifiez EventBridge les règles et la réponse proactive. |
| Aucun GuardDuty résultat en cours de triage | GuardDuty non activé ou ne générant pas de résultats | Vérifier 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 était 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 | Adresse e-mail incorrecte, communications désactivées ou e-mail indésirable | Vérifiez les adresses e-mail et les préférences de communication ; vérifiez les dossiers de courrier indésirable |
| Les actions de confinement ne s'exécutent pas | StackSet non déployé ou préférence non soumise | Vérifiez StackSet le statut CloudFormation et confirmez les préférences soumises via AWS Support |
Ressources connexes
