CISSP · Réussir du premier coup

Chapitre 7
Vulnérabilités
des architectures

Domaine 3, deuxième partie : chaque type de système, sa vulnérabilité phare et sa contre-mesure — du mainframe au serverless.

Domaine
3 — Security Architecture & Engineering · 13 %
Objectifs couverts
3.5
Entraînement
25 questions + corrigé raisonné
L'essentiel en 60 secondes
  • Agrégation = Addition (des morceaux anodins font un tout sensible) ; Inférence = Intelligence (déduire l'interdit à partir de l'autorisé).
  • La polyinstantiation combat l'inférence : deux versions d'une même ligne, une par niveau de classification.
  • ICS/SCADA : la disponibilité et la sûreté priment ; on ne patche ni ne scanne comme en IT ; l'« air gap » meurt d'une clé USB (Stuxnet).
  • Cloud : public · private · community (organisations aux exigences communes) · hybrid · multi-cloud ; risques phares : multitenancy et vendor lock-in.
  • Hyperviseur type 1 = bare metal, datacenter, surface réduite ; type 2 = posé sur un OS, poste de travail.
  • VM escape = sortir de l'invité vers l'hôte ; VM sprawl = prolifération non gérée ; les snapshots réintroduisent des états vulnérables.
  • Les conteneurs partagent le noyau de l'hôte : isolation plus faible qu'une VM — images signées, registres de confiance, scan.
  • Serverless : le fournisseur patche l'infrastructure, mais le code et les permissions des fonctions restent au client.
  • IoT : mots de passe par défaut + pas de mises à jour → réseau séparé et durcissement.
  • Mobile : MDM gère l'appareil, MAM gère les apps, UEM unifie ; contrôle croissant : BYOD < CYOD < COPE < COBO.

Objectif 3.5Client, serveur et bases de données

