Questions d'entretien CompTIA Security+

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. Les trois catégories de facteurs d'authentification sont quelque chose que vous savez (mot de passe/PIN), quelque chose que vous avez (jeton/téléphone) et quelque chose que vous êtes (biométrie). Une empreinte digitale ou un scan facial relève de « quelque chose que vous êtes », un trait physique mesuré. Le piège : la biométrie n'est pas un secret et ne peut pas être renouvelée — si le gabarit de votre empreinte fuite, vous ne pouvez pas changer votre empreinte. C'est pourquoi la biométrie fonctionne mieux comme un facteur, déverrouillant souvent une clé locale, que comme remplacement autonome du mot de passe.

On ne le déchiffre pas — les hashs cryptographiques sont des fonctions à sens unique sans inverse. « Cracker » un hash, c'est deviner des entrées candidates, les hacher et comparer (dictionnaire, force brute, rainbow tables), ce qui explique justement pourquoi on utilise des hashs lents et salés pour les mots de passe. Aucune clé ne « déchiffre » un hash. Si une donnée peut être déchiffrée, c'est qu'elle a été chiffrée, pas hachée — et le Base64 est un encodage réversible, pas du hachage.

Non. Le fichier de test EICAR est une chaîne ASCII délibérément inoffensive de 68 octets que tous les éditeurs d'antivirus s'accordent à détecter, afin de vérifier en toute sécurité la détection et les alertes sans manipuler de vrai malware. Une détection signifie que votre antivirus fonctionne — pas que vous êtes infecté. Ce n'est pas un virus et il ne fait rien s'il est exécuté. Confondre une détection de test EICAR avec une vraie infection est un piège classique en début de carrière.

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. TLS/HTTPS sécurise les données en transit entre client et serveur ; une fois reçues, elles sont déchiffrées et traitées en clair par l'application, puis stockées selon la configuration de la base. Protéger les données au repos est un sujet distinct — chiffrement de disque/colonne, un KMS et le contrôle d'accès. Confondre « on utilise HTTPS » avec « nos données stockées sont chiffrées » est une idée fausse courante et dangereuse.

Non. HTTPS chiffre le canal pour que les attaquants ne puissent ni lire ni altérer le trafic en transit, mais l'entrée malveillante arrive, est déchiffrée et traitée par votre application exactement comme avant. L'injection SQL et le XSS sont des failles applicatives corrigées par des requêtes paramétrées et l'encodage de sortie, pas par le chiffrement du transport. L'erreur suppose que le chiffrement assainit le contenu — il ne le fait pas ; l'attaquant envoie simplement la charge via la connexion HTTPS.

