Questions d'entretien CISSP

Non. On ne peut pas comparer la longueur brute des clés entre familles d'algorithmes différentes. En raison de la manière dont les mathématiques sous-jacentes de chacun durcissent, une clé sur courbe elliptique de 256 bits offre à peu près la même sécurité qu'une clé RSA de 3072 bits — environ 128 bits de force, selon le NIST. Plus gros n'est pas simplement plus solide : l'ECC atteint une force équivalente avec des clés bien plus petites, d'où sa préférence dans les systèmes modernes. Au sein d'un même algorithme, des clés plus longues aident, jusqu'à un certain point.

Non. Le cloud repose sur un modèle de responsabilité partagée : le fournisseur sécurise l'infrastructure sous-jacente (« sécurité du cloud »), mais vous restez responsable de vos données, de la gestion des identités et des accès, de la configuration et — en IaaS — du système d'exploitation et des correctifs (« sécurité dans le cloud »). La grande majorité des fuites cloud sont des erreurs de configuration côté client, comme des buckets publics et un IAM trop permissif, et non des défaillances du fournisseur. Croire que le fournisseur sécurise vos données est précisément ainsi que ces fuites surviennent.

Pas nécessairement. Double-chiffrer avec le même algorithme ne double pas simplement la sécurité — le résultat classique est que le 2DES n'ajoute qu'environ un bit de force effective à cause des attaques par rencontre au milieu (meet-in-the-middle), d'où l'existence du 3DES. Plus important, les schémas multicouches faits maison tendent à introduire des bugs d'implémentation qui affaiblissent l'ensemble. Utilisez plutôt un seul chiffrement authentifié éprouvé (AES-GCM) avec une gestion de clés saine.

Une reconstitution d'incident fiable provient de la corrélation de télémétries indépendantes en une seule chronologie : journaux d'authentification, données de processus/exécution de l'EDR, horodatages MAC du système de fichiers, flux réseau et événements SIEM, afin d'ordonner les actions et de borner la portée. Un seul journal ou le dernier événement à lui seul manque la chaîne et peut être trompeur ou falsifié. Deviner à partir d'une source ou interroger l'attaquant ne sont pas des méthodes d'investigation. La corrélation entre sources indépendantes révèle l'activité complète de l'attaquant et résiste à un attaquant ayant modifié l'une d'elles.

L'intégrité probante repose sur le hachage de l'image lors de l'acquisition (par exemple SHA-256) et la vérification ultérieure du hachage pour prouver qu'elle est inaltérée, le maintien d'une chaîne de possession documentée, et l'analyse d'une copie de travail pour que l'original reste intact. Renommer le fichier ne fait rien pour l'intégrité, et le compresser pour gagner de l'espace ne prouve pas l'intégrité ni n'aide la recevabilité. Toucher à l'original risque une destruction de preuves qui peut faire écarter la preuve. Hachez, documentez la possession et travaillez sur une copie vérifiée.

Équilibrez utilisabilité et risque : imposez un accès conditionnel lié à la posture de l'appareil et isolez les données d'entreprise dans un conteneur géré (MAM/MDM) afin de les contrôler et de les effacer sélectivement sans prendre la main sur tout l'appareil personnel. Un accès illimité risque la fuite sur des terminaux non gérés, possiblement compromis. Une interdiction pure et simple pousse aux contournements non sûrs comme le transfert vers une messagerie personnelle. Et envoyer les données en pièces jointes les disperse de façon incontrôlable sur des appareils que vous ne récupérerez jamais.

Aucun produit unique n'arrête toutes les attaques ; une sécurité mature superpose des contrôles indépendants — la défense en profondeur — pour que la défaillance de l'un ne signifie pas la compromission. Cartographiez la dépense proposée par rapport aux véritables lacunes en identité, réseau, poste de travail, données et détection, et conservez les contrôles complémentaires qui fonctionnent déjà. Tout miser sur un seul outil crée un point unique de défaillance, et arracher les contrôles existants pour les remplacer réduit la couverture. Ne rien dépenser du tout ignore de vraies lacunes.

