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

Dans le AWS Shared Responsibility Model, AWS assure la sécurité « du » cloud (infrastructure physique, hyperviseur, réseau mondial), tandis que les clients assurent la sécurité « dans » le cloud (AWS Shared Responsibility Model, aws.amazon.com/compliance/shared-responsibility-model). Les security groups (à état, au niveau de l'instance) et les NACLs (sans état, au niveau du subnet) sont toujours des contrôles réseau configurés par le client, quel que soit le modèle de service. Pourquoi pas les autres ? La sécurité physique du centre de données est une 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 plus de responsabilités au client, Lambda (serverless) en confie moins. Selon le AWS Well-Architected Security Pillar, toute décision de configuration portant sur les charges de travail du client relève du client. Réf. : AWS Shared Responsibility Model ; AWS Well-Architected Security Pillar ; NIST SP 800-145.

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.

Le certificate pinning lie un certificat ou une clé publique précis au serveur attendu d'une application, en complément de la validation classique de la chaîne TLS. TLS standard fait confiance à n'importe quelle CA présente dans le magasin de l'appareil ; une CA compromise ou frauduleuse peut émettre des certificats falsifiés et permettre une interception MITM. Le pinning l'empêche en vérifiant que le certificat du serveur correspond à une empreinte intégrée à l'avance. Approches : pinning de la feuille (strict), pinning de la CA intermédiaire (souple) ou pinning de la clé publique (qui survit au renouvellement du certificat). Pourquoi pas les autres ? Les attaques DoS visent la disponibilité, pas l'authentification. Le XSS exploite le DOM du navigateur, 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 Security Testing Guide (MSTG) ; OWASP Mobile Top 10 M3 ; RFC 7469 (HTTP Public Key Pinning).