Côté client, le risque vient du code qui s'exécute chez l'utilisateur : applets et code mobile (Java, ActiveX hier ; JavaScript aujourd'hui) tournent dans le navigateur avec les droits de la victime — contre-mesures : sandboxing, désactivation des technologies obsolètes, patching des navigateurs. Les caches locaux s'empoisonnent : cache ARP, cache DNS — l'utilisateur est redirigé sans rien voir (les attaques précises sont au chapitre 10).

Côté serveur, l'enjeu testé est le data flow control : maîtriser le mouvement des données entre systèmes, réguler les débits pour éviter la saturation (DoS) ou la perte de paquets — contre-mesures : répartiteurs de charge, files, contrôles de flux (et le DLP du chapitre 5 pour la nature des données).

Bases de données : agrégation, inférence, polyinstantiation

La paire la plus piégeuse du domaine 3 :

AttaqueMécanismeExempleContre-mesures
AggregationAdditionner des éléments individuellement anodins jusqu'à un ensemble sensibleChaque commande d'un fournisseur est publique ; leur somme révèle le plan produitRestreindre les fonctions d'agrégat (SUM, COUNT), contrôle contextuel
InferenceDéduire une information interdite par raisonnement sur des requêtes autoriséesLe budget du service avant/après une embauche révèle le salaire du nouveau venuPolyinstantiation, cloisonnement (partitioning), suppression de cellules, bruit statistique

La polyinstantiation insère plusieurs lignes de même clé primaire, une par niveau de classification : l'utilisateur non habilité voit une version de couverture plausible au lieu d'un trou révélateur — c'est une défense anti-inférence, pas une corruption de données. Complétez le paysage : ODBC expose une interface générique vers les bases (à authentifier et journaliser), et le NoSQL n'immunise contre rien — l'injection y change simplement de syntaxe.

🧠 Mnémonique

« Agrégation = Addition · Inférence = Intelligence. » L'une empile des faits autorisés, l'autre raisonne pour combler le blanc. Si le scénario contient un calcul mental (« il en a déduit… »), c'est l'inférence.

Objectif 3.5Systèmes industriels (ICS)

Les Industrial Control Systems pilotent le monde physique — énergie, eau, usines. Leur hiérarchie de valeurs s'inverse par rapport à l'IT : sûreté des personnes, puis disponibilité, avant l'intégrité et loin devant la confidentialité. Le vocabulaire :

ComposantRôle
PLCProgrammable Logic Controller : l'automate au contact des capteurs et actionneurs
HMIHuman-Machine Interface : l'écran de conduite de l'opérateur
SCADASupervision et acquisition de données sur de grandes distances (réseaux d'eau, pipelines)
DCSDistributed Control System : contrôle d'un site de production local (raffinerie, usine)
HistorianArchive des mesures de production — souvent le pont (et le maillon faible) entre OT et IT

Vulnérabilités structurelles : protocoles hérités sans authentification (Modbus), cycles de vie de plusieurs décennies, patching quasi impossible sans arrêt de production, et scans de vulnérabilité IT qui peuvent faire tomber un automate. Contre-mesures : segmentation stricte OT/IT (le modèle de Purdue étage les niveaux 0–5, du capteur à l'ERP), passerelles unidirectionnelles (data diodes), fenêtres de maintenance et contrôles compensatoires, guide NIST SP 800-82. Quant à l'« air gap » : Stuxnet a montré qu'une clé USB le traverse — l'isolement physique se complète toujours d'un contrôle des médias amovibles.

Objectif 3.5Cloud et systèmes distribués

Modèles de service et de déploiement

Les modèles de service — IaaS, PaaS, SaaS, et leurs déclinaisons XaaS/FaaS — répartissent la responsabilité comme vu au chapitre 6. Les modèles de déploiement :

ModèleDéfinitionLe point testé
PublicInfrastructure mutualisée d'un fournisseur, ouverte à tousMultitenancy — vous partagez le matériel avec des inconnus
PrivateDédié à une seule organisation (chez soi ou hébergé)Contrôle maximal, coût maximal
CommunityPartagé par des organisations aux exigences communes (mission, conformité)Ex. cloud d'un groupement hospitalier — la définition tombe telle quelle
HybridCombinaison de modèles reliés (débordement, DR)La frontière et les flux entre les deux sont le point faible
Multi-cloudPlusieurs fournisseurs en parallèleRéduit le lock-in, multiplie la complexité opérationnelle

Deux risques nommés par le référentiel : la multitenancy — une défaillance d'isolation ou une attaque par canal auxiliaire expose aux voisins de matériel — et le vendor lock-in — formats propriétaires et coûts de sortie qui emprisonnent ; parades : formats standards, portabilité testée, clause et stratégie de sortie au contrat (le SCRM du chapitre 3).

Distribué, grid, P2P

Tout système distribué élargit la surface d'attaque : plus de nœuds, plus de liens, plus de confiance implicite à gouverner. Le grid computing agrège des machines hétérogènes, souvent volontaires — on n'y confie jamais de données sensibles, chaque nœud pouvant lire ce qu'il traite. Le P2P n'a ni centre ni contrôle : contenus non vérifiés, canal d'exfiltration idéal, bande passante consommée — à interdire ou encadrer strictement en entreprise.

Objectif 3.5Virtualisation, conteneurs, microservices, serverless

Virtualisation

L'hyperviseur type 1 (bare metal) s'exécute directement sur le matériel — datacenters, surface d'attaque réduite ; le type 2 s'installe sur un OS hôte — postes de travail, héritant de toutes les faiblesses de l'OS. Les risques à réciter :

Conteneurs et microservices

Les conteneurs partagent le noyau de l'hôte : démarrage instantané, densité élevée — mais isolation structurellement plus faible qu'une VM (une évasion de conteneur compromet l'hôte et tous ses voisins). Sécurité : images signées issues de registres de confiance, scan de vulnérabilités des images, secrets hors des images (coffre), durcissement de l'orchestrateur (API Kubernetes, RBAC), infrastructure immuable — on remplace, on ne modifie pas. Les microservices transforment l'application en constellation d'API : chaque appel doit être authentifié et autorisé — passerelle d'API, mTLS de service à service, limitation de débit ; l'observabilité devient un contrôle de sécurité à part entière.

Serverless

En FaaS, le fournisseur gère serveurs et patching — mais la responsabilité du code, des dépendances et surtout des permissions attachées à chaque fonction reste au client : une fonction sur-privilégiée est la faille type. S'ajoutent l'injection par événements déclencheurs et le déni de porte-monnaie (facturation à l'exécution).

Objectif 3.5IoT, embarqué, HPC, edge

Objectif 3.5Mobiles — et le tableau maître

Gérer les flottes mobiles

OutilPérimètreCapacités types
MDML'appareil entierChiffrement imposé, code PIN, effacement à distance, géolocalisation
MAMLes applications d'entreprise seulementConteneur applicatif, wipe sélectif — adapté au BYOD (la vie privée du reste de l'appareil est préservée)
UEMUnifié : mobiles + postes + IoTUne console pour toute la flotte

Modèles de propriété, du moins au plus contrôlé : BYOD (appareil personnel — tensions vie privée/sécurité), CYOD (choix dans une liste approuvée), COPE (fourni par l'entreprise, usage personnel toléré), COBO (fourni, usage strictement professionnel — le contrôle maximal). La conteneurisation mobile cloisonne profil pro et personnel sur le même appareil.

🧠 Mnémonique — le gradient mobile

B < C < C < C : BYOD < CYOD < COPE < COBO — « Bring, Choose, Provided, Business-only » : le contrôle de l'entreprise monte à chaque cran, la liberté de l'utilisateur descend d'autant.

Le tableau maître : système → vulnérabilité phare → contre-mesure phare

SystèmeVulnérabilité phareContre-mesure phare
ClientCode mobile, caches empoisonnésSandbox, patching navigateur
ServeurSaturation des flux de donnéesData flow control, load balancing
Base de donnéesInférence / agrégationPolyinstantiation, partitionnement
ICS / SCADAProtocoles sans auth, non patchableSegmentation OT/IT (Purdue), 800-82
Cloud publicMultitenancy, lock-inChiffrement à clés client, stratégie de sortie
Grid / P2PNœuds non maîtrisésAucune donnée sensible, encadrement strict
VirtualisationVM escape, sprawl, snapshotsPatch hyperviseur, gouvernance du cycle de vie
ConteneursNoyau partagé, images compromisesImages signées + scan, durcir l'orchestrateur
MicroservicesAPI exposées à chaque appelAPI gateway, mTLS, authZ par requête
ServerlessFonctions sur-privilégiéesMoindre privilège par fonction
IoT / embarquéDéfauts d'usine, pas de patchRéseau dédié, changer les défauts, lightweight crypto
EdgeExposition physique des nœudsChiffrement + attestation (TPM)
MobilePerte/vol, mélange pro-persoMDM/MAM, conteneurisation, wipe à distance
⚠️ Pièges d'examen
  • Agrégation (additionner l'anodin) ≠ inférence (déduire l'interdit) : cherchez s'il y a raisonnement dans le scénario.
  • La polyinstantiation est une défense anti-inférence (version de couverture), pas une anomalie de données.
  • ICS : jamais de scan agressif ni de patch immédiat en production — fenêtres de maintenance, tests, compensations. La sûreté et la disponibilité gouvernent.
  • L'« air gap » n'arrête pas les médias amovibles : Stuxnet est le contre-exemple canonique.
  • Type 1 = bare metal (plus sûr, datacenter) ; type 2 = sur OS hôte. VM escape (sortie d'invité) ≠ VM sprawl (prolifération).
  • Conteneur ≠ VM : le noyau est partagé, l'isolation est moindre — cohabiter des sensibilités différentes exige des VM, pas des conteneurs.
  • Serverless n'exonère pas : code, dépendances et permissions de fonction restent au client (responsabilité partagée, chapitre 6).
  • Community cloud = organisations aux exigences communes — la définition tombe mot pour mot.
  • BYOD avec respect de la vie privée → MAM/conteneurisation ; contrôle total de l'appareil → MDM (et COBO côté propriété).
Scénario fil rouge — Awa

La cartographie applicative post-acquisition ressemble à ce chapitre. Le cœur de paiement part en microservices sur Kubernetes : Awa impose registre d'images privé, signatures obligatoires, scan à chaque build, et mTLS derrière la passerelle d'API — et refuse que les conteneurs du scoring côtoient ceux du site vitrine : sensibilités différentes, hôtes différents. L'analytique BI soulève un cas d'école : un analyste sans habilitation RH reconstituait les salaires en comparant les agrégats budgétaires avant/après embauche — inférence pure ; la parade combine restriction des requêtes d'agrégat et cloisonnement. Le bâtiment berlinois apporte sa GTB (chauffage, accès) : automates jamais patchés, protocole sans authentification — VLAN OT dédié, passerelle filtrante, et consigne stricte : aucun scan de vulnérabilité actif sur ce segment. Les capteurs IoT des salles serveurs quittent le réseau bureautique pour un segment isolé après découverte de mots de passe d'usine. Enfin, les commerciaux gardent leur BYOD : Awa retient le MAM avec conteneur d'entreprise — wipe sélectif des données pro, photos de famille intactes — quand la direction, elle, passe en COPE géré par MDM complet.


Quiz25 questions

Conditions réelles : 30 minutes, une seule passe, réponses notées avant de consulter le corrigé.

Question 1

A clerk with access to individually unclassified shipping records combines hundreds of them and derives the location of a sensitive facility. Which attack is this?

  1. Inference
  2. Aggregation
  3. Polyinstantiation
  4. SQL injection
Voir la réponse Réponse : B

Additionner des éléments anodins jusqu'à l'ensemble sensible = agrégation (« Agrégation = Addition »). L'inférence (A) exigerait une déduction comblant une information manquante.

Question 2

An analyst authorized to view department budget totals deduces a new employee's salary by comparing totals before and after the hire. Which attack is this?

  1. Aggregation
  2. Inference
  3. Shoulder surfing
  4. Data diddling
Voir la réponse Réponse : B

Le raisonnement avant/après déduit une donnée interdite (le salaire) à partir de requêtes autorisées : inférence (« Inférence = Intelligence »). L'agrégation empilerait des faits, sans déduction.

Question 3

What is the purpose of polyinstantiation in a multilevel secure database?

  1. Improving query performance through duplicate indexes
  2. Preventing inference by presenting lower-cleared users a plausible cover version of a sensitive row
  3. Backing up rows to a secondary site
  4. Enforcing referential integrity
Voir la réponse Réponse : B

Plusieurs versions d'une même ligne, une par niveau : l'utilisateur bas voit une couverture plausible au lieu d'un blanc révélateur — défense anti-inférence. Ce n'est ni de la performance (A) ni de la sauvegarde (C).

Question 4

Which control BEST limits the risk of malicious mobile code executing in users' browsers?

  1. Sandboxing and keeping browsers patched
  2. Disabling TLS
  3. Allowing legacy plug-ins for compatibility
  4. Granting users local administrator rights
Voir la réponse Réponse : A

Le code mobile s'exécute côté client : on le confine (sandbox) et on patche l'exécutant (navigateur). B, C et D aggravent tous la surface d'attaque.

Question 5

In an industrial control environment, which properties take priority over confidentiality?

  1. Nonrepudiation and privacy
  2. Human safety and availability
  3. Portability and scalability
  4. Anonymity and integrity
Voir la réponse Réponse : B

L'ICS pilote le monde physique : la sûreté des personnes puis la disponibilité passent devant tout — la confidentialité est reléguée. C'est l'inversion de valeurs qui fonde toutes les réponses ICS.

Question 6

Which ICS component directly drives sensors and actuators on the factory floor?

  1. The historian
  2. The programmable logic controller (PLC)
  3. The human-machine interface (HMI)
  4. The enterprise resource planning system
Voir la réponse Réponse : B

Le PLC est l'automate au contact des capteurs et actionneurs. L'HMI est l'écran de conduite (C), l'historian archive (A), l'ERP vit côté IT (D).

Question 7

Which architecture supervises geographically dispersed infrastructure such as pipelines and water networks?

  1. DCS
  2. SCADA
  3. VDI
  4. RTOS
Voir la réponse Réponse : B

Grandes distances géographiques = SCADA ; le DCS contrôle un site local (raffinerie). C'est la distinction testée entre les deux.

Question 8

A critical vulnerability is announced for the PLCs of a running production line. What is the BEST response?

  1. Patch all PLCs immediately during production
  2. Run an aggressive vulnerability scan to confirm exposure
  3. Apply compensating controls (segmentation, monitoring) and schedule tested patching in a maintenance window
  4. Ignore the advisory, since ICS networks are air-gapped
Voir la réponse Réponse : C

En ICS, disponibilité et sûreté gouvernent : compenser d'abord (segmentation, surveillance), patcher testé en fenêtre de maintenance. A risque l'arrêt de production, B peut faire tomber les automates, D est un mythe (Q9).

Question 9

The Stuxnet incident demonstrated which limitation of air-gapped networks?

  1. Air gaps slow down legitimate traffic
  2. Removable media and portable devices can carry malware across the gap
  3. Air gaps violate safety regulations
  4. Air gaps prevent patching entirely
Voir la réponse Réponse : B

Stuxnet a traversé l'air gap sur clé USB : l'isolement physique ne vaut que complété d'un contrôle strict des médias amovibles et des équipements nomades.

Question 10

Which NIST publication provides security guidance specifically for industrial control systems?

  1. NIST SP 800-53
  2. NIST SP 800-82
  3. NIST SP 800-63B
  4. NIST SP 800-37
Voir la réponse Réponse : B

NIST SP 800-82 est le guide ICS/OT. 800-53 = catalogue de contrôles, 800-63B = authentification, 800-37 = RMF — trois références déjà croisées dans ce livre.

Question 11

Several regional hospitals with identical compliance requirements share a dedicated cloud infrastructure. Which deployment model is this?

  1. Public cloud
  2. Private cloud
  3. Community cloud
  4. Multi-cloud
Voir la réponse Réponse : C

Organisations distinctes, exigences communes (conformité santé), infrastructure partagée dédiée : community cloud — la définition mot pour mot.

Question 12

Which risk is inherent to multitenancy in a public cloud?

  1. Isolation failures or side-channel attacks exposing data to co-resident tenants
  2. Guaranteed data loss every year
  3. Inability to use encryption
  4. Mandatory disclosure of data to competitors
Voir la réponse Réponse : A

Partager le matériel avec des inconnus expose aux défauts d'isolation et aux canaux auxiliaires — le risque structurel de la multitenancy. B, C, D sont des caricatures.

Question 13

Which measure BEST mitigates vendor lock-in when adopting a cloud provider?

  1. Using as many proprietary services as possible
  2. Standard formats, tested data portability, and a contractual exit strategy
  3. Signing a longer contract for a discount
  4. Avoiding documentation of the architecture
Voir la réponse Réponse : B

Le lock-in se combat en amont : formats standards, portabilité testée, stratégie et clauses de sortie. A et C l'aggravent ; D aggrave tout.

Question 14

In a serverless (FaaS) architecture, which security responsibility remains ENTIRELY with the customer?

  1. Patching the physical servers
  2. The function code, its dependencies, and the permissions granted to each function
  3. Maintaining the hypervisor
  4. Cooling the data center
Voir la réponse Réponse : B

Le fournisseur patche l'infrastructure ; le client répond du code, des dépendances et des permissions de chaque fonction — la fonction sur-privilégiée est la faille serverless type.

Question 15

Which statement about hypervisor types is correct?

  1. Type 1 runs directly on hardware and offers a smaller attack surface; type 2 runs on top of a host OS
  2. Type 2 is used in data centers; type 1 on laptops
  3. Type 1 inherits every vulnerability of the host operating system
  4. Both types are identical in security posture
Voir la réponse Réponse : A

Type 1 = bare metal, surface réduite, datacenter ; type 2 = posé sur un OS hôte dont il hérite les faiblesses. B inverse, C décrit le type 2.

Question 16

An attacker breaks out of a guest virtual machine and gains access to the hypervisor and other guests. What is this attack called?

  1. VM sprawl
  2. VM escape
  3. Snapshot rollback
  4. Live migration
Voir la réponse Réponse : B

Sortir de l'invité vers l'hyperviseur et les voisins = VM escape, le scénario redouté de la virtualisation. Le sprawl (A) est la prolifération — autre piège, autre réponse.

Question 17

An audit finds dozens of forgotten, unpatched virtual machines created outside any process. What is this phenomenon, and what is the remedy?

  1. VM escape; patch the hypervisor
  2. VM sprawl; enforce lifecycle governance and inventory
  3. VDI; deploy thin clients
  4. Multitenancy; change cloud providers
Voir la réponse Réponse : B

Des VM hors inventaire et non patchées = VM sprawl ; le remède est la gouvernance du cycle de vie et l'inventaire (on ne protège pas ce qu'on ignore, chapitre 4).

Question 18

Why can restoring a virtual machine snapshot create a security problem?

  1. Snapshots are always corrupted
  2. It can reintroduce vulnerabilities that were patched after the snapshot was taken, and snapshots may contain sensitive memory data
  3. Snapshots disable the firewall permanently
  4. Restoring requires shutting down the entire cluster
Voir la réponse Réponse : B

Le snapshot fige un état : sa restauration réintroduit les vulnérabilités corrigées depuis, et le fichier capture la mémoire — secrets inclus. Il se protège comme la VM elle-même.

Question 19

Compared with virtual machines, what is the fundamental security limitation of containers?

  1. Containers cannot run network services
  2. Containers share the host kernel, so isolation is weaker than hardware-assisted VM isolation
  3. Containers cannot be scanned for vulnerabilities
  4. Containers require twice the memory
Voir la réponse Réponse : B

Le conteneur partage le noyau de l'hôte : l'isolation est logicielle, plus faible que la frontière matérielle d'une VM. D'où la règle : sensibilités très différentes → VM séparées.

Question 20

Which practices BEST secure a container supply chain?

  1. Pulling any public image for speed
  2. Signed images from trusted registries, vulnerability scanning of images, and secrets kept out of images
  3. Embedding credentials in the image for convenience
  4. Running all containers as root
Voir la réponse Réponse : B

La chaîne d'approvisionnement des conteneurs se sécurise par la provenance (registres de confiance, signatures), l'hygiène (scan des images) et la gestion des secrets hors image. A, C, D sont les anti-patterns exacts.

Question 21

Which combination BEST protects service-to-service communication in a microservices architecture?

  1. An API gateway, mutual TLS, and per-request authorization
  2. A single shared API key for all services
  3. Disabling authentication inside the cluster to reduce latency
  4. Exposing every microservice directly to the Internet
Voir la réponse Réponse : A

Passerelle d'API en façade, mTLS entre services, autorisation à chaque requête — le zero trust appliqué aux microservices. B crée un secret universel, C et D démontent la défense.

Question 22

Why is grid computing unsuitable for processing sensitive data?

  1. Grids are too slow
  2. Participating nodes are not controlled by the data owner and can read the data segments they process
  3. Grid software forbids encryption
  4. Grids only process public weather data
Voir la réponse Réponse : B

Les nœuds du grid n'appartiennent pas au propriétaire des données et lisent ce qu'ils traitent : aucune donnée sensible n'y a sa place. Les autres options sont fantaisistes.

Question 23

What are the FIRST two measures to secure a fleet of IoT sensors being deployed in an office?

  1. Change default credentials and place the devices on a dedicated, segmented network
  2. Install antivirus agents on each sensor and enable Bluetooth
  3. Expose the management interface to the Internet for remote support
  4. Increase the sensors' CPU power
Voir la réponse Réponse : A

Les deux gestes qui neutralisent les faiblesses structurelles de l'IoT : éliminer les identifiants d'usine (Mirai) et isoler sur un segment dédié. B est inapplicable, C est une faute, D est hors sujet.

Question 24

Which constraint typically prevents embedded and RTOS-based devices from using standard security controls?

  1. Their limited processing power and the impossibility of routine patching, requiring isolation and lightweight cryptography
  2. Their excessive memory capacity
  3. Licensing costs of antivirus software
  4. Their incompatibility with electricity
Voir la réponse Réponse : A

CPU modeste + patching impossible : la sécurité vient de la périphérie (isolement réseau, wrapper) et d'une cryptographie légère adaptée. C'est la logique des contrôles compensatoires (chapitre 3) appliquée au silicium.

Question 25

Employees use personal phones for work, and the company must protect corporate data without touching personal content. Which approach fits BEST?

  1. Full-device MDM with remote wipe of the entire phone
  2. Mobile application management with a corporate container and selective wipe
  3. Prohibiting all mobile access
  4. COBO devices for every employee
Voir la réponse Réponse : B

BYOD + respect du personnel = MAM/conteneurisation : l'entreprise gère et efface ses applications et données, rien d'autre. Le MDM complet (A) sur-contrôle un appareil privé ; C et D nient le besoin exprimé.

Auto-diagnostic

≥ 20/25 : passez au chapitre 8 — la cryptographie, le plus gros chapitre du livre. Entre 15 et 19 : relisez le tableau maître et la paire agrégation/inférence. < 15 : relisez le chapitre ; chaque type de système peut porter sa question, le tableau maître est votre filet.

FicheFiche de révision

À savoir par cœur avant le chapitre 8
  1. Agrégation = Addition (empiler l'anodin) · Inférence = Intelligence (déduire l'interdit) ; parades : restriction des agrégats, polyinstantiation, partitionnement, bruit.
  2. Polyinstantiation = une ligne par niveau, version de couverture pour les non-habilités.
  3. ICS : sûreté > disponibilité > le reste ; PLC (terrain) · HMI (conduite) · SCADA (grandes distances) · DCS (site local) · historian (archive, pont OT/IT).
  4. ICS : pas de scan agressif, pas de patch à chaud — segmentation Purdue, data diodes, NIST 800-82, fenêtres de maintenance.
  5. Air gap ≠ invulnérable : les médias amovibles le traversent (Stuxnet).
  6. Déploiements cloud : public · private · community (exigences communes) · hybrid · multi-cloud ; risques : multitenancy, vendor lock-in (parade : portabilité + stratégie de sortie).
  7. Grid/P2P : nœuds non maîtrisés — jamais de données sensibles.
  8. Hyperviseur type 1 = bare metal (datacenter, plus sûr) · type 2 = sur OS hôte (poste).
  9. VM escape = évasion d'invité (patcher l'hyperviseur, séparer les sensibilités) · VM sprawl = prolifération (gouvernance) · snapshots = états vulnérables + mémoire sensible.
  10. Conteneurs : noyau partagé → isolation moindre ; images signées, registres de confiance, scan, secrets au coffre, orchestrateur durci.
  11. Microservices : API gateway + mTLS + authZ par requête.
  12. Serverless : au client — code, dépendances, permissions par fonction (moindre privilège).
  13. IoT : changer les défauts + réseau dédié ; embarqué/RTOS : isolement + lightweight crypto ; edge : chiffrement + attestation TPM.
  14. MDM = appareil · MAM = applications (BYOD) · UEM = tout unifié.
  15. Contrôle croissant : BYOD < CYOD < COPE < COBO.