Le chiffrement au repos ne défend qu'une seule menace — le vol physique ou de disque — et n'apporte rien contre une application compromise, des identifiants volés ou un trafic intercepté, car la base déchiffre de façon transparente pour toute requête autorisée. Une conception saine exige aussi du TLS en transit, une authentification et une autorisation fortes, et une gestion des clés avec séparation des tâches. Doubler le chiffrement au repos ajoute du coût sans changer le modèle de menace, et ne chiffrer que les sauvegardes laisse les données en production et leurs chemins d'accès exposés.

Si la clé réside avec le texte chiffré, quiconque vole la base obtient les deux ; le chiffrement ne protège donc rien — c'est une serrure avec la clé scotchée dessus. Les clés doivent être gérées dans un KMS ou HSM dédié, séparées des données, avec contrôle d'accès strict, rotation et séparation des tâches. Hacher la clé la rend à sens unique et inutile pour le déchiffrement, et stocker des copies supplémentaires au même endroit ne fait que multiplier l'exposition au lieu de la réduire.

La modélisation des menaces est la moins coûteuse et la plus efficace à la conception, avant que le code ne fige les décisions : parcourez les flux de données, énumérez les menaces avec un cadre comme STRIDE, intégrez les mesures, puis révisez à mesure que la conception évolue. La faire seulement après un incident ou au pentest annuel révèle les problèmes une fois qu'ils sont coûteux à corriger et déjà exposés. Et se fier à des « développeurs prudents » est un espoir, non un contrôle reproductible et auditable.

La confiance fondée sur l'emplacement réseau signifie qu'un seul point d'appui à l'intérieur ouvre un large déplacement latéral — un identifiant VPN hameçonné et l'attaquant est « à l'intérieur ». Le zero trust supprime la confiance implicite : chaque accès est authentifié, autorisé et réévalué en continu selon l'identité et la posture de l'appareil, avec moindre privilège et segmentation (NIST SP 800-207). Un second VPN ou un VPN élargi ne fait qu'étendre le même problème de confiance plate, et faire confiance au LAN plutôt qu'au VPN répète l'erreur initiale.

Sans journaux d'audit du plan de contrôle, vous êtes aveugle à qui a fait quoi au niveau cloud, et détection, forensique et conformité dépendent toutes de cet enregistrement. Activez CloudTrail immédiatement, à l'échelle de l'org, en livrant vers un bucket séparé, à accès contrôlé et résistant à la falsification (immuable). Dire que ça n'a pas d'importance tant que rien ne va mal ignore que vous n'auriez aucun historique le jour où ça ira mal. Attendre un incident signifie que les premières actions décisives sont déjà non journalisées et irrécupérables. Les journaux applicatifs ne capturent pas l'activité API, IAM ou console du plan de contrôle.

Un rôle d'instance surprivilégié transforme la moindre faille applicative — notamment une SSRF atteignant le service de métadonnées d'instance — en prise de contrôle complète du compte, car l'attaquant hérite des identifiants du rôle. Remplacez le wildcard par les seules actions et ARN de ressources réellement utilisés par la charge de travail, et imposez IMDSv2 pour durcir le point de terminaison de métadonnées. Un VPC ne contraint en rien l'IAM. Une seule règle de refus relève du jeu de la taupe et laisse tout le reste autorisé. Un répartiteur de charge n'a aucun rapport avec la portée d'impact de l'identifiant.

Suivez l'ordre de volatilité. La RAM, les connexions réseau actives et la table des processus disparaissent à l'arrêt ; capturez-les donc en premier, puis prenez une image forensique du disque en documentant les empreintes et une chaîne de possession ininterrompue. Un arrêt propre détruit les preuves résidentes en mémoire — y compris le malware sans fichier et les clés qui n'existent qu'en RAM. Copier-puis-supprimer altère la scène et brise l'intégrité. Lancer l'antivirus de l'entreprise modifie le système et peut mettre en quarantaine ou supprimer l'artefact même que vous devez analyser.

