🧠Mon second cerveau

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é.

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.

Quelle couche absorbe l'échec de celle-ci. Aucune couche n'est suffisante seule : c'est le principe de défense en profondeur.

Il constate que la destination est hors de son sous-réseau (troisième octet différent avec un masque /24). Il obtient l'adresse MAC de sa passerelle par ARP et lui envoie la trame ; le routage, et le filtrage, se font sur la passerelle.

Il n'a pas obtenu de bail DHCP et s'est attribué une adresse de lien local. À vérifier : le lien, le VLAN du port, la joignabilité du serveur DHCP ou du relais DHCP.

Parce qu'il mémorise la session ouverte (adresses, ports, état TCP) : le retour qui correspond à une session autorisée passe automatiquement. Un filtrage sans état exigerait une règle dans chaque sens.

Pas directement : ils sont dans deux réseaux de niveau 2 distincts. Il faut un routage entre VLAN (routeur, commutateur de niveau 3 ou pare-feu). Placer ce routage sur un pare-feu permet de filtrer et de journaliser le passage.

Parce qu'une topologie redondante crée des boucles en couche 2, où les trames de diffusion tourneraient sans fin. Spanning Tree garde un seul chemin actif vers le pont racine et met les autres en secours. Pour utiliser tous les liens entre deux équipements, on les agrège en EtherChannel.

Mode accès forcé (pas de négociation de trunk), BPDU Guard (le port se coupe s'il reçoit une annonce Spanning Tree), port security ou 802.1X, et le bon VLAN métier. Un port inutilisé est désactivé.

Vers B : la route la plus précise (le plus long préfixe, /24) l'emporte sur la route générale (/8), quel que soit l'ordre de saisie.

Parce qu'il choisit parmi les chemins annoncés selon des préférences administratives (opérateur préféré, chemin d'AS, filtres) et non selon la seule distance. C'est aussi pourquoi une annonce erronée se propage : chaque voisin applique sa politique à ce qu'on lui envoie.

Rien, idéalement : il continue d'envoyer vers la même adresse de passerelle virtuelle, désormais tenue par le routeur de secours. Les sessions en cours peuvent subir une interruption de quelques secondes.

Le reverse proxy (avec WAF) en DMZ ; le serveur applicatif et la base en zone interne. Flux autorisés : Internet vers le reverse proxy en HTTPS, reverse proxy vers le serveur applicatif sur un port déclaré, serveur applicatif vers la base. Aucun accès direct d'Internet ni de la DMZ à la base.

Pour qu'une même vulnérabilité ou une même erreur de configuration ne suffise pas à traverser les deux barrières. C'est la défense en profondeur appliquée au périmètre ; le prix est une exploitation un peu plus lourde.

Cela dépend du coût d'un faux positif. Un IPS bloque en temps réel mais peut couper un flux légitime : on le passe d'abord en observation, on ajuste, puis on bloque. Un IDS n'interrompt rien, mais il faut quelqu'un pour traiter ses alertes.

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.

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.

À 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.

Parce que la messagerie et la navigation sont les premières voies d'intrusion. Si le poste qui détient les accès d'administration est compromis par un courriel piégé, l'attaquant hérite de ces accès. Séparer les usages coupe ce chemin.

