Architecture cyber

Base de connaissance de Jawad Boujnane, Ingénieur cybersécurité GRC

Un seul site, vingt modules courts, trente-deux schémas et des tableaux qui vont droit au but : de quoi tenir une conversation d'architecture, de cloud et de GRC sans réciter un catalogue d'outils. Tout est en français et fonctionne hors ligne.

schémas Archify

chacun validé avant publication

modules de savoir

14 à 26 min chacun

tableaux de référence

filtrables, chiffrés

110

termes au lexique

cherchables d'un Ctrl+K

Parcours conseillé — un module à la fois

01 → 02

Fondations

vocabulaire du risque, principes, réseau et segmentation

03 → 04

Identité et confiance

IAM, MFA, PAM, Zero Trust, accès distant

05 → 09

Cloud et DevSecOps

AWS, pipeline CI/CD, API, Kubernetes, poste et SaaS

10 → 11

Menaces et risque

chaîne d'attaque, threat modelling, priorisation

12 → 13

GRC et conformité

ISO 27001, CSF 2.0, obligations UE, tiers

14 → 17

Défense et données

SOC, détection et CTI, continuité et crise, crypto

18 → 19

Annexes utiles

OT/ICS et sécurité de l'IA

Méthode

revue de design en 10 questions, écart fermé par une preuve

Ctrl+K · tout chercher (modules, tableaux, schémas, lexique)○ · marquer un module comme lu/ · J · K · T · R · raccourcis à une touche (recherche, module suivant/précédent, thème, auto-checks) : à activer ci-dessous

Activer les raccourcis à une touche (/, J, K, T, R) — désactivés par défaut pour ne pas gêner la commande vocale et les lecteurs d'écran

Fondations Débutant 14 min #principes#vocabulaire#arbitrage

Principes d'architecture sécurité

Le vocabulaire du risque et les cinq principes qui tranchent d'avance — avant d'acheter quoi que ce soit.

L'essentiel en 30 secondes

Une architecture se juge à ses arbitrages, pas à son catalogue d'outils : chaque choix a un coût et une dette à assumer.
Six mots à ne jamais confondre : actif, vulnérabilité, menace, risque, contrôle, preuve. La plupart des débats stériles viennent de là.
Cinq principes font 80 % du travail : moindre privilège, défense en profondeur, refus par défaut, séparation des tâches, échec sûr.
La question qui sauve : « quelle preuve le prouve ? » — un contrôle déclaré n'est pas un contrôle testé.

principes permanents

ils tranchent d'avance

question à poser toujours

quelle preuve le prouve ?

8 · 4

plans · piliers transverses

schéma de référence 01

Avant les outils, il y a des distinctions qui tiennent dans le temps. Ce module pose le vocabulaire commun et les principes qui permettent de dire non à une mauvaise idée sans se fâcher avec personne.

🔢 Chiffres 📊 Le vocabulaire qui évite les débats stériles 📊 Cinq principes qui tranchent d'avance 📊 Défense en profondeur : ce que chaque couche absorbe 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Le vocabulaire qui évite les débats stériles

Six termes, une définition opérationnelle, et l'erreur qui coûte cher.

Terme	Définition opérationnelle	Exemple (cloud)	Erreur fréquente
Actif	Ce qui a de la valeur et qu'on protège (donnée, service, compétence, image).	Base Postgres d'un service client	Compter les serveurs et oublier les données et les identités
Vulnérabilité	Faiblesse exploitable : technique, de configuration, de processus ou humaine.	Bucket S3 à policy publique, dépendance non patchée	La réduire à un CVE : la mauvaise configuration domine
Menace	Ce qui peut exploiter la faiblesse (acteur, capacité, intention, opportunité).	Rançongiciel opportuniste, fraude au président	Imaginer un attaquant omniscient et gonfler la sévérité
Risque	Combinaison d'un impact et d'une vraisemblance, dans un contexte donné.	Fuite de données clients via un accès trop large	Traiter le risque brut et jamais le risque résiduel
Contrôle	Ce qui réduit le risque : préventif, détectif ou correctif.	SCP d'organisation, MFA matérielle, sauvegarde immuable	Confondre contrôle et produit acheté
Preuve	Trace datée, attribuable et rejouable qu'un contrôle fonctionne.	Journal de révocation, rapport de restore, ticket d'écart	Prendre une capture d'écran pour la preuve d'un contrôle permanent

Cinq principes qui tranchent d'avance

Quand deux options se valent techniquement, ces principes départagent — et se vérifient.

Principe	Ce que ça veut dire	Ce que ça casse	Signal de vérification
Moindre privilège	Chaque identité a le droit minimum, pour une durée bornée, sur une ressource nommée.	Les droits hérités « au cas où » et les comptes partagés	Combien de rôles ont un `*` dans une politique ? Combien de droits permanents ?
Défense en profondeur	Aucune couche n'est censée suffire : l'attaquant doit en franchir plusieurs.	Le pari sur un produit unique « qui règle tout »	Quelle couche absorbe si la précédente échoue ?
Refus par défaut	Ce qui n'est pas explicitement autorisé est refusé, et le refus est journalisé.	Les flux implicites, l'accès « même réseau »	Le refus apparaît-il dans les journaux avec son motif ?
Séparation des tâches	Celui qui décide, celui qui exécute et celui qui contrôle ne sont pas la même personne.	Le compte administrateur unique, l'auto-approbation en production	Qui peut modifier une politique sans revue ?
Échec sûr	En panne, le système se ferme ou se dégrade proprement — jamais il ne s'ouvre.	Le mode dégradé oublié, l'accès de secours toujours ouvert	Que se passe-t-il si l'annuaire est indisponible ? Le mode dégradé a-t-il été testé ?

Ces principes se traduisent en questions concrètes en revue de design : c'est ce qui les rend opposables.

Défense en profondeur : ce que chaque couche absorbe

Raisonner par couche évite de croire qu'un EDR remplace l'identité faible.

Couche	Ce qu'elle arrête	Ce qu'elle n'arrête pas	Contrôle de secours
Identité et accès	Vol de mot de passe, accès depuis un poste non conforme, élévation	Session déjà ouverte, jeton volé, identité de service	Détection d'abus d'identité, durée de session courte, révocation rapide
Poste et endpoint	Exécution malveillante, rançongiciel, mouvement latéral depuis le poste	Attaque directe sur une API exposée, compromission d'un compte cloud	EDR managé, durcissement, inventaire des logiciels, restauration
Réseau et segmentation	Mouvement latéral, exfiltration, accès aux interfaces d'administration	Trafic chiffré autorisé, hameçonnage, fuite par un SaaS approuvé	Filtrage sortant, DNS filtré, détection réseau, cloisonnement par zone
Application et code	Injection, logique métier détournée, dépendance vulnérable	Abus légitime de fonctionnalité, erreur de configuration	Revue de code, SAST/SCA, tests, limitation de débit, journalisation applicative
Données et cryptographie	Lecture après vol de support ou d'instantané, altération silencieuse	Clé compromise, données exfiltrées avec des droits légitimes	KMS/HSM, séparation des clés, rotation, DLP, classification
Journalisation et sauvegarde	Effacement des traces, extension des privilèges non détectée	Attaque pendant la fenêtre de rétention, sauvegarde corrompue non testée	Journalisation immuable, horodatage, restauration testée, comptes dédiés

Vue d'ensemble — 8 plans de contrôle et 4 piliers à regarder : l'ordre des plans et le rayon d'impact Plein écran

À retenir

Un contrôle qui n'a pas de propriétaire nommé n'existe pas : il redeviendra une intention.
Le rayon d'impact se mesure, il ne se suppose pas : « et si cette brique tombe, qu'est-ce qui tombe avec elle ? »
Un refus journalisé est un signal de détection, pas un échec — c'est ce que produit le refus par défaut.
Dire « je ne sais pas encore, voici comment je tranche » est une position d'ingénieur, pas une faiblesse.

Pièges classiques

Raisonner en catalogue de produits : on ne conçoit plus, on choisit.
Confondre contrôle préventif et contrôle détectif, puis promettre une prévention là où on a posé une détection.
Traiter le vocabulaire comme de la sémantique : en réunion, un mot mal employé coûte une décision.
Oublier de nommer le hors-périmètre : ce qu'on exclut protège autant que ce qu'on inclut.

Auto-check — 3 questions pour vérifier que c'est acquis

Un bucket de stockage exposé publiquement : vulnérabilité ou menace ?
Vulnérabilité (faiblesse exploitable). La menace est l'acteur qui la trouve et l'exploite ; le risque est la combinaison impact × vraisemblance dans le contexte considéré.
Quelle différence entre contrôle déclaré et contrôle testé ?
Déclaré : documenté dans une politique ou un schéma. Testé : exécuté et tracé (date, opérateur, résultat). Un auditeur ne paie qu'avec le second.
Que vérifier systématiquement quand une couche est présentée comme « suffisante » ?
Quelle couche absorbe l'échec de celle-ci. Aucune couche n'est suffisante seule : c'est le principe de défense en profondeur.

Fondations Débutant 18 min #réseau#zones#ZTNA#SASE

Réseau, zones et segmentation

Le périmètre n'est plus un mur : c'est un ensemble de zones, de flux déclarés et de décisions journalisées.

L'essentiel en 30 secondes

Aucun flux n'existe par défaut : chaque flèche d'un schéma réseau correspond à une règle déclarée, possédée par quelqu'un, et dont le refus est journalisé.
Cinq zones de confiance (z0 bordure exposée → z4 administration) suffisent à raisonner tout un SI, cloud compris.
Trois familles d'accès à ne plus confondre : VPN (on entre dans un réseau), ZTNA (on atteint une application), SASE/SSE (la sécurité devient un service cloud).
Segmenter sans avoir observé les flux réels produit des exceptions : la micro-segmentation vient après 30 jours d'observation.

z0 → z4

5 zones de confiance

bordure → administration

30 jours

d'observation avant de segmenter

sinon on conçoit des exceptions

4 champs

minimum par flux déclaré

besoin · propriétaire · service/port · test

Le réseau reste la grammaire de base : on ne peut pas discuter d'architecture cloud sans savoir ce qu'est un flux, une zone et une frontière. Ce module donne la grille de lecture que le cloud réutilise telle quelle (VPC, security groups, points de terminaison).

🔢 Chiffres 📊 Les 4 notions réseau à maîtriser avant tout débat 📊 Cinq zones de confiance et ce qu'on y met 📊 VPN, ZTNA, SASE : ne plus confondre 📊 Ce qui doit figurer dans une matrice de flux 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Les 4 notions réseau à maîtriser avant tout débat

Ce qui revient systématiquement dans une conversation technique, même en full cloud.

Notion	Ce qu'il faut savoir	Pourquoi c'est un sujet de sécurité
Adressage et CIDR	Une plage s'écrit `10.20.0.0/16` : 16 bits fixes, le reste variable. On découpe en sous-réseaux par usage, pas par étage.	Un chevauchement de plages entre deux réseaux interdit tout routage propre et force des contournements.
DNS	Résolution de noms : c'est le premier service appelé et le plus souvent oublié dans l'inventaire.	Qui contrôle le DNS contrôle la destination : DNS filtré, enregistrements surveillés, DNSSEC côté zones publiques.
Flux et ports	Un flux = source + destination + protocole + port + sens + authentification.	Une règle `any/any` interne annule la segmentation : il faut nommer le service et le port.
Chiffrement TLS	TLS 1.3 en standard ; le certificat prouve l'identité du serveur ; mTLS ajoute celle du client.	Un flux interne non chiffré est lisible par un attaquant déjà présent : chiffrer ne remplace pas segmenter, mais limite.

Cinq zones de confiance et ce qu'on y met

Une zone n'est pas un VLAN : c'est un niveau de confiance, avec un contrôle imposé et un propriétaire.

Zone	Ce qu'elle contient	Contrôle imposé	Piège classique
z0 · Bordure exposée	Points d'entrée Internet : répartiteurs, pare-feu, passerelles applicatives	Filtrage, limitation de débit, journalisation complète, correctifs rapides	Y laisser une interface d'administration joignable depuis Internet
z1 · DMZ et services d'exposition	Reverse proxies, serveurs de rebond, collecteurs de fichiers	Zone sacrifiable par conception : aucune donnée de production, aucun accès direct au cœur	Utiliser la DMZ comme zone de transit vers la production
z2 · Applications et API	Services métier, API, ordonnanceurs, files de messages	Politique applicative nommée : qui appelle quoi, avec quelle authentification	Ouvrir les flux « pour que ça marche » sans propriétaire nommé
z3 · Données et journaux	Bases, entrepôts, stockage objet, journaux, sauvegardes	Aucun accès direct depuis les postes ; chiffrement ; immuabilité des journaux et sauvegardes	Laisser un compte applicatif écrire dans les journaux qu'il produit
z4 · Administration et supervision	Bastions, consoles cloud, outils de supervision, coffre de secrets	MFA matérielle, poste dédié, élévation à la demande, session enregistrée	Confondre zone d'administration et zone applicative — c'est le rang 0, il administre tout le reste

La z4 est la plus critique : qui la compromet n'a plus besoin d'exploiter une faille applicative.

VPN, ZTNA, SASE : ne plus confondre

Trois réponses à trois questions différentes — les mélanger, c'est promettre ce qu'on ne livre pas.

Solution	Ce qu'elle donne accès	Où se prend la décision	Ce qu'elle ne règle pas
VPN	Un réseau : une fois connecté, on atteint tout ce que le routage autorise.	Au point d'entrée, une fois pour toutes : l'identité est vérifiée à la connexion.	Le mouvement latéral dans le réseau, la visibilité applicative, l'accès des prestataires non maîtrisés.
ZTNA	Une application précise, jamais un réseau.	À chaque requête : identité + contexte + posture, la décision est rejouée.	Le trafic SaaS direct qui ne passe pas par le tunnel, ni la donnée déjà copiée par un utilisateur légitime.
SASE / SSE	Un plan de contrôle cloud unifié : web, SaaS, applications privées, avec politique unique.	Dans le nuage de sécurité, au plus près de l'utilisateur, quel que soit son lieu.	L'authentification elle-même, et la qualité des politiques : un mauvais réglage reste une mauvaise règle, simplement appliquée partout.

SSE = les fonctions de sécurité du SASE (ZTNA, passerelle web, CASB, filtrage DNS, pare-feu en service). SASE y ajoute la partie réseau (SD-WAN).

Ce qui doit figurer dans une matrice de flux

Une matrice de flux est un document d'ingénierie : six colonnes suffisent à la rendre opposable.

Champ	Pourquoi il est obligatoire	Exemple
Besoin métier	Un flux sans besoin métier écrit est un flux à supprimer : c'est ainsi qu'on ferme une surface.	« Le service de paie consulte l'annuaire pour valider les comptes »
Propriétaire	Une personne, jamais une équipe — sinon personne ne tranche en cas de doute.	Responsable de la plateforme paie (nom, pas service)
Service et port	Nommer le protocole empêche l'ouverture générique « pour que ça marche ».	`HTTPS 443` sortant vers le connecteur d'annuaire
Sens et déclencheur	Un sens unique réduit la surface : le retour est souvent inutile.	Entrant uniquement ; aucun appel retour côté annuaire
Authentification	Sans authentification, le flux est ouvert à qui atteint l'adresse.	mTLS + rôle applicatif dédié
Test de non-accès	C'est la preuve que la segmentation existe vraiment, et pas seulement sur le schéma.	Depuis z2, la base en z3 refuse la connexion — journal à l'appui

Avant toute micro-segmentation : 30 jours d'observation des flux réels. Sans inventaire, on conçoit des exceptions, pas des règles.

Le périmètre distribué — SASE, ZTNA et destinations à regarder : ce qui est réellement protégé, et les deux destinations hors périmètre Plein écran

Segmentation interne — z0 → z4 et contrôles par zone à regarder : la zone 4 (administration), la plus critique Plein écran

À retenir

Un flux se décrit par son besoin, son propriétaire, son service et son test de non-accès — pas par une plage IP.
La zone d'administration est le rang 0 : elle administre tout le reste, donc elle ne partage rien avec le reste.
Le refus journalisé est une preuve de segmentation : sans journal, la segmentation reste une intention.
En cloud, la même logique s'applique : VPC, sous-réseaux, groupes de sécurité, points de terminaison et politiques de ressources.

Pièges classiques

Segmenter avant d'avoir inventorié les flux : six mois plus tard, les exceptions ont reconstruit un réseau plat.
Oublier les flux de gestion (supervision, sauvegarde, correctifs, horodatage) — première cause d'ouvertures sauvages.
Confondre zone de confiance et VLAN : un VLAN est une découpe technique, une zone est un niveau de confiance avec ses règles.
Croire qu'un tunnel chiffré protège du mouvement latéral une fois dedans.

Auto-check — 3 questions pour vérifier que c'est acquis

Un nouveau fournisseur demande un accès « au réseau interne » pour sa supervision. Que lui répondre ?
On ne donne pas un réseau : on expose une application ou une API précise, avec authentification, depuis une zone dédiée, avec journalisation, et un test de non-accès. Le besoin métier et le propriétaire doivent être écrits.
Pourquoi la micro-segmentation arrive-t-elle après 30 jours d'observation ?
Parce que les flux réels diffèrent presque toujours des flux documentés. Sans inventaire, on conçoit des règles à l'aveugle et on multiplie les exceptions ouvertes.
Un utilisateur se plaint : « le VPN marche, mais pas l'application ». Où regarder d'abord ?
À la décision d'accès applicative (ZTNA / politique), pas au tunnel réseau : le tunnel prouve seulement que l'utilisateur atteint le point d'entrée.

Identité et confiance Intermédiaire 22 min #IAM#MFA#PAM#AWS

Identité, IAM et authentification

Quatre populations, cinq familles de politiques : l'identité est devenue le périmètre, et la preuve se lit dans les journaux.

L'essentiel en 30 secondes

Quatre populations, quatre exigences : humains, administrateurs, charges de travail, agents IA. Aucune ne se protège comme les autres.
En cloud, tout se joue sur des politiques : identité, ressource, garde-fou d'organisation, plafond, session. C'est leur intersection qui autorise, et un refus explicite gagne toujours.
Seule la MFA résistante au hameçonnage (FIDO2, passkey) tient face à un site de capture : le code à usage unique se relaie en temps réel.
Un secret qui ne tourne jamais est un secret qui finit par fuir : fédération OIDC et rôles temporaires plutôt que clés d'accès longue durée.

populations d'identité

humains, admin, charges, agents

familles de politiques AWS à connaître d'abord

identité, ressource, SCP, borne, session (+ RCP)

< 15 min

pour révoquer un accès

objectif mesurable, pas une intention

L'identité est le nouveau périmètre : l'attaquant n'a plus besoin d'entrer dans un réseau, il a besoin d'un compte. Ce module couvre les quatre populations, la mécanique réelle des politiques cloud et le cycle de vie d'un accès.

🔢 Chiffres 📊 Quatre populations, quatre exigences 📊 MFA : ce qui protège vraiment 📊 Les cinq familles de politiques AWS à connaître d'abord 📊 Cycle de vie d'une identité en cinq temps 🧩 Schémas (3)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Quatre populations, quatre exigences

Même exigence de fond (identité, portée, journal) mais des moyens très différents.

Population	Ce qui la protège	Ce qui la casse	Preuve attendue
Collaborateurs	SSO, MFA résistante au hameçonnage, accès conditionnel par contexte	Mot de passe réutilisé, session ouverte, appareil non conforme	Taux d'adoption MFA matérielle, liste des exceptions et leur échéance
Administrateurs	Comptes nominatifs, coffre de secrets, élévation à la demande (JIT), session enregistrée	Compte partagé, droits permanents, poste non dédié	Journal d'élévation, durée moyenne de privilège, revue des comptes à privilèges
Charges de travail	Identité fédérée (rôle, mTLS, SPIFFE), portée minimale, expiration courte	Clé d'accès dans une variable d'environnement, secret dans le code	Inventaire des identités non humaines, âge des secrets, rotation constatée
Agents IA	Identité propre, outils en liste blanche, plafonds quantitatifs, validation humaine	Accès direct aux données et aux outils, absence de journal exploitable	Journal des actions d'agent, tests adverses, procédure d'arrêt d'urgence testée

Une identité non humaine n'a pas de MFA : sa protection, c'est sa portée et sa durée de vie.

MFA : ce qui protège vraiment

Toutes les multifacteurs ne se valent pas face à la même attaque.

Méthode	Résiste au hameçonnage	Ce qu'elle arrête	Ce qu'elle n'arrête pas
SMS ou appel	❌ Non	L'attaque par mot de passe seul, partiellement	La lecture du code relayée en direct, la fraude à la carte SIM
Code à usage unique (TOTP)	❌ Non	Le rejeu ultérieur du mot de passe	La capture en temps réel par un proxy inverse : l'attaquant saisit le code avec la victime
Notification push chiffrée (avec numéro)	⚠️ Partiellement	La plupart des hameçonnages automatiques	La fatigue de notification (spam de validation) : elle se traite par politique, pas par l'utilisateur
FIDO2 / passkey (facteur matériel)	✅ Oui	Le hameçonnage, la reprise de session, la fatigue de notification	Rien de tout cela — le reste du travail porte sur les sessions et les jetons : durée courte, liaison à l'appareil, révocation

Un facteur lié à l'origine du site ne peut pas être rejoué sur un site cloné : c'est la seule barrière qui tienne face au proxy inverse.

Les cinq familles de politiques AWS à connaître d'abord

La question n'est pas « qui a le droit ? » mais « quelle intersection autorise ? ».

Vérifié le 26/09/2026

Famille	Ce qu'elle fait	Ce qu'elle ne fait pas	Où elle vit
Politique d'identité	Autorise des actions sur des ressources pour un principal (utilisateur, rôle, groupe).	N'annule jamais un refus explicite posé ailleurs.	Attachée au principal (ou à son groupe)
Politique de ressource	Décrit qui peut accéder à l'objet : seau, clé, file, fonction.	Ne suffit pas seule pour un appel entre deux comptes : les deux côtés doivent autoriser.	Sur la ressource elle-même
Garde-fou d'organisation (SCP)	Plafonne ce que le compte peut faire, y compris son compte racine.	N'accorde jamais de droit : c'est un plafond, pas une permission.	À la racine de l'organisation ou sur une unité
Limite de permissions	Fixe un plafond attaché à un principal précis (délégation encadrée).	N'accorde aucun droit par elle-même : elle réduit.	Attachée à l'utilisateur ou au rôle
Politique de session	Réduit encore la portée le temps d'une session fédérée ou d'un rôle assumé.	Ne survit pas à la session : tout redevient normal au prochain appel d'identifiants.	Fournie au moment de l'obtention des identifiants

Règle simple à retenir : un refus explicite l'emporte ; sinon il faut un « autoriser » explicite ; sans autorisation, c'est un refus implicite — et tout cela finit dans le journal. La documentation AWS recense neuf types au total : s'y ajoutent les RCP (plafond d'organisation côté ressources, depuis 2024), les politiques de point de terminaison VPC, les ACL et les partages RAM.

Cycle de vie d'une identité en cinq temps

C'est là que se perdent les droits : pas à l'ouverture, au changement et au départ.

Étape	Ce qu'on vérifie	Ce qui est souvent oublié
Arrivée (joiner)	Qui approuve, quels rôles par défaut, quel appareil, quelle MFA ?	Les rôles « par défaut » trop larges que personne ne revoit jamais
Mutation (mover)	Les anciens droits sont-ils retirés quand la fonction change ?	L'accumulation : on ajoute des droits, on n'en retire pas
Départ (leaver)	Révocation en heures — sessions, jetons et secrets d'application inclus.	Les jetons déjà émis, les secrets d'application, les comptes de service créés à la main
Revue périodique	Qui a accès à quoi, avec quelle justification écrite ?	La revue validée en bloc sans regarder : elle produit une signature, pas une preuve
Révocation d'urgence	Procédure testée, périmètre connu, délai mesuré et publié.	Le test : on découvre que la révocation prend trois jours — ou qu'elle ne marche pas sur les jetons

Un objectif de révocation (« moins de 15 minutes ») se mesure lors d'un exercice, pas dans une politique.

Identité et accès — quatre populations, six décisions à regarder : ce qui distingue une charge de travail d'un humain Plein écran

AWS IAM — comment une requête est réellement évaluée à regarder : le refus explicite d'abord, puis l'intersection des plafonds Plein écran

Fédération OIDC — déployer sans secret statique à regarder : l'anti-pattern de la clé statique, en bas du schéma Plein écran

À retenir

Le périmètre d'un accès, c'est sa portée et sa durée : un droit permanent est un droit trop large.
Une MFA résistante au hameçonnage est un facteur lié à l'origine, pas un code recopié.
La fédération d'identité remplace la clé statique : plus rien à stocker, tout devient attribuable à une session.
Les identités non humaines se gèrent comme un parc : inventaire, portée, expiration, revue.