Le confinement prime sur la restauration prématurée : stoppez la propagation en isolant les segments touchés et en coupant le vecteur — désactivez le compte de service abusé, bloquez SMB entre segments, retirez l'hôte de staging — tout en préservant les preuves, puis éradiquez et restaurez. Restaurer dans un réseau qui chiffre encore reperd les données restaurées. Payer la rançon n'arrête pas le chiffrement en cours et comporte un risque légal et de sanctions. Couper le courant de toutes les machines détruit les preuves volatiles et peut corrompre des fichiers en cours d'écriture, compliquant une restauration propre.

Éradiquer avant de comprendre la portée laisse l'attaquant persister sur des systèmes que vous n'avez pas trouvés et simplement revenir. Chassez vite les IOC et les identifiants volés sur tout le parc, identifiez chaque hôte touché et chaque mécanisme de persistance, puis éradiquez partout d'un coup. Effacer un seul hôte est du whack-a-mole qui alerte l'attaquant tout en laissant ses autres points d'ancrage intacts. Une coupure totale d'internet d'une semaine est disproportionnée et nuit à l'entreprise. Supprimer juste le fichier malveillant ignore la persistance, le mouvement latéral et les identifiants déjà volés.

Les réseaux plats permettent à un seul appareil invité compromis d'atteindre directement les systèmes les plus précieux. Segmentez par niveau de confiance et appliquez un trafic à moindre privilège entre les zones pour contenir et surveiller les déplacements latéraux. Un pare-feu de bordure ne fait rien pour le trafic est-ouest entre des hôtes déjà à l'intérieur. Re-adresser les serveurs financiers est de la sécurité par l'obscurité qu'un simple scan déjoue. L'antivirus est une couche de détection, pas un substitut au contrôle architectural d'isolement des systèmes sensibles.

Moindre privilège plus accès juste-à-temps : accordez le minimum de permissions nécessaires, limité dans le temps et journalisé, pour que le débogage soit possible sans admin permanent devenant un risque durable et un angle mort d'audit. Un cluster-admin permanent viole le moindre privilège et élargit le rayon d'impact de toute compromission. Un refus total bloque le travail légitime et invite à des contournements parallèles risqués. Partager l'identifiant commun du compte de service admin détruit la responsabilité — les actions ne sont plus rattachables à une personne.

La chaîne d'approvisionnement LLM couvre les modèles de base, les variantes fine-tunées, les jeux de données, les embeddings, les plugins, les bibliothèques et la plateforme d'hébergement — chacun un endroit où introduire du risque. Les menaces incluent le téléchargement de poids de modèle altérés ou avec backdoor, des fine-tunes malveillants, des jeux de données empoisonnés ou à la licence viciée, des plugins vulnérables ou sur-permissionnés et des dépôts de modèles typosquattés. Défenses : sourcer les modèles depuis des registres de confiance, vérifier l'intégrité et la provenance, maintenir un AI bill of materials, scanner et épingler les dépendances, vérifier les plugins et appliquer le moindre privilège à tout ce que le modèle intègre.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

L'OWASP Top 10 for LLM Applications est la liste consensuelle des risques les plus critiques lorsqu'on construit avec de grands modèles de langage. L'édition 2025 couvre la prompt injection, la divulgation d'informations sensibles, la supply chain, l'empoisonnement des données et du modèle, le traitement non sécurisé des sorties, l'excessive agency, la fuite de system prompt, les faiblesses des vecteurs et embeddings, la désinformation et la consommation non bornée. Elle existe parce que les listes appsec traditionnelles ne capturent pas les modes de défaillance propres aux LLM, et elle donne aux équipes un vocabulaire commun et une checklist pour prioriser les contrôles.

