CompTIA SecurityX — Questions d'entraînement et examen blanc

Classe selon le mécanisme de livraison, pas selon l'histoire qui l'enrobe. Un adversaire qui envoie des messages afin d'accéder aux systèmes des victimes fait du phishing, et la classe couvre explicitement les pièces jointes et les liens malveillants ainsi que le fait de se faire passer pour une source de confiance. Usurper l'identité d'un fournisseur est un raffinement du ciblage qui rend le message plus convaincant, mais cela ne change pas la nature de la technique.

Les distracteurs relèvent d'étapes ultérieures ou d'objectifs différents. Abuser d'identifiants existants décrit un adversaire qui dispose déjà d'un accès à un compte valide, ce qui correspond à la poursuite d'une intrusion et non à la manière dont celle-ci arrive. Fondre le trafic de commande dans des protocoles de couche application ordinaires est un comportement de commande et contrôle qui ne compte qu'une fois un point d'appui établi. Exécuter du code au sein d'un autre processus est une technique d'exécution et d'évasion sur un hôte déjà compromis.

Conseil d'examen : bien classer compte, parce que les contre-mesures diffèrent. On contre la livraison par l'authentification des messages, la détonation des pièces jointes et un circuit de signalement pour les utilisateurs, alors que l'abus d'identifiants et l'exécution de code exigent des contrôles totalement différents, si bien que mal étiqueter la technique t'envoie vers la mauvaise défense.

Le shadow IT, c'est l'utilisation de systèmes, d'appareils, de logiciels ou de services cloud sans approbation explicite de l'organisation, ce qui crée un risque non maîtrisé et des angles morts de gouvernance. Ici, le service informatique a utilisé un stockage cloud non approuvé — la définition même du terme. Pourquoi pas les autres ? Le risque résiduel est celui qui subsiste après l'application des contrôles, ce qui suppose que des contrôles existent. Le risque inhérent est le risque de départ, avant tout contrôle, et ne concerne pas l'usage non autorisé. Le risque transféré consiste à déplacer le risque vers un tiers via une assurance ou une externalisation. Le shadow IT met à mal l'inventaire des actifs, la conformité, la réponse à incident et la protection des données, car les équipes sécurité ne peuvent pas sécuriser ce dont elles ignorent l'existence. Il crée des failles dans les évaluations de risque, l'application des politiques et la conformité réglementaire. Réf. : NIST CSRC Glossary (shadow_it) ; NIST SP 800-53 Rev 5 CM-8 (System Component Inventory) ; NIST CSF Identify function.

Dans l’AWS Shared Responsibility Model, AWS gère la sécurité « du » cloud (infrastructure physique, hyperviseur, réseau mondial), tandis que les clients gèrent la sécurité « dans » le cloud (AWS Shared Responsibility Model, aws.amazon.com/compliance/shared-responsibility-model). Pour les déploiements EC2, les security groups (avec état, au niveau de l’instance) et les NACLs (sans état, au niveau du sous-réseau) sont des contrôles réseau que configure le client. Pourquoi pas les autres ? La sécurité physique des centres de données est l’obligation fondamentale d’AWS. L’infrastructure réseau mondiale est gérée par AWS. L’application des correctifs à l’hyperviseur relève d’AWS selon la frontière IaaS. Cette frontière se déplace selon le modèle de service : EC2 (IaaS) confie davantage de responsabilités au client, Lambda (serverless) moins. AWS précise que les responsabilités du client varient selon les services utilisés, si bien que sa part du travail de configuration dépend des services choisis. Réf. : AWS Shared Responsibility Model ; livre blanc AWS Risk and Compliance ; NIST SP 800-145.

Le certificate pinning associe un certificat ou une clé publique spécifique au serveur attendu par une application, en complément de la validation standard de la chaîne TLS. Le TLS standard fait confiance à n’importe quelle CA présente dans le magasin de l’appareil ; une CA compromise ou illégitime peut émettre des certificats frauduleux permettant une interception MITM. Le pinning déjoue ce scénario en vérifiant que la chaîne de certificats du serveur correspond à un pin intégré à l’avance, par exemple un hash d’une clé de la chaîne. Approches : pinning du certificat feuille (strict), pinning de la CA intermédiaire (souple) ou pinning de la clé publique (résiste au renouvellement du certificat si la même paire de clés est réutilisée). Pourquoi pas les autres ? Les attaques DoS visent la disponibilité, pas l’authentification. Le XSS injecte un script malveillant dans un contenu rendu par le client, sans rapport avec la sécurité du transport. L’injection SQL vise l’analyse des requêtes, pas TLS. Parmi les risques du pinning figure la complexité opérationnelle lors de la rotation des certificats ; des pins de secours sont indispensables pour éviter de se retrouver bloqué. Réf. : OWASP Mobile Application Security Testing Guide (MASTG) ; OWASP Mobile Top 10 2024 M5 (Insecure Communication) ; RFC 7469 (HTTP Public Key Pinning, désormais obsolète dans les navigateurs).