Pièges classiques

Croire que la MFA protège une session déjà ouverte ou une identité de service : elle ne fait ni l'un ni l'autre.
Créer un compte administrateur d'urgence jamais testé — ou testé sans procédure écrite.
Accepter un wildcard dans une politique parce qu'« on verra plus tard » : il survivra à son auteur.
Confondre authentification (prouver qui on est) et autorisation (ce qu'on peut faire) : la seconde se décide à chaque appel.

Auto-check — 3 questions pour vérifier que c'est acquis

Un développeur demande une clé d'accès AWS pour son pipeline. Que lui proposer ?
Une fédération OIDC vers un rôle temporaire, une politique de confiance restreinte (émetteur, audience, branche) et des permissions bornées. La clé statique est refusée par défaut : elle ne s'attribue ni ne tourne toute seule.
Pourquoi un refus explicite est-il plus sûr qu'une absence d'autorisation ?
Les deux refusent, mais le refus explicite est intentionnel et documenté : il protège même si une politique large est ajoutée plus tard par erreur. L'absence d'autorisation dépend de la configuration du moment.
Que vérifier lors du départ d'un salarié administrateur ?
Le compte et ses rôles, mais aussi : sessions actives, jetons, secrets d'application qu'il détenait, comptes de service créés à la main, accès physiques et de télémaintenance.

Identité et confiance Intermédiaire 16 min #Zero Trust#PEP#PDP#SASE

Zero Trust et accès distant

La confiance ne vient plus d'un lieu : chaque accès est décidé, journalisé, révocable — et la décision est rejouée en cours de session.

L'essentiel en 30 secondes

PDP / PEP : le point d'application (PEP) exécute, le moteur de politique (PDP) décide. Le PEP ne décide jamais, sinon il n'y a plus de politique centrale.
La question n'est plus « d'où vient la requête ? » mais « qui la fait, sur quoi, dans quel état, pour quel besoin ? » — à chaque requête.
Une session ouverte n'est pas un état acquis : la décision se rejoue, et la révocation doit être possible sans attendre l'expiration du jeton.
Le modèle a un coût assumé : le plan de contrôle devient une cible de rang 0 — jamais joignable depuis le plan de données.

temps de la boucle de décision

de l'intention à la surveillance

sources d'information (PIP)

identité, posture, menace, comportement, crypto

100 %

des accès sur décision explicite

l'objectif, mesuré et journalisé

Zero Trust n'est pas un produit à acheter : c'est un modèle de décision. Ce module explique la boucle réelle d'une requête d'accès, ce qu'elle garantit, ce qu'elle ne garantit pas, et pourquoi le plan de contrôle devient la cible numéro un.

🔢 Chiffres 📊 Ce que Zero Trust change — et ce qu'il ne change pas 📊 Les cinq sources d'information de politique 📊 Ce qui casse un déploiement Zero Trust 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Ce que Zero Trust change — et ce qu'il ne change pas

Beaucoup de malentendus coûteux se règlent avec ce tableau.

Sujet	Ce que Zero Trust change	Ce qu'il ne change pas
Le périmètre	Il devient granulaire : une application, une action, une donnée.	Il ne disparaît pas : il se déplace de la position réseau vers l'identité et le contexte.
L'authentification	Elle se poursuit pendant la session (re-vérification, étape supplémentaire sur action sensible).	Elle ne remplace pas l'autorisation : être authentifié ne dit rien de ce qu'on a le droit de faire.
La segmentation	Elle s'appuie sur une politique nommée par service, pas sur un plan d'adressage.	Elle ne rend pas la segmentation réseau inutile : elle la complète, elle ne l'annule pas.
Le poste	Sa posture devient une condition d'accès : correctifs, chiffrement, agent de protection actif.	Il ne dispense pas de l'inventaire : un poste inconnu est une condition qu'on ne peut pas évaluer.
L'exploitation	Le refus devient normal et journalisé : c'est un signal de détection.	Il n'exonère pas du support aux utilisateurs : un modèle qui bloque l'activité sera contourné.

Les cinq sources d'information de politique

Sans ces sources, la décision se réduit à une authentification déguisée.

Source	Ce qu'elle apporte à la décision	Ce qui se passe si elle manque
Identité et cycle de vie	Qui agit, avec quel rôle, dans quel état (actif, sortant, suspendu).	Un compte oublié reste autorisé : c'est le chemin le plus court pour un attaquant.
Posture et inventaire	L'état de l'appareil et de la charge : correctifs, chiffrement, agent actif.	Un poste compromis accède comme un poste sain : la décision perd sa valeur.
Menace et réputation	Indicateurs, campagnes en cours, adresses et domaines signalés.	Aucun ajustement contextuel : pas de durcissement pendant une campagne active.
Comportement et journaux	Historique d'accès, dérive, horaires et volumes inhabituels.	Les accès anormaux ne se distinguent pas des accès normaux.
PKI et attestation	Certificats, facteur matériel, preuve d'intégrité de la machine.	Impossible de distinguer un utilisateur de la copie de son poste.

Une politique se versionne et se relit comme du code : qui l'a changée, quand, pourquoi, et quel test l'a validée.

Ce qui casse un déploiement Zero Trust

Le modèle échoue rarement pour des raisons techniques.

Erreur	Symptôme observable	Parade
Laisser des accès directs « pour ne pas bloquer »	Des ressources joignables hors du point d'application	Inventorier les chemins de contournement, fermer avec une date ou écrire la dette et la faire valider
Décider sans source de posture	La politique retombe sur le seul mot de passe	Brancher d'abord posture, inventaire et PKI : ce sont des sources, pas des accessoires
Bloquer sans expliquer	Contournements, partage de comptes, « VPN parallèle »	Refus motivé, canal de support, mode dégradé borné et journalisé
Oublier la supervision du plan de contrôle	Une compromission du moteur de décision ouvre tous les accès	Plan de contrôle isolé, administration dédiée, journalisation immuable, alertes sur les modifications de politique
Croire que c'est un projet avec une fin	La politique se périme silencieusement	Revue périodique, propriétaire nommé, tests de refus rejoués à chaque évolution

Zero Trust — plan de contrôle et boucle de décision à regarder : PEP, Policy Engine, Policy Administrator et les sources qui informent la décision Plein écran

La boucle de décision en sept temps à regarder : ce qui se passe à chaque requête, et où la décision se rejoue Plein écran

À retenir

Le point d'application ne décide pas : la décision vient d'ailleurs, elle est datée et révocable.
« Même réseau » n'est plus une justification d'accès : c'est une dette de sécurité à écrire.
Le refus journalisé est une valeur ajoutée : il alimente la détection et prouve que la politique vit.
Le plan de contrôle est la cible la plus rentable pour un attaquant : on le traite comme un rang 0.

Pièges classiques

Commencer par l'outil (le point d'application) au lieu de la politique et des sources d'information.
Confondre Zero Trust et « plus de VPN » : c'est un changement de logique de décision, pas de matériel.
Croire qu'un accès refusé est une panne : sans refus, la politique n'est jamais testée en conditions réelles.
Laisser une politique non versionnée : personne ne sait pourquoi une règle existe, ni si elle est encore justifiée.

Auto-check — 3 questions pour vérifier que c'est acquis

Dans le SI, quelle ressource reste joignable sans passer par le point d'application de la décision ?
Toute ressource joignable hors du point d'application est un chemin de contournement : il faut l'inventorier, puis décider de le fermer ou d'assumer la dette par écrit, avec un propriétaire et une échéance.
Pourquoi le refus doit-il être journalisé avec son motif ?
Parce qu'il devient un signal de détection (tentatives anormales) et une preuve que la politique est appliquée. Un refus silencieux ne produit ni sécurité observable, ni matière à investigation.
Quelle est la différence entre le Policy Engine et le Policy Administrator ?
Le Policy Engine évalue la politique et rend une décision ; le Policy Administrator la traduit en instruction concrète vers le point d'application (ouvrir, restreindre, révoquer). Aucun des deux ne voit le flux de données.

Cloud et DevSecOps Intermédiaire 24 min #AWS#CSPM#VPC#KMS

Sécurité cloud — le socle AWS

La responsabilité partagée n'est pas un slogan : elle se lit dans dix briques de socle, et se prouve dans les journaux.

L'essentiel en 30 secondes

Le fournisseur sécurise le cloud (matériel, hyperviseur, disponibilité) ; le client sécurise ce qu'il y met : identités, données, configuration, code et correctifs.
Le socle minimal tient en dix briques : organisation et garde-fous, comptes cloisonnés, IAM, réseau, clés, journaux, détection, stockage verrouillé, inventaire, sauvegarde.
Quatre capacités d'observation à ne pas confondre : CSPM (configuration), CIEM (droits effectifs), CWPP (charges de travail), DSPM (données) — réunies dans un CNAPP.
Trois causes expliquent l'essentiel des incidents cloud : un stockage exposé, un rôle trop large, une clé statique qui ne tourne pas.

briques du socle

de Organizations à la sauvegarde

capacités d'observation

CSPM · CIEM · CWPP · DSPM

compte racine à ne jamais utiliser

MFA matérielle, aucune clé d'accès

Le cloud déplace le travail : on ne durcit plus des serveurs, on écrit des politiques et des garde-fous. Ce module donne le socle AWS minimal, la lecture des droits effectifs et les réglages qui évitent 90 % des incidents.

🔢 Chiffres 📊 Le socle AWS minimal en dix briques 📊 Qui est responsable de quoi (modèle partagé)📊 VPC et stockage : les réglages qui comptent 📊 Les quatre capacités d'observation cloud 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Le socle AWS minimal en dix briques

À connaître par cœur : chaque brique a un rôle et une erreur classique associée.

Brique	Rôle	Erreur classique
Organizations et garde-fous (SCP)	Plafonner ce que chaque compte membre peut faire, y compris sa racine (le compte de gestion n'est pas concerné : on n'y fait tourner aucune charge).	Créer des comptes hors organisation, sans héritage de garde-fous
Comptes cloisonnés	Séparer production, hors production, journal et sécurité : le rayon d'impact devient un compte.	Tout mettre dans un seul compte « pour simplifier »
IAM	Rôles fédérés, conditions, permissions minimales, bornes.	Wildcard sur l'action et la ressource, clés longue durée
Réseau (VPC)	Sous-réseaux, listes de sécurité, points de terminaison, sortie maîtrisée.	Ouvrir `0.0.0.0/0` sur un port d'administration
Clés et chiffrement (KMS)	Chiffrement au repos, clés séparées par usage, rotation.	Une seule clé pour tout, jamais tournée, sans politique restrictive
Journalisation (CloudTrail, Config)	Trace des actions d'API et état de conformité des ressources.	Journal dans le compte de production, modifiable par ses administrateurs
Détection (GuardDuty, Security Hub)	Findings prioritaires et vue consolidée.	Activer sans triage : la file de findings devient un cimetière
Stockage verrouillé (S3)	Blocage public, chiffrement, journalisation, verrouillage d'objet.	Politique de seau permissive laissée par un test oublié
Inventaire et exposition	Savoir ce qui existe et ce qui est joignable depuis Internet.	Découvrir un service exposé lors de l'incident
Sauvegarde et restauration	Instantanés, sauvegardes immuables, restauration testée.	Sauvegarde dans le même compte avec les mêmes droits que la production

AWS Well-Architected (pilier sécurité) et CIS Benchmarks donnent les détails de configuration : ici, on retient la structure.

Qui est responsable de quoi (modèle partagé)

Le curseur se déplace entre IaaS, PaaS et SaaS, mais la colonne de droite ne se délègue jamais.

Couche	Ce que le fournisseur garantit	Ce qui reste au client
Identités et données	Rien sur les données, l'annuaire et les habilitations du client.	Classification, chiffrement, gestion des accès, cycle de vie, sauvegarde
Configuration des services	Il fournit les garde-fous disponibles (plafonds d'organisation, blocage public, options de journalisation).	Les activer, suivre les écarts, corriger — et ne pas laisser les valeurs par défaut en production
Charges de travail	Sécurité du service managé et de son plan de contrôle.	Images, dépendances, systèmes invités, correctifs, droits d'exécution
Réseau	Isolation physique, disponibilité des services réseau managés.	Sous-réseaux, listes de sécurité, exposition, points de terminaison, sortie maîtrisée
Journalisation et détection	Il expose les journaux d'API et des moteurs de détection.	Tout activer, centraliser, protéger (immuable) et exploiter dans un délai utile
Résilience	SLA du service, redondance des zones du fournisseur.	Architecture multi-zone, sauvegardes, plan de reprise, exercices de restauration
Accès physique	Sécurité des centres de données du fournisseur.	Les locaux du client, ses accès de télémaintenance, sa chaîne de sous-traitants

Phrase à retenir pour un comité : « managé » veut dire que le fournisseur opère le service, pas qu'il configure la sécurité à la place du client.

VPC et stockage : les réglages qui comptent

Cinq réglages qu'on retrouve dans presque tous les constats d'audit cloud.

Objet	À retenir	Erreur qui coûte cher
Listes de sécurité (security groups)	Avec état, uniquement des autorisations, attachées à l'interface d'une ressource.	Ouvrir `0.0.0.0/0` sur un port d'administration « temporairement » — le temporaire a une longue vie
Listes de contrôle (NACL)	Sans état, autorisations et refus, appliquées au sous-réseau, évaluées dans l'ordre.	Y loger la logique métier : une NACL ne voit pas l'application
Points de terminaison et sortie	Le trafic vers les services managés passe sans sortir sur Internet ; la sortie est inspectée et journalisée.	Laisser la sortie Internet grande ouverte : l'exfiltration devient invisible
Comptes et rôles par environnement	Un compte par environnement, des rôles par usage, un compte journal séparé.	Partager un rôle entre production et tests, puis s'étonner du rayon d'impact
Stockage objet	Blocage public, chiffrement par défaut, journalisation des accès, verrouillage d'objet.	Un seau de test resté public qui contient des journaux ou des extraits de base

Les quatre capacités d'observation cloud

Quatre questions différentes — la confusion vient du vocabulaire des éditeurs.

Capacité	La question à laquelle elle répond	Exemples natifs	Piège
CSPM — posture de configuration	La configuration est-elle conforme aux règles que je me suis fixées ?	Config, Security Hub, évaluations de conformité	Corriger à la main ce qui devrait l'être par infrastructure-as-code
CIEM — droits effectifs	Qui peut réellement faire quoi, et par quel chemin d'escalade ?	Analyseur d'accès IAM, inventaire des rôles	Lire seulement les politiques attachées et ignorer les chemins hérités
CWPP — charges de travail	Que font réellement mes conteneurs, fonctions et machines ?	Détection d'exécution, analyse d'images	Protéger les machines et oublier les fonctions et les conteneurs
DSPM — données	Où sont mes données sensibles, et qui peut y accéder ?	Macie, étiquetage de sensibilité	Classer une fois puis ne jamais rafraîchir : la donnée se déplace

Un CNAPP n'est que la réunion de ces quatre vues dans une console corrélée : utile, mais ce sont les décisions de correction qui produisent la sécurité.

Responsabilité partagée et socle de garde-fous à regarder : la colonne client, et les garde-fous qui rendent la frontière vérifiable Plein écran

Posture cloud et applicative — quatre capacités d'observation à regarder : observer sans appliquer ne produit que des rapports Plein écran

À retenir

Le compte est la frontière de sécurité en cloud : les garde-fous hérités de l'organisation s'appliquent à tous les comptes membres, racine incluse — le compte de gestion, lui, y échappe et reste vide de charges.
Le compte racine ne s'utilise jamais au quotidien : MFA matérielle, aucune clé d'accès, alerte sur toute connexion.
Tout ce qui est exposé doit être connu et inventorié : ce qui n'est pas vu sera trouvé d'abord par l'attaquant.
La correction se fait par le code (infrastructure-as-code) : sinon l'écart revient à la prochaine livraison.

Pièges classiques

Croire que « managé » signifie « sécurisé » : la configuration reste la responsabilité du client.
Activer la détection sans triage : la file de findings devient un cimetière et l'équipe cesse de regarder.
Journaliser dans le compte de production : celui qui attaque peut effacer ses traces.
Sauvegarder dans le même compte avec les mêmes droits : l'attaquant supprime la production et ses sauvegardes d'un coup.

Auto-check — 3 questions pour vérifier que c'est acquis

Affirmation entendue en comité : « le stockage est chiffré par défaut, donc les données sont protégées ». Que répondre ?
Le chiffrement par défaut protège contre l'accès au support, pas contre un accès légitime mal encadré : qui a la permission de lecture peut lire. Ce sont les politiques d'accès, le blocage public et la journalisation qui protègent réellement.
Un audit relève un rôle avec un wildcard sur toutes les actions. Quelle est la première question à poser ?
Qui l'utilise réellement et pour quoi (droits effectifs, journaux d'usage) — puis remplacer par des actions nommées, ou justifier par écrit l'exception avec une échéance. Un wildcard non justifié est un incident en attente.
Pourquoi séparer le compte de journalisation des comptes de production ?
Pour que la compromission d'un compte de production ne permette pas de modifier ou d'effacer les preuves. Le journal est en écriture seule depuis les autres comptes, avec sa propre administration.

Cloud et DevSecOps Intermédiaire 22 min #Terraform#CI/CD#SAST#SBOM#SLSA

DevSecOps, IaC et chaîne logicielle

Le pipeline possède les droits de déployer : c'est donc lui qu'on protège, et c'est lui qui produit les preuves.

L'essentiel en 30 secondes

Le pipeline est un compte à privilèges : il peut modifier la production. Il se traite comme tel (droits bornés, identité fédérée, journalisation).
Six portes suffisent : revue, secrets et dépendances, analyse statique et IaC, build signé, admission, déploiement fédéré — chacune laisse un artefact.
Terraform : l'état est un secret (il contient des valeurs sensibles), la dérive est un risque, la politique versionnée tranche d'avance.
Une signature jamais vérifiée ne prouve rien : le contrôle doit avoir lieu à l'admission, au moment du déploiement.

portes de contrôle

chacune laisse une preuve datée

familles d'analyse

secrets · SCA · SAST · IaC

secret statique en intégration

identité fédérée à la place

La sécurité applicative ne se joue plus seulement dans le code : elle se joue dans la chaîne qui l'amène en production. Ce module couvre les portes du pipeline, les risques propres à l'infrastructure-as-code et ce qui rend un artefact réellement déployable.

🔢 Chiffres 📊 Les six portes du pipeline 📊 SAST, SCA, IaC, secrets : qui trouve quoi 📊 Terraform : où sont les risques 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Les six portes du pipeline

Une porte bloque, documente ou refuse — mais jamais elle ne « conseille ».

