Questions d'entretien en cybersécurité niveau Mid-level

En pratique, non. AES-128 exige déjà environ 2^128 d'effort pour être cassé par force brute — totalement infaisable — donc AES-256 ne vous rend pas réellement plus sûr face à la force brute ; il ajoute surtout de la marge (réserve post-quantique, conformité). Les deux sont standardisés et non cassés. Votre mode (GCM), la gestion des nonces et celle des clés comptent bien plus que 128 contre 256. « AES-256 est deux fois plus sûr » est l'idée fausse.

Non. L'antivirus est un signal, pas une preuve. Il manque les attaques sans fichier et en mémoire, les échantillons inédits ou obfusqués, l'abus d'outils légitimes (living-off-the-land) et les rootkits conçus pour s'y cacher. L'absence de preuve n'est pas une preuve d'absence — la vraie assurance vient de la télémétrie EDR, de l'analyse forensique de la mémoire, de l'analyse comportementale et de la chasse aux IOC. Considérer un scan antivirus propre comme la preuve d'un système propre est une erreur classique de réponse à incident.

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.

Non. Supprimer le cookie retire seulement l'identifiant de votre navigateur — l'enregistrement de session (ou un JWT encore valide) sur le serveur reste généralement utilisable jusqu'à son expiration ou son invalidation explicite. Un attaquant ayant déjà capturé le jeton peut continuer à l'utiliser. L'erreur prend le cookie pour la session elle-même ; ce n'est qu'un pointeur vers l'état côté serveur. La vraie déconnexion doit invalider la session côté serveur, ou révoquer et limiter la durée du jeton.

En grande partie non. Le nom d'hôte de destination est envoyé en clair dans l'extension SNI du ClientHello de TLS, et votre requête DNS le révèle généralement aussi, de sorte qu'un FAI ou un réseau peut voir QUEL site vous visitez même en HTTPS — il ne peut simplement pas lire le chemin ni le contenu. Le ClientHello chiffré (ECH) et le DNS-over-HTTPS peuvent combler cette faille, mais ils ne sont pas universels. « HTTPS cache tout » est l'idée fausse.

Non. La MFA élève fortement la barre, mais les facteurs OTP et push sont hameçonnables : les kits d'adversaire au milieu (ex. Evilginx) relaient la connexion et le code en temps réel, et la fatigue MFA / le push-bombing poussent l'utilisateur à approuver. Les codes capturés sont réutilisables dans leur courte fenêtre. L'erreur est « MFA = inhameçonnable » ; c'est le type de facteur qui compte. La MFA résistante au phishing — les passkeys FIDO2/WebAuthn liés à l'origine du site — est ce qui déjoue réellement cela.

Non. Le NAT (et le PAT) associe des adresses privées à une IP publique et, par effet de bord, rejette les connexions entrantes non sollicitées car aucune correspondance n'existe pour elles. Ce n'est pas une politique de sécurité — pas d'inspection, pas de règles, pas de journalisation — et la traversée de NAT, le hole punching et le C2 initié en sortie passent sans problème. Le NAT est un outil d'adressage ; il vous faut un vrai pare-feu. « NAT = pare-feu » est l'idée fausse.

Pas à lui seul. De nombreux systèmes maintiennent valides les sessions existantes et les jetons déjà émis après un changement de mot de passe — jetons OAuth de rafraîchissement, « mots de passe d'application », clés d'API et cookies persistants — si bien qu'un attaquant disposant d'une session active peut rester. La bonne réponse est de changer le mot de passe ET d'invalider toutes les sessions et jetons, révoquer les identifiants d'application, et auditer les appareils MFA et les paramètres de récupération. Croire qu'une réinitialisation seule éjecte l'attaquant est une erreur classique de réponse à incident.

Non. La plupart des vraies intrusions établissent une persistance (services, tâches planifiées, clés de démarrage, implants) qui survit à un redémarrage, donc l'attaquant revient simplement. Pire, éteindre efface les preuves volatiles — processus en cours, connexions réseau, malware en mémoire et clés de chiffrement — dont vous avez besoin pour cadrer l'incident. La bonne action est de confiner en isolant l'hôte tout en préservant la mémoire, puis d'enquêter. Redémarrer ou éteindre comme « solution » est un réflexe néfaste.

Non. Un sel est une valeur aléatoire unique stockée juste à côté du hash ; son rôle est de faire en sorte que des mots de passe identiques produisent des hashes différents et de neutraliser les rainbow tables précalculées — pas de rester secret. Il est normal qu'un attaquant qui vole la base récupère aussi les sels. Ce qui protège réellement les mots de passe, c'est un hash lent et salé (bcrypt, scrypt, Argon2). Un « poivre » secret optionnel et séparé est un concept différent.

Un modèle tiers est une dépendance de chaîne d'approvisionnement : vérifiez qu'il provient d'une source de confiance avec des sommes de contrôle/signatures correspondantes, que sa licence autorise votre usage, et que le format de fichier n'exécute pas de code arbitraire au chargement (préférez une sérialisation sûre aux formats de type pickle). « Il se charge » et « la vitesse de téléchargement » ne disent rien de la confiance, et supposer que les modèles publics sont sûrs ignore les risques réels d'empoisonnement et de désérialisation.

Envoyer des données personnelles de clients à une API externe les expose au traitement et à la conservation d'un tiers et peut enfreindre des obligations de confidentialité. Minimisez et anonymisez ce qui est envoyé, confirmez les conditions d'usage/conservation du fournisseur et un accord de traitement des données (ou des garanties de non-entraînement), ou passez à un déploiement privé pour les données sensibles. La longueur de la clé n'a aucune importance, et envoyer plus de données personnelles augmente l'exposition.

Le stockage de mots de passe exige un hachage délibérément lent, salé et à coût mémoire élevé — bcrypt, scrypt ou Argon2 — pour que casser des hachages volés soit coûteux et que les rainbow tables ne s'appliquent pas. Un hachage rapide comme SHA-256 se brute-force trivialement à grande échelle ; le chiffrement réversible signifie qu'une seule compromission de clé expose tous les mots de passe d'un coup ; et le texte clair est indéfendable, quelle que soit la fermeture de la base. Choisissez Argon2id (ou bcrypt) avec un facteur de coût ajusté et un sel unique par utilisateur.

SSLv3, TLS 1.0 et RC4 sont cassés ou obsolètes et permettent des attaques par rétrogradation et déchiffrement ; désactivez-les donc et exigez TLS 1.2 ou 1.3 avec des suites de chiffrement robustes et à confidentialité persistante, en acceptant la rare perte de très vieux clients. Les laisser actifs par compatibilité maintient la faiblesse exploitable. Ajouter un second certificat ou passer à un certificat auto-signé ne supprime pas les protocoles faibles, et l'auto-signé nuit à la confiance sans corriger la cryptographie.

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.

Les auditeurs vérifient des preuves, pas des intentions : présentez la politique de revue d'accès, des relevés datés de chaque revue avec la validation d'un approbateur, et la confirmation que les accès signalés ont bien été révoqués et vérifiés. Une confirmation verbale ne prouve rien de reproductible, une promesse de commencer le trimestre prochain montre que le contrôle ne fonctionnait pas pendant la période auditée, et un organigramme décrit des liens hiérarchiques, pas des décisions d'accès. Seuls les artefacts datés et attribuables démontrent que le contrôle a fonctionné comme prévu sur toute la période.

Les sauvegardes sont nécessaires mais non suffisantes : la reprise d'activité et la continuité d'activité sont la capacité testée à restaurer l'activité dans les objectifs convenus de temps et de point de reprise (RTO/RPO), ce qui exige un plan documenté, des dépendances cartographiées, des runbooks et des restaurations validées — pas seulement l'existence de fichiers de sauvegarde. Affirmer qu'elles sont identiques confond une copie de données avec une capacité opérationnelle. Le PRA ne se résume pas à souscrire une assurance, qui transfère la perte financière mais ne restaure pas les systèmes. Et les sauvegardes ne rendent pas un PRA inutile — des sauvegardes non testées échouent régulièrement le moment venu. La clarification : le PRA doit être exercé, pas présumé.

Un traitement incohérent traduit généralement l'absence de définition partagée de la sensibilité ; le contrôle fondamental est donc un schéma de classification des données (par ex. public/interne/confidentiel/restreint) avec des exigences définies de traitement, de stockage et de partage par niveau, permettant aux équipes d'appliquer des contrôles proportionnés. Ne rien chiffrer « pour faire simple » ou traiter toutes les données comme publiques retire la protection aux données qui en ont besoin. Supprimer toutes les données de plus d'un jour détruit des enregistrements dont l'entreprise et la loi ont besoin. Seul un schéma de classification aligne la force des contrôles sur la sensibilité réelle des données.

Le risque au départ, c'est l'accès résiduel ; le contrôle à vérifier est donc le déprovisionnement rapide de chaque voie d'accès — comptes d'annuaire, SSO, VPN, identifiants privilégiés et de service, et SaaS tiers — rapproché du processus arrivée/mobilité/départ (JML). Supposer que les RH gèrent tout sans vérification laisse des failles que personne ne possède. Garder le compte actif « au cas où il reviendrait » est un risque permanent et non surveillé. Désactiver seulement l'e-mail ignore les nombreux autres systèmes que la personne pourrait encore atteindre. L'enjeu est de vérifier que l'accès est réellement et totalement retiré, pas de présumer qu'il l'a été.