Non. Une MAC est attribuée par le fabricant (OUI plus identifiant de l'appareil) et « gravée », mais pratiquement chaque système d'exploitation permet de la remplacer en logiciel (macchanger, ip link set address). Les adresses MAC sont donc usurpables et ne doivent pas servir à l'authentification — le filtrage MAC est faible, et les téléphones randomisent désormais leur MAC par confidentialité. « Permanente et unique » 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. POST place simplement les paramètres dans le corps de la requête au lieu de l'URL ; ce corps est en clair et parfaitement visible pour quiconque voit le trafic, sauf en HTTPS. POST est préférable pour les actions qui modifient l'état et garde les paramètres hors des URL, des journaux et de l'historique, mais il n'offre aucune confidentialité en soi. L'erreur confond « pas dans l'URL » et « chiffré » — seul TLS chiffre les données de l'une ou l'autre méthode en transit.

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.

Question piège : il n'existe pas de port unique pour traceroute. Le traceroute Unix classique envoie des datagrammes UDP vers des ports élevés et improbables à partir de 33434 environ, avec un TTL croissant ; le tracert de Windows utilise plutôt ICMP Echo. Il fonctionne en lisant les messages ICMP Time Exceeded que renvoient les routeurs à l'expiration du TTL, et non en visant un port réservé. Et ICMP lui-même n'a aucun port.

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.

Urgence, autorité et contournement de la vérification sont une pression d'ingénierie sociale de manuel visant un compte à forte valeur. L'agent doit suivre le processus de vérification d'identité défini avant toute réinitialisation, et escalader s'il ne peut pas être satisfait. Réinitialiser à la demande, utiliser une « question de sécurité » devinable comme la couleur préférée, ou envoyer le nouveau mot de passe par e-mail à l'appelant remettent tous le contrôle du compte du dirigeant à un attaquant.

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.

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.

Word engendrant un processus enfant juste après l'activation des macros est un schéma classique d'accès initial par document malveillant. Isolez l'hôte pour limiter la propagation, capturez les preuves volatiles, et enquêtez sur le processus engendré, son activité réseau et toute persistance. Demander à l'utilisateur de fermer le fichier ou réparer Office ne traite pas une charge utile en cours d'exécution qui a peut-être déjà tourné. Ne rien faire parce que le fichier est arrivé par e-mail est à l'envers — l'e-mail est précisément le vecteur de livraison de cette attaque. Confinez d'abord, puis enquêtez.

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.

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.

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.

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.

Validez avant d'escalader. Les VPN d'entreprise, les proxys cloud (CASB ou IP de service M365) et les opérateurs mobiles produisent régulièrement de faux « voyages impossibles » ; vérifiez donc les IP de sortie, le résultat MFA et l'appareil/user-agent avant d'agir. Verrouiller à chaque déclenchement provoque de la fatigue d'alertes et érode la confiance des utilisateurs envers le SOC. Supposer que c'est toujours un faux positif laisse passer une vraie compromission de compte. Écrire au manager est lent et n'est pas un contrôle — les journaux répondent plus vite et plus sûrement.

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.

Un jailbreak vise l'alignement de sécurité du modèle : il pousse le modèle à produire du contenu que le fournisseur a cherché à interdire, comme des instructions nuisibles. La prompt injection vise la hiérarchie d'instructions de l'application : elle écrase le system prompt du développeur ou détourne le comportement du modèle dans une application, souvent via des données non fiables. Les jailbreaks attaquent le modèle ; la prompt injection attaque le système environnant. Ils se recoupent, mais l'objectif et la frontière de confiance franchie diffèrent.

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.

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'antivirus traditionnel compare les fichiers à des signatures de malwares connus et les bloque ou les met en quarantaine — efficace contre les menaces connues, faible contre les attaques nouvelles ou sans fichier. L'EDR enregistre en continu le comportement du poste (processus, réseau, registre, mémoire), utilise l'analyse comportementale pour détecter l'activité suspecte, et permet aux intervenants d'investiguer, de traquer et de contenir ou restaurer à distance. L'AV est de la prévention par signature ; l'EDR ajoute visibilité, détection et réponse.

Le modèle classique est PICERL : Préparation, Identification (détection), Confinement, Éradication, Restauration et Retour d'expérience. Le NIST le regroupe en : Préparation ; Détection et analyse ; Confinement, éradication et restauration ; et Activité post-incident. L'ordre compte car il faut cerner et confiner avant d'éradiquer, et l'on ne restaure qu'une fois la menace supprimée — sinon on réinfecte. C'est une boucle, pas une ligne : le retour d'expérience nourrit la préparation.

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.

Sous Windows, les hashes des comptes locaux (NTLM) résident dans la ruche SAM sous C:\Windows\System32\config\SAM, protégée tant que l'OS tourne ; les identifiants vivants se trouvent dans la mémoire de LSASS, et les hashes de domaine sont dans NTDS.dit sur un contrôleur de domaine. Sous Linux, les hashes sont dans /etc/shadow (lisible uniquement par root), tandis que /etc/passwd contient les métadonnées de compte. Les attaquants les volent pour casser les mots de passe hors ligne ou faire du pass-the-hash.

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.

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.

Un honeypot est un système ou service leurre sans usage métier légitime, délibérément exposé pour attirer les attaquants. Comme rien de bénin ne devrait jamais le toucher, toute interaction est une alerte hautement fiable. Les honeypots à faible interaction émulent des services à peu de frais ; ceux à forte interaction sont de vrais systèmes qui livrent une intel plus riche mais comportent plus de risque. Les honeytokens sont la même idée appliquée à de faux identifiants, fichiers ou enregistrements. Valeur : détection précoce, peu de faux positifs et threat intelligence.

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.

Le chiffrement en transit (TLS) protège les données circulant sur le réseau contre l'écoute et l'altération ; imposez TLS partout et rejetez le texte clair. Le chiffrement au repos protège les données stockées sur les disques et les sauvegardes, généralement via des clés gérées par KMS utilisant le chiffrement par enveloppe. Les deux sont des contrôles de base, mais aucun n'arrête une requête autorisée mais malveillante — le service déchiffre de manière transparente pour les appelants valides — donc le contrôle d'accès reste primordial.

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.

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.

Le fournisseur sécurise le cloud lui-même — centres de données physiques, matériel, hyperviseur et services gérés qu'il exploite. Vous sécurisez ce que vous mettez dans le cloud — vos données, identités, configurations, l'application des correctifs OS le cas échéant, et les contrôles d'accès. La frontière exacte se déplace : avec l'IaaS vous possédez l'OS et au-dessus, avec le SaaS vous possédez surtout les données et l'accès.

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.

Une signature numérique est le hachage d'un message transformé avec la clé privée du signataire. Le vérificateur recalcule le hachage, applique la clé publique du signataire, et vérifie qu'ils correspondent. Comme seul le signataire détient la clé privée, une signature valide prouve que le message vient de lui (authenticité), n'a pas été altéré (intégrité), et qu'il ne peut le nier de façon crédible (non-répudiation).

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.

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.

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

Un sel est une valeur aléatoire unique générée par utilisateur et combinée au mot de passe avant le hachage. Il garantit que des mots de passe identiques produisent des hachages différents et rend inutiles les attaques précalculées comme les tables arc-en-ciel, puisque l'attaquant aurait besoin d'une table distincte par sel. Les sels sont stockés à côté du hachage. Un poivre est une valeur secrète supplémentaire, la même pour tous les utilisateurs, conservée séparément (par exemple, dans la config de l'application ou un HSM) de sorte qu'une fuite de base de données seule ne suffise pas.

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.

TOTP (mot de passe à usage unique basé sur le temps) combine un secret partagé, établi à l'enrôlement, avec l'heure courante divisée en fenêtres fixes (généralement 30 secondes). Il exécute HMAC sur le compteur de pas de temps avec le secret, puis tronque le résultat en un code à 6 chiffres. L'application et le serveur détiennent tous deux le même secret et la même horloge, donc ils calculent indépendamment le même code — aucun appel réseau nécessaire. Le code change à chaque fenêtre.

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.

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.

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

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

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.

Un IDS (système de détection d'intrusion) surveille le trafic et lève des alertes mais ne bloque pas — il est généralement hors bande. Un IPS (système de prévention d'intrusion) se place en ligne dans le chemin du trafic et peut activement rejeter ou bloquer le trafic malveillant. L'IPS prévient, mais un faux positif peut casser du trafic légitime.

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.

La MFA exige au moins deux facteurs d'authentification de catégories différentes — quelque chose que vous savez (mot de passe), quelque chose que vous possédez (téléphone/jeton), quelque chose que vous êtes (biométrie). Elle aide car un attaquant qui vole un facteur, comme un mot de passe, ne peut toujours pas se connecter sans les autres. La MFA résistante à l'hameçonnage comme FIDO2 est la plus forte.

L'hameçonnage est une ingénierie sociale qui pousse les gens à révéler des identifiants, envoyer de l'argent ou exécuter un malware, généralement via de faux e-mails ou sites. La défense est en couches : filtrage et authentification des e-mails (SPF/DKIM/DMARC), MFA pour limiter les dégâts d'identifiants volés, formation de sensibilisation, et un moyen simple de signaler les messages suspects.

Le chiffrement symétrique utilise une seule clé secrète partagée pour chiffrer et déchiffrer et il est rapide, mais les deux parties doivent déjà partager la clé. L'asymétrique utilise une paire de clés publique/privée, résolvant le problème de distribution des clés mais plus lentement. De vrais protocoles comme TLS utilisent la crypto asymétrique pour échanger une clé symétrique, puis basculent vers le symétrique pour les données en masse.

TCP est orienté connexion et fiable : il utilise une poignée de main en trois temps, garantit une livraison ordonnée et retransmet les paquets perdus. UDP est sans connexion et rapide, sans garantie de livraison, d'ordre ni de congestion. On utilise TCP pour l'exactitude (web, e-mail, transfert de fichiers) et UDP pour le trafic sensible à la vitesse (DNS, VoIP, streaming, jeux).

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

Un pare-feu contrôle le trafic entre zones réseau en l'autorisant ou en le refusant selon des règles. Un pare-feu sans état évalue chaque paquet isolément par rapport aux règles ; un pare-feu à état suit l'état des connexions pour autoriser le trafic de retour des sessions qu'il a permises. Les pare-feu nouvelle génération ajoutent la connaissance de la couche applicative.

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.

Ni l'un ni l'autre. ARP est un protocole de couche 2 (couche liaison) encapsulé directement dans une trame Ethernet, et non dans un paquet IP. Comme il ne circule jamais sur IP, il ne peut utiliser ni TCP ni UDP, qui sont des transports de couche 4 nécessitant IP en dessous. Le rôle d'ARP est de résoudre une adresse IP connue en l'adresse MAC correspondante sur le même segment de réseau local.

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.

Parce que « supprimer » n'efface normalement pas les données. Cela enlève les métadonnées du système de fichiers (le pointeur/l'entrée de répertoire) et marque les blocs comme libres, mais les octets d'origine restent sur le disque jusqu'à ce que le système d'exploitation réutilise ces blocs pour de nouvelles données. Tant que cette réécriture n'a pas eu lieu, des outils forensiques peuvent extraire le contenu directement.

L'encodage transforme les données dans un autre format pour la compatibilité et est entièrement réversible par quiconque sans clé (par ex. Base64, encodage d'URL) : il n'offre aucune confidentialité. Le chiffrement n'est réversible qu'avec une clé et c'est lui qui assure la confidentialité. Le hachage est une fonction à sens unique : on ne peut pas retrouver l'entrée à partir de la sortie, ce qui le rend adapté aux contrôles d'intégrité et au stockage des mots de passe (avec un sel et une KDF lente).

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.

