Une entreprise exécute des charges de travail sur des centaines d'instances Amazon EC2. Après un incident récent où un logiciel malveillant a fonctionné jusqu'à ce que l'instance soit arrêtée manuellement, l'entreprise a activé Amazon GuardDuty pour détecter les logiciels malveillants sur EC2. L'ingénieur en sécurité doit automatiser la réponse lorsque GuardDuty signale une instance comme infectée, afin d'atténuer l'incident conformément aux directives du cadre AWS Well-Architected pour la réponse aux incidents. Quelle solution répond à ces exigences ?

La bonne réponse est d'invoquer une fonction AWS Lambda sur les découvertes GuardDuty pour détacher tous les volumes Amazon EBS de l'instance, étiqueter les volumes comme « Infected », puis terminer l'instance. Cette approche est conforme aux meilleures pratiques de réponse aux incidents en isolant rapidement la menace (en terminant l'instance) tout en préservant les données pour l'analyse forensique (en détachant et en étiquetant les volumes EBS). Les autres options sont moins efficaces ou potentiellement risquées : Supprimer les adaptateurs réseau via Run Command peut ne pas arrêter complètement le logiciel malveillant et ne permet pas une analyse forensique facile. Supprimer les interfaces réseau élastiques via Lambda est similaire à la suppression des adaptateurs réseau et ne garantit pas l'arrêt de l'exécution du logiciel malveillant ni la préservation des preuves. Déplacer l'instance vers un VPC isolé et un groupe de sécurité « deny-all » est une bonne étape d'isolement, mais ne termine pas l'exécution du logiciel malveillant et ne préserve pas les volumes pour l'analyse forensique de manière aussi directe que la terminaison de l'instance et le détachement des volumes.