La gouvernance, c'est capturer et gérer le risque, pas le traiter de façon informelle : inscrivez-le au registre des risques avec une probabilité et un impact évalués, désignez un propriétaire responsable, décidez et documentez le traitement (atténuer, transférer, accepter ou éviter), et fixez une date de revue. Le corriger vous-même sur-le-champ contourne la responsabilité, la priorisation et le suivi, et ce n'est peut-être même pas à vous de le faire. L'ignorer jusqu'à ce qu'il devienne un incident est une négligence, et l'envoyer par e-mail à tout le monde crée du bruit mais aucune responsabilité ni suivi. Le registre transforme une observation ponctuelle en une décision suivie, attribuée et réexaminée.

Les comptes de service inutilisés et sur-privilégiés sont des cibles de choix et une large surface d'attaque. Inventoriez-les, désactivez ou supprimez les inutilisés (en surveillant les casses), réduisez les survivants au moindre privilège et donnez à chacun un propriétaire et une revue récurrente. Les laisser est un risque permanent, leur accorder un accès admin global maximise le rayon d'impact, et tout consolider sur un compte partagé unique détruit le moindre privilège et la responsabilité.

La persistance Linux se cache dans les chemins d'exécution planifiée et de démarrage : cron et timers/unités systemd, clés ajoutées dans authorized_keys SSH, fichiers rc du shell et scripts de profil modifiés, et binaires de service ou bibliothèques préchargées trojanisés. Examinez-les systématiquement. L'historique du navigateur et les réglages du fond d'écran ne sont pas des mécanismes de persistance, et redémarrer ne supprimera rien qui se rétablit au démarrage — cela ne fait que le relancer. Tout l'intérêt de la persistance est de survivre aux redémarrages, donc un redémarrage ne prouve rien.

Un binaire SUID-root s'exécute avec les privilèges de root, et s'il est accessible en écriture par tous, un attaquant peut le remplacer ou le modifier pour exécuter du code arbitraire en tant que root — une voie classique d'élévation de privilèges locale. Retirez le bit SUID, corrigez le propriétaire et les permissions, et enquêtez sur l'origine de cette mauvaise configuration, car elle peut indiquer une compromission. Chiffrer le fichier laisse intact le chemin exécutable, et le renommer ne fait que déplacer le problème sans supprimer l'élévation. Aucune de ces options ne traite la cause racine.

Le SOC doit agir, alors livrez un contenu de détection structuré et exploitable : IOC réseau, hachages, artefacts hôte comme le mutex, et signatures comportementales ou YARA qu'il peut déployer pour traquer et bloquer. Un récit exhaustif des appels d'API n'est pas directement opérationnel. Un seul hachage est trivialement modifié par les attaquants. Une attribution spéculative n'aide pas le SOC à se défendre. Le but : des détections que le SOC peut déployer aujourd'hui.

Ne détonez que dans une VM jetable et isolée, avec des snapshots et un réseau contrôlé (par ex. services simulés ou egress étroitement surveillé), afin que le malware ne puisse atteindre ni la production ni Internet sans contrôle. L'antivirus de votre portable ne contiendra pas un malware actif de façon fiable. Un serveur de production met en danger de vrais systèmes. La machine d'un collègue ne fait que déplacer le danger. L'isolation et les snapshots réversibles sont le cœur d'un labo de malware sûr.

L'identification de la famille guide les décisions : à partir de la note, de l'extension et des IOC, vous pouvez signaler l'existence d'un décrypteur gratuit, les TTP typiques du groupe (y compris le vol de données pour extorsion) et le rayon d'impact probable, au profit de l'équipe IR. Reformater détruit les preuves et l'information de portée. La grammaire de la note n'est pas exploitable. Recommander de négocier est une décision métier et juridique, pas le premier geste de l'analyste. Identifiez d'abord, puis aidez l'IR.

Commencez par un triage statique dans un environnement isolé : calculez les empreintes, extrayez les chaînes, inspectez les en-têtes PE et les imports, et vérifiez la réputation, afin de comprendre l'échantillon avant de risquer l'exécution. L'exécuter sur votre propre poste peut vous infecter, vous et le réseau. Téléverser des échantillons clients avec des noms identifiants divulgue des données sensibles à des tiers. Le supprimer détruit la preuve et la possibilité de bâtir des détections.

Comme les pare-feu évaluent les règles de haut en bas, une large règle any/any près du haut court-circuite toutes les règles en dessous et autorise tout le trafic — le pare-feu cesse en pratique d'imposer quoi que ce soit. Remplacez-la par des règles explicites de moindre privilège pour les flux réellement nécessaires, ordonnées pour que les autorisations et refus spécifiques prennent effet, et terminez par un refus par défaut. La qualifier d'efficace est faux, la déplacer en bas peut encore masquer le refus par défaut, et la renommer ne change rien à ce qu'elle autorise.

Si le navigateur joint automatiquement le cookie de session, une page malveillante peut déclencher le virement au nom de la victime — c'est le Cross-Site Request Forgery (CSRF). Protégez les requêtes qui modifient un état avec des jetons anti-CSRF et des cookies SameSite, et vérifiez l'en-tête Origin/Referer. Le cookie prouve l'identité mais pas l'intention, un CAPTCHA de connexion ne protège pas une action déjà authentifiée, et HTTPS protège la confidentialité du transport, pas la falsification de requête.

Si un attaquant peut téléverser un fichier exécutable côté serveur (ou du HTML/SVG) dans un répertoire servi, il peut obtenir une exécution de code à distance ou un XSS stocké. Validez le vrai type de contenu, stockez les fichiers hors de la racine web ou sur un stockage non exécutant, randomisez les noms de fichiers et servez-les de manière à empêcher leur exécution ou leur interprétation comme balisage. Les chargements de page plus lents et la consommation disque sont des problèmes opérationnels, pas le risque de sécurité exploité ici.

LSASS stocke des identifiants et secrets en cache, donc un processus inattendu lisant sa mémoire est la signature d'un vol d'identifiants (par exemple un dump de type mimikatz). Triez le processus fautif et son parent, isolez l'hôte pour stopper le mouvement latéral, et renouvelez les identifiants susceptibles d'avoir été capturés — y compris les comptes privilégiés et de service. Cela n'a rien à voir avec le rendu graphique ou l'espace disque, et l'ignorer comme normal peut mener à une compromission de tout le domaine. Les distracteurs d'apparence anodine sont précisément la façon dont les analystes ratent une intrusion active.

Un logiciel légitime exécute rarement PowerShell depuis %TEMP% via une tâche planifiée fraîchement créée — c'est une technique courante de persistance et d'exécution. Examinez la définition de la tâche, le script invoqué, le processus créateur et la chronologie, confinez l'hôte, et balayez l'environnement à la recherche du même motif. Les mises à jour ne ressemblent pas à cela, faire confiance aveuglément aux tâches planifiées ignore une TTP connue, et supprimer System32 casse le système d'exploitation sans rien faire contre la menace. Les trois premières options reflètent toutes un jugement dangereusement faible.

Il s'agit d'un contrôle d'accès défaillant (IDOR) : le serveur ne vérifie pas que l'utilisateur authentifié a le droit d'accéder à l'objet demandé. La correction est une autorisation par objet appliquée côté serveur à chaque requête. Nettoyer le nombre n'établit pas la propriété. Chiffrer ou masquer l'ID relève de l'obscurité et reste devinable, divulgable ou rejouable. La méthode HTTP n'a aucun rapport avec l'autorisation. Vérifiez toujours le droit de l'appelant sur l'objet précis avant de le renvoyer.

C'est une faille d'affectation en masse (over-posting) : le serveur mappe aveuglément le JSON client sur des champs sensibles du modèle. Corrigez-la en ne liant qu'une liste blanche explicite des champs autorisés (DTO / strong params) afin que des attributs privilégiés comme isAdmin ne puissent pas être définis par le client. Masquer le champ dans le frontend et ajouter une validation côté client se contournent tous deux avec une requête brute. Renommer isAdmin relève de l'obscurité, facilement découverte. Contrôlez quels champs sont liés, côté serveur.

Les requêtes paramétrées sont la vraie correction : elles séparent le code des données, de sorte que la saisie utilisateur est toujours traitée comme une valeur, jamais comme du SQL pouvant modifier la structure de la requête. L'échappement manuel est source d'erreurs et contournable selon les encodages et les dialectes. Un WAF est un contrôle compensatoire, pas un correctif, et les astuces d'encodage le déjouent. Une vérification de longueur n'empêche en rien l'injection. Corrigez au niveau de la requête.

Le XSS stocké se corrige en encodant les données pour le contexte exact où elles sont rendues (corps HTML, attribut, JavaScript, URL) afin que le navigateur les traite comme du texte, avec une Content-Security-Policy en seconde couche. Mettre le mot « script » en liste noire se contourne trivialement via des gestionnaires d'événements, la casse mixte et les encodages. Vous ne pouvez pas forcer vos utilisateurs à désactiver JavaScript. Demander aux utilisateurs de ne pas saisir de HTML n'est pas un contrôle applicable. Encodez à la sortie, à chaque rendu.

Le code transitif s'exécute dans votre application, donc une CVE critique est votre risque. Évaluez si le chemin de code vulnérable est réellement atteignable, puis remédiez en montant ou en surchargeant la version (ou en atténuant) et vérifiez en production. L'ignorer parce qu'elle est transitive laisse un trou connu qu'un attaquant peut exploiter. Supprimer l'avertissement ne fait que masquer le signal. Réinstaller node_modules ramène la même version vulnérable. Suivez-la via le SCA, ne la faites pas taire.

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.

