1.2 - Détecter menaces et anomalies avec les services AWS (GuardDuty, Inspector, Macie, Detective, Security Hub)
L'objectif 1.2 de l'AWS Certified Security Specialty couvre le choix du bon service de détection et la lecture de ce qu'il raconte. Amazon GuardDuty analyse les événements de gestion et de données S3 de CloudTrail, les VPC Flow Logs et les journaux de requêtes DNS Route 53 Resolver sans déployer le moindre agent : un finding de minage de Bitcoin vient donc du DNS, une connexion console inhabituelle de CloudTrail et un flux pair à pair suspect des Flow Logs. Seuls les plans de protection optionnels vont plus loin : journaux d'audit EKS, Malware Protection qui scanne les snapshots EBS, et Runtime Monitoring, la seule capacité qui utilise vraiment un agent dans l'hôte ou le conteneur. Amazon Inspector scanne les instances EC2, les images ECR et Lambda à la recherche de CVE connues, Amazon Macie découvre les données sensibles comme les numéros de carte dans les buckets S3, et Amazon Detective construit un graphe de comportement pour mesurer la portée d'un finding. Security Hub normalise le tout au format ASFF, exécute des standards de conformité, agrège les résultats entre régions et comptes via un administrateur délégué, et alimente la billetterie via EventBridge en quelques secondes. Les règles de suppression et les listes d'IP de confiance font taire un scanner autorisé. Attends-toi à des mises en situation qui nomment un type de finding ou un besoin, et à désigner le bon service.
GuardDuty n'a besoin d'aucun agent, sauf Runtime Monitoring. Vulnérabilités et CVE = Inspector ; données sensibles dans S3 = Macie ; portée et chronologie d'un finding = Detective. Une vue normalisée de tous les findings entre comptes = Security Hub avec administrateur délégué.
Questions d'entraînement
1. Un compte d'automatisation emet normalement quelques dizaines d'appels d'API par heure. La nuit derniere, il en a emis plusieurs milliers de type DescribeInstances en dix minutes. Quelle capacite est concue pour faire remonter exactement ce genre d'ecart ?
- AWS Config, qui aurait enregistre un nouvel element de configuration pour chacune des instances decrites par ces appels pendant la fenetre
- Amazon Macie, dont le score de sensibilite aurait augmente pour les buckets que le compte d'automatisation est autorise a lire
- CloudTrail Insights (bonne réponse)
- AWS Trusted Advisor, dont les controles de limites de service alertent un compte qui approche du seuil de bridage d'une API
CloudTrail Insights apprend le rythme normal d'appel de chaque API du compte et leve un evenement Insights quand le volume s'ecarte de cette reference, ce qui correspond exactement a une rafale d'appels d'enumeration. Config enregistre un etat de configuration et non un volume d'appels, Macie inspecte le contenu des donnees, et Trusted Advisor compare un compte a des bonnes pratiques plutot qu'a son propre historique.
2. Une equipe veut que GuardDuty voie l'activite au niveau des processus dans ses instances EC2 et ses conteneurs, par exemple un shell lance par un serveur web. Qu'est ce que cela exige ?
- Rien, GuardDuty observant deja l'execution des processus a travers les evenements de gestion CloudTrail produits par le compte
- Activer les journaux de flux VPC sur chaque sous reseau, l'activite des processus se deduisant des connexions reseau que chaque processus ouvre
- Envoyer les journaux systeme de chaque instance vers CloudWatch Logs, ou GuardDuty s'abonne aux groupes de journaux dont il a besoin
- Activer Runtime Monitoring, qui deploie l'agent de securite GuardDuty (bonne réponse)
Runtime Monitoring est la seule capacite de GuardDuty qui ne soit pas sans agent : elle installe un agent de securite qui remonte les evenements de processus, de fichiers et de reseau depuis l'interieur de l'hote ou du conteneur. Les sources fondees sur des journaux comme CloudTrail et les flux VPC ne voient jamais ce qui se passe dans le systeme d'exploitation, et GuardDuty ne consomme pas des groupes de journaux CloudWatch quelconques.
3. Une equipe securite veut reunir CloudTrail, les journaux de flux VPC, les journaux Route 53 et des sources tierces au meme endroit, convertis dans un schema commun pour l'analyse. Quel service le fait ?
- Amazon Detective, qui ingere deja plusieurs de ces sources afin de construire le graphe de comportement qu'il presente a l'analyste
- AWS Config, dont l'agregateur rassemble les elements de configuration de tous les comptes et regions dans une vue unique pour l'organisation
- Amazon Security Lake, qui normalise les sources au format OCSF (bonne réponse)
- Amazon CloudWatch, dont l'observabilite inter-comptes relie les groupes de journaux et les metriques de plusieurs comptes a un compte de supervision
Security Lake centralise les donnees de securite dans votre propre stockage S3 et les convertit au format Open Cybersecurity Schema Framework, si bien que n'importe quel outil d'analyse peut les interroger de facon uniforme. Detective construit son propre graphe ferme plutot qu'un lac interrogeable, Config ne traite que des elements de configuration, et CloudWatch relie des groupes de journaux sans les convertir dans un schema de securite commun.
4. Une equipe securite veut une detection continue des menaces sur un compte, sans deployer le moindre logiciel sur le parc EC2. Quel service repond au besoin ?
- Amazon Inspector, qui analyse en continu les charges en execution a la recherche de vulnerabilites logicielles connues et de problemes d'accessibilite reseau
- Amazon Macie, qui decouvre et classifie les donnees sensibles stockees dans les buckets Amazon S3
- Amazon GuardDuty (bonne réponse)
- AWS Config, qui enregistre les changements de configuration des ressources et les evalue face a des regles
GuardDuty lit des sources de donnees qu'AWS produit deja, comme les evenements de gestion et de donnees CloudTrail, les journaux de flux VPC et les journaux de requetes DNS, si bien qu'il ne demande aucun agent. Inspector cherche des vulnerabilites logicielles plutot que des menaces actives, Macie concerne la classification des donnees sensibles dans S3, et Config suit la derive de configuration plutot que le comportement d'un attaquant.
5. Quel service agrege les constats de GuardDuty, Inspector et Macie dans une vue unique normalisee avec des referentiels de conformite ?
- Amazon Detective, qui construit un graphe d'investigation interactif a partir des evenements entourant un constat
- AWS CloudTrail Lake, qui stocke des enregistrements d'evenements immuables et permet de les interroger en SQL
- Amazon EventBridge, qui achemine les evenements entre sources et cibles selon des regles que vous definissez
- AWS Security Hub (bonne réponse)
Security Hub ingere les constats au format AWS Security Finding Format et y ajoute des referentiels comme CIS et les bonnes pratiques fondamentales de securite AWS. Detective examine un constat en profondeur au lieu d'en agreger beaucoup, CloudTrail Lake est un magasin d'interrogation de l'activite API, et EventBridge se contente de deplacer des evenements sans les normaliser ni les noter.
6. GuardDuty leve un constat de type CryptoCurrency:EC2/BitcoinTool.B!DNS. Quelle source de donnees l'a produit ?
- Les journaux de requetes DNS du resolveur Route 53 (bonne réponse)
- Les resultats d'analyse de vulnerabilites d'Amazon Inspector collectes par l'agent SSM installe sur l'instance
- Les elements de configuration AWS Config decrivant les groupes de securite attaches a l'instance
- Les taches de classification Amazon Macie executees sur les buckets S3 dans lesquels l'instance ecrit
Le suffixe !DNS dans un type de constat GuardDuty nomme la source de donnees, ici les journaux de requetes DNS du resolveur du VPC, qui ont montre l'instance resolvant un domaine de pool de minage connu. Inspector, Config et Macie ne sont pas des sources de donnees GuardDuty, et aucun n'observe la resolution de noms sortante.