La sécurité RAG, c'est traiter chaque document récupéré comme une entrée non fiable. Risques clés : prompt injection indirecte cachée dans le contenu récupéré, empoisonnement de la base de connaissances ou des embeddings, et absence d'autorisation par utilisateur si bien que le modèle renvoie des données auxquelles l'utilisateur n'a pas accès. Les défenses incluent le contrôle d'accès appliqué à la récupération, la provenance du contenu et la vérification à l'ingestion, traiter le texte récupéré comme des données et non des instructions, la validation des sorties et l'isolement du magasin de vecteurs par locataire.

Un agent LLM transforme du texte en actions via des outils et des function calls, donc une prompt injection devient une action réelle — le risque d'excessive agency. Sécurisez-le en donnant à chaque outil le moindre privilège et la portée dont il a besoin, en validant et contraignant les arguments d'outils, en exigeant une confirmation humaine pour les actions sensibles ou irréversibles, en sandboxant l'exécution, en limitant le débit et en budgétant les appels, et en journalisant chaque invocation d'outil. Ne laissez jamais la sortie du modèle, influencée par des données non fiables, autoriser directement une action à fort impact.

Les applis LLM divulguent des données de plusieurs façons : le modèle mémorise et restitue des données d'entraînement ou de fine-tuning sensibles, le system prompt (qui peut contenir des secrets ou de la logique) est extrait, des documents RAG récupérés exposent des données que l'utilisateur ne devrait pas voir, et le contexte d'un utilisateur ou d'une session déborde sur un autre. La prévention passe par la minimisation des données avant l'entraînement, ne jamais mettre de secrets dans les prompts, appliquer l'autorisation par utilisateur à la récupération, le filtrage des sorties et la rédaction de PII, et l'isolement par locataire.

L'empoisonnement des données d'entraînement, c'est quand un attaquant altère les données utilisées pour pré-entraîner, fine-tuner ou créer les embeddings d'un modèle afin que le modèle résultant se comporte de façon malveillante — en intégrant un déclencheur de backdoor, en injectant du biais ou en dégradant la précision. Il exploite le fait que les modèles aspirent et font confiance à de vastes jeux de données souvent issus du web. Les défenses incluent la curation et la signature des sources de données, les vérifications de provenance et d'intégrité, la détection d'anomalies sur les données d'entraînement, le versionnage des jeux de données, et la limitation de qui peut contribuer aux corpus d'entraînement et RAG.

DAC permet au propriétaire des données d'accorder l'accès à sa discrétion ; MAC applique l'accès de façon centralisée via des étiquettes/habilitations et est non discrétionnaire ; RBAC accorde l'accès via des rôles métier ; ABAC évalue des attributs (utilisateur, ressource, environnement) au regard d'une politique pour des décisions fines et contextuelles.

La continuité d'activité (BCP) est la stratégie globale visant à maintenir les fonctions métier critiques pendant et après une perturbation ; la reprise après sinistre (DRP) en est le sous-ensemble informatique qui restaure les systèmes et les données. Le RTO est le temps maximal tolérable pour rétablir une fonction ; le RPO est la perte de données maximale tolérable mesurée en temps.

La classification étiquette les données par sensibilité afin que l'organisation applique des contrôles proportionnés à la valeur et au risque, évitant à la fois la sous-protection et la surprotection coûteuse. Le propriétaire des données (un rôle métier) fixe la classification et accepte le risque, tandis que le dépositaire des données (souvent l'IT) met en œuvre et maintient les contrôles de protection.

La défense en profondeur superpose des contrôles multiples, variés et indépendants à travers les personnes, les processus et la technologie, afin que la défaillance d'un seul contrôle n'entraîne pas de compromission. Elle suppose que chaque contrôle finira par échouer et utilise la redondance et la variété pour ralentir, détecter et contenir un attaquant.