Un taux de clic de 30 % est un point de référence à améliorer, pas une liste de personnes à punir : associer une formation ciblée par rôle et un bouton de signalement sans friction à des défenses techniques (MFA, filtrage de courrier, moindre privilège) pour qu'un seul clic ne mène pas à une compromission, et suivre la tendance dans le temps. Humilier publiquement les employés étouffe le signalement dont vous dépendez. Déclarer le personnel irrécupérable supprime un contrôle à renforcer. Un nouveau courriel anxiogène à tous n'est pas une intervention mesurable et ne change pas le comportement.

Les simulations répètent le côté humain et décisionnel de la RI — qui a l'autorité de déclarer un incident, comment circule la communication juridique/RP/direction, et où le manuel se brise — afin que la première fois où vous prenez ces décisions ne soit pas en pleine crise réelle. Il est bien moins coûteux de trouver les failles lors d'un exercice qu'en pleine violation. Ce n'est pas une case de conformité vide, ce n'est pas pour attribuer des blâmes sur des incidents passés, et c'est transverse, pas réservé au SOC — la direction doit s'entraîner aux décisions qu'elle seule peut prendre.

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.

Les ports d'administration ouverts à tout Internet sont scannés et attaqués par force brute en quelques minutes ; la solution consiste à réduire la surface d'attaque : restreindre l'ingress du security group à des CIDR d'administration connus ou au VPN, ou supprimer entièrement l'entrant à l'aide d'un bastion ou de SSM Session Manager. Déplacer SSH sur un port non standard est une sécurité par l'obscurité que les scanners contournent trivialement. Un mot de passe plus fort ne réduit pas la surface exposée et n'arrête pas le credential stuffing. Se fier à un pare-feu hôte ignore la surface d'attaque que le security group annonce ouvertement à Internet.

Des données clients publiques constituent une exposition active : remédiez d'abord à l'accès en activant Block Public Access et en corrigeant la politique du bucket et la politique IAM pour stopper la fuite en cours. Récupérez ensuite les journaux d'accès (S3 server access logs / événements de données CloudTrail) pour évaluer ce qui a réellement été atteint, puis déclenchez les processus de violation et de notification prévus par la politique. Créer un ticket pour le prochain sprint laisse des données réglementées exposées pendant des jours. Copier les données ailleurs crée une seconde copie mais laisse le bucket d'origine ouvert. Renommer ne change rien à ses permissions.

Les secrets doivent vivre dans un magasin géré avec contrôle d'accès, audit et rotation, injectés au runtime — jamais versionnés. Utilisez un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault) et retirez les valeurs versionnées de l'historique, puis faites-les tourner car elles doivent être considérées comme compromises. Le base64 est de l'encodage, pas une protection — n'importe qui peut le décoder. Un dépôt privé répand quand même le secret à tous ceux qui ont l'accès en clone, plus les systèmes CI et les forks. Le compiler dans le binaire ne fait que cacher un secret toujours trivial à extraire.

Une clé statique intégrée à une image fuit facilement et vit éternellement ; la solution consiste à éliminer entièrement l'identifiant à longue durée de vie : attachez un rôle IAM via un profil d'instance, qui fournit des identifiants temporaires automatiquement renouvelés sans rien d'intégré. Une rotation manuelle tous les 90 jours laisse quand même un secret à longue durée de vie dans l'AMI entre les rotations. Déplacer la clé vers une variable d'environnement ne la rend ni moins statique ni moins exposée. L'envoyer par e-mail à l'équipe ops répand l'exposition dans les boîtes mail et les archives.

Le changement manuel dans la console est une dérive de configuration : le prochain terraform apply peut annuler silencieusement le correctif, et le changement a aussi contourné la revue et l'audit. Réconciliez-le en codifiant le changement dans Terraform, en lançant plan/apply pour que le code et la réalité concordent, et en ajoutant des garde-fous contre les modifications ad hoc dans la console (accès console au moindre privilège, SCP, détection de dérive). Ne rien faire laisse une mine pour le prochain apply. Supprimer l'état Terraform est destructeur et peut orpheliner ou dupliquer des ressources. Abandonner Terraform sacrifie reproductibilité, revue et pistes d'audit.

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.

Les règles d'engagement excluent généralement le déni de service en production, et un plantage non planifié cause un dommage réel à l'activité et peut annuler la mission. Vérifiez d'abord le périmètre ; si une preuve de concept destructrice n'est pas autorisée, prouvez la vulnérabilité par des moyens plus sûrs et documentez clairement l'impact probable. Lancer l'exploit pour une capture d'écran est imprudent. Le lancer à répétition pour des « métriques de fiabilité » multiplie la panne. Le passer sous silence cache au client un risque sérieux et exploitable.

Les missions professionnelles se terminent par un nettoyage complet et un inventaire des artefacts, pour ne pas laisser de nouvelle surface d'attaque ni brouiller l'environnement du client. Laisser des shells ou des comptes au client à trouver est négligent et dangereux — un vrai attaquant pourrait les réutiliser. Conserver une porte dérobée « pour la prochaine fois » est contraire à l'éthique et probablement illégal. Supprimer vos propres journaux d'activité détruit la piste d'audit dont le client a besoin pour valider le test et reconstituer ce que vous avez fait.

Les tests d'ingénierie sociale doivent rester dans des prétextes convenus et éthiques : assez réalistes pour être utiles, mais sans coercition, sans usurper une autorité ni exploiter des situations personnelles ou médicales. Une réinitialisation générique de mot de passe IT convenue dans les règles d'engagement est acceptable. Se faire passer pour l'enfant malade d'un vrai employé ou menacer quelqu'un de licenciement cause un véritable préjudice psychologique. Se faire passer pour les forces de l'ordre usurpe une autorité et est souvent illégal, même avec une mission signée.

Prouvez la vulnérabilité sans nuire au client ni accumuler ses données : montrez que vous pouvez lire des données arbitraires via la version de la base, le schéma ou un seul échantillon anonymisé, puis arrêtez-vous. Extraire l'intégralité des données personnelles crée une responsabilité de notification de violation et de traitement pour les deux parties. Supprimer une table est destructeur et dépasse de loin la preuve de concept. Chiffrer la base et exiger une prime, c'est de l'extorsion, pas un test : c'est un délit, pas un constat.

L'autorisation définit la mission : tester hors du périmètre convenu est potentiellement illégal et viole les règles d'engagement, aussi tentante que soit la cible. Documentez ce que vous avez vu, arrêtez-vous et obtenez l'accord écrit du client avant d'aller plus loin. Exploiter pour « plus de constats » ne justifie jamais un accès non autorisé. L'exploiter discrètement en pensant ne pas être pris est à la fois contraire à l'éthique et un délit, et étendre le périmètre vous-même prive le client de son consentement éclairé.

Un rapport utile pousse à la remédiation : classez par risque métier (probabilité × impact), mettez en avant les chaînes d'exploitation qui mènent à une compromission critique et donnez des correctifs actionnables pour chaque constat. Le classement alphabétique enterre l'essentiel sous ce qui commence par « A ». Le plus long écrit d'abord récompense le verbiage plutôt que la gravité. Supprimer les constats faibles cache un risque réel et les motifs dont le client a besoin pour la défense en profondeur, le laissant avec une image faussement rassurante.

Les dirigeants sont précisément les comptes que veulent les attaquants (BEC, fraude au virement), donc les exempter inverse le modèle de risque. Résolvez la friction, pas le contrôle : déployez des passkeys/FIDO2 résistants au phishing, plus rapides que les codes. Céder à la dérogation détruit la crédibilité du programme et laisse vos comptes de plus grande valeur sans protection. Abandonner le projet MFA, c'est renoncer à un contrôle de premier ordre. L'activer en douce dans leur dos détruit la confiance et la responsabilité.

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.

Considérez tout secret poussé comme grillé : révoquez-le et faites-le tourner d'abord, car les bots scrutent les commits publics en quelques secondes, puis examinez CloudTrail pour détecter un abus et purgez-le de l'historique. Supprimer le commit ne sert à rien — la clé est déjà clonée, forkée et mise en cache par des tiers. Rendre le dépôt privé laisse une clé déjà divulguée et active aux mains des attaquants. Ajouter le fichier au .gitignore ne change rien à un secret déjà commité.

Les données sensibles ne devraient jamais atteindre les journaux : masquez ou caviardez à la source d'abord pour arrêter l'hémorragie, puis remédiez aux journaux existants et resserrez les accès. PCI DSS interdit de stocker ainsi des PAN complets et des CVV, et les mots de passe ne devraient jamais être journalisés. Des journaux « internes » restent une cible de choix. Chiffrer ou restreindre l'accès au stockage laisse quand même des secrets en clair dans les journaux, accessibles à quiconque a un droit de lecture — sauvegardes, pipelines SIEM et administrateurs les voient tous.

Les renouvellements manuels échouent, alors éliminez le problème par l'ingénierie avec un renouvellement ACME automatisé et une surveillance d'expiration qui alerte plusieurs jours à l'avance. Un rappel d'agenda, c'est le processus manuel qui a déjà échoué. Un certificat auto-signé à longue durée brise la confiance publique et viole les limites de durée modernes (les AC plafonnent la validité à ~398 jours, et cela baisse encore). Désactiver TLS échange une coupure de disponibilité contre une perte catastrophique de confidentialité et d'intégrité.