Non. Le cadenas signifie que le transport est chiffré et que le certificat est valide pour ce domaine : il ne dit rien sur l'honnêteté de l'opérateur ni sur le caractère malveillant du contenu. Des certificats gratuits et automatisés font que les sites d'hameçonnage et de logiciels malveillants ont presque toujours un cadenas parfaitement valide. HTTPS protège le canal, pas la destination.

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.

HTTPS n'est pas un protocole à part entière : c'est du HTTP ordinaire circulant dans un tunnel TLS chiffré. SSL est l'ancien nom : SSL 2.0/3.0 sont les prédécesseurs obsolètes et non sécurisés de TLS, qui les a remplacés (TLS 1.0 à 1.3). Quand les gens disent « certificat SSL » ou « SSL », ils désignent presque toujours en réalité TLS.

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.

Question piège : ping n'utilise aucun port. Il s'exécute sur ICMP, un protocole de couche 3 qui repose directement sur IP. Les ports n'existent que dans les protocoles de couche 4 comme TCP et UDP, donc ICMP (et donc ping) n'en a aucun. ICMP utilise à la place des champs de type et de code, par ex. Echo Request type 8 et Echo Reply type 0.

Trois. Le client envoie un SYN, le serveur répond par un SYN-ACK combiné (un seul paquet qui à la fois accuse réception du SYN du client et envoie le propre SYN du serveur), et le client termine par un ACK. L'astuce est que SYN-ACK est un seul paquet, pas deux, donc le total est de trois — exactement ce que désigne « en trois temps ».

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.