L'identification de la personne (comptes nominatifs, MFA), la gestion des secrets (l'administrateur ne connaît pas le mot de passe de la cible) et la traçabilité fine (qui a fait quoi, quand, avec l'enregistrement de la session). Le pare-feu, lui, ne voit que des flux.

ZTNA, ou un accès par bastion : il n'a besoin que de cette application, pas du réseau. Un VPN complet lui donnerait une visibilité et une surface d'attaque bien plus larges que son besoin.

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.

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.

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.

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.

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.

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.

Le fournisseur corrige et maintient le moteur ; le client gère les identités, les droits, la configuration (exposition réseau, chiffrement) et les données. En PaaS, la plupart des incidents viennent d'un paramétrage client, pas de la plateforme.

L'hybride relie un SI sur site et un cloud pour former un seul système ; le multi-cloud utilise plusieurs fournisseurs de cloud, souvent publics. Les deux peuvent coexister ; chacun multiplie les identités et les flux à maîtriser.

Parce qu'un fournisseur soumis à une loi extra-européenne peut être obligé de transmettre des données, quel que soit leur emplacement. La version 3.2 ajoute des exigences d'immunité à ces lois aux exigences techniques et organisationnelles.

Une politique au niveau de l'organisation qui interdit l'accès public au stockage, héritée par tous les comptes et non modifiable par l'équipe projet. La surveillance de posture (CSPM) doit en plus alerter si un écart apparaît.

Pour qu'un attaquant, ou une erreur, dans un compte applicatif ne puisse ni effacer ni modifier les traces. Les journaux partent vers un compte dédié, en stockage immuable, avec des droits de lecture limités.

Le fournisseur gère l'infrastructure et le logiciel ; le client reste responsable des comptes (MFA, départs), des droits, du paramétrage (partages, transferts automatiques) et des données. La plupart des incidents SaaS viennent de cette part client.

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.

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.

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.

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.

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.

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.

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.

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.

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.

L'événement redouté décrit l'atteinte à une valeur métier et sa gravité (« fuite des plans du produit, G4 »). Le scénario décrit comment une source de risque y parvient (chemin stratégique, mode opératoire) et sa vraisemblance. Le risque combine les deux.

À l'atelier 3 : c'est une partie prenante au niveau de menace élevé (forte dépendance, forte pénétration). Elle entre dans les scénarios stratégiques, et les mesures (accès par bastion, droits réduits, clauses contractuelles) visent à la sortir de la zone de danger.

Le propriétaire du risque désigné au cadrage (pour un SI homologué, l'autorité d'homologation), par écrit, avec le risque restant, sa justification et la date de réexamen. Une acceptation orale n'existe pas en audit.

Certains formats de sérialisation peuvent exécuter du code au chargement : un modèle piégé compromettrait le poste dès son ouverture. Un format qui ne contient que des données, avec une empreinte et une provenance vérifiées, ferme ce chemin.

La réponse fausse reprise comme un fait : l'hallucination est inhérente au fonctionnement d'un modèle de langage. On la réduit par la vérification humaine et le marquage des sorties, mais elle reste un risque résiduel accepté par écrit.

C'est une partie prenante de l'écosystème (atelier 3) et un maillon de la chaîne d'approvisionnement : il fournit des biens supports, les poids. Le scénario « modèle piégé » passe par lui, et les mesures portent sur le sas et la vérification de provenance.

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.

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.

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.

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.

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.

À 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 ».

Elle refuse le jalon ou le conditionne : l'administration passera par un bastion depuis une zone dédiée. L'écart se corrige maintenant pour le prix d'une ligne de schéma, au lieu d'une refonte découverte à l'audit.

Le plan d'assurance sécurité décrit comment le prestataire respecte les exigences de sécurité du projet (organisation, moyens, contrôles). On l'exige dans la consultation et on le contractualise avant la réalisation, pour pouvoir ensuite l'auditer.

Parce qu'il détermine les pièces à produire (analyse de risque plus ou moins complète, audits, plans), donc le budget et le planning. Le découvrir à la fin, c'est découvrir des travaux non prévus.

Non, selon le guide de 2025 : l'homologation porte sur l'emploi en conditions réelles. Elle devient obligatoire avant le passage en production, ou dès que de vraies données y sont traitées.

En évaluant la criticité du système pour l'organisation et son exposition aux sources de risque : un site vitrine ou un poste isolé peu critique relève du simplifié, un système traitant des données personnelles de l'intermédiaire, un système sensible ou critique du renforcé.

Les points bloquants sont traités et le dossier est présenté à nouveau. La commission, lorsqu'elle est réunie, formule un avis ; l'autorité peut décider avec réserves, un plan d'action et une durée adaptée. Sa décision et l'acceptation des risques résiduels sont formalisées par écrit.

L'II 901 : SI homologué, socle de sécurité et PSSI, architecture conforme, et chiffrement de l'information DR qui sort du SI par un produit agréé. Au ministère des Armées, l'IM 900 précise l'organisation interne.

La qualification est une recommandation de l'État après évaluation (niveaux élémentaire, standard, renforcé) ; l'agrément autorise un dispositif à protéger de l'information classifiée ou Diffusion Restreinte. Pour du classifié, c'est l'agrément qui est exigé par défaut.

Depuis le 1er juillet 2021, l'ancien Confidentiel Défense correspond au niveau Secret, et l'ancien Secret Défense au Très Secret. Les règles de transition du décret de 2019 encadrent le traitement des anciens marquages.

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.

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.

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.

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.

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.

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.

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.

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 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.