Réduisez les faux positifs par l'ingénierie de détection, pas en vous aveuglant. Réajustez pour que les alertes ne se déclenchent que sur les motifs qui comptent — un même mot de passe testé sur de nombreux comptes (spraying), un compte attaqué de nombreuses fois (stuffing/force brute), voyage impossible — tout en gardant les événements bruts consultables sur un tableau de bord. Mesurez ensuite la précision des alertes dans le temps. Désactiver la règle supprime un signal réel, une suppression globale crée un angle mort permanent, et embaucher des gens pour trier du bruit pur ne passe pas à l'échelle et les épuise.

Des requêtes TXT à fort volume et forte entropie, ou de longs sous-domaines vers un seul domaine, sont une signature classique de tunneling DNS / C2-exfiltration : des données sont passées en douce dans le DNS pour échapper au filtrage de sortie. Capturez un échantillon de requêtes pour analyse, sinkholez ou bloquez le domaine pour couper le canal, et pivotez vers l'hôte pour trouver le processus responsable. L'écarter comme du cache normal ou un site lent laisse passer une exfiltration en cours. Redémarrer le serveur DNS ne fait rien contre le poste compromis et perturbe juste la résolution de noms.

Supposez le mot de passe déjà compromis : forcez une réinitialisation ET invalidez les sessions et jetons actifs du compte, car un simple reset n'évince pas un attaquant qui détient déjà une session active ou un jeton de rafraîchissement. Chassez ensuite les connexions anormales, les invites MFA, les règles de boîte mail et les autorisations OAuth créées pendant la fenêtre d'exposition. Supprimer l'e-mail ou dire à l'utilisateur de changer son mot de passe « la prochaine fois » laisse le compte grand ouvert. Un scan antivirus traite le malware sur le poste, pas les identifiants volés dans le cloud.

Triez par impact et accessibilité : un dumping d'identifiants (signature mimikatz) sur un contrôleur de domaine est un événement touchant les joyaux de la couronne, pouvant mener à la compromission complète du domaine ; traitez-le en premier. Le scan de ports externe a déjà été bloqué par l'IDS, l'extension de navigateur non approuvée est de faible gravité, et un certificat TLS expiré sur une machine de test interne est informatif. La compétence SOC clé est de prioriser par rayon d'impact et probabilité d'escalade, pas par l'ancienneté ni le « bruit » de l'alerte.

L'IA aide le SOC en triant et dédupliquant les alertes, en résumant les incidents, en enrichissant le contexte, en rédigeant des détections et en accélérant l'intégration des analystes — réduisant la fatigue et le temps de présence. Les risques : conclusions hallucinées ou fausses avec assurance, biais d'automatisation où les analystes cessent de vérifier, prompt injection via des données de logs ou d'alertes contrôlées par l'attaquant, fuite de données sensibles vers des modèles tiers, et adversaires utilisant les mêmes outils. Gardez un humain dans la boucle, vérifiez les sorties et isolez les entrées non fiables.

La prompt injection directe, c'est quand un utilisateur tape des instructions adverses directement dans le prompt pour écraser le system prompt ou les règles de sécurité. La prompt injection indirecte cache des instructions malveillantes dans du contenu externe que le modèle ingère ensuite — une page web, un e-mail, un PDF ou un document RAG — si bien que l'attaque se déclenche sans que la victime ne la tape jamais. L'injection indirecte est le plus grand risque parce que l'attaquant et la victime sont des personnes différentes, et que la charge arrive via des données que l'application fait implicitement confiance.

Le traitement non sécurisé des sorties consiste à faire confiance à ce que le modèle renvoie et à le transmettre à un système en aval sans validation ni encodage. Comme la sortie du modèle est influençable par l'attaquant, l'afficher en HTML brut cause du XSS, l'envoyer à un récupérateur d'URL cause du SSRF, et la passer à un shell ou une requête SQL cause une command ou SQL injection. La solution est de traiter la sortie du modèle exactement comme une entrée utilisateur non fiable : encodage de sortie sensible au contexte, allowlisting, assainissement et paramétrage avant qu'elle n'atteigne un sink.

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.

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.

Le credential stuffing rejoue des paires identifiant:mot de passe connues issues de fuites tierces, en pariant sur la réutilisation des mots de passe — taux de réussite élevé par tentative, souvent réparti sur de nombreuses IP et machines pour paraître humain. Le password spraying essaie un ou deux mots de passe courants (comme Winter2026!) sur de nombreux comptes afin de rester sous les seuils de verrouillage. Le stuffing exploite la réutilisation ; le spraying exploite les mots de passe partagés faibles. La MFA déjoue les deux.

La Cyber Kill Chain modélise une intrusion en sept étapes séquentielles : reconnaissance, militarisation, livraison, exploitation, installation, commande et contrôle (C2), et actions sur les objectifs. Les défenseurs associent des détections et des contrôles à chaque étape ; comme les étapes sont séquentielles, briser un seul maillon — bloquer l'e-mail de phishing, tuer le C2 — perturbe toute l'attaque. Cela pousse à détecter tôt plutôt qu'à la seule intrusion finale.

Un IOC est un artefact forensique prouvant que quelque chose de malveillant s'est déjà produit — un hash de fichier malveillant, une IP ou un domaine de C2, une clé de registre connue comme néfaste. Un IOA est un signal comportemental d'une attaque qui se déroule, indépendamment des outils précis — par ex. un document Word qui lance PowerShell, puis se connecte à Internet. Les IOC sont réactifs et faciles à contourner en changeant un hash ; les IOA capturent l'intention et survivent aux changements d'outils.

La persistance est la façon dont un malware survit aux redémarrages et aux déconnexions. Les incontournables sous Windows sont les clés Run/RunOnce du registre (HKLM et HKCU), les tâches planifiées et les services Windows, plus les dossiers de démarrage, les abonnements aux événements WMI et le détournement de DLL. On les traque avec autoruns/Sysinternals, Sysmon et les journaux d'événements — en cherchant des binaires non signés, des chemins étranges comme %AppData% et des entrées créées juste après la compromission initiale.

L'ordre de volatilité classe les preuves selon leur vitesse de disparition, pour collecter les plus fragiles en premier. Grosso modo : registres/cache CPU, puis RAM et état d'exécution (processus, connexions réseau, ARP), puis fichiers temporaires/swap, puis disque, puis journalisation et données de supervision distantes, et enfin supports d'archivage et sauvegardes. On travaille aussi sur des copies forensiques, on les hashe, et on maintient une chaîne de possession pour que la preuve reste recevable.

Un ransomware est un malware qui chiffre (et de plus en plus exfiltre) des données, puis exige un paiement. En cas actif : isoler les hôtes touchés du réseau sans les éteindre si vous pouvez préserver la mémoire, cerner l'ampleur, le patient zéro et la souche, préserver les preuves, trouver et évincer le point d'ancrage et toute porte dérobée, puis restaurer depuis des sauvegardes hors ligne réputées saines. Payer est un dernier recours et ne garantit jamais la récupération.

SPF publie quelles IP peuvent envoyer du courrier pour un domaine. DKIM ajoute une signature cryptographique pour que le destinataire puisse vérifier que le message n'a pas été altéré et provient bien du domaine. DMARC relie les résultats SPF/DKIM à l'en-tête From: visible via l'« alignement », dit aux destinataires quoi faire en cas d'échec (none/quarantine/reject) et envoie des rapports. SPF et DKIM seuls ne protègent pas le From que voit l'utilisateur — c'est DMARC qui l'impose.

L'analyse statique examine un échantillon sans l'exécuter — hashes, chaînes, imports, en-têtes et désassemblage — donc elle est sûre et couvre tout, mais elle est déjouée par le packing et l'obfuscation. L'analyse dynamique détone l'échantillon dans un bac à sable isolé et observe le comportement réel — fichiers, registre, processus, réseau — ce qui perce l'obfuscation mais ne révèle que ce qui s'exécute dans cette session et peut être contourné par des malwares conscients du bac à sable. Les analystes combinent les deux.

Le journal Security est primordial : 4624 connexion réussie (avec type de connexion), 4625 connexion échouée, 4634/4647 déconnexion, 4672 privilèges spéciaux attribués, 4720 compte créé, 4688 création de processus (avec ligne de commande si activée), et 4768/4769 Kerberos. Ajoutez 7045 installation de service (journal System), 4698 tâche planifiée créée, et la journalisation des blocs de script PowerShell (4104). Le type de connexion et l'audit des lignes de commande sont ce qui rend ces journaux utiles.

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.

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.

Partez d'une image de base minimale et de confiance (distroless ou slim) pour réduire la surface d'attaque, analysez les images à la recherche de CVE connues dans la CI et dans le registre, épinglez et vérifiez les empreintes (digests) des images, exécutez avec un utilisateur non-root et évitez d'intégrer des secrets. Signez les images et imposez des politiques d'admission pour que seules les images analysées et signées s'exécutent. Reconstruisez régulièrement pour que les couches de base corrigées se propagent.

Un utilisateur est une identité à longue durée de vie avec des identifiants permanents ; un rôle est une identité sans identifiants permanents que tout principal de confiance peut assumer pour obtenir des jetons à courte durée de vie ; une politique est le document JSON qui accorde des permissions, attaché à l'un ou l'autre. Le moindre privilège consiste à préférer les rôles aux utilisateurs, à restreindre les politiques à des actions et ressources précises, et à n'accorder que ce dont une tâche a besoin — puis à réviser et élaguer au fil du temps.

