1.3 - Répondre aux ressources et charges compromises (isolement, sessions révoquées, confinement automatisé)

1. Une instance EC2 est confirmee compromise mais la memoire doit encore etre capturee. Comment l'isoler ?

• Terminer l'instance sur le champ et la reconstruire depuis une AMI durcie, la charge etant sans etat et remplacable
• Detacher l'interface reseau elastique de l'instance pour qu'aucun paquet ne puisse plus l'atteindre depuis le reseau
• Remplacer son groupe de securite par un groupe n'autorisant que le chemin forensique (bonne réponse)
• Deplacer l'instance dans un sous reseau prive dont la table de routage n'a aucune route vers la passerelle internet du VPC

Remplacer le groupe de securite coupe l'attaquant immediatement alors que l'instance continue de tourner, donc la memoire survit et l'outillage forensique peut encore l'atteindre. Terminer detruit la preuve, detacher l'interface principale est impossible et couperait aussi les intervenants, et une instance ne change pas de sous reseau une fois lancee.

2. Les identifiants temporaires d'un role IAM ont fuite. Les sessions doivent cesser immediatement sans supprimer le role. Que faire ?

• Attendre l'expiration naturelle de la session, les identifiants temporaires etant de courte duree et devenant inutiles d'eux memes
• Attacher une politique de refus en ligne utilisant la condition aws:TokenIssueTime (bonne réponse)
• Faire tourner les cles d'acces du role depuis la console IAM pour que la paire fuitee ne corresponde plus au secret enregistre
• Modifier la politique de confiance du role pour que le principal compromis ne puisse plus appeler sts:AssumeRole a l'avenir

Une instruction de refus conditionnee sur aws:TokenIssueTime anterieur a l'instant present invalide toutes les sessions emises avant l'incident, c'est la methode documentee de revocation des sessions de role. Attendre laisse l'attaquant actif pendant la duree restante, les roles n'ont pas de cles d'acces a faire tourner, et modifier la politique de confiance bloque seulement les nouvelles assomptions tandis que les sessions en cours continuent.

3. Un constat GuardDuty doit declencher automatiquement une action d'isolement sans intervention humaine. Quelle conception convient ?

• Une alarme CloudWatch sur une metrique personnalisee qui publie dans un sujet SNS auquel est abonne l'ingenieur d'astreinte de la region
• Une regle AWS Config evaluant l'etat de l'instance, associee a une action de remediation lancee au cycle d'evaluation suivant
• Un document Systems Manager Automation planifie qui liste les constats toutes les dix minutes et agit sur ceux qu'il n'a pas vus
• Une regle EventBridge sur le constat, ciblant une fonction Lambda ou un document SSM Automation (bonne réponse)

GuardDuty emet les constats vers EventBridge quasi immediatement, et une regle ciblant Lambda ou Automation realise l'isolement en quelques secondes. Une notification SNS exige un humain, une regle Config reagit a un etat de configuration plutot qu'a un constat de menace, et une interrogation planifiee ajoute un delai que l'attaquant peut exploiter.

4. La cle d'acces a longue duree d'un utilisateur IAM apparait dans un depot de code public. Quelle est la premiere action ?

• Desactiver la cle d'acces exposee (bonne réponse)
• Ouvrir un dossier de support AWS et attendre leurs conseils avant de toucher a quoi que ce soit, pour ne pas detruire de preuves utiles
• Reecrire l'historique du depot pour retirer le commit contenant la cle, puis continuer d'utiliser la meme paire de cles qu'avant
• Activer l'authentification multi facteur sur l'utilisateur afin que la cle exposee ne soit plus utilisable sans second facteur

Desactiver la cle arrete l'abus immediatement et, contrairement a la suppression, la conserve pour l'enquete. Attendre le support laisse la cle utilisable, reecrire l'historique ne sert a rien puisque la cle est deja copiee et indexee, et le MFA ne protege pas les cles d'acces programmatiques sauf si une politique l'exige explicitement.

5. Un instantane forensique d'un volume EBS chiffre doit etre analyse dans un compte de forensique distinct. Que faut-il ?

• Rien de plus que le partage de l'instantane, AWS le dechiffrant et le rechiffrant automatiquement quand il franchit une frontiere de compte
• Copier d'abord l'instantane sans chiffrement, un instantane devant toujours etre dechiffre avant de pouvoir etre partage avec un autre compte
• Partager l'instantane et donner au compte de forensique l'usage de la cle KMS (bonne réponse)
• Deplacer la cle KMS elle meme vers le compte de forensique, une cle geree par le client pouvant etre transferee entre comptes sur demande

Un instantane chiffre est inutilisable sans la cle KMS, donc la politique de cle doit accorder au compte de forensique kms:Decrypt et les permissions associees, et la cle doit etre geree par le client car la cle geree par AWS n'est pas partageable. AWS ne dechiffre jamais les donnees en silence, dechiffrer avant de partager altererait la preuve, et une cle KMS ne se deplace pas entre comptes.

6. Quel service permet a un intervenant de collecter des donnees sur une instance compromise sans ouvrir de port SSH entrant ?

• EC2 Instance Connect, qui pousse une cle publique temporaire sur l'instance puis ouvre une connexion SSH sur le port 22
• AWS Systems Manager Session Manager (bonne réponse)
• Un hote bastion place dans un sous reseau public, joignable uniquement depuis la plage d'adresses du bureau declaree dans son groupe de securite
• AWS Client VPN, qui construit un tunnel chiffre depuis le poste de l'intervenant vers le sous reseau qui heberge l'instance

Session Manager fonctionne via une connexion sortante etablie par l'agent SSM, donc aucun port entrant ni bastion n'est necessaire, et chaque session est journalisee. Instance Connect et un bastion reposent tous deux encore sur du SSH entrant, et Client VPN donne une accessibilite reseau sans supprimer le besoin d'un port ouvert sur l'instance.