Porte	Ce qu'elle arrête	Preuve laissée
1 · Revue par un pair	Le code livré sans relecture, les modifications de dernière minute	Approbation tracée sur la branche protégée
2 · Secrets et dépendances	Secret committé (même dans l'historique), bibliothèque vulnérable connue	Rapport de détection, décision de rotation ou exception écrite
3 · Analyse statique et IaC	Motifs de code dangereux, configuration d'infrastructure non conforme	Rapport SAST et résultat de politique-as-code
4 · Build reproductible et signé	Artefact non traçable, image gonflée par des outils inutiles	Empreinte, SBOM, attestation de provenance et signature
5 · Admission	Image non signée, base vulnérable, configuration interdite en production	Décision d'admission journalisée (accepté ou refusé, et pourquoi)
6 · Déploiement fédéré	Secret statique partagé, droits de déploiement permanents	Journal d'identité fédérée : rôle, session, heure, artefacts

Une exception non écrite devient la règle de fait : toute dérogation doit être datée, nommée et expirante.

SAST, SCA, IaC, secrets : qui trouve quoi

Un outil ne remplace pas l'autre : chacun voit une classe de problème.

Analyse	Ce qu'elle cherche	Quand elle tourne	Ce qu'elle ne voit pas
Secrets	Clés, jetons et mots de passe dans le code, l'historique et les variables du pipeline.	À chaque commit, et sur tout l'historique	Un secret stocké ailleurs (wiki, ticket, capture) ou déjà révoqué
SCA (dépendances)	Bibliothèques vulnérables connues, versions obsolètes, licences.	À chaque build, et en continu sur la production	Une vulnérabilité non encore publiée, ou un code non atteignable
SAST (code)	Motifs dangereux : injection, cryptographie faible, gestion d'erreur, secret en dur.	Avant le build, en priorité sur le diff	La logique métier détournée et les erreurs de conception
Scan IaC	Configuration non conforme : exposition, absence de chiffrement, droits trop larges.	À la pull request, avant le plan et l'application	L'écart entre la politique écrite et ce qui tourne réellement
DAST (applicatif)	Failles observables à l'exécution : en-têtes, session, injection sur l'application déployée.	Sur un environnement de test, à la demande ou en continu	Les chemins fonctionnels que le scanner ne parcourt pas

Deux règles d'or : un rapport sans propriétaire ni échéance ne produit rien, et un seuil qui bloque doit être écrit avant d'être appliqué.

Terraform : où sont les risques

L'infrastructure-as-code est un programme privilégié : elle mérite la même rigueur qu'un accès administrateur.

Point	Le risque	Bonne pratique
État (state)	Il contient des valeurs sensibles en clair et il est indispensable : le perdre ou le divulguer est grave.	Stockage distant chiffré, versionné, accès restreint, verrouillage contre les exécutions concurrentes
Secrets	Un mot de passe passé en variable se retrouve souvent dans l'état ou les journaux.	Secrets gérés hors du code (coffre), références au lieu de valeurs, rotation après toute exposition
Dérive (drift)	Quelqu'un modifie la production à la main : le code ne décrit plus la réalité.	Détection planifiée de la dérive, correction par le code, exception écrite si la main est inévitable
Modules et versions	Un module tiers non figé peut changer de comportement sans prévenir.	Versions figées, modules revus, sources internes quand c'est possible
Identité du pipeline	Un jeton permanent dans les variables du pipeline ouvre la production à qui le lit.	Rôle fédéré à durée courte, permissions bornées au périmètre déployé
Destruction et remplacement	Un `apply` mal relu peut détruire une ressource à données (base, seau, journal).	Protection contre la suppression sur les ressources sensibles, revue obligatoire des plans destructifs, sauvegarde avant application

Le plan (terraform plan) est une pièce d'audit : il montre exactement ce qui va changer avant que cela change.

DevSecOps — du commit à la production, six portes à regarder : chaque porte laisse un artefact daté Plein écran

Chaîne logicielle — des six portes au contrôle d'admission à regarder : ce qui se passe quand la provenance n'est plus vérifiée Plein écran

À retenir

La sécurité du pipeline, c'est la sécurité de la production : c'est le pipeline qui détient les droits de déployer.
Chaque porte doit produire une preuve exploitable : sans artefact, la porte est une opinion.
L'infrastructure-as-code rend la sécurité reproductible : la même règle s'applique à tous les environnements, automatiquement.
Une dérogation se date et expire : sinon elle devient la nouvelle norme silencieuse.

Pièges classiques

Tout automatiser sans réduire le bruit : quand tout compte, plus rien ne compte et l'équipe ignore les alertes.
Signer les artefacts sans vérifier la signature à l'admission : la garantie reste théorique.
Laisser un jeton de pipeline permanent « le temps de stabiliser » : il ne partira jamais.
Cacher un écart de politique derrière une exception permanente au lieu de corriger la règle ou l'infrastructure.

Auto-check — 3 questions pour vérifier que c'est acquis

Un pipeline de déploiement dispose d'un jeton permanent avec des droits d'administration. Quel est le risque principal et la correction ?
Le jeton est un secret partagé et permanent : toute personne qui y accède (ou le vol) obtient la production, sans attribution claire. Correction : identité fédérée par OIDC, rôle à durée courte, permissions limitées au périmètre déployé, journalisation des sessions.
Pourquoi détecter la dérive d'infrastructure plutôt que l'interdire seulement ?
Parce que la réalité finit toujours par diverger (intervention d'urgence, correction à chaud). La détection permet de décider consciemment : réintégrer le changement dans le code, ou le supprimer. Sans détection, on découvre l'écart pendant l'incident.
Un scan SAST remonte 300 alertes sur un dépôt historique. Que faire ?
On ne bloque pas sur l'existant : on bloque sur le diff (nouveau code), on trie par exploitabilité et criticité, on corrige les hautes, et on planifie le reste avec un propriétaire et une échéance. Sinon l'équipe apprend à ignorer le rapport.

Cloud et DevSecOps Intermédiaire 22 min #ASVS 5.0#API Top 10#OAuth#BOLA

Sécurité applicative et API

Une API expose la logique métier, pas seulement des données : la plupart des failles viennent d'une autorisation oubliée, pas d'un chiffrement faible.

L'essentiel en 30 secondes

Le premier risque des API est l'autorisation au niveau de l'objet (BOLA) : l'appel est authentifié, mais personne ne vérifie que l'objet demandé appartient à l'appelant.
Authentifier n'est pas autoriser : le jeton dit qui appelle ; chaque point d'entrée décide encore, côté serveur, ce que cet appelant peut lire, modifier et déclencher.
L'ASVS 5.0 (OWASP, mai 2025) fournit des exigences vérifiables en 17 chapitres et trois niveaux : un niveau se choisit par application, selon son exposition, puis se teste.
On ne protège que ce qu'on connaît : inventaire des API (versions, environnements, consommateurs), contrat OpenAPI versionné, passerelle comme point de passage unique.

risques du Top 10 API

OWASP 2023 · BOLA en tête

chapitres de l'ASVS 5.0

trois niveaux de vérification

décisions par appel

qui · sur quel objet · quelle action

Les applications modernes sont des assemblages d'API : applications mobiles, partenaires, microservices et agents d'IA les consomment. Ce module donne les risques propres aux API, les exigences vérifiables de l'ASVS et un threat model d'API qui tient sur une page.

🔢 Chiffres 📊 OWASP API Security Top 10 (édition 2023)📊 ASVS 5.0 : choisir un niveau, puis vérifier contre lui 📊 Le threat model d'une API en six questions 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

OWASP API Security Top 10 (édition 2023)

Dix risques, dont la moitié relève de l'autorisation ou de l'inventaire — pas de la cryptographie.

Vérifié le 27/09/2026

Risque	Ce qui se passe	Contrôle d'architecture	Test qui le prouve
API1 · BOLA (objet)	Changer un identifiant dans l'URL donne accès à l'objet d'un autre client.	Contrôle d'appartenance côté serveur à chaque accès ; identifiants non devinables en complément, jamais à la place.	Deux comptes de test : A demande l'objet de B, refus attendu et journalisé
API2 · Authentification défaillante	Jetons mal validés, force brute sans limite, récupération de compte contournable.	Fournisseur d'identité standard (OIDC), validation stricte du jeton (signature, audience, expiration), limitation des tentatives.	Jeton expiré, mauvaise audience ou signature altérée : refus
API3 · BOPLA (propriétés)	L'API renvoie ou accepte des champs sensibles qu'elle ne devrait pas (affectation de masse).	Schémas de requête et de réponse explicites, liste blanche des champs modifiables.	Envoi d'un champ « role » ou « prix » non prévu : ignoré ou refusé
API4 · Consommation sans limite	Requêtes coûteuses, pagination infinie, fichiers énormes : déni de service ou facture.	Quotas par client, pagination bornée, tailles maximales, délais d'expiration à la passerelle.	Dépassement de quota : réponse 429 et alerte
API5 · BFLA (fonctions)	Un utilisateur standard appelle une route d'administration.	Autorisation par fonction centralisée, refus par défaut, routes d'administration séparées.	Route d'administration appelée avec un jeton standard : refus
API6 · Flux métier sensibles	Achat en masse, création de comptes, réservation automatisée : l'abus respecte les règles techniques.	Flux à forte valeur identifiés, limitation par flux, détection d'automatisation.	Rejeu scripté d'un flux d'achat : ralenti ou bloqué
API7 · SSRF	L'API va chercher une URL fournie par l'appelant et atteint le réseau interne ou les métadonnées cloud.	Liste blanche de destinations, sortie réseau filtrée, IMDSv2 côté AWS.	URL vers 169.254.169.254 ou un hôte interne : refus
API8 · Mauvaise configuration	CORS permissif, erreurs verbeuses, en-têtes manquants, TLS hétérogène.	Configuration de référence versionnée, appliquée par la passerelle et vérifiée en CI.	Scan de configuration comparé à la référence : zéro écart
API9 · Inventaire défaillant	Une ancienne version ou une API de test reste exposée, sans les correctifs.	Inventaire à jour, contrat OpenAPI par version, retrait daté des anciennes versions.	Découverte externe comparée à l'inventaire : zéro API inconnue
API10 · Consommation risquée d'API tierces	Les réponses d'un partenaire sont crues sans validation.	Valider et borner les données reçues, délais et chiffrement vers les tiers, suivi du fournisseur.	Réponse tierce malformée injectée en test : rejetée

OWASP API Security Top 10, édition 2023 : toujours l'édition en vigueur au 27/09/2026. L'ordre reflète la fréquence et l'impact observés, pas un ordre de traitement.

ASVS 5.0 : choisir un niveau, puis vérifier contre lui

Le niveau se décide par application, selon l'exposition et la valeur des données — pas une fois pour tout le SI.

Vérifié le 27/09/2026

Niveau	Pour quelles applications	Ce qu'il ajoute	Comment on le vérifie
Niveau 1	Premier palier pour tout le parc ; exposition limitée, données peu sensibles.	Les défenses de base : encodage et validation, authentification, session, contrôle d'accès élémentaire.	Tests automatisés en CI et revue ciblée
Niveau 2	La plupart des applications métier : données personnelles, transactions, accès partenaires.	Autorisation fine, journalisation de sécurité, cryptographie maîtrisée, configuration durcie.	Revue de code et de configuration, test d'intrusion applicatif
Niveau 3	Applications critiques : santé, paiement, infrastructures, forte valeur pour un attaquant.	Défense en profondeur sur chaque chapitre, architecture documentée et vérifiée.	Accès au code, à l'architecture et aux équipes ; vérification approfondie

ASVS 5.0.0, publié par l'OWASP en mai 2025 : 17 chapitres, de l'encodage et la validation (V1, V2) à l'API (V4), aux jetons autoportés et à OAuth/OIDC (V9, V10) et à la journalisation (V16). Le niveau retenu s'écrit dans l'ADR de l'application.

Le threat model d'une API en six questions

Une page par API, relue à chaque changement de contrat.

Question	Ce qu'on regarde	Réponse attendue
Qui appelle ?	Types de clients : navigateur, mobile, partenaire, service interne, agent d'IA.	Une identité par type de client, jamais un secret partagé entre clients
Avec quel jeton ?	Flux OAuth adapté (code + PKCE, identifiants client), durée de vie, audience.	Jetons courts, audience restreinte, signature vérifiée par l'API elle-même
Sur quels objets ?	Identifiants exposés, règles d'appartenance, cloisonnement entre clients.	Contrôle d'appartenance à chaque accès, testé avec deux comptes
Quelles actions ?	Routes d'écriture, d'administration, d'export, flux métier sensibles.	Autorisation par fonction, limitation par flux, validation humaine si l'action est irréversible
Jusqu'où ?	Quotas, tailles, pagination, appels sortants.	Limites à la passerelle, sortie réseau en liste blanche
Qu'est-ce qui reste ?	Journaux, corrélation, traces d'accès aux données sensibles.	Un journal par appel : identité, objet, action, décision — exploitable par le SOC

La méthode générale (STRIDE, périmètre, preuves) est dans le module Risque et priorisation ; ces six questions en sont la version API.

Sécurité d'une API — un appel, trois décisions à regarder : ce que la passerelle décide, et ce que seule l'API métier peut décider Plein écran

À retenir

Chaque appel porte trois décisions : qui appelle, sur quel objet, pour quelle action — l'authentification ne tranche que la première.
Le contrôle d'appartenance se fait côté serveur, à chaque accès ; un identifiant aléatoire n'est pas une autorisation.
Une API non inventoriée n'est pas protégée : ni correctif, ni surveillance, ni retrait.
L'ASVS donne des exigences testables : le niveau choisi s'écrit et se vérifie application par application.

Pièges classiques

Croire que la passerelle suffit : elle authentifie et limite, mais ne sait pas à qui appartient la facture n° 4312.
Renvoyer l'objet complet et laisser le client filtrer : les champs sensibles partent quand même sur le réseau.
Garder l'ancienne version « le temps de migrer » sans date de retrait.
Partager un même secret client entre plusieurs applications : impossible d'en révoquer une sans casser les autres.

Auto-check — 3 questions pour vérifier que c'est acquis

Une application mobile appelle /factures/{id} avec un jeton valide. Quel test prouve l'absence de BOLA ?
Deux comptes de test : le compte A demande une facture du compte B et reçoit un refus (403 ou 404), journalisé. Le test s'automatise en CI pour chaque route qui prend un identifiant d'objet.
Quelle différence entre BOLA et BFLA ?
BOLA : l'appelant accède, par une fonction légitime, à un objet qui ne lui appartient pas. BFLA : il appelle une fonction qui ne lui est pas permise, comme une route d'administration. Le premier se corrige par un contrôle d'appartenance, le second par une autorisation par fonction.
Quel niveau ASVS pour un portail client qui affiche des données personnelles et permet des paiements ?
Le niveau 2 au minimum, pour les données personnelles et les transactions. Le niveau 3 se discute si le portail est une cible de forte valeur (paiement à grande échelle, santé). La décision et sa justification vont dans l'ADR de l'application.

Cloud et DevSecOps Intermédiaire 20 min #EDR#DMARC#SSPM#MDM

Poste de travail, messagerie et SaaS

L'attaque commence le plus souvent par un courriel, un poste ou un compte SaaS : c'est la surface la plus banale, et la plus exposée.

L'essentiel en 30 secondes

Le poste se protège en couches : configuration durcie gérée centralement (MDM), EDR qui observe et peut isoler, droits d'administration locaux retirés, correctifs mesurés en jours.
La messagerie se protège en amont : SPF, DKIM et DMARC jusqu'à la politique p=reject empêchent l'usurpation du domaine ; le filtrage traite le reste.
Le SaaS laisse la configuration de sécurité au client : partage externe, applications tierces autorisées par OAuth, journaux — le SSPM mesure cette posture en continu.
Le compte est la nouvelle périphérie : MFA résistant à l'hameçonnage, accès conditionné à l'état du poste, revue des consentements OAuth accordés aux applications tierces.

protocoles d'authentification du courriel

SPF · DKIM · DMARC

p=reject

politique DMARC cible

après une phase de surveillance

administrateur local permanent

élévation à la demande, tracée

Les modules d'identité et de cloud couvrent l'infrastructure ; celui-ci couvre ce que les utilisateurs touchent tous les jours : poste, messagerie et applications SaaS. Il donne les contrôles de base, leur ordre de déploiement et la façon de prouver qu'ils fonctionnent.

🔢 Chiffres 📊 Le poste de travail en couches 📊 Messagerie : empêcher l'usurpation, filtrer le reste 📊 SaaS : la configuration est chez le client 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Le poste de travail en couches

Six couches ; chacune a sa preuve, sinon elle n'existe que dans la politique.

Couche	Contrôle	Preuve de fonctionnement
Configuration	Référentiel de durcissement appliqué par la gestion centralisée (MDM ou équivalent), chiffrement du disque, démarrage sécurisé.	Taux de conformité par parc, écarts datés et traités
Privilèges	Aucun administrateur local permanent ; élévation à la demande, tracée ; mot de passe administrateur local unique par machine et renouvelé.	Inventaire des comptes locaux : aucun compte partagé
Exécution	Contrôle applicatif (liste d'autorisation) sur les postes sensibles, macros bloquées par défaut.	Exécution non autorisée tentée : bloquée et journalisée
Détection et réponse	EDR sur tout le parc, alertes remontées au SOC, isolation réseau à distance.	Couverture mesurée (poste sans agent actif = écart), test d'isolation
Correctifs	Système et navigateur à jour en quelques jours, vulnérabilités exploitées (KEV) en priorité.	Délai médian de déploiement mesuré par parc
Perte ou vol	Chiffrement, effacement à distance, révocation des sessions et jetons.	Exercice de révocation chronométré

Messagerie : empêcher l'usurpation, filtrer le reste

L'authentification du domaine se règle une fois ; le filtrage et le signalement s'exploitent tous les jours.

Vérifié le 27/09/2026

Mécanisme	Ce qu'il garantit	Déploiement	Erreur fréquente
SPF	Quels serveurs ont le droit d'envoyer pour le domaine.	Enregistrement DNS listant les émetteurs, prestataires compris.	Dépasser la limite de 10 résolutions DNS : SPF invalide
DKIM	Que le message est signé par le domaine et n'a pas été modifié.	Une clé par émetteur, rotation planifiée.	Oublier la signature chez un prestataire d'envoi (CRM, facturation)
DMARC	Que le domaine affiché (From) est aligné sur SPF ou DKIM ; dit au destinataire quoi faire sinon.	p=none avec rapports, correction des émetteurs, puis quarantine, puis reject.	Rester en p=none indéfiniment : aucune protection réelle
Filtrage et bac à sable	Qu'une pièce jointe ou un lien n'est pas malveillant au moment du clic.	Filtrage entrant, réécriture des liens, analyse dynamique.	Laisser chaque utilisateur libérer lui-même la quarantaine
Signalement	Qu'un message suspect remonte en un clic au SOC.	Bouton de signalement, retour vers l'utilisateur.	Signalements jamais traités : les utilisateurs arrêtent

DMARC est normalisé depuis mai 2026 par les RFC 9989, 9990 et 9991, qui remplacent la RFC 7489 (2015). Les grands fournisseurs de messagerie exigent SPF, DKIM et DMARC des expéditeurs en volume depuis 2024.

SaaS : la configuration est chez le client

Le fournisseur sécurise la plateforme ; ces cinq réglages restent à la charge du client.

Risque	Exemple	Contrôle	Mesure (SSPM)
Partage externe ouvert	Liens « toute personne disposant du lien » sur des documents sensibles.	Partage externe restreint par défaut, expiration des liens, étiquettes de sensibilité.	Liens publics par niveau de sensibilité
Applications tierces (OAuth)	Une application obtient la lecture de toutes les boîtes aux lettres par un simple consentement.	Consentement utilisateur limité, validation administrateur pour les droits étendus, revue périodique.	Applications autorisées, droits accordés, dernière utilisation
Comptes et rôles	Administrateurs trop nombreux, comptes d'anciens salariés encore actifs.	Rôles minimaux, provisionnement SCIM depuis l'annuaire, revue des administrateurs.	Administrateurs globaux, comptes orphelins
Journalisation	Journaux d'audit désactivés ou conservés quelques jours.	Journaux activés et exportés vers le SIEM, rétention adaptée.	Sources SaaS présentes dans le SIEM
Accès conditionnel	Connexion depuis un poste non géré à des données sensibles.	Accès conditionné à l'état du poste et au niveau de MFA.	Connexions hors politique, par application

Le SSPM fait pour le SaaS ce que le CSPM fait pour le cloud (module Sécurité cloud) : comparer en continu la configuration réelle à une référence.

Poste, messagerie et SaaS — la surface du quotidien à regarder : trois flux, trois contrôles en amont, et un SOC qui reçoit la télémétrie du poste et les écarts de posture SaaS Plein écran

À retenir

Le poste se défend en couches : configuration gérée, privilèges retirés, EDR, correctifs rapides.
Sans DMARC en p=reject, n'importe qui peut envoyer un courriel au nom du domaine.
En SaaS, le fournisseur sécurise la plateforme ; partage, consentements OAuth et journaux restent à la charge du client.
Chaque contrôle se prouve par une mesure : couverture EDR, politique DMARC, liens publics, applications autorisées.

Pièges classiques

Déployer l'EDR en mode détection seule et ne jamais tester l'isolation.
Garder des droits d'administration locaux « pour les développeurs » sans élévation tracée.
Publier DMARC en p=reject sans inventaire des émetteurs légitimes : les factures ne partent plus.
Autoriser tout consentement OAuth utilisateur : l'hameçonnage par consentement contourne le MFA.

Auto-check — 3 questions pour vérifier que c'est acquis

Un courriel semble venir du directeur financier, avec le vrai domaine de l'entreprise. Qu'est-ce qui aurait dû l'arrêter ?
Si le domaine est usurpé : DMARC en p=reject, avec SPF et DKIM alignés, fait rejeter le message par le destinataire. Si le message vient d'un compte réellement compromis, DMARC passe : ce sont alors la détection (connexion anormale, règle de transfert créée) et le MFA résistant à l'hameçonnage qui protègent.
Pourquoi l'hameçonnage par consentement OAuth contourne-t-il le MFA ?
Parce que l'utilisateur s'authentifie normalement, MFA compris, puis accorde des droits à une application malveillante : celle-ci reçoit un jeton et lit les données sans jamais connaître le mot de passe. La parade : limiter le consentement utilisateur et revoir les applications autorisées.
Comment prouver que l'EDR protège réellement le parc ?
Par trois mesures : couverture (postes avec agent actif sur postes inventoriés), remontée effective des alertes au SOC, et test d'isolation à distance sur un poste de test. Un agent installé mais muet, ou jamais exercé, ne prouve rien.

Cloud et DevSecOps Avancé 20 min #Kubernetes#RBAC#NetworkPolicy#Pod Security

Conteneurs et Kubernetes

Kubernetes est permissif par défaut : tout pod parle à tout pod, un compte de service trop large ouvre le cluster, un conteneur privilégié ouvre le nœud.

L'essentiel en 30 secondes

Le plan de contrôle (serveur d'API, etcd) est l'actif le plus sensible : qui peut créer un pod privilégié ou lire les secrets contrôle le cluster.
Par défaut, tous les pods communiquent entre eux : une NetworkPolicy de refus par défaut dans chaque espace de noms, puis des flux autorisés explicitement.
Les Pod Security Standards (privileged, baseline, restricted) s'appliquent par espace de noms avec Pod Security Admission ; *restricted* est la cible des charges applicatives.
Le contrôle d'admission est le dernier point de décision avant l'exécution : image signée, registre autorisé, aucun privilège, ressources bornées — des règles écrites comme du code.

profils Pod Security

privileged · baseline · restricted

NetworkPolicy de refus par défaut

dans chaque espace de noms

compte applicatif en cluster-admin

droits par espace de noms

Les modules cloud et DevSecOps traitent le compte cloud et le pipeline ; celui-ci traite ce qui tourne dedans. Il donne les couches de sécurité d'un cluster, les réglages par défaut à inverser et les contrôles d'admission qui arrêtent un déploiement dangereux avant la production.

🔢 Chiffres 📊 Les couches d'un cluster et ce qui les protège 📊 Les réglages par défaut à inverser 📊 Contrôle d'admission : ce qui ne passe pas 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Les couches d'un cluster et ce qui les protège

Six couches ; une seule ouverte suffit à perdre le cluster.

Couche	Risque	Contrôle	Preuve
Plan de contrôle	Serveur d'API exposé, etcd lisible, accès administrateur partagé.	API privée ou filtrée, authentification par le fournisseur d'identité, secrets chiffrés dans etcd, journaux d'audit activés.	Accès depuis Internet refusé ; journaux d'audit présents dans le SIEM
Identités (RBAC)	Comptes de service trop larges, droits cluster-admin distribués, jeton monté partout.	Rôles par espace de noms, aucun cluster-admin applicatif, montage automatique du jeton désactivé si inutile.	Revue des liaisons de rôles : aucun sujet applicatif en cluster-admin
Charges de travail	Conteneur privilégié, exécution en root, accès au système de fichiers de l'hôte.	Profil restricted, système de fichiers en lecture seule, capacités Linux retirées.	Pod privilégié déployé dans un espace applicatif : refusé
Réseau	Tout pod joint tout pod, et le service de métadonnées du cloud.	NetworkPolicy de refus par défaut, flux déclarés, sortie filtrée.	Connexion entre deux espaces de noms : refusée
Chaîne d'approvisionnement	Image non signée, registre public, vulnérabilités connues.	Registre privé, signature vérifiée à l'admission, analyse d'image dans le pipeline.	Image non signée : refusée à l'admission
Nœuds	Un nœud compromis livre tous ses pods.	Système minimal durci, images de nœud renouvelées, pas d'accès SSH permanent, détection à l'exécution.	Âge des images de nœud, alertes d'exécution remontées

Les réglages par défaut à inverser

Kubernetes de base privilégie la facilité de démarrage ; la production demande l'inverse.

Par défaut	Risque	Réglage cible
Tous les pods communiquent entre eux	Un pod compromis balaie tout le cluster.	NetworkPolicy de refus par défaut dans chaque espace de noms, puis flux déclarés
Jeton du compte de service monté dans chaque pod	Un pod compromis parle à l'API avec l'identité de son compte.	automountServiceAccountToken à false sauf besoin, un compte dédié par application
Aucun profil de sécurité imposé aux pods	Conteneurs privilégiés ou en root admis.	Pod Security Admission en mode enforce, profil restricted pour les applications
Secrets encodés, pas chiffrés	Le Base64 n'est pas du chiffrement : qui lit etcd lit tout.	Chiffrement des secrets au repos par KMS, ou gestionnaire de secrets externe
Aucune limite de ressources	Un pod consomme tout le nœud.	Requêtes et limites obligatoires, quotas par espace de noms

Défauts de Kubernetes de base : certains services managés en corrigent une partie (chiffrement des secrets notamment) — à vérifier pour le service retenu, et à consigner dans l'ADR.

Contrôle d'admission : ce qui ne passe pas

Cinq règles ; chacune passe d'abord en mode audit, puis en refus.

Règle	Pourquoi	Mise en œuvre
Image signée, issue du registre autorisé	Seul ce qui sort du pipeline arrive en production.	Vérification de signature et de provenance (SLSA) à l'admission
Aucun conteneur privilégié ni accès à l'hôte	Un conteneur privilégié équivaut à un accès au nœud.	Pod Security Admission, profil restricted
Pas d'étiquette latest	Une étiquette mobile rend le déploiement non reproductible.	Image référencée par son empreinte
Ressources bornées	Un pod ne doit pas affamer les autres.	Requêtes et limites obligatoires
Étiquette de propriétaire	Chaque charge a un responsable joignable.	Refus d'un déploiement sans étiquette propriétaire

Les politiques s'écrivent en ValidatingAdmissionPolicy (natif, langage CEL) ou avec un moteur dédié (Kyverno, OPA Gatekeeper) ; le choix se trace dans un ADR.

Kubernetes — un cluster en couches à regarder : l'admission entre le serveur d'API et l'exécution, et les métadonnées cloud tenues hors de portée des pods Plein écran

À retenir

Le plan de contrôle et les secrets sont l'actif principal : qui crée des pods privilégiés contrôle le cluster.
Réseau : refus par défaut dans chaque espace de noms, puis flux déclarés et testés.
Le profil restricted s'impose à l'admission pour les applications ; recommandé ne suffit pas.
Tout ce qui entre en production est signé, référencé par empreinte et borné en ressources.

Pièges classiques

Donner cluster-admin à l'outil de déploiement « pour simplifier ».
Croire les Secrets Kubernetes chiffrés parce qu'ils sont encodés en Base64.
Activer une politique d'admission directement en refus : la production s'arrête ; l'audit vient d'abord.
Laisser un pod joindre le service de métadonnées du cloud : il hérite de l'identité du nœud.

Auto-check — 3 questions pour vérifier que c'est acquis

Un développeur demande un pod privilégié pour déboguer en production. Que répondre ?
Non en production : un pod privilégié donne accès au nœud et à ses autres pods. Alternatives : conteneur de débogage éphémère aux droits limités, reproduction hors production, ou exception temporaire tracée dans un espace de noms isolé, avec expiration et revue.
Comment prouver que le cloisonnement réseau entre deux applications fonctionne ?
Par un test : depuis un pod de l'application A, une connexion vers un pod de B échoue, alors que les flux déclarés passent. Le test se rejoue après chaque changement de politique ; la présence d'une NetworkPolicy ne prouve rien si le plugin réseau ne l'applique pas.
Pourquoi désactiver le montage automatique du jeton de compte de service ?
Parce que la plupart des applications n'appellent jamais l'API Kubernetes : le jeton monté ne leur sert à rien, mais sert à l'attaquant qui compromet le pod. Il n'est monté que pour les charges qui en ont besoin, avec un compte dédié aux droits minimaux.

Menaces et risque Débutant 18 min #ATT&CK v19#phishing#ransomware

Menaces, attaques et surface d'exposition

Huit maillons alignés sur les 15 tactiques ATT&CK, trois voies d'intrusion dominantes : le but n'est pas de tout couvrir, c'est de savoir où l'on est aveugle.

L'essentiel en 30 secondes

Trois voies dominent : l'identité (hameçonnage dopé par l'IA, vol de session), les périphériques exposés (exploitation d'un service joignable depuis Internet), l'abus de droits légitimes (personne n'a « piraté » — on a utilisé un accès existant).
La chaîne d'attaque se lit ici en huit maillons, un modèle simplifié qui regroupe les 15 tactiques MITRE ATT&CK ; chaque maillon doit être cassé par un contrôle nommé. Un maillon sans contrôle n'est pas une hypothèse : c'est un écart à écrire.
Le rançongiciel ne casse pas le chiffrement : il exploite une reprise non testée et des sauvegardes atteignables. La priorité n'est pas la détection, c'est la restauration.
La surface d'exposition se gère comme un inventaire : ce qui est exposé sans être connu sera trouvé par l'attaquant avant le défenseur.

maillons à casser

15 tactiques ATT&CK regroupées

voies d'intrusion dominantes

identité · exposition · droits légitimes

priorité en cas de rançongiciel

restaurer, pas négocier

Comprendre l'attaque sert à choisir les contrôles. Ce module donne la chaîne d'attaque en huit maillons alignés sur MITRE ATT&CK, les trois voies réelles d'intrusion, et les prérequis d'une reprise crédible.

🔢 Chiffres 📊 Les huit maillons, leurs tactiques ATT&CK et le contrôle qui casse chacun 📊 Les trois voies d'intrusion dominantes 📊 Rançongiciel : cinq prérequis de reprise 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Les huit maillons, leurs tactiques ATT&CK et le contrôle qui casse chacun

Modèle simplifié : chaque maillon regroupe une ou plusieurs tactiques MITRE ATT&CK Enterprise ; pour chacun, le contrôle préventif et le signal de détection.

Vérifié le 26/09/2026

Maillon	Tactiques ATT&CK	Ce que fait l'attaquant	Contrôle qui casse le maillon	Signal de détection
1 · Préparation	`TA0043` Reconnaissance · `TA0042` Resource Development	Inventorie l'exposition (domaines, services joignables, identités publiques, fuites) et prépare ses moyens : infrastructure, comptes, outils.	Réduction de surface (inventaire d'exposition, fermeture des services inutiles), veille sur les fuites et sur les domaines qui imitent le sien.	Balayages, énumération DNS, domaines voisins enregistrés
2 · Accès initial	`TA0001` Initial Access	Entre par une identité (hameçonnage, vol de session) ou par une faille exposée.	MFA résistante au hameçonnage, filtrage entrant, correctifs rapides sur la bordure.	Connexion impossible (voyage), nouvelle règle de transfert, exploitation de vulnérabilité
3 · Exécution	`TA0002` Execution	Fait tourner du code : script, binaire, outil légitime détourné.	Exécution durcie des charges, contrôle d'intégrité, liste blanche d'applications.	Processus inattendu, ligne de commande suspecte, charge anormale
4 · Persistance	`TA0003` Persistence	S'ancre pour survivre à un redémarrage ou à un changement de mot de passe : compte, clé, tâche planifiée, service.	Revue des identités et des tâches planifiées, rotation des secrets, inventaire des clés d'accès.	Nouveau compte, nouvelle clé, tâche planifiée ou service créé
5 · Élévation et vol d'identifiants	`TA0004` Privilege Escalation · `TA0006` Credential Access	Passe d'un compte ordinaire à un compte à privilèges ; récupère mots de passe, jetons et clés.	Moindre privilège, séparation des rôles, protection du rang 0, secrets courts et coffre-fort.	Création de rôle, ajout à un groupe privilégié, accès à la mémoire d'authentification
6 · Découverte et mouvement latéral	`TA0007` Discovery · `TA0008` Lateral Movement	Cartographie l'environnement puis se déplace vers les données et les systèmes utiles.	Segmentation, authentification entre services, aucun secret partagé.	Connexions inhabituelles entre zones, énumération d'annuaire, découverte de partages
7 · Collecte, commande et exfiltration	`TA0009` Collection · `TA0011` Command and Control · `TA0010` Exfiltration	Rassemble les données, garde un canal de pilotage, les fait sortir.	Sortie maîtrisée (proxy, filtrage DNS), DLP, liste blanche des destinations.	Volume sortant inhabituel, balises régulières vers un domaine récent, archives créées en masse
8 · Impact	`TA0040` Impact	Chiffre, détruit, altère ou rend indisponible ; souvent après avoir volé (double extorsion).	Sauvegardes déconnectées et immuables, restauration testée, identités de secours.	Suppression massive, arrêt de services, altération de sauvegardes
Transverse · Furtivité et neutralisation des défenses	`TA0005` Stealth · `TA0112` Defense Impairment	À chaque maillon : se fond dans l'activité légitime, désactive agents, journaux et pipelines de sécurité.	Journaux immuables hors de portée de l'attaquant, protection anti-altération des agents.	Arrêt d'un agent, trou de journalisation, modification d'une règle de détection

Modèle simplifié : ATT&CK décrit des objectifs, pas une séquence — un attaquant répète, saute ou réordonne les tactiques. Version consultée : MITRE ATT&CK Enterprise v19.2 (15 tactiques ; TA0112 Defense Impairment créée le 14/04/2026, à côté de TA0005 renommée Stealth). Un maillon peut rester sans contrôle, mais il s'écrit alors comme dette assumée, avec l'impact estimé et une échéance.

Les trois voies d'intrusion dominantes

Concentrer l'effort là où ça arrive vraiment, plutôt que de couvrir tous les cas imaginaires.

Voie	Ce que cherche l'attaquant	Ce qui la réduit vraiment	Ce qui la détecte
Identité (hameçonnage, vol de session, fatigue de validation)	Un compte valide, idéalement à privilèges, avec une session ouverte.	MFA liée à l'origine, accès conditionnel, session courte, révocation rapide.	Détection d'abus d'identité, connexions impossibles, création de règles de messagerie, pics de validation
Périphériques et services exposés	Un service joignable depuis Internet avec une faille exploitable (appliance, interface d'administration, API).	Inventaire d'exposition, fermeture par défaut, correctifs rapides, authentification forte sur les interfaces.	Alertes d'exploitation, journaux de la bordure, comptes ou fichiers inattendus
Droits légitimes abusés (interne, prestataire, compte de service)	Utiliser un accès existant sans déclencher d'alarme.	Moindre privilège, revues d'accès, secrets non partagés, traçabilité des actions sensibles.	Analyse comportementale, actions hors horaires, accès inhabituels à des données

Rançongiciel : cinq prérequis de reprise

Le jour où ça arrive, ce qui compte n'est pas la détection mais la capacité à redémarrer.

Prérequis	Ce que ça veut dire concrètement	Comment on le prouve
Sauvegardes déconnectées et immuables	Une copie non atteignable depuis le réseau de production, non modifiable pendant sa rétention.	Test de suppression impossible, compte de sauvegarde séparé, verrouillage d'objet activé
Restauration testée	On a déjà restauré un service complet, avec un chronomètre et un compte rendu.	Rapport de restauration daté : périmètre, durée, écarts constatés
RTO et RPO écrits par criticité	Ce que l'activité accepte comme interruption et comme perte de données.	Validation par la direction, pas seulement par l'équipe technique
Plan de communication	Qui parle aux clients, aux autorités, aux équipes — avec quels délais réglementaires.	Annuaire de crise à jour, procédure de notification connue (24 h / 72 h selon le régime)
Identités de secours	Un accès d'administration hors du domaine compromis, testé et gardé hors ligne.	Procédure d'urgence testée au moins une fois par an, avec compte rendu

Payer ne restaure pas la confiance : la reprise se joue sur les sauvegardes, la documentation et les décisions prises d'avance.

Chaîne d'attaque — huit maillons alignés sur ATT&CK et points de rupture à regarder : où chaque contrôle casse la chaîne, et ce qui reste transverse Plein écran

À retenir

L'attaquant ne « casse » pas toujours : le plus souvent, il se connecte.
Un maillon sans contrôle identifié est un écart assumé — à écrire, pas à oublier.
La priorité budgétaire suit le rayon d'impact : identité, sauvegardes, inventaire avant les outils spectaculaires.
La détection utile est corrélée : un signal isolé est du bruit, trois signaux alignés font une investigation.

Pièges classiques

Raisonner en catalogue de menaces sans les relier à ses propres composants : une liste générique ne protège rien.
Croire qu'un EDR suffit face à une intrusion par identité : il ne voit pas une connexion légitime.
Confondre chiffrement des sauvegardes et sauvegardes inaccessibles : l'attaquant utilise les mêmes identités que les administrateurs.
Chercher à détecter « tout » et ne plus trier : la fatigue d'alerte est une vulnérabilité organisationnelle.

Auto-check — 3 questions pour vérifier que c'est acquis

Citer deux maillons sans contrôle documenté dans l'organisation, et dire ce qui en est fait.
Méthode : projeter les huit maillons (et leurs tactiques ATT&CK) sur les contrôles réels, documentés et testés. Un maillon sans contrôle devient une ligne du registre de risque : impact, vraisemblance, propriétaire, échéance — pas un oubli tacite.
Pourquoi la sauvegarde déconnectée est-elle décisive face au rançongiciel ?
Parce que l'attaquant utilise des identités légitimes : si la sauvegarde est accessible avec ces mêmes identités, il la supprime. Sans copie non atteignable et non modifiable, la reprise dépend de la bonne volonté de l'attaquant.
Un service exposé sur Internet n'a pas été mis à jour depuis six mois. Comment qualifier le risque ?
Risque élevé : exposition (joignable), vraisemblance (vulnérabilités connues sur une interface exposée), impact (selon les données et les droits). Décision : fermer, isoler derrière une authentification forte, ou mettre à jour — avec une date.

Menaces et risque Intermédiaire 24 min #EBIOS RM#STRIDE#CVSS#EPSS#KEV

Risque, threat modelling et priorisation

Un risque s'argumente : impact, vraisemblance, contexte, propriétaire. Le reste n'est qu'une opinion bien présentée.

L'essentiel en 30 secondes

Un risque se décrit en impact × vraisemblance dans un contexte : ce n'est ni une vulnérabilité, ni une intuition, ni un score isolé.
EBIOS RM : cinq ateliers, du cadre socio-technique au traitement du risque ; on part des valeurs métier et des sources de risque, jamais des outils.
STRIDE fournit six familles de menaces à parcourir systématiquement : usurpation, altération, répudiation, divulgation, déni de service, élévation de privilèges.
Prioriser une vulnérabilité : l'exposition, l'exploitation observée (EPSS, KEV) et la criticité métier comptent plus que le seul score de sévérité.

ateliers EBIOS RM

du cadre au traitement du risque

familles STRIDE

une grille à parcourir

notes à croiser

CVSS · EPSS · KEV

P0 → P3

échéances décidées

24-72 h · 7 j · 30 j · accepté

L'analyse de risque est le cœur du métier : c'est là qu'on relie une menace à un actif, une décision à un coût, et un écart à une échéance. Ce module donne la méthode, la grille et la logique de priorisation.

🔢 Chiffres 📊 EBIOS RM : cinq ateliers, cinq livrables 📊 STRIDE : six familles, six questions 📊 Prioriser une vulnérabilité : trois notes, une décision 📊 Registre de risque : les colonnes qui comptent 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

EBIOS RM : cinq ateliers, cinq livrables

Une démarche itérative : chaque atelier produit une pièce utilisable en comité.

Atelier	La question posée	Livrable	Erreur fréquente
1 · Cadrage et socle	Quel périmètre, quelles valeurs métier, quels événements redoutés ?	Besoin, périmètre, valeurs métier, événements redoutés	Lister les menaces avant de savoir ce qu'on protège
2 · Sources de risque	Qui a intérêt à attaquer, et avec quelles ressources ?	Sources de risque retenues, motivations, capacités	Retenir un attaquant omniscient : tout devient critique, donc rien ne l'est
3 · Scénarios stratégiques	Quels chemins mènent d'une source à un événement redouté ?	Scénarios, vraisemblance, gravité, priorités	Confondre scénario stratégique et parcours technique
4 · Scénarios opérationnels	Par quels éléments techniques concrets cela passe-t-il ?	Parcours d'attaque, mesures existantes ou manquantes	Décrire des enchaînements invraisemblables pour justifier un achat
5 · Traitement du risque	Quelles mesures, à quel coût, avec quel risque résiduel ?	Plan de traitement, justification, risque résiduel accepté	Ne pas écrire le risque résiduel : il revient par surprise

STRIDE : six familles, six questions

La grille qui évite d'oublier une catégorie entière de menaces — à parcourir frontière par frontière.

Famille	Question à poser au design	Exemple concret	Contre-mesure typique
Usurpation (Spoofing)	Peut-on se faire passer pour quelqu'un ou quelque chose ?	Vol de session, faux service appelé par un autre	Authentification forte, authentification mutuelle, facteur lié à l'origine
Altération (Tampering)	Peut-on modifier des données ou du code en transit ou au repos ?	Artefact de build modifié, journal édité	Signature, contrôle d'intégrité, journal immuable
Répudiation	Peut-on nier une action sans qu'on puisse le prouver ?	Action administrative sans trace attribuable	Journalisation fiable, horodatage, identités nominatives
Divulgation d'information	Peut-on accéder à ce qu'on ne devrait pas voir ?	Stockage public, journal contenant des données personnelles	Chiffrement, moindre privilège, classification, filtrage des sorties
Déni de service	Peut-on empêcher le service de fonctionner ?	Saturation, épuisement de ressources, requête coûteuse	Limitation de débit, quotas, capacité d'absorption
Élévation de privilèges	Peut-on obtenir plus de droits qu'attendu ?	Rôle trop large, tâche planifiée détournée	Moindre privilège, séparation des rôles, revue des identités

Parcourir STRIDE sur chaque frontière de confiance, pas sur le schéma en général : c'est là que se trouvent les menaces intéressantes.

Prioriser une vulnérabilité : trois notes, une décision

Le score seul ne dit pas quoi faire cette semaine.

Vérifié le 26/09/2026

Élément	Ce qu'il mesure	Ce qu'il ne dit pas	Comment on l'utilise
CVSS (sévérité)	La gravité intrinsèque de la faille (score de base) ; CVSS 4.0 permet de l'ajuster à la menace et à l'environnement (CVSS-BT, -BE, -BTE).	Si quelqu'un l'exploite réellement, ni si l'actif est exposé.	Point de départ du tri, jamais une décision à lui seul
EPSS (probabilité)	La probabilité d'exploitation dans les 30 jours, estimée sur des données observées.	La gravité de l'impact dans l'organisation.	Départage les failles de sévérité proche : on traite d'abord ce qui s'exploite en pratique
KEV (exploitation avérée)	La faille est déjà exploitée activement (catalogue public de la CISA).	Si l'actif est exposé, ni l'impact dans l'organisation.	Priorité absolue si l'actif est exposé ou critique
Contexte métier	Exposition, criticité du service, données touchées, contrôles compensatoires.	—	C'est lui qui fixe l'échéance réelle
Décision et échéance	P0 : 24-72 h · P1 : 7 jours · P2 : 30 jours · P3 : accepté et écrit.	—	Chaque niveau a un propriétaire et une preuve de clôture

Un correctif non déployé n'est pas un risque traité : c'est un risque documenté. La preuve, c'est le re-scan ou le changement constaté.

Registre de risque : les colonnes qui comptent

Un registre utile se lit en comité en trois minutes.

Colonne	Ce qu'on y écrit	Pourquoi c'est obligatoire
Identifiant et date	Une référence stable, la date de création et de dernière revue.	Sans identifiant, aucune décision ne peut le citer ; sans date, il vieillit sans qu'on le sache
Énoncé du risque	« Cause → événement → impact » en une phrase.	Un énoncé flou donne un débat flou : la structure force la précision
Actif ou valeur métier	Ce qui est en jeu : donnée, service, image, conformité.	Un risque sans valeur métier associée n'a pas de gravité défendable
Vraisemblance et impact	Échelle courte (1 à 4) avec justification écrite.	La justification est ce qui rend l'échelle crédible et recalibrable en réunion
Propriétaire	Une personne nommée, pas un service.	Un risque sans propriétaire n'est traité par personne
Mesure et échéance	Ce qui est fait, pour quand, et comment on saura que c'est fait.	C'est la partie actionnable : sans elle, le registre est un inventaire de regrets
Risque résiduel accepté	Ce qui reste après la mesure, validé par qui de droit.	Sans acceptation formelle, le résiduel devient une surprise en cas d'incident

Threat modelling — cinq étapes, du périmètre au contrôle vérifié à regarder : la boucle qui se rejoue à chaque évolution d'architecture Plein écran

Prioriser les vulnérabilités — de l'exposition à la remédiation prouvée à regarder : où l'exposition et l'exploitation observée changent la décision Plein écran

À retenir

Un risque s'énonce « cause → événement → impact », avec une valeur métier et un propriétaire.
On traite d'abord ce qui est exploité en pratique et exposé, pas ce qui obtient le meilleur score.
Le risque résiduel s'accepte par écrit, par la bonne personne : c'est une décision, pas un oubli.
Un threat model se rejoue à chaque évolution d'architecture : sinon il devient un document d'archive.

Pièges classiques

Confondre risque et vulnérabilité : une faille non exploitable dans le contexte de l'organisation n'est pas un risque prioritaire.
Gonfler la criticité pour obtenir un budget : la crédibilité se perd en une réunion.
Produire un registre sans échéances ni propriétaires : il sera ignoré dès la deuxième revue.
Traiter la priorisation comme un exercice de notation plutôt que comme un exercice de décision.

Auto-check — 3 questions pour vérifier que c'est acquis

Une faille critique (CVSS 9,8) touche une bibliothèque utilisée uniquement dans un outil interne non exposé et sans donnée. Quelle priorité ?
Probablement P2 ou P3, par écrit : la sévérité est élevée mais l'exposition et l'impact sont faibles. La décision se documente (exposition, impact, contrôles compensatoires) et se revoit à date. Le P0 est réservé à l'exploitation avérée ou à une exposition critique.
Comment prouver qu'une vulnérabilité est réellement traitée ?
Par une preuve de clôture : re-scan propre, changement de version constaté, ou test manuel daté. Un ticket fermé « corrigé » sans vérification est une déclaration, pas une preuve.
À quoi sert le risque résiduel dans une décision d'architecture ?
À rendre explicite ce qu'on accepte de ne pas couvrir, avec son impact et ses critères de réexamen. C'est ce qui permet de dire en comité : « nous avons choisi, voici le coût de ce choix ».

GRC et conformité Intermédiaire 26 min #ISO 27001#CSF 2.0#NIS2#CRA

SMSI, ISO 27001 et référentiels

Un SMSI n'est pas un classeur : c'est un cycle qui transforme une politique en preuve, et une preuve en décision.

L'essentiel en 30 secondes

ISO/IEC 27001:2022 : les clauses 4 à 10 décrivent le système (contexte, leadership, planification, support, fonctionnement, évaluation, amélioration) ; l'Annexe A liste 93 mesures en 4 thèmes.
La déclaration d'applicabilité (SoA) est le document le plus lu en audit : chaque mesure y est incluse ou exclue, avec justification.
Déclaré ≠ testé : un contrôle devient prouvé par une exécution tracée (date, opérateur, résultat). Le reste est une intention documentée.
Les référentiels ne s'empilent pas : on choisit un pivot (souvent CSF 2.0 ou ISO 27001) et on y rattache NIS2, DORA, CRA et RGPD au lieu de maintenir quatre copies.

mesures de l'Annexe A

37 org · 8 personnes · 14 physiques · 34 techno

clauses pour le système

de la clause 4 à la clause 10

3 ans

cycle de certification

audit initial puis surveillances annuelles

24 h / 72 h

délais de notification

selon le régime applicable

La conformité n'est utile que si elle change des décisions techniques. Ce module donne la mécanique du SMSI, la carte des référentiels et les obligations de notification qu'il faut connaître sans les confondre.

🔢 Chiffres 📊 ISO 27001:2022 — clauses 4 à 10 : ce que l'auditeur vérifie 📊 Annexe A : quatre thèmes, 93 mesures 📊 Carte des référentiels : lequel utiliser pour quoi 📊 Notifications : qui, quoi, quand 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

ISO 27001:2022 — clauses 4 à 10 : ce que l'auditeur vérifie

Le système de management, avant même les mesures techniques.

Clause	Exigence	Preuve typiquement demandée	Écart classique
4 · Contexte	Comprendre l'organisation, les parties intéressées, définir le périmètre du SMSI.	Analyse de contexte, périmètre documenté, cartographie des parties intéressées	Périmètre flou : les filiales ou le cloud sont « dedans mais pas vraiment »
5 · Leadership	Direction impliquée : politique, rôles, responsabilités, moyens.	Politique signée, comptes rendus de comité, définition de rôles	Politique signée il y a trois ans, jamais revue, jamais déclinée
6 · Planification	Appréciation des risques, traitement, déclaration d'applicabilité, objectifs.	Méthode d'appréciation, registre de risques, SoA, objectifs mesurables	Risques identifiés sans propriétaire ni échéance
7 · Support	Ressources, compétences, sensibilisation, communication, informations documentées.	Matrice de compétences, plan de sensibilisation, gestion documentaire	Sensibilisation annuelle générique, sans mesure d'efficacité
8 · Fonctionnement	Mettre en œuvre ce qui a été planifié, maîtriser les prestataires et les évolutions.	Procédures appliquées, suivi des changements, contrats fournisseurs	Procédures écrites jamais suivies : le document vit sa vie
9 · Évaluation	Surveillance, mesure, audit interne, revue de direction.	Programme d'audit, rapports d'audit interne, revue de direction annuelle	Auto-évaluation déguisée en audit interne : la même personne contrôle son travail
10 · Amélioration	Non-conformités, actions correctives, amélioration continue.	Fiches de non-conformité, actions correctives, suivi d'efficacité	Non-conformités fermées sans analyse de cause racine

Un SMSI se juge à ses traces : si une exigence n'a pas de preuve datée, elle n'existe pas pour un auditeur.

Annexe A : quatre thèmes, 93 mesures

La répartition à connaître, avec ce qui rate le plus souvent dans chaque thème.

Thème	Nombre	Exemples	Ce qui rate le plus souvent
Organisationnelles (A.5)	37	Politiques, rôles et responsabilités, gestion des incidents, continuité, relations fournisseurs, menaces liées au cloud	Politiques écrites jamais déclinées dans les outils ; fournisseurs jamais évalués ni revus
Personnes (A.6)	8	Sélection, sensibilisation, télétravail, signalement des incidents, fin de contrat	Sensibilisation annuelle générique, sans mesure d'efficacité ni retour d'expérience
Physiques (A.7)	14	Zones sécurisées, accès physique, bureaux, équipements, destruction de supports	Accès physiques des prestataires accordés puis jamais revus
Technologiques (A.8)	34	Identité, chiffrement, journalisation, sécurité des développements, réseau, sauvegardes, cloud	Journalisation activée mais non testée ; secrets hors coffre ; sauvegardes non restaurées

La SoA justifie l'inclusion ou l'exclusion de chaque mesure : « non applicable, voici pourquoi » est une réponse valable — « on verra plus tard » n'en est pas une.

Carte des référentiels : lequel utiliser pour quoi

Neuf textes qui reviennent en permanence, et le piège d'usage de chacun.

Vérifié le 26/09/2026

Référentiel	Nature	Ce qu'il apporte	Piège d'usage
ISO/IEC 27001:2022 (+ Amd 1:2024)	Exigences certifiables pour un SMSI ; l'amendement 2024 ajoute le changement climatique au contexte (4.1, 4.2)	Un système managé, auditable et reconnu en Europe	Confondre certification et sécurité réelle : on certifie un système, pas un niveau de résistance
ISO/IEC 27002:2022	Recueil de mesures (guide)	Le détail des 93 mesures et un vocabulaire commun	Le présenter comme une exigence : c'est un guide, pas un cahier des charges
NIST CSF 2.0	Cadre volontaire (6 fonctions, 22 catégories)	Excellent pivot pour rattacher plusieurs réglementations	Répondre oui/non sans preuve : le taux de couverture devient décoratif
CIS Controls v8.1	18 contrôles opérationnels priorisés	Le langage de l'exploitation, très concret	Le suivre seul et ignorer la gouvernance et le risque
SOC 2	Attestation (critères de confiance)	Attendu par les clients SaaS anglo-saxons	Croire qu'il remplace ISO 27001 — ou l'inverse : les périmètres diffèrent
NIS2	Directive UE (art. 21 mesures, art. 23 notification)	Obligation juridique avec délais et responsabilité de la direction	Attendre la transposition nationale : les obligations s'imposent déjà par contrat
DORA	Règlement UE (secteur financier)	Risque TIC, incidents, tests de résistance, prestataires tiers	Oublier le registre des prestataires et la capacité de sortie (réversibilité)
CRA	Règlement UE (produits comportant du numérique)	Sécurité produit, SBOM, notification des vulnérabilités exploitées	Ne pas qualifier son périmètre : fabricant, importateur et distributeur ont des rôles différents
RGPD	Règlement UE (données personnelles)	Protection des personnes, analyse d'impact, notification sous 72 h	Le traiter comme un sujet purement juridique, déconnecté de la sécurité

Un seul pivot, plusieurs déclinaisons : maintenir quatre copies d'un même contrôle aboutit toujours à quatre vérités différentes.

Notifications : qui, quoi, quand

Quatre régimes, des délais courts, et une procédure unique à écrire avant l'incident.

Vérifié le 26/09/2026

Régime	Déclencheur	Délais	Piège
CRA	Vulnérabilité activement exploitée ou incident grave affectant un produit.	Vulnérabilité : 24 h (alerte précoce) · 72 h (notification) · 14 j après le correctif (rapport final). Incident grave : 24 h · 72 h · 1 mois	Ne pas savoir qui notifie : c'est le fabricant, pas le client
NIS2	Incident significatif dans une entité essentielle ou importante.	24 h (alerte) · 72 h (évaluation initiale) · 1 mois (rapport final)	Confondre « significatif » et « grave » : les critères sont écrits, il faut les lire avant
RGPD	Violation de données personnelles susceptible d'engendrer un risque pour les personnes.	72 h auprès de l'autorité de contrôle ; information des personnes si risque élevé	Attendre la fin de l'investigation pour prévenir : le délai court dès la connaissance
DORA	Incident lié aux technologies avec impact majeur sur les services financiers.	4 h après classification comme majeur (au plus tard 24 h après la connaissance) · 72 h (rapport intermédiaire) · 1 mois (rapport final) — règlement délégué (UE) 2025/301	Isoler le sujet « incident TIC » de la classification d'incident : les deux se recoupent

Un incident peut déclencher les quatre : la procédure doit désigner un décideur, trois canaux et un modèle de notification prêt à remplir.

SMSI ISO 27001 — la boucle qui transforme une politique en preuve à regarder : la non-conformité qui revient vers la mise en œuvre, pas vers le document Plein écran

NIST CSF 2.0 — six fonctions et rôle de pivot à regarder : GOUVERNER en position transversale, d'où tout se décline Plein écran

À retenir

Un contrôle se prouve par une exécution tracée : date, opérateur, résultat — sinon il est déclaré, pas testé.
La déclaration d'applicabilité porte la logique : ce qui est exclu doit être justifié, pas oublié.
Un référentiel pivot évite de maintenir quatre vérités parallèles (NIS2, DORA, CRA, RGPD).
Les délais de notification courent dès la connaissance de l'incident, pas à la fin de l'investigation.

Pièges classiques

Faire de la conformité un exercice documentaire : le classeur est beau, les contrôles ne tournent pas.
Confondre audit interne et auto-évaluation : celui qui conçoit ne peut pas être seul à contrôler.
Fermer une non-conformité sur la déclaration « c'est corrigé » sans test de non-régression.
Répondre « conforme » partout pour rassurer : l'écart réel se découvre toujours, et plus cher.

Auto-check — 3 questions pour vérifier que c'est acquis

Quelle est la différence entre une mesure incluse dans la SoA et une mesure testée ?
Incluse : la mesure est déclarée applicable et s'applique dans le périmètre. Testée : on a vérifié par une exécution tracée qu'elle fonctionne réellement. Beaucoup d'organisations ont la première sans la seconde — c'est exactement ce que l'auditeur cherche à distinguer.
Un incident touche des données personnelles et concerne aussi un produit logiciel. Que faire ?
Appliquer la procédure unique : qualification (RGPD + CRA, voire NIS2 selon le secteur), désignation du décideur, notification à 72 h pour le RGPD et 24 h/72 h pour le CRA, communication coordonnée, puis retour d'expérience. Les régimes se cumulent, ils ne se remplacent pas.
Pourquoi choisir un référentiel pivot plutôt qu'une matrice par réglementation ?
Parce que les contrôles sont les mêmes à 80 % : un pivot (CSF 2.0 ou ISO 27001) évite de maintenir plusieurs vérités divergentes, permet de prouver une fois et de décliner vers NIS2, DORA, CRA et RGPD sans recompter.

GRC et conformité Intermédiaire 20 min #TPRM#DORA#NIS 2#réversibilité

Tiers et chaîne d'approvisionnement

Un fournisseur est une extension du SI : ses accès, ses sous-traitants et ses défaillances deviennent ceux de l'organisation.

L'essentiel en 30 secondes

La gestion des tiers (TPRM) proportionne l'effort à la criticité : un prestataire qui détient des données ou un accès d'administration ne se traite pas comme un fournisseur de fournitures.
Le contrat est un contrôle : droit d'audit, notification des incidents, localisation des données, sous-traitance encadrée, réversibilité et stratégie de sortie.
DORA impose aux entités financières un registre d'information de tous les accords TIC et des stratégies de sortie ; NIS 2 (art. 21, § 2, d) fait de la sécurité de la chaîne d'approvisionnement une mesure obligatoire.
La confiance se vérifie dans le temps : preuves à jour, suivi des incidents, et accès techniques du prestataire traités comme des accès à privilèges.

niveaux de criticité

exigences proportionnées

registre d'information DORA

tous les accords TIC, tenu à jour

prestataires TIC critiques désignés

autorités européennes, 18/11/2025

Les autres modules sécurisent ce que l'organisation opère ; celui-ci traite ce qu'elle confie à d'autres. Il donne une méthode de classement des tiers, les clauses qui comptent, les exigences de DORA et de NIS 2, et la façon de garder la main sur les accès des prestataires.

🔢 Chiffres 📊 Classer les tiers par criticité 📊 Les clauses qui font la différence 📊 DORA et NIS 2 : ce qu'ils imposent sur les tiers 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Classer les tiers par criticité

Trois niveaux ; l'effort de vérification suit le niveau, pas la taille du contrat.

Niveau	Critères	Exigences à l'entrée	Suivi
Critique	Soutient une fonction critique, détient des données sensibles ou dispose d'un accès d'administration ; difficile à remplacer.	Analyse de risque, preuves d'audit (ISO 27001 au périmètre vérifié, rapport SOC 2 de type II), clauses complètes, plan de sortie.	Revue annuelle, suivi des incidents, audit possible, plan de sortie testé
Important	Accès à des données internes ou connexion au SI ; remplaçable en quelques mois.	Questionnaire de sécurité, certifications, clauses de notification et de confidentialité.	Revue tous les deux ans, preuves mises à jour
Standard	Ni données sensibles ni accès au SI.	Clauses contractuelles types.	Revue à l'échéance du contrat

Le périmètre d'une certification se lit : un certificat ISO 27001 qui couvre le siège social ne dit rien du service réellement fourni.

Les clauses qui font la différence

Six clauses ; chacune a un signe d'alerte reconnaissable à la lecture.

Clause	Ce qu'elle garantit	Signe d'alerte
Notification d'incident	Délai et contenu de la notification, contact d'astreinte.	« Dans les meilleurs délais », sans durée chiffrée
Droit d'audit et d'accès	Accès aux preuves, audit sur place ou mutualisé, suivi des écarts.	Audit refusé, ou limité aux documents commerciaux
Sous-traitance	Liste des sous-traitants, information préalable, obligations répercutées en cascade.	Sous-traitance libre, sans information
Localisation et droit applicable	Lieux de traitement et de stockage, juridiction, accès des autorités étrangères.	Localisation « selon les besoins du service »
Réversibilité et sortie	Restitution des données dans un format exploitable, assistance à la transition, délais.	Restitution en format propriétaire, sans délai garanti
Sécurité et niveaux de service	Exigences minimales, indicateurs, pénalités, résiliation pour manquement.	Aucune exigence de sécurité mesurable

DORA et NIS 2 : ce qu'ils imposent sur les tiers

Deux textes, une même logique : connaître ses dépendances, les encadrer par contrat, pouvoir en sortir.

Vérifié le 27/09/2026

Texte	Exigence	Conséquence pratique
DORA · art. 28	Stratégie de risque lié aux tiers TIC, registre d'information de tous les accords, évaluation avant contrat, stratégies de sortie pour les fonctions critiques.	Registre tenu à jour et remis chaque année à l'autorité ; plan de sortie testé pour les prestataires critiques
DORA · art. 30	Dispositions contractuelles essentielles : description des services, localisation, niveaux de service, notification d'incident, droits d'accès et d'audit, résiliation.	Contrats revus, avenants pour les accords existants
DORA · art. 31 et suivants	Surveillance directe des prestataires TIC critiques par les autorités européennes de surveillance.	19 prestataires désignés le 18/11/2025 ; cette surveillance n'exonère pas l'entité de sa propre gestion du risque
NIS 2 · art. 21, § 2, d)	Sécurité de la chaîne d'approvisionnement, y compris les relations avec les fournisseurs directs.	Exigences de sécurité dans les contrats, évaluation des fournisseurs
NIS 2 · art. 21, § 3	Tenir compte des vulnérabilités propres à chaque fournisseur direct et de la qualité de ses pratiques, développement sécurisé compris.	Évaluation fournisseur par fournisseur, pas un questionnaire unique

Registre d'information : modèles fixés par le règlement d'exécution (UE) 2024/2956, collecte annuelle par les autorités nationales pour les autorités européennes. Liste des prestataires critiques publiée par l'EBA, l'EIOPA et l'ESMA.

Tiers — le cycle de vie d'un fournisseur à regarder : le passage de relais entre métier et sécurité à chaque étape, et la réévaluation qui revient au classement Plein écran

À retenir

L'effort se proportionne à la criticité : données sensibles, accès d'administration et difficulté de remplacement.
Le contrat est un contrôle : notification chiffrée, audit, sous-traitance, localisation, réversibilité.
Les accès techniques d'un prestataire sont des accès à privilèges : nominatifs, bornés, enregistrés, révocables.
Un plan de sortie non testé ne permet pas de sortir : il se répète pour les prestataires critiques.

Pièges classiques

Envoyer le même questionnaire de 300 questions à tous les fournisseurs, puis ne rien en faire.
Accepter une certification sans lire son périmètre.
Oublier les sous-traitants du sous-traitant : l'incident vient souvent du rang 2.
Laisser un compte de télémaintenance permanent et partagé « parce que le contrat le prévoit ».

Auto-check — 3 questions pour vérifier que c'est acquis

Un éditeur SaaS critique refuse tout audit. Que faire ?
Demander des preuves indépendantes équivalentes (rapport SOC 2 de type II récent, certificat ISO 27001 au périmètre vérifié, résultats de tests d'intrusion), proposer un audit mutualisé avec d'autres clients, et compenser par des contrôles côté client (journaux, chiffrement, réversibilité). Pour une fonction critique d'une entité soumise à DORA, le droit d'accès et d'audit n'est pas négociable.
Que contient une stratégie de sortie crédible ?
Les données à récupérer et leur format, une solution de remplacement identifiée, la durée et le coût de la transition, l'assistance contractuelle du prestataire sortant, et un test daté, au moins sur table. Sans ces éléments, la dépendance est subie.
Comment traiter les accès de télémaintenance d'un prestataire ?
Comme des accès à privilèges : comptes nominatifs, passage par un bastion ou un courtier d'accès, activation à la demande et limitée dans le temps, session enregistrée, revue régulière et révocation immédiate en fin de contrat.

Défense et données Intermédiaire 24 min #SOC#NIST 800-61#RTO#sauvegardes

SOC, réponse à incident et résilience

Détecter vite, contenir sans détruire la preuve, restaurer pour de vrai : trois compétences différentes, une même chaîne.

L'essentiel en 30 secondes

La chaîne de valeur du SOC va de la télémétrie à la décision humaine : sans télémétrie collectée, il n'y a rien à détecter ; sans procédure, rien à exécuter.
Les seuls indicateurs qui comptent sont le délai de détection et le délai de remédiation — pas le nombre d'alertes générées.
Contenir n'est pas éteindre : on isole en préservant la preuve (mémoire, journaux, images), sinon l'analyse devient impossible.
La résilience se prouve par des exercices : RTO/RPO décidés par l'activité, restauration testée, sauvegardes déconnectées et immuables (règle 3-2-1-1-0).

étapes de la chaîne SOC

télémétrie → décision humaine

indicateurs qui comptent

délai de détection, délai de remédiation

3-2-1-1-0

règle de sauvegarde

copies isolées, immuables, testées

Détecter et répondre ne s'improvise pas au moment de l'incident. Ce module couvre la chaîne de valeur du SOC, le cycle de réponse aligné sur le CSF 2.0, et la mécanique de résilience qui décide de la survie d'un service.

🔢 Chiffres 📊 La chaîne de valeur du SOC 📊 Réponse à incident : phases, décisions, preuves 📊 Sauvegardes : la règle 3-2-1-1-0 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

La chaîne de valeur du SOC

Cinq étapes ; si l'une est faible, les suivantes ne compensent pas.

Étape	Objectif	Indicateur utile	Piège
1 · Télémétrie	Collecter ce qui permet de détecter et de reconstituer : identités, postes, réseau, cloud, applications.	Couverture par source et par actif critique	Collecter beaucoup et n'exploiter rien : le volume n'est pas la couverture
2 · Plateforme	Normaliser, corréler, conserver — avec une rétention adaptée aux délais d'investigation.	Durée de rétention utile, coût par source	Rétention de 30 jours sur une attaque qui dure trois mois
3 · Analytique	Détecter par règles versionnées et par comportement, avec un tri par risque réel.	Taux de vrais positifs, couverture des techniques adverses	Empiler des règles sans réduire le bruit : l'équipe cesse de regarder
4 · Réponse	Contenir, éradiquer, restaurer selon des procédures connues et des rôles nommés.	Délai de confinement, taux de procédures appliquées	Improviser le confinement et détruire les preuves
5 · Humain	Décider : escalade, crise, communication, obligations réglementaires.	Délai de décision, qualité du retour d'expérience	Confier la décision à un outil ou à une seule personne non suppléée

Objectifs de temps à écrire et à mesurer : détection en minutes pour les signaux forts, confinement en heures, restauration selon le RTO validé.

Réponse à incident : phases, décisions, preuves

Chaque phase a une décision à prendre et une trace à conserver.

Phase	Décision à prendre	Preuve à conserver	Erreur qui coûte cher
Préparer	Qui est d'astreinte, qui décide, avec quels moyens et quels accès de secours ?	Playbooks testés, annuaire de crise, exercices datés	Découvrir pendant l'incident que personne ne peut couper un accès
Détecter et qualifier	Est-ce un incident, quelle sévérité, qui est prévenu ?	Journal de qualification : heure, signaux, décision	Qualifier à la baisse pour éviter la procédure
Contenir	Quel périmètre isoler, sans détruire la preuve ?	Horodatage des actions, captures, images mémoire si pertinent	Éteindre la machine : la mémoire et les indices disparaissent
Éradiquer	Quelle est la cause racine, et qu'est-ce qui a été touché ?	Analyse de cause, liste des comptes et secrets à révoquer	Se contenter de supprimer le symptôme visible
Restaurer	Quel retour progressif, avec quelle surveillance renforcée ?	Rapport de restauration, mesures de surveillance temporaires	Reconnecter tout d'un coup sur une sauvegarde non vérifiée
Clôturer	Quelles actions datées, quels contrôles à renforcer ?	Retour d'expérience, actions avec propriétaire et échéance	Clore sans retour d'expérience : le même incident revient
Crise et obligations	Faut-il notifier, à qui, et qui communique ?	Modèle de notification horodaté, journal de crise	Attendre la fin de l'analyse pour respecter un délai qui courait déjà

Un incident se termine quand les actions du retour d'expérience sont planifiées, pas quand le service redémarre.

Sauvegardes : la règle 3-2-1-1-0

Cinq exigences qui font la différence entre une sauvegarde et une illusion.

Exigence	Ce que ça veut dire	Comment on le prouve
3 copies	Trois exemplaires des données au minimum, dont la production.	Inventaire des jeux de sauvegarde et des dépendances oubliées
2 supports différents	Deux technologies ou emplacements distincts (pas deux dossiers du même serveur).	Cartographie des supports, séparation des identifiants d'accès
1 copie hors site	Une copie dans un autre lieu ou un autre compte, isolée du réseau principal.	Test d'accès depuis le réseau compromis : doit échouer
1 copie hors ligne ou immuable	Non modifiable, non supprimable pendant la rétention (verrouillage d'objet, bande hors ligne).	Tentative de suppression refusée, documentée
0 erreur de restauration	On a restauré et vérifié l'intégrité, pas seulement écrit les données.	Rapport de restauration daté, avec durée et écarts

Un RTO et un RPO se décident avec l'activité : sans validation, ce sont des vœux techniques que personne ne tiendra en cas de crise.

SOC — chaîne de valeur, de la télémétrie à la décision à regarder : le délai entre le premier signal et le confinement Plein écran

Réponse à incident — cycle de vie, décisions et preuves à regarder : la boucle d'amélioration qui revient vers la préparation Plein écran

À retenir

Sans télémétrie collectée, la détection n'existe pas : la couverture compte plus que le volume.
Le confinement préserve la preuve : on isole, on n'éteint pas.
Un délai de remédiation mesuré vaut mieux qu'un taux de conformité déclaré.
La sauvegarde ne compte que si la restauration a été testée et chronométrée.

Pièges classiques

Mesurer l'activité du SOC au nombre d'alertes : c'est un indicateur de bruit, pas de sécurité.
Sauvegarder dans le même domaine d'administration : l'attaquant supprime les deux.
Confondre plan de reprise et sauvegarde : le premier décrit comment redémarrer, la seconde fournit la matière.
Reporter les exercices : un plan non testé est une hypothèse, pas une capacité.

Auto-check — 3 questions pour vérifier que c'est acquis

Un serveur est compromis : l'isoler ou l'éteindre ?
On isole (réseau, identités) pour préserver la mémoire et les journaux locaux. Éteindre détruit les indices volatils et complique l'analyse — sauf si le risque physique ou la propagation impose la coupure, et cela se décide explicitement.
Quelle différence entre RTO et RPO ?
Le RTO est la durée maximale d'interruption acceptée par l'activité ; le RPO est la perte de données maximale acceptable. Les deux se décident avec les métiers, par criticité, et se vérifient par des exercices de restauration.
Pourquoi la détection-as-code change-t-elle la donne ?
Parce que les règles deviennent versionnées, testées et déployées comme du code : on peut mesurer la couverture des techniques adverses, gérer les régressions et démontrer au comité ce qui est réellement détecté.

Défense et données Avancé 22 min #ATT&CK#Sigma#CTI#TLP

Ingénierie de détection et renseignement sur la menace

Une détection vaut par la technique adverse qu'elle couvre et par le test qui prouve qu'elle se déclenche — pas par le nombre de règles.

L'essentiel en 30 secondes

L'ingénierie de détection part d'une hypothèse de menace (une technique ATT&CK, sur un actif précis), pas de la source de journaux qui se trouve disponible.
Une règle est un produit : données requises, logique, test d'attaque simulé, gestion des faux positifs, propriétaire et date de revue.
Sigma décrit une détection indépendamment de l'outil : la même règle se traduit vers plusieurs SIEM, se relit en revue de code et se versionne.
La CTI n'a de valeur que si elle change une décision (correctif, détection, blocage) ; un indicateur technique se remplace en minutes, un mode opératoire en mois.

tactiques ATT&CK Enterprise

v19 · base de la couverture

test par règle, au minimum

sinon la règle reste une hypothèse

étiquettes TLP 2.0

CLEAR · GREEN · AMBER · AMBER+STRICT · RED

Le module SOC décrit la chaîne qui exécute ; celui-ci explique comment décider quoi détecter. Il relie la menace (ATT&CK, renseignement) à des règles versionnées et testées, et donne les indicateurs qui disent si la couverture progresse vraiment.

🔢 Chiffres 📊 Le cycle de vie d'une détection 📊 Mesurer la couverture sans se mentir 📊 La CTI qui sert à décider 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Le cycle de vie d'une détection

Six étapes ; une règle qui saute le test n'est qu'une intention.

Étape	Ce qu'on produit	Critère de sortie
1 · Hypothèse	Technique visée (identifiant ATT&CK), actifs concernés, scénario de l'attaquant.	Hypothèse écrite, rattachée à un risque ou à un renseignement
2 · Données	Sources nécessaires (identité, EDR, cloud, réseau) et champs requis.	Source collectée, normalisée, conservée assez longtemps pour enquêter
3 · Logique	Règle en Sigma ou dans le langage du SIEM, seuils, exclusions justifiées.	Revue par un pair, règle versionnée dans le dépôt
4 · Test	Émulation de la technique en environnement contrôlé.	Alerte déclenchée par le test, silence sur l'activité normale mesurée
5 · Déploiement	Mise en production par pipeline, runbook de réponse associé.	Runbook lié à l'alerte, propriétaire nommé
6 · Mesure et revue	Taux de vrais positifs, volume, délai de traitement, date de revue.	Règle revue, ajustée ou retirée à échéance

C'est le « detection-as-code » du module SOC, détaillé : la règle vit dans un dépôt, passe en CI et porte son test d'émulation.

Mesurer la couverture sans se mentir

Cinq indicateurs ; chacun a sa façon de paraître bon sans l'être.

Indicateur	Ce qu'il mesure	Piège
Couverture ATT&CK testée	Part des techniques prioritaires qui ont au moins une détection testée récemment (par exemple sur 90 jours).	Déclarer une technique « couverte » sur la foi de la documentation de l'éditeur
Couverture des données	Part des actifs critiques dont les journaux nécessaires arrivent réellement.	Un tableau de bord vert alors qu'une source est muette depuis un mois
Taux de vrais positifs	Alertes confirmées sur alertes traitées, règle par règle.	Supprimer une règle bruyante au lieu de l'affiner
Délai de détection	Temps entre l'action de l'attaquant (ou du test) et l'alerte.	Ne mesurer que le délai de traitement, une fois l'alerte ouverte
Âge des règles	Règles non revues depuis un an, règles jamais déclenchées.	Prendre une règle jamais déclenchée pour la preuve d'une absence d'attaque

Les techniques prioritaires se choisissent avec le threat model et la CTI du secteur : couvrir 100 % d'ATT&CK n'est ni possible ni utile.

La CTI qui sert à décider

Quatre niveaux de renseignement, quatre publics, quatre types de décision.

Niveau	Pour qui	Question traitée	Exemple de décision
Stratégique	Direction, comité des risques	Quels acteurs visent le secteur, avec quels objectifs ?	Arbitrer un budget de résilience face au rançongiciel
Opérationnel	Responsable sécurité, cellule de crise	Quelle campagne est en cours, avec quel mode opératoire ?	Durcir en urgence un service exposé visé par une campagne
Tactique	Ingénierie de détection, architecture	Quelles techniques (TTP) ces acteurs emploient-ils ?	Écrire ou tester les détections des techniques observées
Technique	SOC, outils de filtrage	Quels indicateurs (IP, domaines, empreintes) bloquer maintenant ?	Blocage temporaire, recherche rétroactive dans les journaux

Pyramide de la douleur (David Bianco) : une empreinte ou une adresse IP se remplace en minutes, un mode opératoire en mois — les détections comportementales durent. Partage selon le TLP 2.0 du FIRST (2022).

Ingénierie de détection et CTI — de la menace à la règle testée à regarder : la boucle de couverture qui ramène la revue vers de nouvelles hypothèses Plein écran

À retenir

Une détection part d'une technique adverse et d'un actif, pas d'une source de journaux disponible.
Une règle sans test d'émulation reste une hypothèse ; une règle sans propriétaire finit muette.
La couverture se mesure en techniques prioritaires testées, pas en nombre de règles.
La CTI utile change une décision : correctif, détection, blocage ou arbitrage.

Pièges classiques

Acheter un flux d'indicateurs sans capacité à l'exploiter : des milliers d'adresses IP périmées dans le pare-feu.
Afficher une matrice ATT&CK « verte » remplie d'après la documentation de l'éditeur.
Désactiver les règles bruyantes sans analyse : le bruit cachait parfois le signal.
Diffuser un renseignement TLP:AMBER sur une liste ouverte : la source ne partagera plus.

Auto-check — 3 questions pour vérifier que c'est acquis

Une campagne vise le secteur avec des jetons OAuth volés. Par quoi commencer ?
Extraire les techniques (TTP) du rapport, vérifier que les journaux d'identité et de consentement OAuth sont collectés, écrire ou adapter une détection, la tester par émulation, puis chercher rétroactivement dans l'historique. Les indicateurs techniques du rapport servent à cette recherche, pas de protection durable.
Pourquoi écrire les règles en Sigma plutôt que directement dans le SIEM ?
Parce que la logique devient portable et versionnable : la même règle se traduit vers plusieurs outils, se relit en revue de code et survit à un changement de SIEM. Le langage natif sert à l'optimisation, pas de source de vérité.
Une règle ne s'est jamais déclenchée depuis deux ans. Bonne nouvelle ?
Pas forcément : la source peut être muette, un champ renommé ou la logique cassée. Le test d'émulation se rejoue : s'il ne déclenche pas l'alerte, la règle est réparée ou retirée.

Défense et données Intermédiaire 20 min #BIA#PCA / PRA#ISO 22301#crise

Continuité d'activité et gestion de crise

La continuité ne se décide pas dans la salle serveur : c'est l'activité qui dit ce qui redémarre d'abord, en combien de temps, et avec quelle perte acceptable.

L'essentiel en 30 secondes

Le BIA (bilan d'impact sur l'activité) part des processus métier, pas des serveurs : pour chacun, la durée d'interruption tolérable, la perte de données acceptable et les dépendances.
Trois dispositifs, trois questions : le PCA garde l'activité en marche (mode dégradé), le PRA remet le SI en service, la gestion de crise décide et communique.
Le scénario de référence est le SI indisponible en entier (rançongiciel, annuaire compromis) : un plan qui suppose l'annuaire, la messagerie ou la supervision disponibles échoue ce jour-là.
Un plan non exercé est une hypothèse : exercices sur table, tests de bascule et restauration chronométrée, suivis d'actions correctives datées.

seuils par processus

DMIA · RTO · RPO

dispositifs distincts

continuité · reprise · crise

scénario de référence

SI entièrement indisponible

Le module SOC traite l'incident ; celui-ci traite ce qui se passe pendant qu'il dure. Il donne la méthode du BIA, la différence entre plan de continuité, plan de reprise et gestion de crise, et le programme d'exercices qui transforme un document en capacité.

🔢 Chiffres 📊 Du BIA aux objectifs de reprise 📊 Continuité, reprise, crise : qui fait quoi 📊 Ce que les textes exigent sur la continuité 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Du BIA aux objectifs de reprise

Cinq étapes ; les objectifs de reprise sont des décisions de l'activité, arbitrées par la direction.

Étape	Ce qu'on établit	Qui décide	Livrable
1 · Processus critiques	Les activités dont l'arrêt met en cause la mission, la conformité ou la trésorerie.	Direction et métiers	Liste hiérarchisée des processus
2 · Impacts dans le temps	Ce que coûte l'arrêt à 4 h, 24 h, 72 h, une semaine : financier, réglementaire, humain, image.	Métiers, avec la gestion des risques	Courbe d'impact par processus
3 · Seuils	DMIA, RTO et RPO par processus, cohérents entre eux.	Métiers, arbitrés par la direction	Objectifs de reprise signés
4 · Dépendances	Applications, données, identités, prestataires, locaux et personnes clés derrière chaque processus.	Architecture et métiers	Cartographie des dépendances
5 · Écarts	Comparaison entre les objectifs et ce que l'infrastructure sait réellement faire.	Architecture, avec le RSSI	Plan d'action chiffré, ou risque accepté par écrit

Si le RTO d'une application est plus court que celui de l'annuaire ou du réseau dont elle dépend, l'objectif est faux : les dépendances fixent le plancher.

Continuité, reprise, crise : qui fait quoi

Quatre dispositifs complémentaires ; aucun ne remplace les autres.

Dispositif	Question traitée	Contenu minimal	Preuve de capacité
PCA · plan de continuité d'activité	Comment l'activité continue-t-elle pendant l'interruption ?	Modes dégradés par processus, procédures manuelles, sites et moyens de repli, rôles.	Exercice métier en mode dégradé, daté
PRA · plan de reprise d'activité	Comment le SI revient-il, dans quel ordre, en combien de temps ?	Ordre de reprise par dépendances, sauvegardes isolées, environnement de reconstruction, runbooks.	Restauration chronométrée, comparée au RTO
Gestion de crise	Qui décide, qui communique, qui notifie ?	Cellule de crise, annuaire hors ligne, moyens de communication de secours, main courante, modèles de notification.	Exercice de crise sur table ou simulé, retour d'expérience
Plan de reconstruction	Comment repartir d'un SI de confiance après une compromission ?	Cœur de confiance (identité, administration) reconstruit en premier, secrets renouvelés, réintégration progressive.	Répétition de la reconstruction du cœur d'identité

Après un rançongiciel, restaurer ne suffit pas : restaurer sur une infrastructure encore compromise rejoue l'attaque. La reconstruction du cœur de confiance précède la reprise des applications.

Ce que les textes exigent sur la continuité

Trois références ; les mêmes preuves servent aux trois.

Vérifié le 27/09/2026

Texte	Ce qu'il exige	Conséquence d'architecture
NIS 2 · art. 21, § 2, c)	Continuité des activités : gestion des sauvegardes, reprise après sinistre, gestion des crises.	Sauvegardes isolées et testées, plan de reprise et cellule de crise documentés
DORA · art. 11 et 12	Politique de continuité des TIC, plans de réponse et de rétablissement testés au moins une fois par an, politique de sauvegarde et de restauration.	Exercices annuels tracés, sauvegardes séparées physiquement et logiquement de la source
ISO 22301:2019	Système de management de la continuité : BIA, stratégies, plans, exercices, amélioration continue.	Cadre certifiable, qui partage le cycle PDCA du SMSI ISO 27001

NIS 2 (directive (UE) 2022/2555) s'applique à travers la transposition de chaque État membre ; DORA (règlement (UE) 2022/2554) s'applique directement aux entités financières depuis le 17 janvier 2025.

Continuité — du BIA à la reprise à regarder : le cœur de confiance reconstruit avant les applications, et le retour d'expérience qui revient aux seuils Plein écran

À retenir

Le BIA part des processus métier : les objectifs de reprise sont des décisions de l'activité, pas des paramètres techniques.
Les dépendances fixent le plancher : aucune application ne redémarre avant l'identité, le réseau et les sauvegardes dont elle dépend.
Le scénario dimensionnant est le SI entièrement indisponible ; la crise se gère avec des moyens extérieurs au SI.
Une capacité se prouve par l'exercice : restauration chronométrée, bascule testée, retour d'expérience daté.

Pièges classiques

Stocker le PCA et l'annuaire de crise uniquement sur le SI qu'ils sont censés secourir.
Afficher un RTO de 4 heures sans avoir jamais restauré l'application en moins de deux jours.
Confondre haute disponibilité et reprise : la réplication recopie aussi le chiffrement du rançongiciel.
N'exercer que l'équipe technique : la décision, la communication et les notifications restent improvisées.

Auto-check — 3 questions pour vérifier que c'est acquis

Un métier demande un RTO de 2 heures pour une application qui dépend d'un annuaire dont le RTO est de 24 heures. Que répondre ?
Que l'objectif est incohérent : l'application ne redémarre pas avant l'annuaire. Soit l'annuaire reçoit un objectif plus court et les moyens associés, soit l'application prévoit un mode dégradé sans lui, soit le RTO est révisé. La décision est tracée et arbitrée par la direction.
Quelle différence entre PCA et PRA ?
Le PCA maintient l'activité pendant l'interruption (modes dégradés, procédures manuelles, repli) ; le PRA restaure le système d'information dans l'ordre fixé par les dépendances et dans les délais convenus. Les deux s'appuient sur le BIA et se testent séparément.
Pourquoi la gestion de crise doit-elle disposer de moyens extérieurs au SI ?
Parce que le scénario de référence rend le SI indisponible ou non fiable : messagerie et annuaire peuvent être compromis, voire surveillés par l'attaquant. Annuaire de crise imprimé, téléphones et canal de communication de secours permettent de décider et de notifier quand même.

Défense et données Intermédiaire 22 min #KMS#PKI#secrets#post-quantique

Cryptographie, clés et données

Chiffrer ne suffit pas : la vraie question est qui détient la clé, pour combien de temps, et comment on la remplace.

L'essentiel en 30 secondes

Trois états à couvrir : au repos, en transit, et en usage (le plus souvent oublié, et le plus difficile).
Un secret qui vit dans le code, un ticket ou un état d'infrastructure n'est pas protégé : il est seulement en attente de fuite.
KMS, HSM, PKI interne et coffre de secrets sont quatre usages différents — un seul secret partagé partout est le contraire d'une architecture.
Post-quantique : le risque est présent (intercepter aujourd'hui pour déchiffrer demain) ; la réponse commence par l'agilité — inventaire, algorithmes paramétrables, rotation répétée.

états à couvrir

repos · transit · usage

niveaux de classification

public · interne · confidentiel · secret

vagues post-quantiques

inventaire → hybridation → signatures → retrait

conditions d'agilité

paramétrable · multi-algorithmes · rotation testée

La cryptographie est le dernier rempart : quand tout le reste est tombé, c'est elle qui protège encore la donnée. Ce module couvre la détention des clés, la gestion des secrets, la classification des données et la trajectoire post-quantique.

🔢 Chiffres 📊 Qui détient la clé ? Quatre modèles 📊 KMS, HSM, PKI, coffre de secrets : qui fait quoi 📊 Classification : quatre niveaux et ce qu'ils imposent 📊 Post-quantique : quatre vagues et une priorité 🧩 Schémas (3)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Qui détient la clé ? Quatre modèles

Le même chiffrement ne protège pas la même chose selon qui contrôle la clé.

Modèle	Ce que ça protège	Ce que ça ne protège pas	Cas d'usage
Clé gérée par le fournisseur	L'accès au support physique et les erreurs d'exploitation de bas niveau.	Une injonction légale visant le fournisseur, ou une compromission de son plan de contrôle.	Données peu sensibles, services managés, rapidité de mise en œuvre
Clé gérée par le client (dans son compte)	La séparation des périmètres : un accès perdu chez le client ne donne pas la donnée.	Une mauvaise politique de clé côté client : wildcard, clé partagée, rotation absente.	Données métier sensibles, environnements multi-comptes
Clé détenue hors du cloud (BYOK / HYOK)	Le contrôle juridique et opérationnel de la clé racine.	La disponibilité : perdre la clé, c'est perdre la donnée.	Exigences de souveraineté, données réglementées
Clé matérielle (HSM)	L'extraction de la clé : elle ne sort pas du module.	Le mauvais usage fait avec la clé depuis l'application autorisée.	Signature, PKI racine, chiffrement à haute criticité

Question à poser systématiquement en revue : « qui peut utiliser cette clé, depuis où, et comment le prouve-t-on ? »

KMS, HSM, PKI, coffre de secrets : qui fait quoi

Quatre briques complémentaires — les confondre est une erreur d'architecture classique.

Brique	Rôle	Ce qu'elle protège	Erreur classique
Gestionnaire de clés (KMS)	Créer, stocker, utiliser et faire tourner les clés de chiffrement, avec journalisation des usages.	Les clés elles-mêmes et la traçabilité de leur usage.	Une seule clé pour toute l'organisation, sans politique ni rotation
Module matériel (HSM)	Conserver les clés racines hors d'atteinte logique : elles ne sortent pas du module.	Les clés les plus critiques (signature, autorité racine).	Garder la clé racine dans un fichier de configuration « plus simple »
Autorité de certification (PKI)	Émettre et révoquer des certificats, avec des durées de vie courtes.	L'identité des services et la confiance mutuelle (mTLS).	Certificats de dix ans, liste de révocation jamais publiée ni testée
Coffre de secrets	Stocker et distribuer les secrets applicatifs (mots de passe, jetons) avec audit et rotation.	Les secrets d'exécution, hors du code et de l'état d'infrastructure.	Secrets dans les variables d'environnement du pipeline, visibles de tous

Le chiffrement d'enveloppe (une clé de données protégée par une clé maîtresse) permet de tourner la clé maîtresse sans réécrire toutes les données : c'est ce qui rend la rotation praticable.

Classification : quatre niveaux et ce qu'ils imposent

Une donnée mal classée n'est protégée par aucune politique — elle est seulement espérée protégée.

Niveau	Exemples	Ce que ça impose	Piège
Public	Site vitrine, documentation produit, offres d'emploi.	Intégrité et disponibilité ; diffusion maîtrisée.	Publier par erreur un document interne non classé
Interne	Procédures, comptes rendus, données d'exploitation non sensibles.	Accès réservé aux collaborateurs et prestataires habilités, journalisation des accès.	Tout laisser « interne par défaut » y compris le sensible
Confidentiel	Données clients, contrats, données financières, journaux contenant des identifiants.	Chiffrement au repos et en transit, accès nominatif, traçabilité, restriction de partage externe.	Partager par lien public « le temps d'une réunion »
Secret / hautement critique	Données réglementées, secrets industriels, clés, données de sécurité.	Chiffrement avec clés dédiées, séparation des environnements, journalisation immuable, DLP strict.	Mettre ces données dans le même compartiment que le reste pour simplifier

La classification doit être rafraîchie : les données se déplacent, se copient dans des exports, des sauvegardes, des environnements de test.

Post-quantique : quatre vagues et une priorité

Le risque n'est pas futur : ce qui est intercepté aujourd'hui peut être déchiffré demain.

Vérifié le 26/09/2026

Vague	Ce qu'on fait	Pourquoi cette priorité	Piège
1 · Inventaire et agilité	Inventorier les algorithmes, clés et certificats (inventaire cryptographique) et rendre l'algorithme paramétrable.	Sans inventaire, aucune migration n'est planifiable ; l'agilité est le seul prérequis durable.	Attendre la fin de l'inventaire pour rendre le code paramétrable
2 · Hybridation des échanges de clés	Combiner un algorithme post-quantique et un algorithme classique sur les flux à longue conservation.	Protège contre l'interception aujourd'hui pour déchiffrement demain (HNDL).	Migrer tout en même temps plutôt que par criticité et durée de conservation
3 · Signatures et racines de confiance	Migrer les signatures et les autorités racines, avec double signature pendant la transition.	Une signature forgée casse la confiance dans les mises à jour et les certificats.	Oublier les composants embarqués et les micrologiciels, difficiles à mettre à jour
4 · Retrait des algorithmes faibles	Retirer progressivement RSA et les courbes classiques là où c'est possible, avec des critères écrits.	La dette cryptographique finit toujours par devenir un risque opérationnel.	Considérer la fin comme une date : c'est un plan par périmètre, pas un couperet

Trois conditions d'agilité : algorithme paramétrable (jamais en dur), bibliothèques et matériel multi-algorithmes, rotation déjà répétée en production avant d'en avoir besoin. Jalons publics : la feuille de route coordonnée de l'UE (2025) demande des plans nationaux fin 2026, la migration des cas à haut risque fin 2030 et la généralisation fin 2035 ; le projet NIST IR 8547 déprécie RSA et les courbes elliptiques après 2030 et les interdit après 2035.

Cryptographie appliquée — clés, secrets et agilité à regarder : où vit chaque clé et comment la rotation se prouve Plein écran

Cycle de vie de la donnée — de la découverte à la destruction à regarder : le sort des clés après la destruction des données Plein écran

Trajectoire post-quantique — quatre vagues à regarder : la priorité donnée à l'agilité plutôt qu'au remplacement Plein écran

À retenir

La question n'est pas « est-ce chiffré ? » mais « qui peut utiliser cette clé, et comment le prouve-t-on ? ».
Un secret partagé dans le code, un ticket ou un état d'infrastructure est un secret déjà fuité en puissance.
La rotation de clés doit être testée en production avant d'être nécessaire, pas pendant un incident.
L'agilité cryptographique se prépare des années avant la menace : c'est une décision d'architecture, pas un projet de fin d'année.

Pièges classiques

Choisir un modèle de clés pour la simplicité sans évaluer qui peut y accéder juridiquement et opérationnellement.
Tourner les clés une fois puis arrêter : la rotation doit être un processus répété, pas un exploit ponctuel.
Classer les données dans un fichier Excel que personne ne met à jour : la classification doit être une propriété, pas un inventaire parallèle.
Traiter le post-quantique comme un sujet de veille : les données à longue conservation sont déjà concernées.

Auto-check — 3 questions pour vérifier que c'est acquis

Un éditeur propose de gérer lui-même les clés. Quelle question poser en premier ?
Qui peut utiliser la clé, sous quelle juridiction, et avec quelle traçabilité ? Si la clé est chez le fournisseur, une injonction ou une compromission de son plan de contrôle peut donner accès à la donnée : d'où l'intérêt du modèle client, voire externe, pour les données sensibles.
Pourquoi le chiffrement d'enveloppe facilite-t-il la rotation ?
Parce qu'on ne rechiffre pas les données : on renouvelle la clé maîtresse qui protège les clés de données. La rotation devient une opération rapide et peu risquée, donc praticable régulièrement.
Que répondre à « le quantique, c'est pour 2030 » ?
Que le risque d'interception aujourd'hui est déjà couvert par la stratégie HNDL : toute donnée à longue conservation (données de santé, secrets industriels, archives) peut être déchiffrée plus tard. On commence par l'inventaire cryptographique et l'agilité, sur les données qui ont la plus longue durée de vie.

Annexes Avancé 18 min #Purdue#IEC 62443#sûreté

OT et systèmes industriels

En industrie, la sûreté des personnes prime sur la confidentialité : cette inversion change toutes les règles.

L'essentiel en 30 secondes

Le modèle Purdue (niveaux 0 à 5) reste la carte de référence : chaque niveau a des contraintes de temps réel et de sûreté différentes.
Deux règles non négociables : aucun scan actif sur le procédé (un scan peut arrêter une ligne), et exercices conjoints IT/OT avant tout incident.
Un conduit (IEC 62443) est l'unique chemin autorisé entre deux zones : filtrage protocolaire en liste blanche, unidirectionnel quand c'est possible.
L'inventaire passif précède tout : sans savoir ce qui parle sur le réseau industriel, toute segmentation est une hypothèse.

0 → 5

niveaux Purdue

du procédé physique au SI de gestion

conduit par paire de zones

tout autre chemin est interdit

scan actif sur le procédé

règle absolue, sans exception

L'OT n'est pas « l'IT en plus dur » : les priorités sont inversées (sûreté, disponibilité, intégrité, puis confidentialité), les équipements ont vingt ans et ne se patchent pas. Ce module donne la carte et les deux règles qui évitent l'accident industriel.

🔢 Chiffres 📊 Purdue : niveaux et contrôles associés 📊 Ce qui traverse le conduit — et ce qui ne passe jamais 🧩 Schémas (2)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Purdue : niveaux et contrôles associés

Ce qui protège à chaque niveau, et ce qui ne se fait jamais.

Niveau	Ce qu'on y trouve	Contrôle adapté	Interdit
Niveau 5 et 4 · SI de gestion	ERP, messagerie, postes de bureau, services partagés.	Sécurité IT classique, cloisonnement strict avec l'OT.	Établir une confiance implicite avec l'OT « puisqu'on est interne »
Niveau 3,5 · DMZ industrielle	Répliques de données, dépôts de correctifs, courtier d'accès distant.	Aucun passage direct : médiation, authentification, journalisation, unidirectionnel si possible.	Laisser un accès direct de l'IT vers la supervision
Niveau 3 · Opérations du site	Supervision centrale, historiens, ingénierie.	Cloisonnement par cellules, comptes nominatifs, journaux remontés vers le SOC.	Ouvrir un accès distant de maintenance en permanence
Niveau 2 · Supervision locale	Interfaces opérateurs, automates de conduite.	Sessions nominatives, restrictions d'usage, pas de messagerie ni de navigation.	Brancher une clé USB « juste pour un rapport »
Niveau 1 · Automatisation	Automates, capteurs et actionneurs intelligents.	Programmes versionnés et sauvegardés, accès d'ingénierie encadré.	Mettre à jour un automate sans fenêtre ni sauvegarde du programme
Niveau 0 · Procédé physique	Capteurs, actionneurs, machines.	Sûreté intrinsèque : système instrumenté de sécurité indépendant, arrêt d'urgence matériel.	Compter sur le réseau pour arrêter un procédé dangereux

Ce qui traverse le conduit — et ce qui ne passe jamais

Chaque flux entre zones est un contrôle nommé, possédé et surveillé.

Flux	Sens autorisé	Contrôle appliqué	Ce qui est interdit
Données de supervision vers l'IT	OT → IT uniquement (réplique)	Miroir en lecture seule, filtrage protocolaire, journalisation vers le SOC.	Écriture depuis l'IT vers la supervision
Journaux industriels	OT → SOC	Collecte dédiée, sonde passive, horodatage, conservation immuable.	Utiliser un compte d'administration OT partagé pour la collecte
Correctifs et dépôts	IT → OT (via dépôt contrôlé)	Dépôt intermédiaire, validation antivirale et de signature, application en fenêtre de maintenance.	Déposer un correctif directement depuis un poste de bureau
Télémaintenance constructeur	Entrant borné, sur demande	Courtier d'accès : session enregistrée, fenêtre validée, comptes nominatifs, journalisation.	Accès permanent, compte partagé, absence d'enregistrement de session
Observation de sécurité	Passif uniquement	Sonde en écoute (SPAN/TAP), aucun paquet émis vers le procédé.	Scan actif, requêtes d'énumération, script d'inventaire agressif

Le SIS (système instrumenté de sécurité) reste indépendant du réseau : cette indépendance est une exigence de sûreté, pas un choix d'architecture.

OT et ICS — niveaux industriels et contrôles associés à regarder : la frontière IT/OT et la priorité à la sûreté Plein écran

Conduits IEC 62443 — faire remonter les données sans exposer le procédé à regarder : le sens unique et le courtier d'accès distant Plein écran

À retenir

En OT, la priorité est sûreté > disponibilité > intégrité > confidentialité : elle gouverne toutes les décisions.
Un conduit unique par paire de zones, filtrage protocolaire en liste blanche, unidirectionnel quand c'est possible.
L'inventaire passif précède toute segmentation : on n'inventorie pas un réseau industriel en le scannant.
IT et OT s'entraînent ensemble : un exercice de crise séparé découvre les problèmes le jour de l'incident.

Pièges classiques

Appliquer les réflexes IT (scan actif, patch immédiat, redémarrage) sur un réseau industriel.
Laisser un accès de télémaintenance permanent « pour éviter les délais ».
Confondre segmentation logique et sûreté : l'arrêt d'urgence reste matériel.
Oublier les copies de données consommées en IT : la source ne doit jamais être exposée.

Auto-check — 3 questions pour vérifier que c'est acquis

Un constructeur demande un accès permanent à distance pour « monitorer » une machine. Que lui répondre ?
Un courtier d'accès : accès sur demande, fenêtre validée, compte nominatif, session enregistrée et journalisée, à travers la DMZ industrielle. Pas d'accès permanent ni partagé — et l'accès doit pouvoir être coupé immédiatement.
Pourquoi ne pas scanner activement un réseau industriel ?
Parce que certains équipements anciens (automates, capteurs) ne supportent pas le trafic inattendu : un scan peut provoquer un arrêt de production, voire un incident de sûreté. On inventorie par observation passive (miroir de port, sonde en écoute).
Comment prouver qu'un conduit est bien unidirectionnel ?
Par un test : une tentative de connexion dans le sens interdit doit échouer et être journalisée. Le sens unique se prouve par le refus observé, pas par la documentation de l'équipement.

Annexes Intermédiaire 20 min #IA#agents#prompt injection#OWASP LLM#ATLAS#AI Act

IA et sécurité

Un copilote fuite, un RAG se fait piéger, un agent agit : trois risques distincts, une même règle — rien ne parle directement aux données.

L'essentiel en 30 secondes

Trois usages, trois risques : copilote (fuite de données vers un tiers), RAG (injection indirecte via un document), agent (action non contrôlée sur un outil).
L'injection indirecte est le vrai vecteur : l'instruction hostile est cachée dans un contenu que le modèle consulte (page, ticket, document, télémétrie).
Aucun accès direct entre le modèle, les données et les outils : tout passe par une passerelle IA avec identité, filtrage, plafonds et journal exploitable.
Gouvernance minimale : inventaire des cas d'usage, outils en liste blanche, validation humaine sur l'action sensible, capacité d'arrêt testée.
Trois repères externes se complètent : l'OWASP Top 10 LLM (risques applicatifs), MITRE ATLAS (techniques adverses) et l'AI Act (obligations par niveau de risque, haut risque reporté au 2 décembre 2027).

usages à inventorier

copilote · RAG · agent · assistant de code

garde-fous de passerelle

identité · filtrage · périmètre · journal

conditions pour un agent

identité propre, outils bornés, plafonds, validation, journal, arrêt

02/12/2027

haut risque de l'AI Act (annexe III)

report voté par l'Omnibus IA

L'IA n'est pas un sujet à part : c'est un nouveau composant d'architecture, avec des identités, des flux et des responsabilités. Ce module donne les usages, les risques réels et les conditions à remplir avant de laisser un agent agir.

🔢 Chiffres 📊 Quatre usages, quatre risques 📊 Six conditions avant de laisser agir un agent 📊 Les référentiels de l'IA : à quoi sert chacun 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Quatre usages, quatre risques

Le risque change de nature selon que le modèle lit, restitue ou agit.

Usage	Ce que ça apporte	Risque principal	Contrôle prioritaire
Copilote (assistant généraliste)	Gain de temps sur la rédaction, la synthèse, le code.	Fuite de données dans un service tiers, hallucinations prises pour des faits.	Interdiction d'entrée des données classifiées, journalisation des requêtes, sensibilisation ciblée
RAG (recherche augmentée)	Réponses ancrées dans des documents internes, traçables.	Injection indirecte par un document empoisonné ; fuite par élargissement du périmètre de recherche.	Filtrage des sources indexées, cloisonnement par droits de l'utilisateur, citations obligatoires
Agent (appelle des outils)	Automatisation d'actions : requêtes, tickets, correctifs, déploiements.	Action non autorisée, effet de bord en cascade, boucle coûteuse.	Identité propre, outils en liste blanche, plafonds, validation humaine, arrêt d'urgence
Assistant de code	Productivité des développeurs, génération de tests, revue assistée.	Code vulnérable accepté sans revue, dépendance inventée, secret suggéré.	Revue humaine obligatoire, analyse statique, détection de secrets, politique de provenance des dépendances

Six conditions avant de laisser agir un agent

Une seule manquante suffit à transformer un gain de productivité en incident.

Condition	Ce que ça veut dire	Comment on le vérifie
Identité propre	L'agent a sa propre identité, journalisée comme telle — pas celle d'un humain.	Journal des appels attribués à l'agent, pas au compte du demandeur
Outils en liste blanche	Il ne peut appeler que des outils explicitement autorisés, avec des actions bornées.	Configuration de la passerelle, test d'appel refusé
Plafonds quantitatifs	Limites de volume, de coût, de débit et de portée d'écriture.	Compteurs et alertes, test de dépassement
Validation humaine	Toute action sensible (écriture, suppression, envoi externe) exige une approbation.	Trace d'approbation par action, proportion d'actions auto-approuvées
Journal exploitable	Requêtes, sources consultées, outils appelés et résultats : de quoi reconstituer une décision.	Relecture d'un incident simulé : peut-on reconstituer le cheminement ?
Arrêt d'urgence	Coupure immédiate, testée, avec effet connu sur les tâches en cours.	Exercice d'arrêt daté et compte rendu

Le modèle n'est pas le seul composant à sécuriser : la passerelle, les sources, les outils et les identités portent l'essentiel du risque.

Les référentiels de l'IA : à quoi sert chacun

Quatre repères, quatre usages : ils ne se remplacent pas, ils se complètent.

Vérifié le 27/09/2026

Référentiel	Ce qu'il contient	Usage en architecture
OWASP Top 10 LLM (2025)	Dix risques des applications à base de LLM : injection de prompt (LLM01), divulgation d'informations sensibles, chaîne d'approvisionnement, empoisonnement des données et du modèle, gestion des sorties, agentivité excessive (LLM06), fuite du prompt système, faiblesses des vecteurs et embeddings, désinformation, consommation illimitée.	Grille de revue d'une application d'IA et de ses tests avant mise en production
MITRE ATLAS	Matrice des tactiques et techniques adverses contre les systèmes d'IA, sur le modèle d'ATT&CK : 16 tactiques, 120 techniques, 73 études de cas (version v2026.09 du 15/09/2026).	Threat model d'un système d'IA, scénarios d'exercice, couverture de détection
AI Act · règlement (UE) 2024/1689	Obligations par niveau de risque : pratiques interdites et maîtrise de l'IA depuis le 02/02/2025, modèles à usage général depuis le 02/08/2025, transparence (art. 50) depuis le 02/08/2026 ; haut risque reporté par l'Omnibus IA, en vigueur depuis le 27/07/2026, au 02/12/2027 (annexe III) et au 02/08/2028 (annexe I).	Inventaire des cas d'usage classés par niveau de risque ; dossier de conformité pour chaque système à haut risque
ISO/IEC 42001 · NIST AI RMF	Système de management de l'IA (norme certifiable, 2023) et cadre de gestion des risques de l'IA (NIST, 2023).	Gouvernance : rôles, inventaire, évaluation d'impact, revue périodique

Sources relues le 27/09/2026 : genai.owasp.org (édition 2025), atlas-data v2026.09, Conseil de l'UE (adoption finale de l'Omnibus IA le 29/06/2026) et Commission européenne (entrée en vigueur le 27/07/2026).

Plateforme d'IA — des usages aux garanties à regarder : la passerelle, et pourquoi aucun accès direct n'existe entre modèle, données et outils Plein écran

À retenir

Le risque suit la capacité : un modèle qui lit ne fait pas les dégâts d'un agent qui écrit.
L'injection indirecte se traite par l'architecture (cloisonnement, outils bornés), pas par des consignes de prompt.
Tout usage d'IA s'inventorie : sans inventaire, ni gouvernance, ni retrait possible.
Un agent sans arrêt d'urgence testé n'est pas prêt à agir sur la production.
OWASP Top 10 LLM pour revoir l'application, ATLAS pour modéliser l'attaquant, AI Act pour classer l'usage : trois questions différentes.

Pièges classiques

Croire qu'une instruction du type « ignore les instructions malveillantes » suffit : le contenu hostile arrive par une source que le modèle doit lire.
Laisser un agent utiliser une identité humaine à privilèges : aucune attribution, aucune limitation.
Indexer tous les documents sans appliquer les droits des utilisateurs : le RAG devient un canal de fuite.
Acheter un outil de gouvernance avant d'avoir un inventaire des cas d'usage : le catalogue précède l'outil.

Auto-check — 4 questions pour vérifier que c'est acquis

Un métier veut brancher un agent sur la base de production pour automatiser les demandes. Quelles conditions poser ?
Identité propre à l'agent, accès en lecture via une vue restreinte, outils en liste blanche, plafonds de volume et de coût, validation humaine sur toute écriture, journal exploitable, arrêt d'urgence testé, et un test d'injection indirecte (document piégé).
Comment un RAG peut-il devenir un vecteur de fuite ?
Si l'index agrège des documents au-delà des droits de l'utilisateur, la réponse peut restituer une information à laquelle il n'a pas accès. La correction est le cloisonnement des sources par périmètre de droits, pas un filtre après coup.
Que met-on dans un inventaire de cas d'usage IA ?
Usage, propriétaire, données concernées et leur classification, modèle employé, outils accessibles, garde-fous en place, preuve de test, et décision (autorisé, encadré, refusé). Sans cette base, la gouvernance reste déclarative.
Un assistant RAG interne doit être mis en production. Quels référentiels mobiliser, et pour quoi faire ?
L'OWASP Top 10 LLM pour la revue de l'application (injection de prompt, divulgation d'informations sensibles, faiblesses des vecteurs et embeddings) ; MITRE ATLAS pour construire le threat model et les scénarios de test ; l'AI Act pour classer l'usage — un assistant documentaire interne n'est en général pas à haut risque, mais l'obligation de transparence envers les utilisateurs s'applique [hypothèse : à confirmer selon le cas d'usage].

Méthode Tous publics 14 min #méthode#revue de design#preuves

Méthode : revoir un design, fermer un écart par une preuve

Une compétence ne se déclare pas, elle se démontre : une action minimale, une pièce vérifiable, une date.

L'essentiel en 30 secondes

Un écart de compétence se traite comme un écart de contrôle : on le nomme, on choisit l'action minimale qui le ferme, on produit la preuve qui le démontre.
La preuve est un livrable vérifiable par un tiers : un déploiement reproductible, un pipeline avec ses portes, une revue de code documentée, un outil qui tourne, un parc administré.
Le plan se lit en trois temps : fondations (poser un socle reproductible), pratique (répéter les gestes du métier), démonstration (montrer la chaîne de bout en bout, écarts assumés compris).
Ce qui convainc en comité comme en revue : une décision argumentée, un schéma, une trace datée — jamais une affirmation.

preuve par écart

vérifiable par un tiers

temps du plan

fondations · pratique · démonstration

questions de revue

avant de valider un design

Une méthode ne vaut que par ce qu'elle produit. Ce module donne la façon de transformer un écart en pièce démontrable, puis les dix questions à poser avant de valider un design — la grille qui sert aussi à relire ses propres architectures.

🔢 Chiffres 📊 Cinq familles de compétences, cinq preuves 📊 Trois temps : fondations, pratique, démonstration 📊 Dix questions à poser avant de valider un design 🧩 Schémas (1)✅ À retenir · ⚠️ Pièges 🎯 Auto-check

Cinq familles de compétences, cinq preuves

Pour chaque famille : l'action minimale qui produit une compétence réelle, et la pièce qui la démontre.

Famille	Action minimale	Preuve attendue	Durée réaliste
Cloud opérationnel	Monter un compte dans une organisation avec garde-fous, un réseau, des rôles fédérés, la journalisation et la détection managée.	Schéma d'architecture du compte + garde-fous actifs + journal d'API centralisé	3 à 5 semaines
Infrastructure-as-code et CI/CD	Écrire un module versionné, un état distant verrouillé, et un pipeline avec portes (secrets, IaC, build signé, admission).	Dépôt de démonstration : plan, garde-fous, artefact signé, pipeline vert puis rouge sur un écart	4 à 6 semaines
AppSec et revue de code	Revoir dix pull requests avec une grille écrite : entrées, authentification, autorisation, secrets, dépendances, journalisation.	Grille de revue + deux revues documentées avec commentaires et suivi de correction	2 à 3 semaines
Automatisation sécurité	Écrire un outil utile : collecte de preuves, vérification de configuration, export de conformité — testé et journalisé.	Code versionné, tests, exécution planifiée, sortie exploitable par un tiers	4 à 8 semaines
Administration de parc	Administrer un parc réel ou un laboratoire : politiques de conformité, inventaire, durcissement, remontée d'alertes.	Tableau de conformité du parc, politique appliquée, procédure d'exception écrite	3 à 4 semaines

Un laboratoire personnel suffit : ce qui compte est la démarche complète (conception, mise en œuvre, preuve, écarts assumés), pas la taille du parc.

Trois temps : fondations, pratique, démonstration

Ce qui doit être vrai à la fin de chaque temps — et comment le montrer.

Temps	Objectif	Livrable démontrable	Signal d'échec
1 · Fondations	Poser un socle reproductible sans dépendre d'un tiers : compte et garde-fous, réseau, identités fédérées, journalisation, premier module d'infrastructure-as-code.	Un dépôt d'infrastructure qui déploie un environnement complet, avec garde-fous actifs et journaux centralisés.	Un environnement monté à la main, sans code, impossible à reproduire
2 · Pratique	Répéter les gestes du métier : revue de code avec grille, threat model d'un service, priorisation de vulnérabilités, pipeline à portes.	Une revue de code documentée, un threat model d'une page, une file de vulnérabilités priorisée avec échéances.	Des rapports sans décision : rien n'est corrigé, rien n'est daté
3 · Démonstration	Montrer la chaîne complète : un service déployé, détecté, sauvegardé, documenté, avec ses preuves et ses écarts assumés.	Un dossier de cinq pages : schéma, décisions, preuves (journal, rapport de restauration, pipeline), écarts et plan.	Un dossier sans écarts assumés : signe qu'il n'a pas été regardé en face

Le même dossier sert à plusieurs auditoires : ce sont les preuves mises en avant qui changent, pas le fond.

Dix questions à poser avant de valider un design

La grille de revue à garder sous la main — en comité comme sur une pull request d'architecture.

Question	Ce qu'elle révèle
Qu'est-ce qui tombe si ce composant tombe ?	Le rayon d'impact et les points uniques de défaillance
Qui a le droit de faire quoi, et qui l'a décidé ?	La propriété des accès et la traçabilité des décisions
Quelle est la preuve que ce contrôle fonctionne ?	La différence entre un contrôle déclaré et un contrôle testé
Que se passe-t-il si l'authentification est indisponible ?	Le mode dégradé, souvent oublié, et l'accès de secours
Où sont les secrets, et comment tournent-ils ?	La gestion des identités non humaines et des clés
Quels flux sont autorisés, et qui les possède ?	Le sérieux de la segmentation et l'existence d'un propriétaire par règle
Quel signal produit ce composant en cas d'abus ?	L'observabilité et l'exploitabilité de la détection
Comment restaure-t-on, et en combien de temps ?	La résilience réelle, mesurée par un test et non par une promesse
Quelle donnée sort du périmètre, vers qui ?	Les tiers, la souveraineté et la réversibilité
Qu'est-ce qu'on accepte de ne pas couvrir ?	Le risque résiduel : la question qui transforme un débat en décision

Ces dix questions se posent en cinq minutes ; elles évitent trois réunions et un incident.

Feuille de route — quatre vagues et les gains associés à regarder : la séquence, et le gain obtenu à chaque étape plutôt qu'en fin de programme Plein écran

À retenir

Un écart se ferme par une preuve, pas par une lecture ni une certification.
On séquence : les fondations (identité, journaux, sauvegardes, inventaire) avant l'optimisation.
Le livrable qui convainc tient en cinq pages : schéma, décisions, preuves, écarts assumés.
Les dix questions de revue valent pour tous les designs, y compris les siens.

Pièges classiques

Empiler les formations sans jamais livrer : le savoir non pratiqué ne se défend pas.
Attendre de tout maîtriser avant de montrer : une trajectoire assumée est plus crédible qu'une perfection simulée.
Confondre volume de livrables et qualité des preuves : dix schémas sans décision valent moins qu'un dossier argumenté.
Oublier d'écrire ce qui n'est pas couvert : c'est pourtant la première question d'un relecteur.

Auto-check — 3 questions pour vérifier que c'est acquis

Trois semaines pour démontrer une compétence cloud et infrastructure-as-code : par quoi commencer ?
Un environnement complet déployé par code : organisation et garde-fous, réseau, rôles fédérés, journalisation centralisée, un module versionné avec état distant. On peut alors raconter des décisions et des erreurs vécues — c'est ce qui distingue une pratique d'une lecture.
Comment démontrer une compétence d'administration de parc sans parc à disposition ?
Par un laboratoire : deux machines, un outil open source d'administration, des politiques de conformité, un inventaire, une exception écrite et un test de non-conformité détecté. La démarche et les écarts sont transposables — la taille du parc n'est pas le sujet.
Quelle est la preuve la plus utile à montrer sur un profil GRC ?
Un registre de risque ou une matrice de conformité reliés à des preuves datées : contrôle, composant, propriétaire, statut déclaré/testé, échéance. C'est la démonstration qu'on ne confond pas l'écrit et le fait.

Repères🧠 110 termes

Lexique

Le vocabulaire qui fait gagner du crédit en réunion technique — filtrable à la volée, chaque terme relié à son module.

Admission (contrôle d'admission)

Porte d'entrée d'un déploiement : elle vérifie la signature, la provenance et la configuration avant d'admettre un artefact en production.

M6 · DevSecOps et IaC

ADR

Architecture Decision Record : fiche datée d'une décision — contexte, options, décision, conséquences, critères de réexamen. Règle du dossier : aucune technologie retenue sans ADR.

M8 · Risque et priorisation

AI Act

Règlement (UE) 2024/1689 : obligations par niveau de risque. Interdictions depuis février 2025, modèles à usage général depuis août 2025 ; haut risque reporté par l'Omnibus IA au 2 décembre 2027 (annexe III) et au 2 août 2028 (annexe I).

M13 · IA et sécurité

AIBOM

AI Bill of Materials : inventaire des modèles, jeux de données et dépendances d'intelligence artificielle.

M13 · IA et sécurité

ASPM

Application Security Posture Management : dette de sécurité applicative, priorisée par le risque réel.

M6 · DevSecOps et IaC

AssumeRole / identité fédérée

Obtention d'identifiants temporaires par échange de confiance (OIDC, SAML) au lieu d'un secret permanent : attribuable, expirant, révocable.

M3 · Identité et IAM

ASVS

Application Security Verification Standard (OWASP) : exigences de sécurité applicative vérifiables, en 17 chapitres et trois niveaux ; version 5.0 publiée en mai 2025.

M15 · AppSec et API

ATT&CK

Référentiel MITRE des tactiques (15 en version Enterprise v19) et des techniques adverses. Les tactiques sont des objectifs, pas une séquence ; le référentiel sert à nommer les menaces d'un threat model et à mesurer la couverture de détection.

M7 · Menaces et attaques

BIA (bilan d'impact sur l'activité)

Analyse, processus métier par processus métier, de l'impact d'une interruption dans le temps : elle fixe DMIA, RTO et RPO et révèle les dépendances.

M17 · Continuité et crise

Blast radius

Rayon d'impact : ce qu'une compromission d'un composant permet d'atteindre ensuite. À mesurer, jamais à supposer.

M3 · Identité et IAM

BOLA / BFLA

Autorisation défaillante au niveau de l'objet (accès à la donnée d'un autre) ou de la fonction (appel d'une route interdite) : premier et cinquième risques du Top 10 API de l'OWASP (2023).

M15 · AppSec et API

CASB

Cloud Access Security Broker : découverte des applications SaaS et contrôle des flux, en API et/ou inline. Couvrir les deux modes est une preuve, pas une option.

M2 · Réseau et segmentation

CBOM

Cryptography Bill of Materials : inventaire des algorithmes, clés et certificats. Prérequis de la migration post-quantique.

M11 · Crypto et données

Cellule de crise

Instance restreinte qui décide, communique et notifie pendant une crise, avec des moyens extérieurs au SI touché (annuaire imprimé, téléphones, canal de secours) et une main courante.

M17 · Continuité et crise

Chiffrement d'enveloppe

Une clé maîtresse protège des clés de données : la rotation devient praticable sans rechiffrer les volumes.

M11 · Crypto et données

CIEM

Cloud Infrastructure Entitlement Management : droits effectifs et chemins d'escalade de privilèges dans le cloud.

M5 · Sécurité cloud (AWS)

CNAPP

Cloud-Native Application Protection Platform : posture cloud et applicative (CSPM, CIEM, CWPP, DSPM) dans une vue corrélée.

M5 · Sécurité cloud (AWS)

Compte racine

Compte créateur d'un compte AWS, qui détient tous les droits sur ce compte. Dans une organisation, les SCP le plafonnent sur les comptes membres, jamais sur le compte de gestion. MFA matérielle, aucune clé d'accès, usage exceptionnel et alerté.

M5 · Sécurité cloud (AWS)

Conduit

IEC 62443 : unique chemin autorisé entre deux zones — filtrage protocolaire en liste blanche, unidirectionnel quand c'est possible.

M12 · OT / ICS

CRA

Cyber Resilience Act (règlement UE 2024/2847). Vulnérabilité activement exploitée : alerte 24 h, notification 72 h, rapport final 14 jours après la mise à disposition d'un correctif. Incident grave : 24 h, 72 h, rapport final sous 1 mois. Déclarations obligatoires depuis le 11 septembre 2026 ; application complète le 11 décembre 2027.

M9 · SMSI et référentiels

Crypto-agilité

Capacité à changer d'algorithme par paramétrage : l'algorithme est un paramètre, les bibliothèques en supportent plusieurs, la rotation est testée en production.

M11 · Crypto et données

CSPM

Cloud Security Posture Management : détection des écarts de configuration aux référentiels durcis, corrigés par infrastructure-as-code.

M5 · Sécurité cloud (AWS)

CTI (renseignement sur la menace)

Cyber Threat Intelligence : connaissance des acteurs, campagnes, techniques et indicateurs, organisée pour éclairer une décision — stratégique, opérationnelle, tactique ou technique.

M16 · Détection et CTI

CTPP (prestataire TIC critique)

Prestataire de services TIC désigné critique au titre de DORA et surveillé directement par les autorités européennes : 19 désignés le 18/11/2025.

M20 · Tiers et fournisseurs

CWPP

Cloud Workload Protection Platform : protection à l'exécution des charges de travail, blocage des comportements interdits.

M5 · Sécurité cloud (AWS)

DCP (donnée à caractère personnel)

Toute information se rapportant à une personne physique identifiée ou identifiable (RGPD, art. 4). Sa violation déclenche la notification à la CNIL sous 72 heures lorsqu'elle présente un risque pour les personnes.

M11 · Crypto et données

Déclaré / testé

Un contrôle documenté est « déclaré » ; il ne devient « testé » qu'après une exécution tracée (date, opérateur, résultat). Seul le test mesure la maturité réelle.

M8 · Risque et priorisation

Deny-by-default

Aucun flux n'existe par défaut : chaque flèche correspond à une règle déclarée, possédée par une personne nommée, et son refus est journalisé.

M2 · Réseau et segmentation

Detection-as-code

Règles de détection versionnées, testées et déployées comme du code — condition d'une couverture ATT&CK mesurable et opposable.

M10 · SOC et résilience

Diode de données

Transfert unidirectionnel : les données remontent, aucune commande ne descend. Moyen technique d'imposer un sens unique.

M12 · OT / ICS

DMIA

Durée maximale d'interruption admissible d'un processus métier, fixée par le BIA : au-delà, l'impact devient inacceptable. Le RTO doit rester en deçà.

M17 · Continuité et crise

DORA

Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier : risque TIC, incidents, tests, prestataires tiers. Applicable depuis le 17 janvier 2025.

M9 · SMSI et référentiels

Drift (dérive d'infrastructure)

Écart entre l'infrastructure décrite par le code et celle qui tourne réellement. Se détecte par un plan régulier, se corrige par le code.

M6 · DevSecOps et IaC

DSPM

Data Security Posture Management : découverte et classification de la donnée, y compris celle que l'on croyait absente.

M5 · Sécurité cloud (AWS)

EDR

Endpoint Detection and Response : agent qui observe l'activité du poste ou du serveur, détecte les comportements malveillants et permet l'isolation à distance. Se prouve par sa couverture et un test d'isolation.

M18 · Poste, messagerie et SaaS

EPSS

Probabilité d'exploitation d'une vulnérabilité dans les 30 jours, fondée sur des données observées : complète le score de sévérité.

M8 · Risque et priorisation

Espace de noms (namespace)

Cloisonnement logique d'un cluster Kubernetes : unité d'application des rôles, des quotas, des NetworkPolicy et des profils Pod Security.

M19 · Conteneurs et Kubernetes

FIDO2 / passkey

Authentification résistante au hameçonnage par facteur matériel ou clé liée à l'origine. NIST SP 800-63B-4 (2025) encadre aussi les passkeys synchronisées entre appareils.

M3 · Identité et IAM

FWaaS

Firewall as a Service : pare-feu opéré dans le cloud, avec politique unique et DNS filtré.

M2 · Réseau et segmentation

Garde-fou (guardrail)

Contrôle appliqué automatiquement par la plateforme ou par le code, qui rend une mauvaise configuration difficile, voire impossible.

M6 · DevSecOps et IaC

Hameçonnage par consentement

Attaque où l'utilisateur, authentifié normalement, accorde par OAuth des droits à une application malveillante : le MFA ne protège pas, la limitation du consentement oui.

M18 · Poste, messagerie et SaaS

HNDL

Harvest Now, Decrypt Later : intercepter aujourd'hui ce qui sera déchiffrable demain. C'est pourquoi la menace post-quantique est présente, pas future.

M11 · Crypto et données

IAC (infrastructure as code)

Décrire réseaux, identités et services dans des fichiers versionnés : la sécurité devient reproductible et vérifiable en revue.

M6 · DevSecOps et IaC

IdP

Identity Provider : socle d'identité. Quand il est unique, il devient un point de défaillance de tous les accès — d'où l'ADR-004 sur l'accès d'urgence.

M3 · Identité et IAM

Injection indirecte

Instruction hostile logée dans un contenu que l'agent consulte (document, ticket, télémétrie). Le vrai vecteur d'attaque des agents, plus que le jailbreak spectaculaire.

M13 · IA et sécurité

ISO 42001 / NIST AI RMF

Référentiels de management et d'évaluation du risque d'IA : inventaire des cas d'usage, tests adverses, journal, capacité de retrait.

M13 · IA et sécurité

ITDR

Identity Threat Detection and Response : détection d'abus d'identité — dérive de comportement, vol de jeton, MFA fatigue.

M3 · Identité et IAM

JIT

Just-In-Time : droit accordé pour une durée bornée, puis expiré automatiquement. Le contraire d'un droit permanent.

M3 · Identité et IAM

KEV (Known Exploited Vulnerabilities)

Catalogue public (CISA) des vulnérabilités exploitées activement : un signal fort, à croiser avec l'exposition et la criticité de l'actif pour fixer la priorité.

M8 · Risque et priorisation

Limite de permissions (permission boundary)

Plafond attaché à un principal IAM : elle réduit ses droits effectifs sans jamais en accorder. Utile pour déléguer la création de rôles sans donner les clés du royaume.

M3 · Identité et IAM

Matrice de conformité

Registre reliant chaque contrôle d'un référentiel à un composant d'architecture et à une preuve. Une ligne sans preuve n'est pas un contrôle : c'est un écart.

M8 · Risque et priorisation

MDM

Mobile Device Management : gestion centralisée des postes et mobiles (configuration, chiffrement, correctifs, effacement à distance) ; l'état qu'il rapporte sert aussi à l'accès conditionnel.

M18 · Poste, messagerie et SaaS

MFA

Authentification multifacteur. Attention à ce qu'elle ne protège pas : une session déjà ouverte, ni une identité de service.

M3 · Identité et IAM

Micro-segmentation

Politique par service à l'intérieur d'une zone : le rayon d'impact se réduit au service, et le refus devient un signal exploitable.

M2 · Réseau et segmentation

MITRE ATLAS

Base de tactiques, techniques et études de cas d'attaques contre les systèmes d'IA, construite sur le modèle d'ATT&CK : 16 tactiques et 120 techniques en version v2026.09.

M13 · IA et sécurité

ML-KEM / ML-DSA

FIPS 203 (ML-KEM, encapsulation de clés) et FIPS 204 (ML-DSA, signatures), publiés le 13 août 2024 avec FIPS 205 (SLH-DSA), signature à base de hachage retenue comme alternative de secours. HQC a été sélectionné en mars 2025 comme second mécanisme d'encapsulation.

M11 · Crypto et données

Moindre agence

Principe appliqué aux agents IA : lecture seule par défaut, action bornée par exception, outils en liste blanche, plafonds et journal exploitable.

M13 · IA et sécurité

MTTD / MTTR

Délais de détection et de remédiation : les seuls indicateurs qui comptent réellement pour un SOC. Le volume d'alertes n'en est pas un.

M10 · SOC et résilience

NetworkPolicy

Règle Kubernetes qui filtre les flux entre pods. Sans elle, tout pod joint tout pod ; elle n'agit que si le plugin réseau l'applique — d'où le test de connexion refusée.

M19 · Conteneurs et Kubernetes

NHI

Non-Human Identity : identité de service, de charge de travail ou d'agent. Aucune MFA ne la protège : il faut un registre, une portée et une expiration.

M3 · Identité et IAM

NIS2

Directive (UE) 2022/2555 : dix domaines de mesures (art. 21) et notification d'incident 24 h / 72 h / 1 mois (art. 23). Transposition française en attente (CJUE saisie le 08/07/2026).

M9 · SMSI et référentiels

Non-conformité / action corrective

Écart constaté, analyse de cause racine, correction, vérification d'efficacité. La clause 10.2 est le moteur de l'amélioration.

M9 · SMSI et référentiels

OIDC

OpenID Connect : couche d'identité au-dessus d'OAuth 2.0. En fédération CI → cloud, la plateforme présente un jeton signé et reçoit un rôle temporaire, sans secret statique à stocker.

M3 · Identité et IAM

OWASP Top 10 LLM

Liste des dix risques des applications à base de grands modèles de langage (édition 2025) : de l'injection de prompt (LLM01) à la consommation illimitée (LLM10), en passant par l'agentivité excessive (LLM06).

M13 · IA et sécurité

PAM

Privileged Access Management : coffre de secrets, élévation à la demande, enregistrement de session pour les comptes à privilèges.

M3 · Identité et IAM

PCA / PRA

Plan de continuité d'activité (l'activité continue en mode dégradé) et plan de reprise d'activité (le SI revient dans l'ordre des dépendances). Deux plans distincts, testés séparément.

M17 · Continuité et crise

PDCA (roue de Deming)

Planifier, déployer, contrôler, améliorer : la boucle qui fait vivre un SMSI et se prouve par des enregistrements datés.

M9 · SMSI et référentiels

PDP

Policy Decision Point : le moteur de décision (le « juge »). Il évalue la politique et rend une instruction — il ne voit pas le trafic.

M4 · Zero Trust

PEP

Policy Enforcement Point : le point d'application de la décision (le « gendarme »). Il intercepte la requête et exécute l'instruction.

M4 · Zero Trust

PKCE

Proof Key for Code Exchange : extension d'OAuth qui lie la demande du code d'autorisation à son échange, et rend inutile un code intercepté. Recommandée pour tous les clients par la RFC 9700 (2025).

M15 · AppSec et API

Pod Security Standards

Trois profils de sécurité des pods (privileged, baseline, restricted), imposés par espace de noms avec Pod Security Admission ; restricted est la cible des applications.

M19 · Conteneurs et Kubernetes

Posture

État de conformité de l'appareil ou de la session (correctifs, chiffrement, EDR actif). Une posture non fiable ramène la décision au niveau d'une simple authentification.

M4 · Zero Trust

Posture (cloud)

État de conformité d'un environnement : configuration, droits effectifs, charges, données. Quatre vues, quatre outils, une décision.

M5 · Sécurité cloud (AWS)

PQC

Post-Quantum Cryptography : algorithmes résistants à l'ordinateur quantique. Migration hybride, par vagues, priorité à l'agilité.

M11 · Crypto et données

Preuve

Pièce datée, attribuable et rejouable : fichier:ligne, commande exécutée, capture horodatée, compte rendu de test. Une capture prouve un état à une date, pas un contrôle permanent.

M8 · Risque et priorisation

Purdue

Modèle de référence des niveaux industriels : 0 procédé, 1 automatisation, 2 supervision, 3 opérations, 3,5 DMZ industrielle, 4-5 SI de gestion.

M12 · OT / ICS

Pyramide de la douleur

Modèle de David Bianco : plus un indicateur est haut (des empreintes et adresses IP jusqu'aux TTP), plus il coûte à l'attaquant de le changer — et plus la détection qui s'y appuie dure.

M16 · Détection et CTI

RBAC (Kubernetes)

Contrôle d'accès par rôles de l'API Kubernetes : rôles et liaisons, par espace de noms ou pour tout le cluster. Un compte applicatif ne reçoit jamais cluster-admin.

M19 · Conteneurs et Kubernetes

RBI

Remote Browser Isolation : navigation distante jetable — le contenu s'exécute ailleurs, rien n'atteint le poste.

M2 · Réseau et segmentation

Registre d'information (DORA)

Registre, imposé par l'article 28 de DORA, de tous les accords contractuels TIC d'une entité financière ; modèles fixés par le règlement d'exécution (UE) 2024/2956, collecte annuelle par les autorités.

M20 · Tiers et fournisseurs

Réversibilité

Capacité de sortie d'un fournisseur : clause contractuelle, format d'export, coût et délai. Elle se prouve par un test, jamais par une clause.

M8 · Risque et priorisation

RTO / RPO

Durée maximale d'indisponibilité tolérée et perte de données acceptable, par criticité. Un RTO est une décision d'activité, pas un choix technique.

M17 · Continuité et crise

SASE

Secure Access Service Edge : convergence du réseau et de la sécurité en un plan de contrôle cloud (ZTNA, SWG, FWaaS, CASB). Le périmètre n'est plus un lieu, c'est une décision.

M2 · Réseau et segmentation

SBOM

Software Bill of Materials : inventaire des composants logiciels. Sans inventaire, une vulnérabilité critique devient une chasse au trésor de plusieurs semaines.

M6 · DevSecOps et IaC

SCP (Service Control Policy)

Garde-fou d'organisation AWS : il plafonne ce que les comptes membres peuvent faire, y compris leur compte racine — mais pas le compte de gestion, qu'aucune SCP ne limite. Il n'accorde jamais de droit.

M5 · Sécurité cloud (AWS)

Sigma

Format ouvert de description des règles de détection, indépendant de l'outil : une règle Sigma se traduit vers plusieurs SIEM et se versionne comme du code.

M16 · Détection et CTI

SIS

Safety Instrumented System : système instrumenté de sécurité, indépendant du réseau — son indépendance est une exigence de sûreté, pas une option d'architecture.

M12 · OT / ICS

SL-T / SL-A

IEC 62443 : niveau cible de sécurité (SL-T, ce que l'on vise) et niveau atteint (SL-A, ce qui est démontré). Deux valeurs distinctes, à écrire toutes les deux ; SL-C désigne la capacité intrinsèque d'un composant.

M12 · OT / ICS

SL1 à SL4

IEC 62443 : niveaux de sécurité, du niveau 1 (violation fortuite ou accidentelle) au niveau 4 (attaque intentionnelle, moyens sophistiqués, ressources étendues, forte motivation).

M12 · OT / ICS

SLSA

Niveaux de garantie de provenance d'un artefact de build ; la signature de la provenance arrive dès le niveau 2, le niveau 3 ajoute une plateforme de build durcie et des builds isolés.

M6 · DevSecOps et IaC

SoA (déclaration d'applicabilité)

Document central du SMSI : chaque mesure de l'Annexe A est déclarée applicable ou non, avec justification, propriétaire et preuve.

M9 · SMSI et référentiels

Souveraineté

Localisation et contrôle juridique des données et des traitements : contrôle capitalistique, immunité extraterritoriale, exposition aux injonctions.

M9 · SMSI et référentiels

SPF / DKIM / DMARC

Authentification du courriel : serveurs autorisés (SPF), signature du domaine (DKIM), alignement avec le domaine affiché et politique en cas d'échec (DMARC, RFC 9989 depuis mai 2026).

M18 · Poste, messagerie et SaaS

SPIFFE / mTLS

Identité cryptographique de charge de travail et authentification mutuelle entre services, sans secret statique.

M3 · Identité et IAM

SPOF

Single Point Of Failure : composant dont la perte arrête le service. Le plus fréquent n'est pas matériel — c'est un plan de contrôle ou un annuaire.

M8 · Risque et priorisation

SSE

Security Service Edge : sous-ensemble du SASE, limité aux fonctions de sécurité. Ne pas confondre avec SASE — ambiguïté corrigée dans le schéma 04.

M2 · Réseau et segmentation

SSPM

SaaS Security Posture Management : comparaison continue de la configuration des applications SaaS (partage, applications tierces, rôles, journaux) à une référence.

M18 · Poste, messagerie et SaaS

SSRF

Server-Side Request Forgery : le serveur émet une requête vers une destination choisie par l'attaquant — réseau interne, métadonnées cloud. Se traite par liste blanche de destinations et filtrage de sortie.

M15 · AppSec et API

Stratégie de sortie

Plan qui permet de quitter un prestataire sans interrompre la fonction soutenue : données et format, remplacement, durée, coût, assistance, test daté.

M20 · Tiers et fournisseurs

SWG

Secure Web Gateway : passerelle web qui filtre la navigation et applique la politique d'usage.

M2 · Réseau et segmentation

Threat model

Analyse structurée des menaces : actifs, frontières de confiance, chemins d'abus, priorisation impact × exploitabilité, contre-mesures. Règle du dossier : aucun schéma livré sans threat model.

M8 · Risque et priorisation

Tier 0

Domaine de contrôle qui administre tous les autres (annuaire, plan de contrôle, console d'administration). Qui le contrôle, contrôle l'ensemble.

M3 · Identité et IAM

TLP (Traffic Light Protocol)

Étiquettes de diffusion du renseignement, version 2.0 du FIRST (2022) : CLEAR, GREEN, AMBER, AMBER+STRICT, RED — du partage public au destinataire nommé seulement.

M16 · Détection et CTI

TPRM

Third-Party Risk Management : gestion du risque lié aux tiers, de la sélection à la sortie, avec un effort proportionné à la criticité de chaque fournisseur.

M20 · Tiers et fournisseurs

TTP

Tactiques, techniques et procédures d'un attaquant : son mode opératoire, décrit par exemple avec ATT&CK. Plus durables que les indicateurs techniques, donc meilleures cibles de détection.

M16 · Détection et CTI

VEX

Document qui déclare si un produit est réellement affecté par une vulnérabilité — la réponse qui évite de courir après chaque CVE.

M8 · Risque et priorisation

WORM

Write Once Read Many : stockage immuable (non modifiable, non supprimable) — condition pour que la preuve survive à la compromission.

M10 · SOC et résilience

Zero Trust

Modèle où aucune confiance n'est accordée à partir de la position réseau : chaque accès est décidé par identité, contexte et posture.

M4 · Zero Trust

Zone d'atterrissage (landing zone)

Socle multi-comptes standardisé : structure d'unités, garde-fous hérités, réseau et journalisation centralisés, comptes pré-provisionnés.

M5 · Sécurité cloud (AWS)

ZTNA

Zero Trust Network Access : accès à une application, jamais à un réseau. L'utilisateur ne voit que les applications autorisées pour lui.

M2 · Réseau et segmentation

Repères🧾 Traçabilité

Sources, méthode et outillage

Ce que contient ce site, d'où vient l'information, et comment il se régénère.

La règle du dossier

Aucune donnée inventée : chaque schéma est un fichier JSON validé 9/9 avant publication, et un composant cité existe dans un schéma.
Toute inférence est marquée [hypothèse] ; les chiffres de référence sont datés.
Un seul site : index.html (portfolio), base.html (cette base) et schemas/ (sources JSON et rendus HTML). Le reste est archive ou dossier professionnel.

Sources d'appui

Référentiels et documents de travail utilisés pour calibrer le contenu.

Source	Ce qu'on en tire	Lien
NIST SP 800-207 — Zero Trust Architecture	Définition du plan de contrôle : Policy Engine, Policy Administrator, PEP, sources de décision.	csrc.nist.gov/pubs/sp/800/207/final
NIST CSF 2.0 (2024)	6 fonctions (GOUVERNER, IDENTIFIER, PROTÉGER, DÉTECTER, RÉPONDRE, RÉTABLIR) et usage comme pivot multi-référentiels.	www.nist.gov/cyberframework
NIST SP 800-61r3 — Incident Response	Réponse à incident réorganisée autour des fonctions du CSF 2.0 : cycle de vie, gouvernance, preuves.	csrc.nist.gov/pubs/sp/800/61/r3/final
ISO/IEC 27001:2022 et ISO/IEC 27002:2022	Exigences du SMSI (clauses 4 à 10) et 93 mesures de l'Annexe A réparties en 4 thèmes.	www.iso.org/standard/27001
CIS Critical Security Controls v8.1	18 contrôles priorisés, très opérationnels : le langage commun des équipes qui font tourner un parc.	www.cisecurity.org/controls
ANSSI — hygiène numérique, Zero Trust, EBIOS RM	Guides opérationnels francophones, EBIOS RM pour l'analyse de risque en 5 ateliers.	cyber.gouv.fr/publications
MITRE ATT&CK	Tactiques et techniques adverses : nommer les menaces et mesurer la couverture de détection.	attack.mitre.org
AWS — responsabilité partagée, IAM, Well-Architected	Logique d'évaluation des politiques, socle multi-comptes, garde-fous et détection managée.	docs.aws.amazon.com/IAM/latest/UserGuide/r
CVSS v4.0 (FIRST), EPSS (FIRST), KEV (CISA)	Sévérité intrinsèque, probabilité d'exploitation à 30 jours, catalogue des vulnérabilités exploitées.	www.first.org/epss/
SLSA, Sigstore, SBOM (SPDX / CycloneDX)	Provenance et signature des artefacts de build ; inventaire logiciel exploitable.	slsa.dev
Règlements UE : NIS2, DORA, CRA, RGPD	Obligations de notification et délais : 24 h / 72 h / 1 mois selon le régime.	eur-lex.europa.eu
IEC 62443 et modèle Purdue	Zones et conduits, niveaux de sécurité, sûreté industrielle.	www.iec.ch/blog/understanding-iec-62443
OWASP — Top 10, ASVS, Cheat Sheets	Application security : ce qu'on regarde dans une revue de PR et dans un design d'API.	owasp.org

Régénérer le site

node outils/build-formation.cjs — reconstruit index.html et base.html depuis app/data/*.json.
node outils/f1-selftest.cjs — rejoue les contrôles headless et écrit le reçu JSON.
powershell -File schemas/_check.ps1 -Type architecture -Files <schéma.json> — revalide un schéma (9/9 exigé).

Ce que ce site ne prouve pas

Les schémas sont pédagogiques : ils n'ont pas été produits sur un SI réel audité.
Les délais réglementaires évoluent : la source officielle fait foi et se relit avant tout engagement.
Aucun test avec lecteur d'écran n'a été conduit — la structure est sémantique, sans plus.

Repères🧾 Méthode et preuves

Comment ce site est construit

Le site est traité comme un livrable d'ingénierie : contenu en données, assemblage déterministe, tests automatiques, preuves datées et limites déclarées.

L'essentiel en 30 secondes

Le texte est une donnée : chaque module vit dans un fichier JSON ; le HTML est assemblé par un script et n'est jamais retouché à la main. La même entrée produit le même fichier, octet pour octet.
Chaque schéma est validé avant d'être livré : 32 schémas d'architecture décrits en JSON, contrôlés par l'outil Archify (9 vérifications sur 9), puis rendus en pages interactives.
Le comportement est prouvé, pas affirmé : un navigateur sans écran rejoue la recherche, le thème, les filtres, la progression, la politique de sécurité du contenu, l'absence de débordement et le contraste, puis écrit un reçu daté.
L'intégrité est vérifiable : un manifeste liste l'empreinte SHA-256 de chaque source, rendu, outil et preuve ; une commande la rejoue sans rien réécrire. Le dépôt source est privé : accès et démonstration sur demande.

La chaîne de production, étape par étape

Chaque étape laisse un artefact que l'on peut ouvrir et rejouer.

Étape	Ce qui se passe	Artefact laissé
1 · Contenu	Modules, tableaux, lexique et sources rédigés en JSON, relus et datés pour les faits sensibles.	app/data/*.json
2 · Schémas	Composants et flux décrits en JSON typé, validés (9 vérifications sur 9), puis rendus par l'outil Archify.	schemas/.json · schemas/rendus/.html
3 · Assemblage	Un script lit les données, la feuille de style et les comportements, et produit une page unique avec sa CSP à empreintes.	index.html
4 · Preuves	Harnais de comportement dans un navigateur sans écran, captures de rendu, capture et validation de chaque schéma.	reçus JSON et captures datées
5 · Intégrité	Manifeste des empreintes SHA-256, vérifiable sur un clone neuf quelle que soit la plateforme.	MANIFEST.json · --verifier
6 · Publication	Dossier dist/ sans aucune ressource tierce, avec les en-têtes de sécurité de l'hébergeur.	dist/ · _headers

Le dossier d'architecture

Un dossier d'architecture de travail accompagne le site : 7 décisions d'architecture (ADR), 8 threat models, 2 matrices de contrôles (NIST CSF 2.0 et ISO/IEC 27002:2022, 133 lignes), une revue contradictoire de 14 constats.
Il s'agit d'un cas d'étude sans aucune donnée client réelle : il sert à pratiquer la méthode de bout en bout, pas à décrire un système en production.
Règles du dossier : aucun schéma livré sans threat model, aucune technologie retenue sans ADR, aucun contrôle déclaré sans preuve datée.

Réserves assumées

8 threat models couvrent, à ce jour, 8 schémas sur 32 : le périmètre SASE, la chaîne d'attaque et chaque schéma ajouté depuis le 27/09/2026. La dette est déclarée, pas cachée.
Les 133 contrôles des matrices sont déclarés, 0 est encore testé : c'est la différence entre « déclaré » et « testé » que le site enseigne.
Aucun test avec lecteur d'écran ni impression papier n'a encore été réalisé.

Part de l'IA

Le site a été conçu, structuré et vérifié par son auteur. Des assistants d'IA ont servi à rédiger des premiers jets, à produire les schémas via le skill Archify et à écrire l'outillage ; chaque sortie passe par les mêmes contrôles (validation des schémas, harnais, faits datés et sourcés). L'IA accélère ; la méthode, les arbitrages et la responsabilité du contenu restent humains.

Architecture cyber

🧭 Parcours conseillé — un module à la fois

Principes d'architecture sécurité

⚡ L'essentiel en 30 secondes

📊 Le vocabulaire qui évite les débats stériles

📊 Cinq principes qui tranchent d'avance

📊 Défense en profondeur : ce que chaque couche absorbe

✅ À retenir

⚠️ Pièges classiques

Réseau, zones et segmentation

⚡ L'essentiel en 30 secondes

📊 Les 4 notions réseau à maîtriser avant tout débat

📊 Cinq zones de confiance et ce qu'on y met

📊 VPN, ZTNA, SASE : ne plus confondre

📊 Ce qui doit figurer dans une matrice de flux

✅ À retenir

⚠️ Pièges classiques

Identité, IAM et authentification

⚡ L'essentiel en 30 secondes

📊 Quatre populations, quatre exigences

📊 MFA : ce qui protège vraiment

📊 Les cinq familles de politiques AWS à connaître d'abord

📊 Cycle de vie d'une identité en cinq temps

✅ À retenir

⚠️ Pièges classiques

Zero Trust et accès distant

⚡ L'essentiel en 30 secondes

📊 Ce que Zero Trust change — et ce qu'il ne change pas

📊 Les cinq sources d'information de politique

📊 Ce qui casse un déploiement Zero Trust

✅ À retenir

⚠️ Pièges classiques

Sécurité cloud — le socle AWS

⚡ L'essentiel en 30 secondes

📊 Le socle AWS minimal en dix briques

📊 Qui est responsable de quoi (modèle partagé)

📊 VPC et stockage : les réglages qui comptent

📊 Les quatre capacités d'observation cloud

✅ À retenir

⚠️ Pièges classiques

DevSecOps, IaC et chaîne logicielle

⚡ L'essentiel en 30 secondes

📊 Les six portes du pipeline

📊 SAST, SCA, IaC, secrets : qui trouve quoi

📊 Terraform : où sont les risques

✅ À retenir

⚠️ Pièges classiques

Sécurité applicative et API

⚡ L'essentiel en 30 secondes

📊 OWASP API Security Top 10 (édition 2023)

📊 ASVS 5.0 : choisir un niveau, puis vérifier contre lui

📊 Le threat model d'une API en six questions

✅ À retenir

⚠️ Pièges classiques

Poste de travail, messagerie et SaaS

⚡ L'essentiel en 30 secondes

📊 Le poste de travail en couches

📊 Messagerie : empêcher l'usurpation, filtrer le reste

📊 SaaS : la configuration est chez le client

✅ À retenir

⚠️ Pièges classiques

Conteneurs et Kubernetes

⚡ L'essentiel en 30 secondes

📊 Les couches d'un cluster et ce qui les protège

📊 Les réglages par défaut à inverser

📊 Contrôle d'admission : ce qui ne passe pas

✅ À retenir

⚠️ Pièges classiques

Menaces, attaques et surface d'exposition

⚡ L'essentiel en 30 secondes

📊 Les huit maillons, leurs tactiques ATT&CK et le contrôle qui casse chacun

📊 Les trois voies d'intrusion dominantes

📊 Rançongiciel : cinq prérequis de reprise

✅ À retenir

⚠️ Pièges classiques

Risque, threat modelling et priorisation

⚡ L'essentiel en 30 secondes

📊 EBIOS RM : cinq ateliers, cinq livrables

📊 STRIDE : six familles, six questions

📊 Prioriser une vulnérabilité : trois notes, une décision

Parcours conseillé — un module à la fois

L'essentiel en 30 secondes

Le vocabulaire qui évite les débats stériles

Cinq principes qui tranchent d'avance

Défense en profondeur : ce que chaque couche absorbe

À retenir

Pièges classiques

L'essentiel en 30 secondes

Les 4 notions réseau à maîtriser avant tout débat

Cinq zones de confiance et ce qu'on y met

VPN, ZTNA, SASE : ne plus confondre

Ce qui doit figurer dans une matrice de flux

À retenir

Pièges classiques

L'essentiel en 30 secondes

Quatre populations, quatre exigences

MFA : ce qui protège vraiment

Les cinq familles de politiques AWS à connaître d'abord

Cycle de vie d'une identité en cinq temps

À retenir

Pièges classiques

L'essentiel en 30 secondes

Ce que Zero Trust change — et ce qu'il ne change pas

Les cinq sources d'information de politique

Ce qui casse un déploiement Zero Trust

À retenir

Pièges classiques

L'essentiel en 30 secondes

Le socle AWS minimal en dix briques

Qui est responsable de quoi (modèle partagé)

VPC et stockage : les réglages qui comptent

Les quatre capacités d'observation cloud

À retenir

Pièges classiques

L'essentiel en 30 secondes

Les six portes du pipeline

SAST, SCA, IaC, secrets : qui trouve quoi

Terraform : où sont les risques

À retenir

Pièges classiques

L'essentiel en 30 secondes

OWASP API Security Top 10 (édition 2023)

ASVS 5.0 : choisir un niveau, puis vérifier contre lui

Le threat model d'une API en six questions

À retenir

Pièges classiques

L'essentiel en 30 secondes

Le poste de travail en couches

Messagerie : empêcher l'usurpation, filtrer le reste

SaaS : la configuration est chez le client

À retenir

Pièges classiques

L'essentiel en 30 secondes

Les couches d'un cluster et ce qui les protège

Les réglages par défaut à inverser

Contrôle d'admission : ce qui ne passe pas

À retenir

Pièges classiques

L'essentiel en 30 secondes

Les huit maillons, leurs tactiques ATT&CK et le contrôle qui casse chacun

Les trois voies d'intrusion dominantes

Rançongiciel : cinq prérequis de reprise

À retenir

Pièges classiques

L'essentiel en 30 secondes

EBIOS RM : cinq ateliers, cinq livrables

STRIDE : six familles, six questions

Prioriser une vulnérabilité : trois notes, une décision

Registre de risque : les colonnes qui comptent

À retenir

Pièges classiques

L'essentiel en 30 secondes

ISO 27001:2022 — clauses 4 à 10 : ce que l'auditeur vérifie

Annexe A : quatre thèmes, 93 mesures

Carte des référentiels : lequel utiliser pour quoi

Notifications : qui, quoi, quand

À retenir

Pièges classiques

L'essentiel en 30 secondes

Classer les tiers par criticité