La due diligence est l'investigation et la compréhension continues des risques (savoir ce qu'il faut faire), tandis que la due care consiste à prendre les mesures raisonnables qu'une personne prudente prendrait pour y répondre (le faire réellement). La diligence est la recherche et la supervision ; la care est la mise en œuvre et le maintien.

La gestion du cycle de vie des identités encadre un compte de sa création à sa fin : attribution à l'arrivée (joiner), ajustement des droits lors d'un changement de rôle (mover), et suppression rapide au départ (leaver), avec des revues d'accès périodiques tout au long. Les défaillances les plus courantes sont l'accumulation de privilèges chez les movers et les comptes orphelins issus de suppressions manquées.

Une politique est l'énoncé obligatoire de haut niveau de l'intention de la direction ; une norme est une règle obligatoire et spécifique qui applique la politique (par exemple AES-256) ; une procédure est le mode opératoire obligatoire étape par étape ; une ligne directrice est une recommandation facultative. Les politiques, normes et procédures sont obligatoires, tandis que les lignes directrices sont discrétionnaires.

L'analyse quantitative attribue des valeurs monétaires concrètes pour calculer la perte attendue ; l'analyse qualitative classe le risque sur des échelles relatives (élevé/moyen/faible) par jugement d'expert. La quantitative utilise SLE = valeur de l'actif x facteur d'exposition, ARO = occurrences attendues par an, et ALE = SLE x ARO pour exprimer la perte annuelle attendue en euros.

