Questions d'entretien en cybersécurité niveau Senior

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.

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 autonomie sans limites associée à l'accès aux outils, c'est l'« agence excessive » d'OWASP LLM : un modèle manipulé ou en erreur peut entreprendre des actions destructrices. Encadrez-le avec des outils au moindre privilège, exigez une confirmation humaine pour les opérations irréversibles, et gardez des permissions restreintes et auditées. Lui faire confiance ou lui donner les droits admin élargit le rayon d'impact, et masquer un bouton dans l'interface ne change rien à la capacité sous-jacente du modèle à appeler l'action.

Le contenu non fiable que le modèle ingère peut porter des instructions — c'est l'injection de prompt indirecte. Vous ne pouvez pas empêcher totalement le modèle d'être influencé, alors isolez le contenu récupéré en tant que donnée, limitez les outils/permissions de l'agent, exigez une confirmation pour les actions sensibles, et évitez de lui confier des secrets qu'il pourrait être contraint de divulguer. Supposer que le modèle ignorera simplement les instructions injectées, c'est exactement le mode de défaillance exploité.

C'est la « gestion incorrecte des sorties » d'OWASP LLM : une sortie de modèle influencée par l'entrée utilisateur peut devenir une injection de commande lorsqu'elle est transmise à un shell ou à eval. Traitez-la comme non fiable — faites correspondre les intentions à une petite liste blanche d'actions paramétrées, validez strictement et exécutez dans un bac à sable plutôt que de lancer des chaînes générées brutes. Faire confiance à la sortie, augmenter la limite de jetons ou se contenter de journaliser n'arrête en rien l'injection.

Si la récupération extrait n'importe quel document indexé quelle que soit la personne qui interroge, le modèle restituera fidèlement des données que l'utilisateur ne devrait pas voir — c'est une faille d'autorisation, pas une hallucination. Imposez les permissions de l'utilisateur au niveau du document au moment de la récupération, pour que seuls les fragments autorisés entrent dans le contexte. Un prompt système plus long est contournable et n'implémente aucun contrôle d'accès, la température n'a aucun rapport, et un autre modèle présente la même faille.

S'entraîner sur des données utilisateurs non vérifiées permet à un attaquant d'empoisonner le modèle — en y implantant des portes dérobées, des déclencheurs ou un comportement biaisé qui surgit plus tard. Maîtrisez-le par la vérification et le filtrage des données, le suivi de provenance, la détection d'anomalies sur le jeu de données et l'évaluation du comportement du modèle après l'entraînement. « Plus de données, c'est mieux » ignore l'intégrité, et le vrai souci est l'empoisonnement, pas la vitesse ni l'espace disque.

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.

Un vide dans les journaux locaux pendant un incident peut signifier des journaux effacés ou falsifiés, une étape anti-forensique courante, donc ne traitez pas l'absence de journaux comme une absence d'activité. Recoupez avec des journaux centralisés/transférés, l'EDR et les données réseau que l'attaquant n'a probablement pas pu altérer, et consignez le vide d'intégrité comme un constat. Supposer que le serveur était inactif fait confiance à des preuves que l'attaquant contrôle peut-être, traiter le vide comme une preuve que rien ne s'est passé est exactement la conclusion qu'il veut, et supprimer d'autres journaux détruit ce qui reste. Corroborez plutôt avec une télémétrie indépendante.

Les référentiels fixent une barre minimale et peuvent être pleinement satisfaits alors qu'un risque réel subsiste ; une check-list réussie ne signifie donc pas sécurisé : signalez la faille, évaluez son risque et pilotez son traitement, quel que soit le statut de conformité. Conclure que c'est sécurisé parce que la conformité est validée est un amalgame dangereux entre deux choses différentes. Retirer la faille du rapport est une falsification, voire une fraude. Attendre le prochain cycle d'audit laisse sciemment une exposition réelle ouverte. La posture mature traite la conformité comme la preuve d'un plancher, pas d'un plafond, et agit sur le risque que l'on peut réellement voir.

Le périmètre PCI DSS couvre les systèmes qui stockent, traitent ou transmettent les données de titulaires de cartes, plus tout système qui leur est connecté ou peut les affecter ; une segmentation réseau efficace isole donc l'environnement des données de cartes (CDE) et exclut du périmètre les systèmes sans rapport, réduisant coût, effort et risque. Chiffrer tous les serveurs ne définit aucune frontière et les systèmes connectés restent dans le périmètre ; ajouter des pare-feu partout sans cible n'est pas de la segmentation si cela ne restreint ni ne valide les flux de données ; et cesser de lire les numéros de carte à voix haute relève de l'hygiène, pas d'un contrôle de périmètre. La réponse systémique est de maîtriser où vivent les données de cartes et ce qui peut les atteindre.