CloudTrail enregistre chaque appel API dans le compte — qui a fait quoi, quand, d'où — vous donnant la piste d'audit faisant autorité pour les investigations et la conformité. GuardDuty est un service géré de détection des menaces qui analyse CloudTrail, les flux VPC et les journaux DNS pour faire remonter des découvertes comme l'exfiltration d'identifiants ou le minage de cryptomonnaie. CloudTrail est la source de vérité que vous devez protéger ; GuardDuty transforme cette télémétrie en alertes exploitables.

Les erreurs classiques sont des ACL publiques ou des politiques de bucket autorisant un accès anonyme ou à tous les utilisateurs AWS, des principaux trop larges ou des actions avec wildcard, l'absence de chiffrement par défaut et l'absence de journalisation. On les évite en activant le Block Public Access au niveau du compte, en utilisant des politiques IAM/bucket selon le moindre privilège, en imposant le chiffrement par défaut et TLS, et en activant la journalisation des accès et des règles Config pour détecter les dérives.

Stockez les secrets dans un service géré dédié (Secrets Manager, Parameter Store, Vault), chiffrés avec une clé KMS, et accordez l'accès via des rôles IAM pour que les charges de travail les récupèrent à l'exécution avec des identifiants à courte durée de vie. N'intégrez jamais de secrets dans le code, les images de conteneurs ou des fichiers .env versionnés. Ajoutez une rotation automatique, des politiques de clé restreintes et une journalisation d'audit pour que chaque récupération soit traçable.

Les security groups sont des pare-feux à état attachés aux instances/ENI : ils n'ont que des règles d'autorisation, et le trafic de retour d'un flux autorisé est automatiquement permis. Les network ACL sont des filtres sans état à la frontière du sous-réseau : ils ont des règles ordonnées d'autorisation et de refus, et vous devez autoriser explicitement le trafic de retour sur les ports éphémères. Les security groups sont le contrôle principal ; les NACL ajoutent des garde-fous grossiers au niveau du sous-réseau, comme bloquer une plage d'IP.

RSA est un algorithme asymétrique utilisé pour chiffrer des données ou créer des signatures numériques à l'aide d'une paire de clés. Diffie-Hellman est un protocole d'accord de clé qui permet à deux parties de dériver un secret partagé sur un canal public sans jamais le transmettre. Ils résolvent des problèmes différents : RSA prouve l'identité et peut encapsuler des clés ; DH négocie une clé de session — et sa variante éphémère assure la confidentialité persistante.