Vous pouvez atténuer (réduire la probabilité/l'impact avec des contrôles), transférer (déplacer l'impact financier via une assurance ou des contrats), éviter (cesser entièrement l'activité risquée) ou accepter (tolérer sciemment le risque résiduel). Le choix dépend de l'appétit pour le risque et d'une comparaison coûts-bénéfices au regard de la perte attendue du risque.

Intégrez la sécurité à chaque phase du SDLC plutôt que de tester à la fin : les exigences incluent des exigences de sécurité et de confidentialité, la conception inclut la modélisation des menaces, le développement suit des normes de codage sécurisé avec SAST, les tests ajoutent DAST et des revues, et la mise en production nécessite une validation — le tout gouverné par la politique, la séparation des tâches et la gestion des changements. Corriger les failles tôt coûte nettement moins cher qu'après la mise en production.

Le client construit une chaîne du certificat serveur (feuille) en remontant par une ou plusieurs autorités de certification intermédiaires jusqu'à une autorité racine de son magasin de confiance. Il vérifie la signature de chaque certificat avec la clé publique de l'émetteur suivant, contrôle les dates de validité, la correspondance du nom/nom d'hôte, l'usage de la clé et la révocation (CRL/OCSP). La confiance se termine à une racine auto-signée pré-approuvée ; la chaîne n'est valide que si chaque maillon est correct.

La signature lie cryptographiquement un artefact à son producteur, afin que les consommateurs puissent vérifier qu'il n'a pas été altéré ou substitué. La provenance est une métadonnée signée décrivant comment, où et à partir de quelle source l'artefact a été construit. Ensemble — via des outils comme Sigstore pour la signature sans clé et le framework SLSA pour les niveaux de provenance — ils permettent à un déployeur de vérifier qu'une image provient du pipeline et de la source attendus, déjouant l'altération et les attaques par substitution de dépendances.

Traitez le pipeline comme une infrastructure de production : il détient les identifiants pour livrer le code et atteindre la prod, donc le compromettre contourne tous les contrôles en aval. Durcissez-le avec des runners isolés et éphémères ; des tokens à privilège minimal et courte durée (fédération OIDC au lieu de secrets à longue durée) ; des branches protégées et une config de pipeline revue ; des actions tierces épinglées par empreinte ; et une journalisation d'audit complète. Le pipeline est une cible de premier ordre, pas de la tuyauterie.

La triade CIA désigne les trois objectifs fondamentaux de la sécurité de l'information : la confidentialité (seules les parties autorisées peuvent lire les données), l'intégrité (les données ne sont pas modifiées sans autorisation) et la disponibilité (les utilisateurs autorisés accèdent aux systèmes quand ils en ont besoin). Presque chaque contrôle se rattache à un ou plusieurs de ces objectifs.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants afin que, si l'un échoue, les autres protègent encore l'actif. Elle suppose qu'aucun contrôle n'est parfait — par exemple en combinant pare-feu, segmentation réseau, protection des terminaux, MFA, moindre privilège et chiffrement, plutôt que de se fier au seul périmètre.

Le moindre privilège signifie que chaque utilisateur, processus et service ne reçoit que l'accès minimal requis pour sa tâche, et rien de plus. Cela limite le rayon d'impact d'un compte compromis, réduit le risque de menace interne et diminue la surface d'attaque. On l'applique via l'accès basé sur les rôles, des revues d'accès régulières et l'élévation juste-à-temps.

Une vulnérabilité est une faiblesse (logiciel non corrigé). Une menace est un acteur ou un événement qui pourrait l'exploiter (un groupe de rançongiciel). Le risque est la combinaison de la probabilité qu'une menace exploite une vulnérabilité et de l'impact si elle le fait. Risque = menace x vulnérabilité x impact, et c'est ce que l'on priorise réellement.

Parce qu'ils sont rapides. MD5 et SHA-256 sont conçus pour la vitesse, ce qui est exactement l'inverse de ce qu'il faut pour les mots de passe : un attaquant qui vole les hachages peut calculer des milliards de tentatives par seconde sur un GPU. La solution est une fonction de dérivation de clé délibérément lente et coûteuse en mémoire — bcrypt, scrypt ou Argon2 — combinée à un sel par utilisateur et à un facteur de travail ajustable.

Les contrôles se classent de deux façons. Par type : administratif (politiques, formation, procédures), technique/logique (pare-feu, MFA, chiffrement) et physique (serrures, badges, caméras). Par fonction : préventif (empêcher un événement — MFA, contrôle d'accès), détectif (repérer un événement — SIEM, IDS, journaux d'audit), correctif (réparer après — restauration de sauvegarde, correctif), dissuasif (décourager — bannières d'avertissement) et compensatoire (une alternative quand le contrôle principal n'est pas faisable). La défense en profondeur superpose ces contrôles pour qu'aucune défaillance isolée ne mène à une compromission.

Le NIST Cybersecurity Framework organise les résultats de cybersécurité en fonctions principales. Dans le CSF 2.0, il y en a six : Govern (la nouvelle fonction faîtière pour la stratégie, les rôles, les décisions de risque et la supervision), Identify (comprendre les actifs et les risques), Protect (garanties pour limiter l'impact), Detect (repérer les événements), Respond (agir sur les incidents) et Recover (restaurer les capacités). Elles ne sont pas strictement séquentielles — elles fonctionnent en continu et décrivent ensemble un cycle de vie complet de gestion du cyber-risque.

Les revues d'accès (recertification) sont des vérifications périodiques où un propriétaire responsable confirme que l'accès de chaque personne reste justifié, et révoque ce qui ne l'est pas. Elles constituent le filet de sécurité qui détecte la dérive de privilèges, les comptes orphelins et les droits accordés pour un projet terminé. Le contrôle ne fonctionne que si un propriétaire compétent — généralement le manager ou le propriétaire de la ressource — examine réellement l'accès au lieu de le valider machinalement, et si les révocations sont appliquées.

Une analyse de risque identifie les actifs et leur valeur, les menaces et vulnérabilités qui pourraient les affecter, puis estime le risque comme une fonction de la vraisemblance et de l'impact. On peut la mener qualitativement (élevé/moyen/faible, rapide et subjectif) ou quantitativement (SLE × ARO = ALE, fondé sur des données mais plus difficile). Des référentiels comme NIST RMF et ISO 27005 lui donnent une structure, et la sortie alimente le traitement du risque : atténuer, transférer, éviter ou accepter.

Un SDLC sécurisé intègre la sécurité à chaque phase au lieu de tester à la fin : exigences (cas de sécurité et d'abus), conception (modélisation des menaces), implémentation (standards de codage sécurisé, SAST/SCA dans l'IDE et la CI), tests (DAST, pentest), publication (gates et validation) et exploitation (surveillance, patching, feedback). Le shift-left déplace les défauts plus tôt, là où ils sont peu coûteux à corriger ; des modèles de maturité comme OWASP SAMM et BSIMM mesurent à quel point vous le faites réellement.

La modélisation des menaces répond à quatre questions : que construisons-nous, qu'est-ce qui peut mal tourner, qu'allons-nous y faire, et avons-nous bien fait le travail. Vous schématisez le système (souvent un diagramme de flux de données avec frontières de confiance), énumérez les menaces avec un framework comme STRIDE, priorisez par risque et assignez des mitigations. PASTA ajoute une saveur centrée sur le risque et l'attaquant ; les arbres d'attaque décomposent un seul objectif. Le faire au moment de la conception est bien moins coûteux que de patcher la production.

Une DMZ (zone démilitarisée) est un segment réseau situé entre l'Internet non fiable et le réseau interne de confiance, hébergeant des services exposés au public comme les serveurs web, mail et DNS. Les règles de pare-feu laissent Internet atteindre la DMZ mais restreignent fortement l'accès de la DMZ au réseau interne. Le but est le confinement : si un serveur public est compromis, l'attaquant reste coincé dans la zone tampon plutôt que d'atterrir dans le LAN.

Un bon rapport sert deux publics : un résumé exécutif qui cadre le risque métier pour la direction, et des trouvailles détaillées et reproductibles avec preuves, évaluations de risque exactes et remédiation priorisée pour l'équipe technique. Le rapport — et non l'exploit — est le livrable.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants pour que, si l'un échoue, les autres protègent encore l'actif. Aucun contrôle n'est supposé parfait, on empile donc des mesures préventives, de détection et de réponse sur les couches réseau, hôte, application et données.

Le moindre privilège signifie que chaque utilisateur, processus ou service ne reçoit que l'accès minimal nécessaire à sa tâche, et rien de plus. Cela réduit le rayon d'impact de toute compromission ou erreur. On l'applique avec l'accès basé sur les rôles, l'élévation juste-à-temps, des revues d'accès régulières et la suppression des droits administrateurs permanents.

Un SDLC sécurisé intègre la sécurité à chaque phase plutôt que de la rajouter à la fin. Les exigences incluent des cas de sécurité et d'abus, la conception ajoute la modélisation des menaces, le développement utilise le codage sécurisé et le SAST plus l'analyse des dépendances, les tests ajoutent le DAST et les tests d'intrusion, et l'exploitation ajoute la surveillance, les correctifs et la réponse aux incidents — en décalant la sécurité vers la gauche.

La segmentation divise un réseau en zones isolées pour qu'une intrusion dans l'une ne puisse pas atteindre librement les autres, limitant le mouvement latéral. Le zero trust va plus loin : il supprime entièrement la confiance implicite fondée sur l'emplacement réseau, en authentifiant et autorisant chaque requête où qu'elle provienne — la microsegmentation est l'un des moyens de l'implémenter.

Une PKI est le système de CA, de certificats et de politiques qui lie les clés publiques aux identités. Pour valider un certificat de serveur, un client construit une chaîne jusqu'à une racine de confiance, vérifie chaque signature, contrôle les dates de validité et le nom d'hôte, confirme l'usage de la clé, et vérifie la révocation via CRL ou OCSP.