Un rapport SOC 2 ne vous rassure que si vous le lisez vraiment : confirmez le bon type (le Type II teste l'efficacité opérationnelle dans la durée, le Type I seulement la conception à un instant donné), vérifiez le périmètre et les critères des services de confiance couverts, que la période est récente et sans trou, l'opinion rendue par l'auditeur (sans réserve ou avec réserve), et examinez les exceptions relevées ainsi que les contrôles complémentaires de l'entité utilisatrice (CUEC) qui vous incombent. Se contenter de constater que le rapport existe — ou le juger à son logo de couverture ou à son nombre de pages — ne dit rien de l'efficacité réelle des contrôles du fournisseur ni de vos obligations résiduelles.

Une redirection ouverte sur un flux d'authentification permet à un attaquant de forger un lien de connexion d'apparence fiable qui, après authentification, envoie l'utilisateur — et potentiellement un code d'autorisation ou un jeton — vers un domaine contrôlé par l'attaquant, permettant le détournement de compte et un phishing convaincant. Corrigez-le en allow-listant strictement les redirect URI exacts côté serveur et en rejetant tout le reste. Ce n'est ni cosmétique ni un problème de performance, et HTTPS n'aide pas car la destination de l'attaquant peut aussi être un site HTTPS valide.

Le malware fileless vit dans la mémoire des processus (injection, chargement réflectif, LOLBins), donc acquérez et analysez une image mémoire pour trouver le code injecté, les modules suspects et les relations entre processus. Un scan antivirus du disque et un disque propre ne vous disent rien d'un implant en mémoire. La corbeille est hors sujet. L'analyse mémoire est le bon outil quand il n'y a pas de fichier à trier, et vous devez capturer avant tout redémarrage de l'hôte.

Utilisez des services réseau simulés ou un egress étroitement surveillé et non attribuable, pour étudier le comportement du C2 sans révéler votre vraie IP à l'attaquant ni laisser l'hôte recevoir des commandes nuisibles. Interagir depuis l'IP de l'entreprise alerte l'opérateur et risque un vrai dommage. Ponter le sandbox au LAN invite à la propagation. Désactiver les logs jette les données d'analyse. Contrôlez le réseau pour observer sans exposer ni être instrumentalisé.

Le packing masque le vrai code, donc une entropie élevée plus des imports absents est un signe qu'il faut dépaqueter — détectez le packer et dumpez l'image dépaquetée depuis la mémoire une fois le loader exécuté, puis analysez la vraie charge utile. Des chaînes illisibles sont une preuve d'évasion, pas de bénignité. Conclure à un faux positif ou renommer l'extension ignore un échantillon activement obfusqué. L'obfuscation elle-même est un fort indicateur malveillant à investiguer.

Les malwares vérifient couramment les artefacts de VM/sandbox, les durées d'exécution courtes ou l'interaction utilisateur et restent dormants s'ils les détectent. Déguisez et durcissez la VM d'analyse, prolongez l'exécution ou passez sur bare metal, et extrayez le comportement depuis une image mémoire de l'hôte vivant. Supposer qu'il est cassé ou que l'hôte se trompe ignore un échantillon prouvé malveillant en conditions réelles. Un redémarrage ne change rien car la logique d'évasion se déclenche à chaque exécution.

Récupérer côté serveur des URL contrôlées par l'attaquant relève du Server-Side Request Forgery (SSRF) : cela permet d'atteindre des services internes ou le point de terminaison de métadonnées cloud pour voler des identifiants. Pour l'atténuer, restreignez les hôtes et schémas autorisés par allow-list, bloquez les plages privées et link-local (en revérifiant après chaque redirection) et durcissez l'accès aux métadonnées avec IMDSv2. Dire qu'il n'y a aucun risque ignore l'accès que confère la requête, et un spinner de chargement ou une mise en cache ne change rien aux destinations que le serveur peut joindre.

`alg: none` permet à quiconque de forger un jeton non signé d'apparence valide et d'usurper n'importe quel utilisateur — un contournement total de l'authentification, pas un détail. Corrigez-le en autorisant côté serveur une liste blanche des algorithmes attendus et en vérifiant toujours la signature avec la bonne clé ; ne faites jamais confiance à l'en-tête alg du jeton pour choisir la méthode de vérification. Une expiration plus longue ou un changement de stockage ne fait rien contre des jetons forgés et non signés. C'est critique et exploitable, documenter n'est donc pas une correction.

L'injection de prompt ne se résout pas entièrement avec plus de texte ; supposez que le modèle peut être détourné et contraignez ce qu'il est autorisé à FAIRE. Donnez aux outils le moindre privilège, conditionnez les actions à fort impact à une confirmation humaine, et validez ou isolez les appels d'outils avant d'agir (OWASP LLM « excès d'autonomie » et « gestion inadéquate des sorties »). Implorer dans le prompt système est contournable. Une température plus élevée n'ajoute que de l'aléa, et la seule journalisation enregistre le dommage sans empêcher l'action injecté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.

Transmettre des données personnelles à un tiers étend votre périmètre de confiance ; menez donc d'abord une évaluation de sécurité du fournisseur — traitement des données, chiffrement, contrôles d'accès, certifications comme SOC 2 / ISO 27001, sous-traitants, modalités de notification de violation — et signez un accord de traitement des données (DPA) avant tout transfert. Un contrat de prix ou la parole verbale d'un commercial n'est pas une diligence raisonnable. Et un « site web soigné » ne dit rien sur la façon dont le fournisseur protège réellement les données ; vous en restez responsable.

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.

« Sécurisé » n'est pas binaire ; un RSSI communique dans le langage du risque métier : les risques les plus importants, la manière dont les contrôles actuels les réduisent par rapport à l'appétit pour le risque du conseil, les investissements prévus et le risque résiduel accepté. Un « oui » absolu est une fausse assurance qui s'effondre dès le premier incident. « Non, nous ne serons jamais sécurisés » est techniquement vrai mais inutile et trahit un manque de maîtrise. Une liste d'achats de pare-feu et d'outils traduit une dépense, pas un risque ni un résultat que le conseil puisse gouverner.

La gestion d'une violation est encadrée par la loi et le contrat : travailler avec le juridique pour respecter les délais de notification obligatoires (comme les 72 heures du RGPD vers l'autorité de contrôle) et informer les personnes concernées avec exactitude. La dissimulation expose à des amendes bien plus lourdes, à des sanctions et à une atteinte à la réputation lorsqu'elle est découverte. Diffuser prématurément des détails techniques bruts et non vérifiés peut induire les clients en erreur et aider les attaquants. Désigner publiquement un employé comme bouc émissaire n'est ni exact, ni légal, ni une gestion de crise efficace.

Les métriques de niveau conseil doivent se rattacher au risque et aux résultats : temps de détection et de réponse (MTTD/MTTR), respect des SLA de correctifs sur les systèmes critiques, couverture des contrôles et évolution du risque résiduel par rapport à l'appétit. Le nombre d'attaques bloquées par le pare-feu, le compte des signatures antivirus et le total des courriels reçus sont des chiffres vaniteux — ils impressionnent mais ne disent rien sur la baisse du risque. Le conseil gouverne le risque, les métriques doivent donc lui montrer la tendance et lui permettre de décider.

Les dépenses de sécurité doivent suivre le risque, pas l'effet de mode : utiliser une analyse de risque pour orienter l'argent là où l'impact métier et la probabilité sont les plus élevés et où la couverture des contrôles actuels est la plus faible, puis mesurer la réduction obtenue. Acheter ce que vend le fournisseur à la mode ignore votre profil de menace réel et finance souvent des outils inutilisés. Répartir le budget également sous-finance les rares domaines qui comptent le plus. Copier les concurrents suppose que leur profil de risque égale le vôtre, ce qui est rarement le cas.

Quand on ne peut pas remédier, on gère le risque : réduire l'exposition par des contrôles compensatoires (segmentation réseau, restriction des accès, surveillance renforcée), quantifier le risque résiduel et faire accepter formellement ce risque par le propriétaire métier responsable, avec une date de revue définie. Un arrêt unilatéral outrepasse l'autorité du RSSI et nuit à l'entreprise. L'ignorer parce qu'il est non corrigeable est une négligence. L'omettre du registre des risques masque la responsabilité, rompt la piste d'audit et signifie que personne n'assume officiellement la décision.

Une violation chez un fournisseur est aussi votre incident : déclencher la réponse à incident pour cadrer quelles données et intégrations ont été exposées, faire tourner tous les secrets partagés, clés API et relations de confiance SSO, évaluer vos propres obligations de notification réglementaire et tenir le fournisseur à sa divulgation. Attendre passivement le fournisseur vous fait perdre le contrôle de votre propre calendrier et de vos obligations. Une résiliation publique du contrat est un effet de manche prématuré avant même de connaître votre exposition. Supposer que vous n'êtes pas touché saute précisément l'évaluation qu'attendent les régulateurs et vos clients.

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.

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.

Ce qui compte, c'est l'impact : un identifiant de service réutilisé ou surprivilégié qui débloque l'admin du domaine ou des systèmes critiques est le constat qui compte, alors testez la réutilisation et cartographiez les privilèges et le chemin de mouvement latéral. Casser d'abord tous les autres hashs est une perte de temps qui retarde l'essentiel. Changer le mot de passe du compte de service est destructeur, casse la production et alerte les défenseurs. Envoyer un identifiant actif en clair par e-mail est en soi une exposition et une mauvaise hygiène opérationnelle.

Découvrir une intrusion active est une urgence hors bande : les règles d'engagement doivent définir une procédure d'escalade, alors déclenchez-la immédiatement, préservez les preuves et évitez de contaminer un incident en cours. Continuer à tester peut interférer avec le vrai attaquant ou détruire les preuves mêmes dont les intervenants ont besoin. Tenter d'expulser l'attaquant vous-même est hors périmètre, risqué et peut l'alerter. Attendre le rapport final pourrait signifier des jours de violation continue et de perte de données.

Une RCE non authentifiée sur un serveur exposé sur Internet relève de l'urgence : réduisez la fenêtre d'exposition par un déploiement testé, en staging ou progressif, et ajoutez des contrôles compensatoires (restreindre l'accès, règles WAF) en attendant. Attendre la fenêtre trimestrielle laisse un trou exploitable comme un ver ouvert des semaines. Patcher à l'aveugle en production en heures ouvrées sans test risque une panne et un rollback raté. Se fier au pare-feu périmétrique ne sert à rien — le service est déjà exposé et l'exploit n'a besoin d'aucun identifiant.

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.

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.

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.

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.

L'exfiltration DNS encode des données volées dans des requêtes DNS (par ex. de longs labels de sous-domaine envoyés à un serveur autoritaire contrôlé par l'attaquant), en abusant du fait que le DNS est presque toujours autorisé en sortie et souvent non surveillé. Détectez-la par des anomalies : volume de requêtes anormalement élevé vers un domaine, sous-domaines longs / à forte entropie, nombreux sous-domaines uniques par domaine parent, abus d'enregistrements TXT/NULL, et requêtes vers des domaines récemment enregistrés ou rares.

L'injection de processus exécute le code de l'attaquant dans l'espace mémoire d'un processus légitime pour que l'activité se fonde dans la masse et hérite de la confiance de ce processus. Les techniques classiques incluent l'injection de DLL (CreateRemoteThread + LoadLibrary), le process hollowing (lancer un processus bénin suspendu, le démapper, y écrire du code malveillant) et l'injection d'APC. Les défenseurs la détectent via les hooks d'API de l'EDR, des relations parent/enfant ou des régions mémoire anormales (RWX, mémoire exécutable non adossée à un fichier) et les événements CreateRemoteThread de Sysmon.

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

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.

IMDS est un point d'accès link-local (169.254.169.254) qui fournit à une instance ses métadonnées, dont les identifiants temporaires de son rôle IAM attaché. La SSRF peut tromper le serveur pour qu'il récupère cette URL et fasse fuiter ces identifiants. IMDSv2 exige un PUT pour obtenir un jeton de session à courte durée de vie, définit une limite de saut (hop limit) / TTL IP par défaut de 1, et rejette les requêtes avec certains en-têtes — si bien qu'un simple GET de SSRF ne peut plus l'atteindre.

Le RBAC contrôle ce que les identités peuvent faire sur l'API Kubernetes — les Roles et ClusterRoles accordent des verbes sur des ressources, liés à des sujets via des RoleBindings — et doit suivre le moindre privilège, en évitant cluster-admin et les wildcards. Les politiques réseau contrôlent le trafic pod-à-pod, qui est autorisé par défaut jusqu'à ce que vous appliquiez un default-deny puis permettiez explicitement les flux requis. Ensemble, ils limitent le rayon d'impact si un pod ou un jeton est compromis.

La CI/CD est de grande valeur car elle détient les identifiants de déploiement et exécute du code non fiable. Les risques incluent les dépendances et actions de build compromises, les secrets divulgués ou trop larges, les actions tierces mutables, et les runners ou la confiance OIDC surprivilégiés. Réduisez-les avec des dépendances épinglées et vérifiées, une fédération OIDC à courte durée de vie au lieu de clés à longue durée de vie, le moindre privilège restreint à des dépôts/branches précis, des runners éphémères isolés, et des artefacts signés à provenance tracée (SLSA).

Kerberos repose sur un centre de distribution de clés (KDC) de confiance. Le client s'authentifie une fois auprès du serveur d'authentification et obtient un ticket d'octroi de tickets (TGT) chiffré avec la clé du KDC. Pour atteindre un service, il présente le TGT au service d'octroi de tickets et reçoit un ticket de service chiffré avec la clé de ce service. Le service le déchiffre et lui fait confiance. Les mots de passe ne traversent jamais le réseau, et les tickets ont une durée limitée.

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.

Les lockfiles épinglent les versions exactes et les empreintes des dépendances pour que chaque build résolve les mêmes octets vérifiés — rendant les builds reproductibles et bloquant les mises à jour malveillantes silencieuses. L'épinglage par empreinte, la vérification des empreintes d'intégrité et le cloisonnement des paquets internes dans un registre privé défendent aussi contre la confusion de dépendances, où un attaquant publie un paquet public de version supérieure correspondant à un nom interne pour détourner la résolution. Le principe : ne jamais laisser le build récupérer silencieusement du code non vérifié.

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.

Ne faites échouer le build que sur les résultats à forte confiance, à forte gravité et nouvellement introduits ; signalez (sans bloquer) tout le reste afin que les développeurs gardent confiance dans la porte. Gérez les faux positifs par des règles ajustées, une mise en référence des problèmes préexistants, et des suppressions documentées, limitées dans le temps et revues, plutôt que de désactiver les scanners. Une porte qui crie au loup finit ignorée ou contournée : la qualité du signal est tout l'enjeu.

Cela confirme le XSS. Si alert() s'est déclenché du tout, c'est que le navigateur a analysé et exécuté votre JavaScript injecté dans le contexte de la page : c'est la vulnérabilité. Une fenêtre vide signifie simplement que l'argument chaîne que vous avez transmis ne s'est pas affiché comme prévu (gestion des guillemets, encodage ou altération du contexte ont cassé le message), pas que la charge est bloquée. Le point d'exécution est actif ; vous affinez la charge à partir de là.

Non. CORS n'est pas une défense contre le CSRF : il assouplit en réalité la politique de même origine pour qu'une page puisse lire des réponses cross-origin qu'elle ne pourrait pas lire autrement. Le CSRF n'a pas besoin de lire la réponse ; il a juste besoin que le navigateur de la victime envoie une requête authentifiée qui modifie l'état. Les vraies défenses sont les jetons anti-CSRF, l'attribut de cookie SameSite, et la vérification d'Origin/Referer.

La gouvernance est la façon dont la direction fixe le cap, définit la responsabilité et aligne la sécurité sur les objectifs métier — les politiques, les rôles et la supervision qui disent à quoi ressemble « le bon niveau ». La gestion des risques est le processus d'identification, d'évaluation, de traitement et de surveillance des menaces pesant sur ces objectifs. La conformité consiste à démontrer le respect des obligations — lois, règlements, contrats et politiques internes. La gouvernance pilote les décisions de risque ; le risque détermine les contrôles nécessaires ; la conformité prouve que ces contrôles répondent aux normes exigées. La conformité est un résultat d'une bonne GRC, pas un substitut à la sécurité.

ISO/IEC 27001 spécifie les exigences d'un Information Security Management System (ISMS) : un cadre descendant et fondé sur le risque, fait de politiques, de processus, de rôles et d'amélioration continue (Plan-Do-Check-Act) qui régit la manière dont une organisation gère la sécurité de l'information. L'Annexe A est un catalogue de contrôles de référence. On ne les applique pas tous aveuglément — on mène une analyse des risques, on décide quels contrôles sont nécessaires, et on documente les décisions d'inclusion/exclusion avec justification dans une Statement of Applicability (SoA).

Un KPI (Key Performance Indicator) mesure la performance d'une activité de sécurité par rapport à son objectif — par exemple le délai moyen de détection, le respect du SLA de correctifs, ou le pourcentage de systèmes avec MFA. Un KRI (Key Risk Indicator) est un signal prospectif indiquant que l'exposition au risque augmente vers un niveau inacceptable, avec un seuil censé déclencher une action — par exemple le nombre de correctifs critiques en retard, le compte d'appareils non gérés, ou les revues d'accès échouées en hausse. Les KPI vous disent comment vous vous en sortez ; les KRI vous avertissent de la direction que vous prenez.

Traitez le risque fournisseur comme un cycle de vie, pas comme un questionnaire ponctuel. Inventoriez vos tiers et classez-les par criticité et sensibilité des données. Menez une due diligence proportionnelle au niveau — examinez les rapports SOC 2 / ISO 27001, les questionnaires de sécurité, les synthèses de pentest, ainsi que les données et accès concernés. Inscrivez les contrôles dans le contrat (exigences de sécurité, droit d'audit, notification de violation, traitement des données, sous-traitants). Surveillez ensuite en continu, pas seulement à l'onboarding, et prévoyez un processus d'offboarding propre pour révoquer les accès et récupérer ou détruire les données. Le risque de quatrième partie (sous-traitant) compte aussi.

Le beaconing C2 est le check-in périodique qu'un implant effectue auprès de son contrôleur. Chassez-le dans la télémétrie réseau/proxy/DNS en cherchant la régularité : connexions vers une destination à intervalles quasi fixes (même avec du jitter), petites requêtes uniformes, faibles ratios données-entrantes / données-sortantes, destinations rares de longue durée, et empreintes TLS/JA3 suspectes ou user-agents étranges. Le signal est le rythme et la rareté de la destination, pas le payload — qui est généralement chiffré.

L'ingénierie de détection traite les détections comme un produit logiciel doté d'un cycle de vie : identifier une menace ou technique à couvrir, étudier la télémétrie et le comportement, développer la règle, la tester face à des données de vrais positifs et bénignes, la déployer (souvent par étapes), la valider par émulation d'adversaire, puis l'ajuster en continu pour les faux positifs et retirer les règles qui ne se justifient plus. Chaque étape est documentée et versionnée, et la couverture est suivie par rapport à un cadre comme ATT&CK.

Les LOLBins (living-off-the-land binaries) sont des outils système légitimes, signés et préinstallés — comme certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — que les attaquants détournent pour télécharger, exécuter ou persister tout en se fondant dans l'activité d'administration normale. Comme le binaire lui-même est de confiance, on ne peut pas détecter sur le fichier ; on détecte sur le contexte : arguments de ligne de commande anormaux, processus parents inhabituels, connexions réseau inattendues depuis ces outils, et exécution depuis des chemins étranges ou par des utilisateurs inhabituels.

La chasse basée sur les TTP utilise MITRE ATT&CK comme carte : choisissez une technique pertinente pour votre modèle de menace (idéalement à faible couverture), formez une hypothèse concrète sur la façon dont elle apparaîtrait dans votre télémétrie, identifiez les sources de données qui la révèlent, interrogez-les et analysez les résultats. Une bonne chasse est délimitée, guidée par des hypothèses, liée à un comportement réel d'adversaire, reproductible, et produit un résultat durable — une nouvelle détection, une lacune de couverture documentée, ou la preuve que la technique est absente — qu'elle trouve ou non une compromission.

L'accès juste-à-temps accorde des privilèges élevés uniquement quand c'est nécessaire, pour une durée limitée, généralement avec approbation — puis ils expirent automatiquement, de sorte qu'il n'y a aucun privilège permanent à voler. Les comptes bris de glace sont l'exception délibérée : des comptes d'urgence très privilégiés, normalement dormants, verrouillés derrière des contrôles stricts et de fortes alertes, utilisés uniquement quand les chemins d'accès normaux échouent. Le JIT réduit la surface d'attaque quotidienne ; le bris de glace garantit que vous pouvez encore entrer en cas de crise.

Gardez les jetons d'accès à courte durée de vie (quelques minutes) pour qu'un jeton volé expire vite, et utilisez des jetons de rafraîchissement à plus longue durée pour obtenir de nouveaux jetons d'accès sans re-solliciter l'utilisateur. Faites tourner les refresh tokens à chaque utilisation et détectez la réutilisation d'un jeton consommé comme un signal de vol, en révoquant la chaîne. L'objectif est d'équilibrer la limitation de la fenêtre d'un jeton compromis sans forcer les utilisateurs à se réauthentifier sans cesse.

Le Zero Trust abandonne l'hypothèse selon laquelle être à l'intérieur du réseau vous rend digne de confiance. Chaque requête vers une ressource est authentifiée et autorisée pour elle-même — en vérifiant l'identité, l'état de santé de l'appareil et le contexte — par un point de décision de politique, accordant un accès au moindre privilège par session. Il n'y a pas de zone interne de confiance ; l'emplacement réseau d'une requête n'est qu'un signal, pas un laissez-passer.

Un désassembleur comme Ghidra ou IDA vous donne la carte statique complète : références croisées, pseudocode décompilé et chaque chemin de code, qu'il s'exécute ou non. Un débogueur comme x64dbg vous permet d'exécuter l'échantillon sous contrôle — poser des points d'arrêt, inspecter registres et mémoire, observer le déchiffrement se produire, et suivre le chemin que le code prend réellement avec de vraies entrées. On lit la structure et l'intention statiquement, puis on attache le débogueur pour résoudre ce que l'analyse statique ne peut pas : chaînes déchiffrées au runtime, API résolues dynamiquement, charges utiles empaquetées, et quelle branche une condition prend. Les deux ensemble comblent leurs lacunes mutuelles.

L'injection de processus exécute du code malveillant à l'intérieur d'un autre processus pour se cacher et hériter de sa confiance. L'injection distante classique alloue de la mémoire dans une cible avec VirtualAllocEx, écrit une charge utile via WriteProcessMemory, et l'exécute avec CreateRemoteThread. Les variantes incluent l'injection de DLL via LoadLibrary, le process hollowing qui démappe un processus légitime suspendu et remplace son image, l'injection APC qui met du code en file d'attente sur un thread, et le chargement réflexif ou mappé manuellement qui évite LoadLibrary entièrement. On les repère par les séquences d'API révélatrices, la mémoire RWX dans un processus normalement propre, les threads sans fichier de sauvegarde sur le disque et les anomalies parent-enfant.

Un malware conscient du sandbox vérifie s'il est observé avant de mal se comporter. Il cherche des artefacts de VM et d'hyperviseur (pilotes, préfixes MAC, clés de registre, CPUID), des outils d'analyse et débogueurs (noms de processus, IsDebuggerPresent, temporisation du pas-à-pas), et des signes d'un vrai utilisateur (peu de processus, aucun document récent, pas de mouvement de souris, faible uptime, petit disque). Il peut temporiser avec de longs sommeils ou ne se déclencher qu'à une date, une langue ou un domaine précis. Les analystes y font face en durcissant la VM pour la rendre réaliste, en neutralisant les vérifications par patch, en accélérant les sommeils, en simulant l'activité utilisateur, et en confirmant le comportement par désassemblage statique.

La décompression récupère le code original que le packer a caché. Pour les packers connus, vous utilisez le décompresseur correspondant ou un émulateur. Pour les packers personnalisés, vous décompressez manuellement : exécutez l'échantillon dans un débogueur, laissez le stub décompresser la charge utile en mémoire, trouvez le moment où il saute vers le point d'entrée original (souvent en posant un point d'arrêt sur de la mémoire qui devient exécutable, ou sur le saut de queue), puis dumpez l'image du processus depuis la mémoire et reconstruisez la table d'adresses d'imports avec un outil comme Scylla ou PE-sieve. Le résultat est un PE exécutable ou analysable contenant la véritable charge utile.

Un pentest vise une large couverture — trouver autant de vulnérabilités que possible dans une cible délimitée. Une red team est une émulation d'adversaire pilotée par objectif : choisir un but (par ex. atteindre les données les plus précieuses), émuler les TTP d'un acteur de menace précis, rester furtif pour tester la détection et la réponse, et éviter le scan bruyant. La red team mesure l'équipe bleue et toute l'organisation, pas seulement l'actif ; les deux exigent des règles d'engagement strictes et une autorisation.

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.

Commencez par comprendre le modèle de menace de l'application et où elle manipule des entrées non fiables, des secrets, de l'authentification et de l'autorisation. Utilisez le SAST pour scanner largement et le DAST contre l'application en cours d'exécution, mais traitez la sortie des outils comme des pistes, pas des constats — triez les faux positifs. Consacrez ensuite le temps humain aux zones à forte valeur et dépendantes du contexte que les outils manquent : logique d'autorisation, logique métier, usage de la cryptographie et frontières de confiance. Tracez le flux de données de la source au sink.

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.

Utilisez l'hôte compromis comme relais vers le sous-réseau inaccessible. Mettez en place une redirection de port pour un service unique, ou un proxy SOCKS dynamique (SSH -D ou chisel) et routez vos outils à travers lui avec proxychains, pour que votre machine d'attaque atteigne les hôtes internes via le pivot.

Énumérez les privilèges actuels (whoami /priv), les services mal configurés (permissions faibles, chemins de service non quotés), AlwaysInstallElevated, les tâches planifiées, les identifiants stockés et les correctifs manquants. WinPEAS ou PowerUp automatisent le balayage ; les abus de privilèges de jetons comme SeImpersonate sont des gains fréquents à forte valeur.

Tout utilisateur du domaine authentifié peut demander un ticket de service Kerberos (TGS) pour n'importe quel compte ayant un SPN. Ce ticket est chiffré avec le hachage de mot de passe NTLM du compte de service ; vous l'extrayez et cassez le mot de passe hors ligne — aucun accès privilégié requis au départ, et c'est quasi silencieux.

Le pivoting transforme un hôte compromis en relais pour atteindre des segments internes vers lesquels votre machine ne peut pas router. Vous utilisez le port forwarding, un proxy SOCKS sur votre canal C2 (par ex. Chisel, le forwarding dynamique SSH) ou un routage par agent, puis vous lancez des outils à travers ce tunnel pour attaquer le sous-réseau suivant.

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.

Réduire la surface d'attaque (supprimer paquets et services inutilisés), imposer SSH par clé uniquement sans connexion root, maintenir le système à jour, exécuter un pare-feu en deny-par-défaut n'exposant que les ports nécessaires, appliquer le moindre privilège via sudo et les permissions de fichiers, activer auditd et la journalisation centralisée, et ajouter la surveillance d'intégrité ainsi qu'un MAC comme SELinux ou AppArmor.

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.

Presque tout passe par le DNS, donc les logs DNS révèlent des menaces que d'autres sources manquent : le beaconing de command-and-control (rappels réguliers vers un domaine), le tunneling et l'exfiltration DNS (gros volume de sous-domaines longs et encodés), et les domaines générés algorithmiquement (DGA). On les détecte via des motifs comme la régularité des requêtes, l'entropie, les types d'enregistrement et le volume, plutôt que par une seule résolution suspecte.

Le mouvement latéral, c'est un attaquant qui utilise un point d'appui pour atteindre d'autres systèmes. Les signes incluent des logons réseau inattendus (type 3) et RDP (type 10), l'accès aux partages admin comme C$ et ADMIN$, des outils d'exécution distante tels que PsExec, WMI et WinRM, des motifs de pass-the-hash, et un compte normalement local qui s'authentifie soudain sur de nombreux hôtes.

La Content-Security-Policy est un en-tête de réponse HTTP qui indique au navigateur quelles sources de scripts, styles, images et autres contenus sont autorisées à se charger et s'exécuter sur une page. En interdisant le script en ligne et les origines non fiables — idéalement via des nonces ou des hachages — elle sert de rempart de défense en profondeur qui neutralise les charges utiles XSS injectées, même lorsqu'une passe au travers.

Le SSRF pousse un serveur à effectuer des requêtes HTTP (ou autres) vers une destination choisie par l'attaquant, en abusant de la position réseau du serveur pour atteindre des services internes derrière le pare-feu. Dans le cloud, c'est particulièrement grave car le service de métadonnées d'instance (par exemple 169.254.169.254) peut renvoyer des identifiants IAM, transformant un SSRF en compromission du compte cloud.

Le XXE abuse d'un analyseur XML qui résout les entités externes définies dans la DTD d'un document. Un attaquant déclare une entité pointant vers un fichier local ou une URL interne, et l'analyseur la récupère — permettant la divulgation de fichiers, le SSRF et le déni de service. Le correctif est de désactiver le traitement des DTD et la résolution des entités externes dans la configuration de l'analyseur.