Le NIST SP 800-63B moderne privilégie la longueur à la complexité : autoriser de longues phrases secrètes (au moins 8, en prendre en charge 64+), accepter tous les caractères y compris les espaces, et ne pas imposer de règles de composition comme « une majuscule, un symbole ». Filtrer les nouveaux mots de passe contre les listes de mots de passe compromis, abandonner l'expiration périodique obligatoire (renouveler uniquement en cas de preuve de compromission), et abandonner les « questions de sécurité » fondées sur la connaissance. Le but : des règles qui résistent aux vraies attaques au lieu d'agacer les utilisateurs vers des schémas prévisibles.

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.

On classe selon ce que l'échantillon est conçu pour faire, observé à partir de son comportement et de ses capacités. Un dropper transporte et écrit une charge utile sur le disque ; un loader récupère ou injecte l'étape suivante, souvent uniquement en mémoire ; un RAT donne à un opérateur un contrôle distant interactif ; un wiper détruit les données ou les enregistrements d'amorçage sans intention de récupération ; un ransomware chiffre les fichiers et exige un paiement. Les vrais échantillons combinent souvent les rôles — un loader qui déploie un RAT — donc on décrit la chaîne de capacités plutôt que d'imposer une étiquette unique, et on associe chaque comportement aux techniques ATT&CK.

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.