Un HMAC est un code d'authentification de message à clé : il hache le message avec une clé secrète via une construction imbriquée (hachage interne et externe avec des bourrages dérivés de la clé). Il prouve à la fois l'intégrité (le message n'a pas été altéré) et l'authenticité (il vient de quelqu'un détenant la clé). Un simple hachage ne prouve ni l'un ni l'autre, puisque n'importe qui peut le recalculer ; HMAC résiste aussi aux attaques par extension de longueur.

Un JWT comporte trois parties en base64url — en-tête, charge utile (revendications) et signature — réunies par des points. Le serveur signe l'en-tête et la charge utile avec un secret ou une clé privée, et vérifie cette signature à chaque requête pour faire confiance aux revendications sans état de session côté serveur. Pièges : accepter alg=none, la confusion de clés RS256 vers HS256, ne pas valider l'expiration/l'émetteur/l'audience, mettre des secrets dans la charge utile lisible, et l'absence de voie de révocation.

L'application redirige l'utilisateur vers le serveur d'autorisation pour se connecter et consentir. Le serveur redirige avec un code d'autorisation de courte durée. Le backend de l'application échange ensuite ce code (plus son secret client) au point de terminaison de jeton contre un jeton d'accès, via un canal arrière de serveur à serveur. Cela garde les jetons hors du navigateur/de l'URL. Les clients publics ajoutent PKCE pour lier le code au demandeur initial.

Stockez les mots de passe avec une fonction de hachage de mots de passe délibérément lente, salée et adaptative — bcrypt, scrypt ou Argon2 — jamais un hachage générique rapide comme SHA-256 ou MD5. Les hachages rapides sont conçus pour la vitesse, donc des attaquants avec des GPU peuvent tester des milliards d'essais par seconde contre une base de données fuitée. Les hachages lents ont un facteur de travail ajustable (et un coût mémoire) qui rend chaque essai coûteux, gardant le brute force impraticable même après une fuite.

La confidentialité persistante parfaite (PFS) signifie que chaque session dérive une clé unique d'un échange de clés éphémère jeté ensuite. Si un attaquant vole plus tard la clé privée à long terme du serveur, il ne peut toujours pas déchiffrer le trafic capturé précédemment, car cette clé n'a jamais servi à dériver les clés de session. Cela s'obtient avec un Diffie-Hellman éphémère (DHE/ECDHE).

Le SSO centralise l'authentification chez un fournisseur d'identité (IdP). Quand un utilisateur visite un fournisseur de service (l'application), l'application redirige vers l'IdP ; l'utilisateur se connecte une fois, et l'IdP renvoie une assertion ou un jeton signé attestant son identité. SAML porte cela comme une assertion XML signée ; OIDC le porte comme un jeton d'identité JSON signé posé sur OAuth 2.0. L'application fait confiance à la signature de l'IdP plutôt que de gérer elle-même les mots de passe.

Analysez les images pour les CVE connues dans les paquets OS et les bibliothèques applicatives, ainsi que les mauvaises configurations et les secrets intégrés, à la fois au moment du build et en continu dans le registre — car de nouvelles CVE apparaissent après la construction d'une image. Utilisez des images de base minimales ou distroless pour réduire la surface d'attaque, épinglez et référencez les images de base par empreinte, et exécutez le conteneur en non-root. L'analyse est nécessaire mais ne remplace pas la protection à l'exécution.

L'analyse IaC analyse statiquement les définitions Terraform, CloudFormation, Kubernetes et similaires par rapport à une politique pour détecter les mauvaises configurations — buckets S3 publics, groupes de sécurité ouverts, chiffrement manquant — avant même leur provisionnement. Parce que le même modèle provisionne de nombreuses ressources, le corriger une fois évite la dérive répétée, et le détecter avant l'application est bien moins coûteux que de remédier à des ressources cloud actives. Les outils incluent Checkov, tfsec et KICS, idéalement appliqués comme barrières policy-as-code.

Le SAST lit le code source sans l'exécuter et trouve tôt les failles comme les points d'injection, mais avec beaucoup de faux positifs. Le DAST attaque l'application en cours d'exécution depuis l'extérieur, sans visibilité sur le code, et trouve de vrais problèmes exploitables mais tardivement et avec une couverture superficielle. L'IAST instrumente l'application en cours d'exécution pour corréler le comportement runtime au code, obtenant des résultats précis avec le contexte du code, mais nécessite une application sollicitée et le support d'un agent.

Utilisez la défense en profondeur : les hooks pre-commit (par ex. gitleaks) attrapent les secrets avant qu'ils n'arrivent, l'analyse CI côté serveur attrape ce qui passe, et des analyses périodiques de tout l'historique trouvent les anciennes fuites. Crucialement, un secret qui a atteint un dépôt distant doit être considéré comme compromis et tourné — supprimer le commit n'aide pas car il vit dans l'historique, les forks et les logs. Associez cela à un vrai gestionnaire de secrets pour que les secrets ne soient pas du tout dans le code.

Le shift-left consiste à déplacer la sécurité plus tôt — dans la conception, l'IDE et la pull request — là où les problèmes coûtent moins cher à corriger qu'en production. Vous évitez de bloquer les développeurs en faisant du chemin sécurisé le chemin facile : retour rapide et contextualisé, portes à faible taux de faux positifs qui n'échouent durement que sur les nouveaux problèmes à forte gravité, valeurs par défaut sécurisées et modèles « voie pavée », et en traitant la sécurité comme un facilitateur plutôt qu'un veto tardif.

La SCA inventorie les composants open-source et tiers qu'une application embarque — y compris les dépendances transitives — et signale ceux qui présentent des CVE connues ou des licences problématiques. Elle compte parce que la majeure partie du code moderne, ce sont des dépendances que vous n'avez pas écrites, et un seul paquet transitif vulnérable (comme Log4j) peut exposer toute l'application. Une bonne SCA priorise par accessibilité et exploitabilité, pas par simple décompte brut de CVE.

Un SBOM est un inventaire lisible par machine de chaque composant, bibliothèque et dépendance d'un logiciel, avec les versions et idéalement les empreintes (hashes). Il est important car lorsqu'une nouvelle vulnérabilité apparaît, vous pouvez interroger vos SBOM pour répondre instantanément à « sommes-nous affectés et où ? » au lieu de paniquer. Les deux standards dominants sont SPDX et CycloneDX, et les SBOM sont de plus en plus exigés par la réglementation et les achats.

Le client et le serveur se mettent d'accord sur un secret partagé en un seul aller-retour grâce au Diffie-Hellman éphémère (ECDHE). Le ClientHello transporte les groupes pris en charge et un key share ; le serveur répond avec son key share et son certificat, les deux parties dérivent les mêmes clés, et les données applicatives circulent immédiatement, avec la confidentialité persistante par défaut.

L'encodage (comme le Base64) est un changement de format réversible sans secret — ce n'est pas de la sécurité. Le chiffrement est réversible avec une clé et protège la confidentialité. Le hachage est une fonction à sens unique produisant un condensé de longueur fixe, utilisé pour les vérifications d'intégrité et le stockage des mots de passe, et ne peut pas être inversé pour retrouver l'entrée.

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.

Un zero-day est une vulnérabilité que l'éditeur ne connaît pas encore (ou n'a pas corrigée), de sorte que les défenseurs ont eu « zéro jour » pour la corriger. Comme aucun correctif n'existe, la défense repose sur des contrôles en couches, la détection comportementale, la segmentation, le moindre privilège et une réponse rapide aux incidents plutôt que sur une signature.

Compresser d'abord, puis chiffrer. Un bon chiffrement produit une sortie statistiquement indiscernable de l'aléatoire, donc le texte chiffré n'a plus aucun motif à compresser : compresser après est inutile. La mise en garde importante : compresser ensemble des données secrètes et des données contrôlées par l'attaquant avant le chiffrement peut fuiter de l'information via la longueur du texte chiffré, ce qui est exactement le cas des attaques CRIME et BREACH.

D'un point de vue purement sécurité, un faux négatif est généralement pire : il signifie qu'une vraie attaque n'a pas été détectée, donc pas de réponse, pas de confinement, et la brèche peut rester tapie sans être découverte. Mais les faux positifs ne sont pas anodins : en grand nombre, ils provoquent la fatigue d'alerte, où les analystes commencent à ignorer les alertes et manquent la vraie. La bonne réponse nomme le compromis, pas seulement un gagnant.

Filtré. Un port filtré rejette silencieusement le paquet, donc le scanner n'obtient aucune réponse et doit attendre un délai d'expiration : il n'apprend rien sur l'existence même de l'hôte, et le scan est considérablement ralenti. Un port fermé renvoie un RST TCP, qui confirme que l'hôte est vivant et répond, offrant gratuitement à l'attaquant une valeur de reconnaissance.

Pas à lui seul. HTTPS empêche le MITM uniquement quand la validation du certificat est strictement appliquée et que le client atteint le site en HTTPS dès le départ. Si une AC malveillante est de confiance (proxy d'entreprise, racine installée par un logiciel malveillant), si l'utilisateur passe outre les avertissements de certificat, ou si du SSL stripping rétrograde la connexion vers HTTP avant le démarrage de TLS, un attaquant peut toujours se placer au milieu.

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.

L'article 5 du GDPR pose sept principes : licéité/loyauté/transparence, limitation des finalités, minimisation des données, exactitude, limitation de la conservation, intégrité et confidentialité, et responsabilité. En cas de violation de données personnelles, le responsable du traitement doit notifier l'autorité de contrôle compétente sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance (article 33). Si la violation est susceptible d'engendrer un risque élevé pour les personnes, le responsable doit aussi notifier les personnes concernées sans retard injustifié (article 34).

HIPAA (la loi américaine Health Insurance Portability and Accountability Act) protège les Protected Health Information (PHI). La Privacy Rule encadre l'utilisation et la divulgation des PHI ; la Security Rule s'applique aux PHI électroniques (ePHI) et exige trois catégories de garanties — administratives, physiques et techniques. Elle s'applique aux covered entities (prestataires, régimes de santé, chambres de compensation) et aux business associates qui traitent des PHI pour leur compte, liés par des Business Associate Agreements. La Breach Notification Rule fixe les obligations de notifier les personnes, le HHS et parfois les médias.

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.

PCI DSS (Payment Card Industry Data Security Standard) est une norme de sécurité maintenue par le PCI Security Standards Council qui s'applique à toute organisation qui stocke, traite ou transmet des données de titulaires de cartes. Elle s'organise autour d'objectifs de contrôle couvrant un réseau sécurisé, la protection des données stockées, la gestion des vulnérabilités, un contrôle d'accès fort, la surveillance/les tests et une politique de sécurité de l'information. Le périmètre est tout ce qui se trouve dans le cardholder data environment (CDE) — donc la segmentation, la tokenisation et le fait de ne pas stocker de données inutiles sont les principaux moyens de le réduire.

Traitez la sensibilisation comme un changement de comportement, pas comme une case à cocher annuelle. Rendez-la basée sur les rôles (un développeur a besoin d'un contenu différent de celui de la finance), continue plutôt qu'un diaporama une fois par an, et ancrée dans des risques réels comme le phishing, l'ingénierie sociale et la manipulation des données. Renforcez-la avec des simulations de phishing, des rappels au bon moment et des canaux de signalement clairs. Mesurez les résultats — taux de signalement de phishing, taux de clic, temps de signalement — pas seulement les pourcentages d'achèvement. Bâtissez une culture où les gens signalent leurs erreurs sans crainte, car la crainte étouffe le signalement.

Un rapport SOC 2 Type I évalue si les contrôles d'une organisation de services sont conçus de façon adéquate à un instant unique. Un rapport Type II va plus loin : il teste si ces contrôles ont fonctionné efficacement sur une période d'examen, généralement de 3 à 12 mois. Les deux reposent sur les Trust Services Criteria de l'AICPA — la Sécurité (les critères communs obligatoires), plus en option la Disponibilité, l'Intégrité du traitement, la Confidentialité et la Vie privée.

Un référentiel est un modèle du comportement normal d'un hôte, d'un utilisateur, d'un compte ou d'un segment réseau — quels processus s'exécutent, qui se connecte d'où et quand, les volumes de données typiques, les intervalles normaux de beaconing. Une fois la normalité connue, les anomalies (paires processus parent-enfant rares, binaires vus pour la première fois, connexions à des heures inhabituelles, exfiltration de données inhabituelle) deviennent détectables comme des écarts. L'établissement d'un référentiel est le fondement de la détection d'anomalies, mais il exige un historique propre suffisant et une gestion soigneuse des changements légitimes pour ne pas se noyer sous les faux positifs.

Partez des techniques que vous voulez détecter, puis remontez jusqu'à la télémétrie qui les révèle — le mappage des sources de données d'ATT&CK y aide. En pratique, les sources à plus forte valeur sont la télémétrie endpoint des processus/lignes de commande et des chargements de modules (EDR/Sysmon), les journaux d'authentification et d'identité, le DNS et les flux proxy/réseau, et les journaux du plan de contrôle cloud. Vous auditez ensuite ce que vous collectez et conservez réellement face à ce dont chaque technique a besoin, exposant les angles morts. Une technique invisible dans tout journal n'est pas encore chassable.

La Pyramid of Pain classe les types d'indicateurs selon le coût pour un attaquant de les modifier une fois que vous détectez dessus. Les hashs sont triviaux à altérer (en bas), puis les adresses IP, les noms de domaine, les artefacts réseau/hôte, les outils, et enfin les TTP au sommet — qu'un attaquant ne peut changer qu'en réoutillant fondamentalement son comportement. Détecter aux niveaux supérieurs cause plus de « douleur » et est plus durable, donc les programmes matures investissent l'effort de détection vers les comportements et les TTP plutôt que les seuls IOC.

L'UEBA (User and Entity Behaviour Analytics) construit des référentiels comportementaux pour les utilisateurs et les entités (hôtes, comptes de service, appareils) et utilise des statistiques ou l'apprentissage automatique pour scorer les écarts comme du risque. Elle excelle face aux menaces sans signature nette : identifiants compromis, abus interne et déplacement latéral — p. ex. un utilisateur accédant soudain à des systèmes qu'il ne touche jamais, à des heures inhabituelles, ou déplaçant des volumes de données anormaux. Elle complète la détection basée sur des règles plutôt que de la remplacer, et nécessite un ajustement pour éviter les faux positifs dus aux changements de comportement légitimes.

La chasse aux menaces est la pratique proactive, guidée par des hypothèses, qui consiste à fouiller la télémétrie pour y trouver l'activité d'un adversaire que les détections existantes ont manquée. Contrairement au tri des alertes — réactif et qui attend qu'un outil se déclenche — la chasse part d'une question (« si un attaquant faisait X, quelles preuves verrais-je ? »), la teste face aux données, et soit trouve quelque chose, soit produit une nouvelle détection. Elle suppose que la prévention et les alertes sont imparfaites et qu'un adversaire déterminé est peut-être déjà à l'intérieur.

Sigma est un format YAML ouvert et neutre vis-à-vis des éditeurs pour décrire des détections SIEM. Vous définissez une logsource (product/category, par exemple Windows process_creation), un bloc detection avec des sélections nommées de correspondances champ/valeur, et une condition qui les combine. Un convertisseur (comme sigma-cli/pySigma) traduit la règle dans le langage de requête de votre backend réel — Splunk, Sentinel, Elastic — de sorte qu'une seule règle est portable. Elle porte aussi des métadonnées : title, level, status, faux positifs et tags ATT&CK.

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.

L'accès conditionnel fait dépendre la décision d'accès du contexte plutôt que d'une règle fixe. Il évalue des signaux — qui est l'utilisateur, la conformité de l'appareil, la localisation, l'application et un score de risque calculé par détection d'anomalies — et répond proportionnellement : autoriser, bloquer ou exiger un renforcement comme la MFA ou un appareil conforme. L'accès basé sur le risque est la variante dynamique où un signal de risque en temps réel pilote la politique.

La fédération d'identités établit une relation de confiance entre un fournisseur d'identité (IdP) qui authentifie les utilisateurs et des fournisseurs de services (parties de confiance) qui consomment cette authentification. L'IdP vérifie l'utilisateur et émet une assertion ou un jeton signé ; le fournisseur de services lui fait confiance au lieu de gérer ses propres identifiants. Cela permet le SSO inter-domaines et un contrôle centralisé, mais concentre le risque : compromettez l'IdP et vous compromettez tout ce qui lui fait confiance.

La MFA résistante au hameçonnage signifie que le second facteur ne peut pas être rejoué contre le vrai site même si l'utilisateur est trompé. Les passkeys FIDO2/WebAuthn y parviennent grâce à une cryptographie à clé publique liée à l'origine : l'authentificateur signe un défi lié au domaine du vrai site, de sorte qu'un identifiant capturé par un site sosie ou un attaquant-au-milieu est inutile. Les codes TOTP et les invites par notification restent hameçonnables car ils peuvent être relayés en temps réel.

Le PAM contrôle et surveille les comptes qui peuvent causer le plus de dégâts — administrateurs de domaine, root, comptes de service. Il met en coffre et fait tourner leurs identifiants pour qu'aucun secret ne soit partagé ou codé en dur, courtise les sessions pour que les administrateurs ne voient jamais le mot de passe brut, enregistre ce que font les utilisateurs privilégiés, et accorde idéalement l'élévation juste-à-temps plutôt qu'un accès permanent. L'objectif est de réduire le rayon d'impact des comptes que les attaquants convoitent le plus.

Le RBAC accorde des permissions via des rôles assignés aux utilisateurs — simple à raisonner mais sujet à l'explosion des rôles à mesure que les cas particuliers se multiplient. L'ABAC évalue des politiques sur les attributs de l'utilisateur, de la ressource, de l'action et de l'environnement, ce qui permet des décisions fines et contextuelles au prix de la complexité. La plupart des systèmes matures les combinent : des rôles pour les octrois grossiers, des attributs et des politiques pour les détails conditionnels.

SCIM (System for Cross-domain Identity Management) est une API REST/JSON et un schéma standard pour créer, mettre à jour et supprimer des comptes utilisateurs entre applications. Relié à un système RH ou à un IdP, il automatise le cycle de vie joiner-mover-leaver : les comptes et droits sont provisionnés à l'embauche, ajustés au changement de poste, et — surtout — déprovisionnés au départ, éliminant les comptes orphelins que les attaquants adorent.

Le beaconing de commande et contrôle, c'est l'implant qui appelle périodiquement la maison pour des instructions. On le reconnaît à des rappels sortants réguliers et de faible volume à intervalle à peu près fixe — souvent avec du jitter pour éviter de paraître mécanique — vers un petit ensemble de destinations, fréquemment via HTTP/HTTPS ou DNS avec des charges utiles encodées ou chiffrées et un User-Agent ou un motif d'URI distinctif. On extrait les indicateurs statiquement en tirant domaines, IP, URI et clés des chaînes et blocs de config, et dynamiquement en détonant l'échantillon contre un réseau factice et en capturant les vrais rappels, puis on associe le comportement à ATT&CK et on alimente les IOC dans la détection.

L'empaquetage compresse ou chiffre la vraie charge utile et y préfixe un stub qui la dépaquette en mémoire à l'exécution ; l'obfuscation transforme le code ou les données pour résister à la lecture et aux signatures. On détecte l'empaquetage à une entropie de section élevée proche de 8,0, une table d'imports minuscule ou réduite au stub, des noms de section inhabituels ou inscriptibles-exécutables comme UPX0, un point d'entrée hors de .text, une grande taille virtuelle face à une petite taille brute, et des détecteurs comme Detect It Easy ou PEiD. Aucun de ces signaux n'est concluant seul, donc les analystes en pèsent plusieurs ensemble et confirment en observant le dépaquetage à l'exécution.

Un fichier PE commence par l'en-tête DOS et son pointeur e_lfanew vers les en-têtes PE/NT, qui contiennent le File Header et l'Optional Header (point d'entrée, image base, sous-système). Il est divisé en sections — .text pour le code, .data, .rdata, .rsrc pour les ressources — chacune avec une adresse virtuelle et une taille brute. Lors du triage, on lit la table d'imports pour les API suspectes, la table des sections pour les noms étranges et l'entropie élevée qui suggèrent l'empaquetage, le timestamp et le rich header, les ressources embarquées et toute signature numérique. Les incohérences entre ces éléments en disent long avant même d'exécuter le fichier.

L'outillage statique lit l'échantillon au repos : PEStudio, CFF Explorer et pefile pour les en-têtes et imports, FLOSS et strings pour le texte embarqué, capa pour la cartographie des capacités, et Ghidra ou IDA pour le désassemblage. L'outillage dynamique l'observe s'exécuter dans une VM isolée : Procmon et Process Hacker pour l'activité hôte, Wireshark et INetSim ou FakeNet pour le réseau simulé, Regshot pour les diffs avant/après, et x64dbg pour le pas-à-pas contrôlé. Le workflow consiste à trier statiquement, détoner dynamiquement, puis revenir au désassembleur pour combler les lacunes comportementales.

Une règle YARA comporte un bloc meta, une section strings (motifs texte, hexa ou regex, avec jokers et sauts) et une condition qui combine ces correspondances par une logique booléenne et de comptage. Une règle efficace s'appuie sur un élément durable et distinctif — un stub de code unique, un nom de mutex, un marqueur de configuration ou une combinaison d'imports inhabituelle — plutôt que sur des valeurs qu'un attaquant change trivialement comme un seul hash ou une chaîne générique. On équilibre la spécificité face aux faux positifs, on teste contre un corpus propre, et on documente la règle pour que d'autres lui fassent confiance et la maintiennent.

La divulgation coordonnée de vulnérabilités est un processus où un chercheur signale une faille en privé à l'éditeur, les deux parties s'accordent sur la correction et un délai, et les détails ne sont publiés qu'une fois un correctif disponible (ou le délai convenu écoulé). Elle équilibre le temps laissé aux défenseurs pour corriger et le droit du public à être informé. Un fichier security.txt et une politique claire rendent le signalement sans friction ; les programmes de bug bounty ajoutent des récompenses structurées par-dessus.

Le DFIR suit un processus rigoureux : identification (confirmer et délimiter l'incident), acquisition (préserver les preuves selon l'ordre de volatilité, avec images forensiques et empreintes), analyse (chronologie, cause racine, étendue de la compromission) et reporting (constats pour des publics techniques et juridiques). La chaîne de possession documente qui a manipulé chaque artefact et quand, afin que la preuve tienne si elle arrive un jour devant un tribunal. Préserver avant de remédier.

ATT&CK est une base de connaissances des tactiques (le pourquoi), techniques (le comment) et procédures adverses réelles. Vous l'utilisez pour cartographier vos détections existantes sur la matrice, repérer les lacunes de couverture et prioriser les techniques employées par les acteurs qui ciblent réellement votre secteur. Il offre un langage commun entre CTI, ingénierie de détection et réponse à incident, transformant « sommes-nous sécurisés ? » en une carte de couverture concrète et mesurable, fondée sur le comportement adverse réel.

Le WSTG est une méthodologie adossée à une checklist qui fait passer une application par des catégories de test : collecte d'informations, configuration et déploiement, identité et authentification, autorisation, gestion de session, validation des entrées (injection/XSS), gestion des erreurs, cryptographie, logique métier et côté client. Il offre une couverture systématique avec des identifiants de test stables, de sorte que les constats sont reproductibles et que rien d'évident n'est oublié.

PTES définit sept phases : pré-engagement (périmètre, règles d'engagement, autorisation), collecte de renseignements (OSINT, reconnaissance), modélisation des menaces, analyse de vulnérabilités, exploitation, post-exploitation (pivotement, données de valeur, persistance) et reporting. La structure rend les missions reproductibles, défendables et liées au risque métier plutôt qu'à du hacking improvisé. Le pré-engagement et le reporting sont les phases que les juniors sous-estiment.

Le purple teaming est collaboratif plutôt qu'adversarial : le côté rouge exécute des TTP précis et convenus (souvent reliés à MITRE ATT&CK) pendant que le côté bleu observe sa télémétrie en temps réel pour confirmer si chaque technique est journalisée, alertée et détectable. On mesure la couverture de détection technique par technique, on ajuste les détections et comble les lacunes immédiatement, puis on re-teste. Le livrable est une détection améliorée et mesurable — pas une liste de qui a « gagné ».

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 gestion des vulnérabilités est une boucle continue : découvrir les actifs et vulnérabilités (scan, inventaire d'actifs), prioriser selon le risque réel (CVSS plus exploitabilité, exposition et criticité des actifs — des frameworks comme EPSS et SSVC aident), remédier ou atténuer, vérifier la correction et rapporter sur les tendances et les SLA. Le scan est la partie facile ; la discipline est de prioriser et de boucler la boucle pour que le risque baisse réellement avec le temps.

Un proxy direct se place devant les clients et émet des requêtes sortantes en leur nom — pour le contrôle de sortie, le filtrage, la mise en cache et l'anonymat. Un proxy inverse se place devant les serveurs et reçoit les requêtes entrantes en leur nom — pour la répartition de charge, la terminaison TLS, la mise en cache et comme façade de sécurité pour un WAF. Le sens vers lequel il fait face, côté client ou côté serveur, est la distinction clé.

Traceroute découvre les routeurs entre vous et une destination en exploitant le champ TTL. Il envoie des paquets avec TTL=1, puis 2, puis 3, et ainsi de suite. Chaque routeur décrémente le TTL ; quand le TTL atteint zéro, ce routeur rejette le paquet et renvoie un message ICMP Time Exceeded, révélant son adresse. En augmentant le TTL, traceroute cartographie chaque saut dans l'ordre jusqu'à atteindre la destination.

Le NAT (Network Address Translation) réécrit l'IP source et/ou destination à mesure que les paquets franchissent une frontière, mappant généralement des adresses internes privées vers des publiques. Le PAT (Port Address Translation, ou NAT overload) étend cela en traduisant aussi les ports, laissant de nombreux hôtes internes partager une seule IP publique — chaque flux distingué par son port. Le PAT est ce que les routeurs domestiques et de bureau utilisent pour placer tout un LAN derrière une seule adresse.

Un VLAN (réseau local virtuel) partitionne logiquement un commutateur physique en domaines de diffusion de couche 2 distincts, de sorte que des appareils sur des VLAN différents ne peuvent pas se joindre directement, même sur le même matériel. Il est étiqueté par un marqueur 802.1Q sur les liens de trunk. La valeur de sécurité est la segmentation : isoler le trafic des utilisateurs, des serveurs, des invités et de l'IoT limite la portée des diffusions et le mouvement latéral, le trafic inter-VLAN étant forcé de passer par un routeur ou un pare-feu où la politique est appliquée.

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.

Énumérez méthodiquement : vérifiez sudo -l, les binaires SUID/SGID, les tâches cron, la version du noyau et de l'OS, les fichiers inscriptibles dans des chemins privilégiés, les capabilities et les identifiants stockés. Des outils comme LinPEAS automatisent le balayage, mais vous vérifiez chaque découverte avec GTFOBins ou une technique connue.

Identifiez le service et la version exacts, cherchez sur Exploit-DB ou searchsploit un PoC correspondant, puis lisez le code ligne par ligne avant de l'exécuter — corrigez l'IP cible, le port et l'adresse du reverse shell, régénérez tout shellcode, et comprenez ce qu'il fait pour qu'il ne se retourne pas contre vous.

Identifiez d'abord le format du hachage (hashid ou contexte), puis lancez hashcat ou John avec le mode correct contre une wordlist comme rockyou, en appliquant des règles pour muter les candidats. Utilisez le bon flag de format (NTLM, sha512crypt, NetNTLMv2, etc.) pour que l'outil hache les essais de la même façon que la cible.

Pour SMB, énumérez les partages, vérifiez l'accès anonyme/session null, listez les utilisateurs et identifiez la version pour les CVE connues. Pour SNMP, essayez les community strings par défaut comme « public » et parcourez la MIB pour extraire noms d'utilisateurs, processus en cours, logiciels installés et détails réseau.

Isolément, une SQLi expose ou modifie des données et peut atteindre le RCE ; une XSS stockée détourne les sessions dans le navigateur des victimes. Enchaînées, vous pouvez utiliser la SQLi pour implanter une charge XSS stockée qui se déclenche dans la session d'un admin, voler sa session et passer au contrôle total de l'application.

Énumérez d'abord : privilèges actuels, droits sudo, binaires SUID/SGID, tâches cron, fichiers inscriptibles dans le PATH, version du noyau et identifiants stockés. Puis exploitez le chemin le plus simple et fiable — souvent une règle sudo mal configurée ou un GTFOBin SUID — avant de recourir à un exploit du noyau.

Énumérez les privilèges du compte et les mauvaises configurations de l'hôte : privilèges de jeton comme SeImpersonate, chemins de service non entre guillemets, permissions de service faibles, AlwaysInstallElevated et identifiants stockés. Puis abusez du plus fiable — l'usurpation de jeton (attaques Potato) est une voie courante vers SYSTEM.

Un bind shell ouvre un port d'écoute sur la cible et attend que vous vous y connectiez. Un reverse shell fait que la cible se connecte en sortie vers un écouteur que vous contrôlez. Les reverse shells l'emportent généralement car le trafic sortant contourne les règles de pare-feu entrantes et le NAT.

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.

Ne jamais coder en dur les secrets dans le code source ni les committer dans git. Les stocker dans un gestionnaire de secrets ou un coffre-fort dédié, les injecter à l'exécution, restreindre l'accès au moindre privilège, les faire tourner régulièrement, et préférer des identifiants dynamiques à courte durée de vie aux identifiants statiques persistants. Auditer chaque accès.

Imposer TLS partout, authentifier chaque requête (par exemple des jetons OAuth2/OIDC) et autoriser par objet pour que les utilisateurs n'atteignent que leurs propres données. Ajouter la validation des entrées, la limitation de débit et les quotas, la validation de schéma et une journalisation approfondie. La faille d'API la plus courante est l'autorisation au niveau objet défaillante, vérifiez donc la propriété à chaque accès à une ressource.

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.

La force brute cible un seul compte avec de nombreuses tentatives de mot de passe, on voit donc beaucoup d'échecs concentrés sur un même identifiant. Le password spray inverse la logique : un ou quelques mots de passe courants essayés sur de nombreux comptes, lentement et discrètement, de sorte que chaque compte ne voit que quelques échecs. Le signal de détection est le ratio comptes/échecs et le timing, pas le nombre brut d'échecs.

Comprenez d'abord pourquoi la règle se déclenche autant — trouvez le motif bénin commun derrière le bruit. Écrivez ensuite l'exclusion la plus étroite possible (hôte, compte ou comportement précis), documentez la justification, et validez qu'un vrai positif se déclencherait encore. Évitez les suppressions larges qui créent discrètement des angles morts.

ATT&CK est une base de connaissances des tactiques et techniques adverses réelles. Dans un SOC, vous mappez chaque règle de détection aux techniques qu'elle couvre, construisez une carte de couverture (souvent avec l'ATT&CK Navigator), puis priorisez la fermeture des lacunes selon les techniques les plus pertinentes pour votre modèle de menace et celles sur lesquelles vous n'avez aucune visibilité.

Le CSRF piège le navigateur d'un utilisateur connecté pour lui faire envoyer une requête modifiant l'état vers un site où il est authentifié, en abusant du fait que les cookies sont envoyés automatiquement. On l'empêche avec des jetons anti-CSRF (une valeur secrète par session que l'attaquant ne peut ni lire ni deviner) et l'attribut de cookie SameSite, qui empêche les cookies d'accompagner les requêtes intersites.

Ne stockez jamais les mots de passe en clair ni chiffrés de façon réversible, et jamais avec des hachages rapides à usage général comme MD5 ou SHA-256. Utilisez une fonction de hachage de mots de passe lente et exigeante en mémoire — Argon2id (préféré) ou bcrypt — avec un sel aléatoire unique par mot de passe et un facteur de coût ajusté, afin qu'un attaquant qui vole la base de données ne puisse pas casser les hachages de manière réaliste.

Les requêtes préparées envoient d'abord le modèle de requête à la base de données, avec des emplacements réservés, afin que la structure soit figée avant l'arrivée de toute donnée utilisateur. Les paramètres sont ensuite liés comme de pures données et ne peuvent jamais être interprétés comme du SQL — ainsi une entrée comme ' OR 1=1 est traitée comme une chaîne littérale, pas comme du code. Cette séparation est le correctif canonique et fiable contre l'injection.

La défense principale est l'encodage de sortie contextuel — encoder les données non fiables pour l'endroit exact où elles atterrissent (corps HTML, attribut, JavaScript, URL). Associez cela à des API DOM sûres (textContent plutôt qu'innerHTML), à l'auto-échappement des frameworks, à la validation des entrées et à une Content-Security-Policy comme rempart de défense en profondeur qui limite quels scripts peuvent s'exécuter.

La Same-Origin Policy est la règle du navigateur selon laquelle un script d'une origine (schéma + hôte + port) ne peut pas lire les réponses d'une origine différente, ce qui protège les sessions authentifiées. CORS est un assouplissement contrôlé : un serveur renvoie des en-têtes Access-Control-Allow-Origin pour autoriser explicitement des origines spécifiques à lire ses réponses, ce qui assouplit la SOP au lieu de la contourner.

Les en-têtes de sécurité clés incluent Strict-Transport-Security (force HTTPS, bloque le SSL stripping), Content-Security-Policy (limite les sources de scripts, atténue le XSS), X-Frame-Options ou CSP frame-ancestors (bloque le clickjacking), X-Content-Type-Options: nosniff (stoppe le MIME sniffing) et Referrer-Policy (contrôle la fuite du référent). Chacun traite une classe d'attaque spécifique.

L'injection SQL permet à l'entrée d'un attaquant de modifier une requête. Les techniques en bande renvoient les données directement : celle basée sur UNION ajoute un UNION SELECT pour extraire des colonnes supplémentaires, et celle basée sur les erreurs fait fuiter les données via les messages d'erreur de la base. Quand aucune sortie n'est visible, les attaquants utilisent la SQLi à l'aveugle — la booléenne déduit les données des différences de réponse vrai/faux, et la temporelle utilise des délais comme SLEEP() pour lire les données bit par bit.

Tout XSS injecte un script contrôlé par l'attaquant dans le navigateur d'une victime. Le XSS stocké persiste la charge utile sur le serveur (par exemple un commentaire) et touche tous ceux qui la consultent ; le XSS réfléchi renvoie la charge utile depuis le serveur dans une seule réponse, généralement via un lien forgé ; le XSS basé sur le DOM n'atteint jamais la logique serveur — du JavaScript côté client vulnérable écrit une entrée non fiable dans la page.