1.1 - Concevoir et mettre en oeuvre un plan de réponse à incident (runbooks, compte forensique, chaîne de possession)
L'objectif 1.1 de l'AWS Certified Security Specialty couvre la construction du programme de réponse à incident avant que tout ne brûle. Tu retiens l'ordre des phases : préparation, détection et analyse, confinement, éradication et rétablissement, puis activité post-incident, et pourquoi un runbook transforme une décision sous stress en une séquence répétable que n'importe quelle personne d'astreinte peut suivre. L'analyse forensique se fait dans un compte forensique dédié pour que l'outillage d'investigation ne soit jamais sous le contrôle de l'attaquant et que le rayon d'impact reste contenu, les preuves étant écrites dans un bucket protégé par S3 Object Lock en mode compliance et le versioning pour que rien ne soit écrasé. La chaîne de possession consiste à consigner qui a pris chaque image disque, quand, et son empreinte, et la mémoire est capturée avant d'arrêter l'instance car l'état volatile disparaît à l'extinction. L'équipe détient des rôles IAM pré-créés au lieu de quémander des permissions en plein incident, les niveaux de gravité pilotent l'escalade et l'autorisation de couper un service générateur de revenus, et la communication hors bande sert quand la messagerie d'entreprise est peut-être déjà compromise. Les game days répètent une clé d'accès fuitée, et les revues post-incident produisent des changements concrets. Attends-toi à des mises en situation sur les lacunes de préparation, l'intégrité des preuves et qui décide.
Analyser une compromission sans risque = compte forensique dédié, jamais le compte compromis. Preuves que personne ne peut modifier ni supprimer = S3 Object Lock en mode compliance plus versioning. Capturer la mémoire d'abord, snapshotter le disque ensuite, car l'état volatile meurt à l'extinction.
Questions d'entraînement
1. AWS Trust and Safety ecrit au contact de votre compte pour signaler qu'une de vos instances EC2 balaie les ports de reseaux tiers. Comment traiter cet avis ?
- La considerer comme purement informative, car AWS aurait lui meme suspendu l'instance si l'activite etait reellement nuisible aux reseaux concernes
- La traiter comme un signal de detection, investiguer l'instance et repondre dans le delai indique (bonne réponse)
- La transmettre a l'equipe finance, un avis d'abus etant normalement la consequence d'une facture impayee sur le compte proprietaire
- Attendre que GuardDuty leve un constat correspondant, et ne rien faire tant qu'aucun constat de ce type n'apparait dans la console
Un avis d'abus est une preuve externe qu'une charge dont vous etes proprietaire attaque autrui : il entre donc dans le processus de reponse a incident comme toute autre detection, avec une investigation et une reponse documentee avant l'echeance. AWS ne suspend pas d'abord pour expliquer ensuite, l'abus n'a rien a voir avec la facturation, et attendre GuardDuty revient a ignorer un signalement deja plus precis qu'un constat.
2. Une investigation correle des enregistrements CloudTrail, des journaux applicatifs de trois regions et un export de pare feu. Quelle pratique evite de reconstituer une fausse sequence d'evenements ?
- Normaliser tous les horodatages en UTC avant de construire la chronologie (bonne réponse)
- Classer les enregistrements selon le moment ou chaque fichier a ete ecrit dans le bucket de preuves du compte de forensique
- Se fier a l'ordre d'affichage de la console, chaque service triant deja ses propres enregistrements avant de les presenter
- Convertir tous les horodatages dans le fuseau local de l'analyste pour que le recit colle aux heures ouvrees de l'equipe d'astreinte
AWS enregistre les evenements en UTC, et une reference commune unique est ce qui permet d'ordonner de facon fiable des enregistrements d'origines differentes. L'heure de livraison dans un bucket accuse plusieurs minutes de retard sur l'evenement, l'ordre affiche par la console d'un service ne dit rien du sequencement entre sources, et convertir en heure locale ajoute un decalage et un piege d'heure d'ete sans aucun benefice.
3. Une intrusion est decouverte au soixantieme jour de la fenetre d'investigation, et le bucket de journaux a une regle de cycle de vie qui expire les objets au bout de quatre vingt dix jours. Le service juridique demande une conservation. Que faut il faire d'abord ?
- Copier les objets utiles sur le poste de l'analyste, puis laisser la regle de cycle de vie expirer les originaux comme c'etait deja prevu
- Suspendre la regle d'expiration ou en exclure le prefixe concerne avant l'echeance (bonne réponse)
- Passer les objets en classe Glacier Deep Archive, ce qui met en pause le compteur de cycle de vie jusqu'a leur restauration
- Demander au support AWS de geler le bucket, seule l'equipe du service pouvant empecher une regle d'expiration de s'executer a une date donnee
Une regle de cycle de vie supprime a l'heure dite et ignore une enquete en cours : il faut donc l'arreter ou la restreindre avant que les objets n'atteignent leur date d'expiration. Une copie sur un poste de travail n'est pas un emplacement de preuve maitrise, la transition vers Glacier change la classe de stockage sans suspendre l'expiration, et le support AWS ne gere pas les regles de cycle de vie du client.
4. Pendant un incident, pourquoi l'analyse forensique doit-elle se faire dans un compte AWS dedie plutot que dans le compte compromis ?
- Parce qu'AWS interdit techniquement de creer des instantanes dans un compte que GuardDuty a signale comme compromis
- Parce que l'attaquant detient peut-etre encore des identifiants dans le compte compromis et pourrait detruire les preuves (bonne réponse)
- Parce que les licences des outils forensiques ne sont facturees qu'une fois par unite d'organisation quand l'outillage y est centralise
- Parce que la copie d'instantanes entre comptes est toujours plus rapide qu'un instantane pris et analyse dans le meme compte
Un compte de forensique isole met les preuves et l'outillage d'analyse hors de portee de celui qui controle encore le compte compromis, ce qui preserve la chaine de possession. AWS n'interdit techniquement pas les instantanes dans un compte signale, la facturation des licences n'est pas un argument de securite, et les copies entre comptes sont en realite plus lentes que les copies locales.
5. Quel est l'objectif principal d'un runbook dans un plan de reponse a incident AWS ?
- Lister le cout mensuel de chaque service de securite pour que l'equipe justifie son budget apres un incident
- Remplacer l'astreinte en decrivant quel ingenieur reveiller pour chaque niveau de gravite
- Donner aux intervenants des etapes predefinies pour un type d'incident connu, afin que la reponse soit rapide et reproductible (bonne réponse)
- Conserver les cles de chiffrement necessaires au dechiffrement des volumes de preuve dans le cas ou l'equipe securite en perdrait l'acces
Un runbook supprime l'improvisation sous stress en ecrivant la sequence d'actions d'un scenario connu, ce qui rend la reponse rapide, coherente et auditable. Le suivi des couts n'a rien a voir, un runbook complete l'astreinte au lieu de la remplacer, et stocker des cles dans un document serait en soi une faille grave.
6. Un analyste doit preserver la memoire d'une instance EC2 compromise avant toute autre chose. Que faut-il faire en premier ?
- Capturer la memoire volatile pendant que l'instance tourne encore (bonne réponse)
- Arreter l'instance immediatement, puis prendre un instantane EBS de chaque volume attache et l'analyser hors ligne
- Redemarrer l'instance sur un noyau de secours afin de monter le disque en lecture seule pour l'imager
- Terminer l'instance et la reconstruire depuis la derniere AMI saine connue pour retablir vite le service
La memoire est la preuve la plus volatile et disparait des que l'instance s'arrete ou redemarre, elle doit donc etre capturee en premier, sur une instance encore en marche mais isolee par groupe de securite. Arreter, redemarrer ou terminer detruisent cette memoire, et terminer detruit en plus les donnees du magasin d'instance et toute possibilite d'analyse ulterieure.