Un laboratoire sécurisé isole le malware de tout ce qu'il pourrait endommager. Vous exécutez les échantillons dans des VM jetables sur un hyperviseur, prenez des snapshots propres pour pouvoir revenir en arrière après chaque détonation, et coupez tout accès réseau réel via un réseau host-only avec un Internet simulé (INetSim ou FakeNet) ou un segment isolé physiquement. Vous séparez la machine d'analyse d'une passerelle contrôlée, n'analysez jamais sur votre poste de travail quotidien, durcissez contre l'évasion de VM, manipulez les échantillons sous forme de zips protégés par mot de passe, et gardez l'outillage et les indicateurs hors de la VM de détonation. L'objectif est d'observer un comportement réel tout en garantissant que l'échantillon ne peut atteindre ni la production ni Internet.

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

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.

SSH utilise TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS le 53 (UDP et TCP), RDP TCP 3389 et SMB TCP 445. Connaître les ports réservés permet de lire la sortie d'un scan, d'écrire des règles de pare-feu et de trier les alertes rapidement — un service sur son port attendu plutôt qu'inattendu est un signal immédiat.

Un résolveur stub demande un nom à un résolveur récursif. S'il n'est pas en cache, le résolveur récursif parcourt la hiérarchie : il interroge un serveur racine (qui pointe vers le TLD), le serveur TLD (qui pointe vers les serveurs autoritaires du domaine) et enfin le serveur autoritaire, qui détient l'enregistrement réel. La réponse est mise en cache en chemin selon son TTL. Le DNS utilise le port 53 — UDP pour la plupart des requêtes, TCP pour les volumineuses.

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.

Le modèle OSI divise le réseau en sept couches, chacune ajoutant une responsabilité : Physique (bits sur le câble), Liaison de données (trames et adressage MAC), Réseau (routage IP), Transport (TCP/UDP, ports, fiabilité), Session (gestion des connexions), Présentation (encodage, chiffrement, compression) et Application (protocoles comme HTTP). Chaque couche encapsule celle au-dessus à mesure que les données descendent la pile.

Un sous-réseau est une subdivision logique d'un réseau IP. Le masque de sous-réseau marque quels bits d'une adresse IP forment la partie réseau et quels bits forment la partie hôte — par exemple, /24 (255.255.255.0) signifie que les 24 premiers bits identifient le réseau et les 8 derniers les hôtes. Le découpage contrôle comment le trafic est routé et permet de segmenter un réseau en domaines de diffusion plus petits.

TCP ouvre une connexion en trois étapes. Le client envoie un SYN avec un numéro de séquence initial, le serveur répond par un SYN-ACK (accusant réception du numéro du client et envoyant le sien), et le client renvoie un ACK. Après cet échange, les deux parties se sont accordées sur les numéros de séquence de départ et la connexion est établie pour une livraison fiable et ordonnée des octets.

TCP est orienté connexion : il fait une poignée de main, numérote les octets, retransmet les pertes et contrôle la congestion, offrant une livraison fiable et ordonnée au prix de la latence et du surcoût. UDP est sans connexion et fonctionne en mode envoyer-et-oublier — pas de poignée de main, pas de retransmission, pas d'ordonnancement. Utilisez TCP quand l'exactitude compte (web, e-mail, transfert de fichiers) et UDP quand la vitesse prime sur la perfection (DNS, VoIP, jeux, vidéo).

Le modèle TCP/IP a quatre couches — Liaison, Internet, Transport et Application — et décrit le fonctionnement réel d'Internet. OSI en a sept. Elles correspondent étroitement : la couche Application de TCP/IP absorbe les couches Application, Présentation et Session d'OSI ; sa couche Liaison combine les couches Physique et Liaison de données d'OSI. OSI est la meilleure référence pour l'enseignement et le dépannage ; TCP/IP est la suite de protocoles réellement mise en œuvre.

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.

