CISSP · Réussir du premier coup

Chapitre 6
Principes de conception
et modèles de sécurité

Domaine 3, première partie : les principes qui fondent toute architecture, les modèles formels, Common Criteria et les capacités matérielles.

Domaine
3 — Security Architecture & Engineering · 13 %
Objectifs couverts
3.1 · 3.2 · 3.3 · 3.4
Entraînement
25 questions + corrigé raisonné
L'essentiel en 60 secondes
  • Fail-safe protège les personnes (la porte se déverrouille) ; fail-secure protège les actifs (le firewall bloque tout).
  • Zero trust (NIST 800-207) : never trust, always verify — chaque requête est vérifiée, la localisation ne donne aucun privilège.
  • SASE = réseau (SD-WAN) + sécurité (SWG, CASB, ZTNA, FWaaS) convergés et servis depuis le cloud.
  • Responsabilité partagée : le client garde toujours ses données et ses accès ; le fournisseur a toujours le physique.
  • Bell-LaPadula = confidentialité : no read up (simple), no write down (★).
  • Biba = intégrité, miroir exact : no read down (simple), no write up (★).
  • Clark-Wilson = intégrité commerciale : le sujet ne touche un CDI qu'à travers un TP (triple), vérifié par IVP, avec SoD.
  • Brewer-Nash = muraille de Chine : les droits changent dynamiquement selon l'historique d'accès (conflits d'intérêts).
  • Common Criteria : PP = ce que le client veut, ST = ce que le vendeur revendique, EAL1–7 = rigueur d'évaluation (EAL4 = « methodically designed, tested and reviewed »).
  • Certification = évaluation technique ; accréditation/ATO = décision formelle du management.
  • TPM = puce soudée (PCR, sealing/binding, measured boot) ; HSM = boîtier dédié haute performance ; rings 0–3 ; ASLR randomise, DEP rend non exécutable.

Objectif 3.1Les principes de conception sécurisée

Ces principes sont le vocabulaire de l'architecte — et chacun peut porter une question. Les fondamentaux d'abord, en une ligne chacun : threat modeling dès la conception (chapitre 3) ; least privilege — le minimum nécessaire, rien de plus ; defense in depth — des couches indépendantes, pour qu'aucune défaillance unique ne soit fatale ; secure defaults — sûr à la sortie de la boîte, deny by default ; separation of duties — aucun pouvoir complet entre les mains d'un seul ; keep it simple and small — la complexité est l'ennemie de la sécurité : moins de surface, moins d'erreurs.

Fail securely — et la question de la vie humaine

Un système qui échoue doit échouer dans un état sûr. Mais « sûr » pour qui ? Deux logiques s'opposent :

ModeÀ la défaillanceProtègeExemple
Fail-safe / fail-openS'ouvre, laisse passerLes personnesPorte de sortie qui se déverrouille en cas de coupure — obligatoire pour l'évacuation
Fail-secure / fail-closedSe ferme, bloqueLes actifsFirewall qui coupe tout trafic quand il tombe ; chambre forte qui reste verrouillée

La règle d'arbitrage est celle du chapitre 0 : quand la vie humaine est en jeu, fail-safe gagne toujours. Les issues d'évacuation se déverrouillent ; en revanche, un équipement réseau échoue fermé, et un logiciel qui plante ne doit jamais retomber en mode « tout autorisé » ni exposer ses erreurs de debug à l'utilisateur.

Zero trust — et son ancêtre

Le modèle périmétrique classique (« trust but verify ») faisait confiance à tout ce qui était dedans — il meurt avec le cloud, le télétravail et les mouvements latéraux des attaquants. Le zero trust (NIST SP 800-207) le remplace : never trust, always verify. Concrètement : aucune confiance implicite liée à la localisation réseau ; chaque requête est authentifiée, autorisée et chiffrée ; les décisions d'accès sont dynamiques (identité, appareil, contexte, comportement) ; on assume breach et on limite le rayon d'explosion par la micro-segmentation (détaillée au chapitre 11).

Privacy by design — les 7 principes de Cavoukian

  1. Proactif, pas réactif — prévenir, non corriger.
  2. La vie privée par défaut — aucun réglage à activer : c'est l'état initial.
  3. Intégrée à la conception — pas un module ajouté après coup.
  4. Fonctionnalité totale — somme positive : vie privée et service, pas l'un contre l'autre.
  5. Sécurité de bout en bout — sur tout le cycle de vie de la donnée.
  6. Visibilité et transparence — pratiques vérifiables par tous.
  7. Respect de l'utilisateur — l'individu au centre, par défaut.

Responsabilité partagée et SASE

Dans le cloud, la sécurité se partage selon le modèle de service — mais deux invariants encadrent tout : le client reste toujours responsable de ses données et de la gestion des accès ; le fournisseur l'est toujours du physique.

CoucheIaaSPaaSSaaS
Données & accèsClientClientClient
ApplicationClientClientFournisseur
Runtime / middlewareClientFournisseurFournisseur
OSClientFournisseurFournisseur
Virtualisation, réseau, matériel, physiqueFournisseurFournisseurFournisseur

SASE (Secure Access Service Edge) tire les conséquences du zero trust et du cloud : il fait converger le réseau (SD-WAN) et une pile de sécurité servie depuis le cloud — Secure Web Gateway, CASB (chapitre 5), Zero Trust Network Access, firewall as a service — au plus près de l'utilisateur, où qu'il soit. Le mot déclencheur en question : « effectifs distribués, sécurité homogène sans rapatrier le trafic au siège ».

Objectif 3.2Les modèles de sécurité

Un modèle de sécurité formalise mathématiquement une politique pour qu'un système puisse la faire respecter. Quatre briques théoriques d'abord :

Bell-LaPadula — la confidentialité

Né pour le secret militaire, appliqué en MAC multiniveau. Ses règles :

PropriétéRègleLecture
Simple Security PropertyNo read upUn sujet Secret ne lit pas du Top Secret
★ (Star) PropertyNo write downUn sujet Top Secret n'écrit pas dans un document Secret — il y divulguerait du haut niveau
Strong ★ PropertyLire et écrire uniquement à son niveauVersion stricte de la précédente
Discretionary (ds) PropertyMatrice d'accès en complémentLe besoin d'en connaître s'ajoute aux niveaux
TranquilityLes étiquettes ne changent pas pendant l'usagePas de reclassification à chaud

Limites testables : BLP ignore l'intégrité et la disponibilité, et ne traite pas les canaux cachés.

Biba — l'intégrité, en miroir

Biba inverse BLP pour protéger la vérité plutôt que le secret : simple integrity = no read down (ne pas lire une source moins fiable — on ne fonde pas une décision sur des données douteuses) et ★ integrity = no write up (une source peu fiable ne contamine pas un référentiel plus fiable). Premier objectif d'intégrité couvert : empêcher les modifications non autorisées.

🧠 Mnémoniques — BLP et Biba

« Simple rime avec lire ; l'étoile écrit. » Dans les deux modèles, la propriété simple régit la lecture, la propriété régit l'écriture. Puis le sens : BLP garde le secret (on ne lit pas au-dessus, on n'écrit pas en dessous) ; Biba garde la vérité (on ne lit pas en dessous, on n'écrit pas au-dessus) — Biba est le miroir exact de BLP.

Clark-Wilson — l'intégrité commerciale

Le monde bancaire ne raisonne pas en étiquettes mais en transactions bien formées. Clark-Wilson interdit tout accès direct aux données : le sujet ne manipule un CDI (constrained data item — la donnée protégée) qu'à travers un TP (transformation procedure — la transaction validée), et un IVP (integrity verification procedure) vérifie périodiquement la cohérence des CDI. Les données non protégées sont des UDI. Le contrôle s'exprime en triple d'accès : sujet — TP — objet, avec séparation des tâches entre ceux qui certifient les TP et ceux qui les exécutent. Il couvre les trois objectifs d'intégrité : bloquer les modifications non autorisées, préserver la cohérence interne et externe, et empêcher les modifications impropres par des utilisateurs autorisés.

Brewer-Nash — la muraille de Chine

Conçu pour les cabinets de conseil et d'audit : empêcher les conflits d'intérêts. Sa signature : les droits évoluent dynamiquement selon l'historique — dès qu'un analyste accède aux données de la banque A, les données des banques concurrentes lui deviennent inaccessibles. Tout scénario « les permissions changent selon ce que l'utilisateur a déjà consulté » pointe ici.

Les modèles de gestion des droits

ModèleApportMot déclencheur
Graham-Denning8 règles de manipulation sûre : créer/supprimer sujet et objet, fournir les droits read, grant, delete, transfer« Comment créer et administrer sûrement sujets, objets et droits »
Harrison-Ruzzo-Ullman (HRU)Étend Graham-Denning : matrice d'accès, droits génériques, commandes — pose la question de la sûreté de l'attribution des droits« Intégrité des droits d'accès », édition de droits par commandes
Take-GrantGraphe orienté ; quatre règles : take, grant, create, remove — comment les droits peuvent se propager« Propagation des droits entre sujets »

Objectif 3.3Common Criteria et autorisation des systèmes

Common Criteria (ISO/IEC 15408)

Le cadre international d'évaluation des produits de sécurité, héritier du TCSEC américain (« Orange Book », confidentialité seule, échelle D→A1) et de l'ITSEC européen (qui couvrait déjà C-I-A et séparait fonction et assurance). Son vocabulaire exact :

NiveauIntitulé officielRepère
EAL1Functionally testedAssurance minimale
EAL2Structurally testedBonnes pratiques de développement
EAL3Methodically tested and checkedConception examinée
EAL4Methodically designed, tested, and reviewedLe plus haut niveau économiquement viable pour un produit existant
EAL5Semiformally designed and testedConception semi-formelle
EAL6Semiformally verified design and testedHauts risques ciblés
EAL7Formally verified design and testedPreuve formelle — rarissime

Nuance décisive : un EAL élevé mesure la rigueur de l'évaluation, pas la sécurité intrinsèque du produit — un produit EAL2 au périmètre bien choisi peut mieux servir qu'un EAL5 mal déployé.

Autoriser un système : certification et accréditation

Dans le vocabulaire RMF (chapitre 3, étape Authorize) : la certification est l'évaluation technique des contrôles d'un système dans son environnement ; l'accréditation est la décision managériale formelle d'accepter le risque résiduel et d'autoriser l'exploitation. L'Authorizing Official délivre :

Objectif 3.4Capacités de sécurité des systèmes

Racines matérielles : TPM et HSM

CritèreTPMHSM
FormePuce soudée à la carte mèreBoîtier ou carte dédiés, souvent amovibles/réseau
UsageMachine locale : clés de disque (BitLocker), attestation de démarrageVolumes industriels : PKI, paiement, signatures — tamper-resistant
Concepts clésPCR (registres de mesure du boot), binding (chiffrer pour ce TPM), sealing (chiffrer pour ce TPM dans cet état de PCR)Génération, garde et usage des clés sans qu'elles sortent du module

Deux démarrages protégés à distinguer : secure boot (l'UEFI refuse d'exécuter tout composant non signé) et measured boot (chaque étape est mesurée dans les PCR du TPM pour attestation — on n'empêche pas, on prouve). Sealing + measured boot : le disque ne se déchiffre que si la chaîne de démarrage est intègre.

Protéger la mémoire et l'exécution

⚠️ Pièges d'examen
  • BLP : l'étoile (★) concerne l'écriture. « No write down » empêche la fuite vers le bas — pas la corruption.
  • Biba est le miroir exact de BLP et ne protège que l'intégrité : si le scénario parle de fiabilité des données, oubliez BLP.
  • Clark-Wilson ne se fonde pas sur des étiquettes : transactions bien formées + triple + SoD. « Accès uniquement via une application validée » = Clark-Wilson.
  • Brewer-Nash est le seul modèle dynamique : les droits dépendent de l'historique d'accès.
  • EAL élevé = évaluation plus rigoureuse, pas produit « plus sûr » ; EAL4 = plafond économique du rétrofit ; EAL7 = preuve formelle.
  • PP = demande du client ; ST = promesse du vendeur. Les distracteurs les inversent.
  • Certification = technique ; accréditation = décision du management (ATO). Réflexe chapitre 1 : le management décide.
  • Porte sécurisée en cas d'incendie : fail-safe (déverrouillée) — la vie d'abord ; le firewall, lui, échoue fermé.
  • Binding lie au TPM ; sealing lie au TPM et à l'état des PCR. Secure boot bloque ; measured boot mesure et atteste.
Scénario fil rouge — Awa

L'architecture de la nouvelle plateforme de paiement se dessine. Awa pose le zero trust en principe directeur — l'acquisition a fait exploser le périmètre, et les commerciaux nomades passeront par un SASE (ZTNA + SWG + le CASB du chapitre 5) plutôt que par le VPN historique. La revue incendie du bâtiment tranche un vieux débat : les portes des salles serveurs passent en fail-safe — la vie d'abord — compensées par caméras et alarmes ; le firewall de cœur, lui, reste fail-closed. Les clés de paiement quittent les serveurs pour un HSM certifié — PCI l'exige et le volume de signatures aussi ; les portables, eux, s'appuient sur leur TPM : BitLocker scellé aux PCR, le disque ne s'ouvre que si le boot est intègre. Dans l'appel d'offres firewall, Awa demande une évaluation Common Criteria EAL4+ et lit le Security Target de chaque candidat pour vérifier que le périmètre évalué correspond à l'usage prévu. Et avant le go-live, elle institue une mini-accréditation interne : l'équipe certifie techniquement, le COMEX signe l'autorisation d'exploiter — chacun son rôle, comme au chapitre 1.


Quiz25 questions

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

Question 1

During a power failure, how should the emergency exit doors of an occupied data center behave?

  1. Remain locked to protect the servers
  2. Unlock (fail-safe) so personnel can evacuate
  3. Lock from the outside only
  4. Trigger the gas suppression system
Voir la réponse Réponse : B

Des personnes sont présentes : fail-safe, les portes se déverrouillent — la vie prime sur les actifs (règle n° 1, chapitre 0). A protège les serveurs au prix des personnes ; D est dangereux avec du personnel à l'intérieur.

Question 2

A perimeter firewall suffers a software crash. Which failure behavior is MOST appropriate?

  1. Fail-open, passing all traffic to preserve availability
  2. Fail-closed, blocking traffic until the device recovers
  3. Failover to a rule set that allows all outbound traffic
  4. Display detailed debug errors to remote users
Voir la réponse Réponse : B

Aucune vie n'est en jeu : l'équipement de sécurité échoue fermé. A et C retombent en « tout autorisé » — l'anti-modèle du fail securely ; D expose de l'information de debug, autre violation du principe.

Question 3

Which statement BEST captures the core principle of zero trust architecture?

  1. Users on the internal network are trusted by default
  2. Every access request is verified, regardless of network location
  3. A strong perimeter eliminates the need for internal controls
  4. Trust is granted permanently after the first authentication
Voir la réponse Réponse : B

Never trust, always verify : chaque requête est vérifiée, la localisation ne confère rien. A et C décrivent le modèle périmétrique que le zero trust remplace ; D contredit la vérification continue.

Question 4

Which description BEST defines Secure Access Service Edge (SASE)?

  1. A hardware firewall installed at headquarters
  2. The convergence of SD-WAN and cloud-delivered security services (SWG, CASB, ZTNA, FWaaS) close to the user
  3. A backup solution for branch offices
  4. An on-premises identity server
Voir la réponse Réponse : B

SASE = convergence réseau (SD-WAN) + sécurité cloud (SWG, CASB, ZTNA, FWaaS) livrée au plus près de l'utilisateur. Les autres options décrivent des composants isolés ou hors sujet.

Question 5

A new application enables the most privacy-protective settings automatically, without any user action. Which privacy-by-design principle does this illustrate?

  1. Privacy as the default setting
  2. Visibility and transparency
  3. Full functionality
  4. Reactive remediation
Voir la réponse Réponse : A

Le réglage le plus protecteur sans action de l'utilisateur = « privacy as the default », deuxième principe de Cavoukian. La transparence (B) concerne la vérifiabilité ; la somme positive (C) la non-opposition vie privée/service.

Question 6

Under the shared responsibility model for a SaaS application, which responsibilities ALWAYS remain with the customer?

  1. Patching the application code
  2. Securing the physical data centers
  3. Protecting its data and managing user access
  4. Maintaining the hypervisor
Voir la réponse Réponse : C

Invariant du modèle partagé : données et gestion des accès restent au client, quel que soit le modèle de service. Le code applicatif (A), le physique (B) et l'hyperviseur (D) sont au fournisseur en SaaS.

Question 7

In the Bell-LaPadula model, what does the simple security property state?

  1. A subject cannot read information at a higher classification level
  2. A subject cannot write to a lower classification level
  3. A subject cannot read information at a lower integrity level
  4. Labels may change during use
Voir la réponse Réponse : A

Simple security property = no read up — « simple rime avec lire ». B est la propriété ★ ; C vient de Biba ; D contredit la tranquility.

Question 8

In Bell-LaPadula, what does the star (★) property state?

  1. No read up
  2. No write down
  3. No read down
  4. No write up
Voir la réponse Réponse : B

★ = écriture : no write down. A est la propriété simple de BLP ; C et D sont les règles de Biba — le miroir.

Question 9

Why does Bell-LaPadula forbid a Top Secret subject from writing into a Secret document?

  1. To prevent corruption of high-quality data
  2. To prevent leaking higher-classified information to lower levels
  3. To enforce separation of duties
  4. To guarantee availability of the document
Voir la réponse Réponse : B

BLP protège le secret : écrire vers le bas transporterait du contenu Top Secret dans un conteneur moins protégé — une fuite. La corruption (A) est le problème de Biba, pas de BLP.

Question 10

In the Biba model, what does the simple integrity property state?

  1. A subject cannot read data at a lower integrity level
  2. A subject cannot read data at a higher classification level
  3. A subject cannot write to a lower integrity level
  4. Subjects may write to any level after authentication
Voir la réponse Réponse : A

Simple integrity = no read down : ne pas fonder ses décisions sur des sources moins fiables (« garbage in »). B est du BLP ; C décrit l'inverse de la règle ★ de Biba (no write up).

Question 11

Which security objective does the Biba model address?

  1. Confidentiality
  2. Integrity
  3. Availability
  4. Nonrepudiation
Voir la réponse Réponse : B

Biba est un modèle d'intégrité — il protège la fiabilité des données, pas leur secret. C'est le premier réflexe à avoir devant tout scénario de modèle : confidentialité → BLP ; intégrité → Biba ou Clark-Wilson.

Question 12

In the Clark-Wilson model, how may a subject modify a constrained data item (CDI)?

  1. Directly, if the subject's clearance is high enough
  2. Only through a transformation procedure (TP), as defined by the access triple
  3. By requesting a label change
  4. Through any application that can open the database
Voir la réponse Réponse : B

Le triple sujet–TP–objet est le cœur de Clark-Wilson : jamais d'accès direct au CDI, uniquement des transactions validées. A applique une logique d'étiquettes étrangère au modèle ; D ouvre la porte aux modifications impropres.

Question 13

What is the role of the integrity verification procedure (IVP) in Clark-Wilson?

  1. Encrypting data at rest
  2. Verifying that constrained data items remain in a valid, consistent state
  3. Managing user passwords
  4. Transferring access rights between subjects
Voir la réponse Réponse : B

L'IVP vérifie périodiquement que les CDI restent dans un état valide et cohérent — le contrôle de santé du modèle. Les autres options n'appartiennent pas au vocabulaire de Clark-Wilson.

Question 14

A consulting firm's system automatically blocks an analyst from accessing Bank B's files after she works on rival Bank A's engagement. Which model is implemented?

  1. Bell-LaPadula
  2. Biba
  3. Brewer-Nash (Chinese Wall)
  4. Graham-Denning
Voir la réponse Réponse : C

Droits modifiés dynamiquement par l'historique d'accès pour prévenir un conflit d'intérêts : signature exacte de Brewer-Nash. BLP et Biba sont statiques ; Graham-Denning administre des droits, il ne les fait pas évoluer selon l'usage.

Question 15

Which model defines eight rules for securely creating and deleting subjects and objects and for providing read, grant, delete, and transfer access rights?

  1. Graham-Denning
  2. Take-Grant
  3. Clark-Wilson
  4. Noninterference
Voir la réponse Réponse : A

Les 8 règles de création/suppression de sujets et objets et de fourniture des droits (read, grant, delete, transfer) définissent Graham-Denning. Take-Grant n'a que 4 opérations (B) ; Clark-Wilson parle transactions (C).

Question 16

Which four operations define the Take-Grant model?

  1. Read, write, execute, delete
  2. Take, grant, create, remove
  3. Certify, enforce, verify, audit
  4. Encrypt, decrypt, sign, hash
Voir la réponse Réponse : B

Take, grant, create, remove — les quatre règles du graphe orienté qui modélise la propagation des droits. Les autres listes relèvent d'autres registres.

Question 17

What is the PRIMARY goal of the noninterference model?

  1. Ensuring actions at a higher security level produce no observable effect at lower levels
  2. Guaranteeing rapid failover between systems
  3. Preventing users from sharing passwords
  4. Enforcing well-formed transactions
Voir la réponse Réponse : A

La noninterférence exige que le niveau haut soit invisible du niveau bas — aucune influence observable, donc pas de canal caché exploitable. D décrit Clark-Wilson.

Question 18

Which mathematical structure underpins mandatory access control by defining upper and lower bounds for information flows?

  1. A lattice
  2. A hash table
  3. A binary tree
  4. A directed acyclic graph of processes
Voir la réponse Réponse : A

Le treillis (lattice) ordonne étiquettes et compartiments avec bornes supérieure et inférieure pour chaque flux — le socle mathématique du MAC. Les autres structures n'ont pas ce rôle.

Question 19

In Common Criteria terms, what is the difference between a protection profile and a security target?

  1. The protection profile states customer security needs; the security target states what the vendor's product claims to provide
  2. The security target is written by the customer; the protection profile by the vendor
  3. They are two names for the same document
  4. The protection profile applies only to hardware
Voir la réponse Réponse : A

PP = « voilà ce que je veux » (client) ; ST = « voilà ce que je fournis » (vendeur). L'évaluation confronte le ST du ToE, éventuellement à un PP. B inverse — le piège standard.

Question 20

A product is evaluated as "methodically designed, tested, and reviewed." Which evaluation assurance level does this correspond to?

  1. EAL2
  2. EAL4
  3. EAL6
  4. EAL7
Voir la réponse Réponse : B

« Methodically designed, tested, and reviewed » est l'intitulé exact d'EAL4 — le plafond économiquement viable pour un produit existant. EAL2 = structurally tested ; EAL6 = semiformally verified ; EAL7 = formally verified.

Question 21

A vendor advertises that its EAL5 firewall is "more secure" than any EAL3 competitor. What is the MOST accurate correction?

  1. The claim is correct; EAL measures product security strength
  2. A higher EAL indicates a more rigorous evaluation, not necessarily a more secure product in a given deployment
  3. EAL5 products are only for military use, so the comparison is invalid
  4. EAL levels apply only to operating systems
Voir la réponse Réponse : B

L'EAL mesure la rigueur de l'évaluation du périmètre déclaré, pas la sécurité absolue du produit déployé. C'est la nuance que le marketing gomme — et que l'examen teste.

Question 22

What distinguishes accreditation from certification?

  1. Accreditation is the technical testing of controls; certification is a management decision
  2. Certification is the technical evaluation; accreditation is management's formal acceptance of residual risk and authorization to operate
  3. They are performed by the same engineer on the same day
  4. Accreditation applies only to cloud systems
Voir la réponse Réponse : B

Certification = évaluation technique ; accréditation = décision formelle du management d'accepter le risque résiduel (ATO). A inverse les deux — distracteur systématique ; et souvenez-vous : les décisions de risque appartiennent au management.

Question 23

A laptop's disk encryption key is released by the TPM only when the boot measurements in the PCRs match the expected values. Which TPM capability is this?

  1. Binding
  2. Sealing
  3. Key escrow
  4. Remote wipe
Voir la réponse Réponse : B

Clé libérée seulement si l'état mesuré (PCR) correspond = sealing. Le binding lie au TPM sans condition d'état ; l'escrow est une garde par tiers (chapitre 8).

Question 24

Which option BEST distinguishes an HSM from a TPM?

  1. An HSM is a chip soldered to every laptop motherboard
  2. An HSM is a dedicated, tamper-resistant module for high-volume key management, often external or networked
  3. A TPM is used exclusively for payment processing
  4. They are identical technologies
Voir la réponse Réponse : B

L'HSM est un module dédié, résistant à l'effraction, dimensionné pour les volumes (PKI, paiement), souvent réseau ou amovible ; le TPM est la puce locale de la carte mère. A décrit le TPM ; C restreint à tort.

Question 25

Which memory protection randomizes the location of the stack, heap, and libraries to defeat exploits that target known addresses?

  1. Data execution prevention
  2. Address space layout randomization
  3. Process isolation
  4. Protection ring 3
Voir la réponse Réponse : B

Randomiser la disposition mémoire = ASLR : l'exploit ne trouve plus ses adresses. DEP (A) rend les données non exécutables — les deux se complètent mais ne se confondent pas.

Auto-diagnostic

≥ 20/25 : passez au chapitre 7. Entre 15 et 19 : récitez les règles BLP/Biba jusqu'à l'automatisme (« simple rime avec lire, l'étoile écrit ») et relisez Common Criteria. < 15 : relisez le chapitre — les modèles formels sont du par-cœur pur, et l'examen ne pardonne pas l'à-peu-près sur les directions read/write.

FicheFiche de révision

À savoir par cœur avant le chapitre 7
  1. Fail-safe = personnes (porte déverrouillée) · fail-secure = actifs (firewall fermé) ; la vie humaine impose fail-safe.
  2. Zero trust (800-207) : never trust always verify, assume breach, micro-segmentation, décision par requête.
  3. SASE = SD-WAN + SWG + CASB + ZTNA + FWaaS, servis du cloud, au plus près de l'utilisateur.
  4. Privacy by design : proactif · défaut · intégré · somme positive · bout en bout · transparent · centré utilisateur.
  5. Responsabilité partagée : client = données + accès, toujours ; fournisseur = physique, toujours ; entre les deux selon IaaS/PaaS/SaaS.
  6. « Simple rime avec lire ; l'étoile écrit. »
  7. BLP (confidentialité) : no read up · no write down · strong ★ = son niveau seulement · tranquility = étiquettes stables.
  8. Biba (intégrité, miroir) : no read down · no write up.
  9. Clark-Wilson : CDI touché uniquement via TP (triple sujet–TP–objet), IVP vérifie, SoD certifie/exécute.
  10. Brewer-Nash : conflits d'intérêts, droits dynamiques selon l'historique.
  11. Graham-Denning : 8 règles ; HRU : matrice et sûreté des droits ; Take-Grant : take, grant, create, remove.
  12. State machine (états sûrs) · information flow (flux entre niveaux) · noninterference (le haut invisible du bas — anti-covert channels) · lattice (bornes, socle du MAC).
  13. Common Criteria (ISO 15408) : ToE · PP (client) · ST (vendeur) ; TCSEC/ITSEC = ancêtres.
  14. EAL : 1 functionally · 2 structurally · 3 methodically tested · 4 methodically designed (plafond économique) · 5 semiformally designed · 6 semiformally verified · 7 formally verified. EAL = rigueur d'évaluation.
  15. Certification (technique) → accréditation (décision management) ; ATO · IATT · DATO · common control.
  16. TPM : PCR, binding (ce TPM), sealing (ce TPM + cet état) ; HSM : module dédié tamper-resistant haut volume.
  17. Secure boot bloque le non-signé ; measured boot mesure et atteste.
  18. Rings : 0 noyau → 3 applications ; ASLR randomise ; DEP/NX rend non exécutable ; constrained interface limite ce qui est visible.