Un VPN crée un tunnel chiffré au niveau réseau/OS, de sorte que tout le trafic d'un appareil y est routé et protégé de bout en bout — utilisé pour l'accès distant sécurisé. Un proxy opère au niveau applicatif, relayant le trafic d'applications ou de protocoles spécifiques sans nécessairement le chiffrer. Les grandes différences sont la portée (tout l'appareil vs par application) et le fait qu'un VPN chiffre par conception alors que de nombreux proxys ne le font pas.

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

Un scan de vulnérabilités est un inventaire automatisé, en largeur, des faiblesses potentielles, souvent avec des faux positifs. Un test d'intrusion est mené par un humain : il valide les trouvailles, les enchaîne et démontre un impact métier réel par une exploitation effective.

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

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.

Le chiffrement est réversible : avec la clé, on récupère le texte en clair ; il protège la confidentialité. Le hachage est une fonction à sens unique produisant une empreinte de taille fixe impossible à inverser ; il vérifie l'intégrité et l'identité. Les mots de passe doivent être hachés avec un algorithme lent et salé comme bcrypt ou Argon2, jamais chiffrés.

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.

Le chiffrement symétrique utilise une seule clé partagée pour chiffrer et déchiffrer : c'est rapide, mais la clé doit être partagée de façon sûre. Le chiffrement asymétrique utilise une paire de clés publique/privée, ce qui résout la distribution des clés mais lentement. Les vrais systèmes utilisent la cryptographie asymétrique pour échanger une clé de session symétrique, puis le chiffrement symétrique rapide pour les données en masse.

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 fatigue d'alerte est la désensibilisation qui s'installe lorsque les analystes font face à trop d'alertes peu utiles ou de faux positifs, ce qui les pousse à manquer ou à bâcler les vraies. On la combat en affinant les règles bruyantes, en priorisant par le risque, en dédupliquant et regroupant les alertes liées, en automatisant l'enrichissement répétitif avec un SOAR, et en mesurant la qualité des alertes, pas seulement leur volume.

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.

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.

L'EDR est centré sur l'endpoint : il enregistre et répond à l'activité des processus, fichiers et réseau sur les hôtes. Le XDR étend cette corrélation à plusieurs domaines — endpoint, réseau, identité, e-mail, cloud — en une stack intégrée par un même éditeur. Le SIEM est la couche large d'agrégation de logs qui ingère des données de n'importe quelle source, y compris non liées à la sécurité, pour la détection, la recherche et la conformité.

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.

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.

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

Examinez l'e-mail sans cliquer : vérifiez les en-têtes et l'authentification de l'expéditeur (SPF/DKIM/DMARC), inspectez les URL et pièces jointes en sandbox ou avec des outils de réputation, puis mesurez la portée — qui d'autre l'a reçu, quelqu'un a-t-il cliqué ou saisi des identifiants. Selon les constats, remédiez en purgeant l'e-mail, en bloquant les indicateurs et en réinitialisant les identifiants exposés.

Un SIEM ingère et corrèle les logs de tout le parc pour générer des alertes — c'est votre couche de détection et de recherche. Un SOAR se situe en aval et automatise la réponse : il exécute des playbooks, enrichit les alertes via des intégrations, et gère les cas pour que les analystes passent moins de temps sur les étapes répétitives.

Confirmez que l'alerte est réelle avant d'agir : lisez ce qui s'est déclenché et pourquoi, puis enrichissez — qui est l'utilisateur, l'IP/géo/appareil source sont-ils attendus, est-ce un voyage impossible, y a-t-il eu des échecs antérieurs ? Classez en vrai ou faux positif, escaladez ou confinez si c'est réel (désactiver la session, forcer une réinitialisation MFA), et documentez tout pour que le prochain analyste puisse suivre votre raisonnement.

4624 est un logon réussi, 4625 est un logon échoué, et 4688 est une création de processus. Dans une enquête, vous utilisez 4625 pour repérer les attaques d'identifiants, 4624 (avec son type de logon et sa source) pour confirmer un accès réussi et comment il s'est produit, et 4688 pour voir ce qui a réellement été exécuté, idéalement avec l'audit de ligne de commande activé.