Biais cognitifs en investigation de sécurité

Biais cognitifs en investigation de sécurité

Une investigation échoue rarement parce qu’il manque un outil. Elle échoue parce qu’une hypothèse séduisante devient une vérité avant d’avoir rencontré une preuve contradictoire. Les biais cognitifs transforment alors des journaux exacts en récit faux, avec une confiance remarquable et des captures d’écran parfaitement décoratives.

Explication de la marmotte

Une enquête ressemble à une recherche d’objet perdu : dès qu’une personne pense savoir où regarder, elle risque de ne plus voir ce qui contredit son idée. Repérer ce réflexe permet de vérifier les faits avant de décider qu’une histoire est la bonne.

→ Lire l’explication complète de la marmotte

Biais de confirmation et hypothèse unique

Le biais de confirmation consiste à privilégier les éléments qui soutiennent une hypothèse initiale et à minimiser ceux qui la contredisent. En investigation, l’alerte initiale devient souvent cette hypothèse : une connexion depuis une adresse IP géolocalisée dans un pays inattendu devient immédiatement une compromission, alors qu’elle peut provenir d’un relais d’accès distant, d’un fournisseur cloud ou d’une sortie réseau mal documentée.

Le problème n’est pas d’avoir une hypothèse. Une investigation sans hypothèse produit une collecte infinie, donc une crise transformée en brocante numérique. Le problème est de ne conserver qu’une hypothèse active.

La règle opérationnelle est stricte : toute conclusion intermédiaire doit être accompagnée d’au moins une explication concurrente et d’un fait qui permettrait de la réfuter. Une hypothèse qui ne peut pas être réfutée n’est pas une piste d’investigation, c’est un sentiment avec un tableau de bord.

Pour une alerte d’authentification suspecte, les hypothèses minimales sont souvent :

1. compromission d’identifiant ou de session ;
2. comportement légitime non référencé ;
3. erreur de corrélation entre deux événements ;
4. artefact généré par un équipement intermédiaire ;
5. altération ou perte partielle des journaux.

La collecte doit chercher des éléments discriminants. Pour distinguer une compromission d’un accès légitime, l’adresse IP ne suffit pas. Il faut comparer le terminal, le mode d’authentification, la durée de session, les ressources consultées, les échecs précédents, les changements de privilèges et les actions réalisées après connexion.

Les pages sur les identités et les mécanismes de NTLM, NT LAN Manager rappellent une contrainte souvent oubliée : une authentification valide prouve qu’un mécanisme a accepté une preuve, pas que la personne attendue était derrière le clavier.

Ancrage, disponibilité et récit prématuré

Le biais d’ancrage donne un poids disproportionné à la première information reçue. Une étiquette de sévérité élevée, un nom de groupe connu dans un rapport de renseignement ou un fichier nommé mimikatz.exe suffisent à orienter toute l’analyse. L’attaquant n’a même pas besoin d’être créatif : il suffit parfois de nommer un binaire pour que l’enquête parte courir après un fantôme célèbre.

Le biais de disponibilité fonctionne autrement. Les incidents récents, médiatisés ou douloureux semblent plus probables que les scénarios banals. Après une campagne d’hameçonnage, toute création de règle de messagerie paraît malveillante. Après un incident de rançongiciel, tout script PowerShell devient un prélude à l’apocalypse. Or PowerShell est aussi utilisé par des outils d’administration, ce qui est moins spectaculaire mais statistiquement encombrant.

Ces biais se corrigent par une chronologie construite avant l’interprétation. Chaque événement doit être enregistré avec :

• son horodatage source ;
• son horodatage de collecte ;
• le fuseau horaire déclaré ;
• la source qui l’a produit ;
• l’identifiant corrélé ;
• la précision connue de l’horloge ;
• la transformation appliquée lors de l’ingestion.

Une chronologie sans qualité temporelle est un roman. Un écart de cinq minutes entre un contrôleur de domaine et une sonde réseau peut inverser une relation de cause à effet. Le protocole NTP (Network Time Protocol) doit être supervisé sur les systèmes qui produisent des preuves, pas seulement sur les serveurs qui font joli dans l’inventaire.

L’ancrage se réduit aussi par une séparation explicite entre trois catégories :

• fait observé : un événement signé ou un journal brut établit qu’une action a été enregistrée ;
• inférence : plusieurs faits rendent une action probable ;
• attribution : une identité, un groupe ou une intention est associée à cette action.

Mélanger ces catégories détruit la valeur du rapport. Dire « l’attaquant a exfiltré des données » alors que les journaux montrent un transfert sortant inhabituel est une conclusion excessive. La formulation correcte décrit le transfert, son volume, sa destination, les données accessibles et les preuves manquantes. Le reste doit rester conditionnel.

Biais d’automatisation et confiance dans les outils

Le biais d’automatisation apparaît lorsqu’une décision produite par un outil est traitée comme une preuve. Un système de détection et de réponse sur les terminaux, ou EDR (Endpoint Detection and Response), peut corréler une exécution, une connexion réseau et une élévation de privilèges. Cette corrélation accélère le triage. Elle ne remplace ni la validation des données sources ni la compréhension de la règle.

Chaque détection repose sur des hypothèses : couverture des agents, intégrité de la télémétrie, synchronisation des horloges, règles à jour, identifiants stables et absence de contournement. Une machine non supervisée ne devient pas visible parce qu’un tableau de bord affiche 98 % de couverture. Les pourcentages sont très sociables avec les comités, beaucoup moins avec les angles morts.

Le compromis central est net : automatiser réduit le délai de détection et augmente le volume de décisions à accepter sans lecture complète. Exiger une validation humaine de tout détruit la capacité de réponse. Accepter les verdicts automatiques sans contrôle transforme une erreur de configuration en incident certifié conforme.

La recommandation est d’automatiser les actions réversibles et de réserver les actions destructrices ou coûteuses à une validation fondée sur plusieurs sources indépendantes. Isoler un poste peut être automatisé si une procédure garantit l’accès de secours. Révoquer un compte d’administration, purger une messagerie ou arrêter une charge critique exige une confirmation de contexte.

Les règles de détection doivent conserver leur version, leurs sources, leur propriétaire et leurs cas de test. Une alerte sans règle versionnée ne peut pas être auditée. Une règle corrigée après incident sans conserver la version précédente efface la capacité à expliquer pourquoi l’alerte a existé ou pourquoi elle a manqué.

Biais de coût irrécupérable et arrêt de piste

Le biais de coût irrécupérable pousse à poursuivre une piste parce qu’elle a déjà consommé du temps. Dans une investigation, cela se traduit par des heures consacrées à décoder un fichier, suivre une adresse IP ou reconstruire un processus, alors que les éléments disponibles ne relient plus cette piste à l’impact métier.

Une piste doit avoir une condition d’arrêt définie au moment de son ouverture. Cette condition peut être temporelle, technique ou probatoire : absence de nouvel événement corrélé, absence d’accès à une ressource sensible, artefact identifié comme légitime, ou impossibilité documentée d’obtenir une donnée manquante.

Abandonner une piste n’est pas conclure qu’elle était fausse. C’est conclure que les preuves disponibles ne justifient plus son coût. Cette nuance protège contre deux erreurs opposées : déclarer trop vite un faux positif, ou consacrer l’incident entier à une hypothèse devenue orpheline.

Le registre de décision doit enregistrer l’heure, la piste, les éléments examinés, la décision, le niveau de confiance et le motif d’arrêt. Ce registre sert à la revue croisée, à la reprise après changement d’astreinte et à l’analyse post-incident. Sans lui, chaque rotation recommence à croire qu’elle est la première à découvrir le dossier. L’humanité a inventé les journaux, puis les a cachés dans des espaces de discussion éphémères. Performance artistique.

Exemple : séparer observation et interprétation

L’exemple suivant part d’événements fictifs et compte les connexions réussies par compte et par adresse IP. Il ne démontre pas une compromission. Il démontre seulement une observation vérifiable : plusieurs connexions réussies existent pour une combinaison donnée.

Après ce décompte, l’investigation doit rechercher les données qui pourraient invalider l’interprétation hâtive : propriété de l’adresse IP, inventaire du concentrateur d’accès distant, type de facteur d’authentification, terminal associé, changement de privilèges et activité après session. Une requête ne produit jamais une intention humaine. Même avec un thème sombre et un graphique hexagonal.

Intégrité des preuves et attaques contre l’analyse

Les biais ne viennent pas uniquement de l’analyste. Un adversaire peut les exploiter en injectant du bruit, en utilisant des noms d’outils connus, en déclenchant des alertes concurrentes ou en modifiant des horloges. Une investigation doit donc protéger ses propres sources.

Les journaux bruts doivent être exportés vers un stockage à rétention contrôlée, avec contrôle d’accès séparé de l’administration courante. Un stockage WORM (Write Once Read Many) empêche la réécriture d’un objet conservé, mais ne garantit ni que l’événement initial était exact, ni que toutes les sources sont présentes. La protection doit commencer sur l’équipement producteur : journalisation activée, accès administrateur tracé, synchronisation horaire, capacité disque surveillée et transfert chiffré.

Les empreintes cryptographiques peuvent détecter une modification après collecte. Une empreinte SHA-256 (Secure Hash Algorithm 256 bits) relie un export à son contenu exact, à condition de conserver cette empreinte dans un système distinct de la donnée. Stocker le fichier et son empreinte dans le même emplacement administré par le même compte revient à coller un scellé sur une boîte dont la clé est posée dessus.

Aucune chaîne de conservation ne garantit l’exhaustivité. Un journal absent peut résulter d’une désactivation, d’une saturation, d’une erreur de collecte, d’une rétention expirée ou d’un contournement adverse. Le rapport doit déclarer ces limites, ainsi que les systèmes non couverts. La gouvernance des sources de preuve doit définir qui peut modifier la journalisation, qui valide les exceptions et combien de temps les données restent récupérables.

Conditions d’exploitation d’une investigation défendable

Une méthode anti-biais nécessite une plateforme minimale avant l’incident :

• inventaire des sources de journalisation et de leurs propriétaires ;
• horloge synchronisée et surveillée ;
• rétention alignée sur le temps maximal de détection ;
• comptes d’investigation séparés des comptes d’administration ;
• procédure de collecte préservant les données originales ;
• accès aux configurations, aux identités et aux flux réseau ;
• capacité de revue par un second analyste pour les décisions à fort impact.

Les secrets d’accès aux journaux, aux interfaces d’administration et aux exports doivent être stockés dans un gestionnaire de secrets, limités par rôle et journalisés. Une clé d’accès partagée entre l’équipe d’investigation et l’exploitation empêche d’établir qui a consulté ou modifié une source. La rotation doit préserver une période de recouvrement documentée : révoquer brutalement un accès de collecte peut créer exactement le trou de visibilité qu’une investigation cherchait à éviter.

Les sauvegardes des journaux et des configurations de collecte doivent être testées par restauration. Une sauvegarde jamais relue est une croyance, pas une capacité de reprise. La restauration doit vérifier les droits, les horodatages, les empreintes et la possibilité de rejouer les requêtes d’investigation.

🐝 Ce qui arrive si on s’en passe

Sans séparation entre fait, inférence et attribution, ce qui entre dans la ruche est une remédiation dirigée contre le mauvais point d’entrée : le compte cité dans le rapport est réinitialisé, le vecteur réel reste actif, et la réinfection survient après restauration puisque l’éradication n’a jamais touché la cause. Les conséquences dépassent la technique : une notification réglementaire fondée sur une exfiltration supposée engage des déclarations qu’aucune preuve ne soutient, et une attribution publiée sans élément discriminant devient indéfendable dès qu’un tiers rejoue les mêmes journaux. Sans condition d’arrêt ni registre de décision, les pistes closes sont rouvertes à chaque rotation, le temps d’investigation croît sans réduire l’incertitude, et les alertes récurrentes finissent traitées par réflexe : la détection continue de fonctionner, plus personne ne la lit.

🦫 Explication de la marmotte 🍫

Pendant une enquête de sécurité, une personne examine des traces laissées par des ordinateurs : connexions, fichiers ouverts, actions réalisées et échanges sur le réseau. Le risque principal est de choisir trop tôt une explication, puis de ne retenir que les informations qui la confirment. Une alerte n’est donc pas une preuve complète. Elle indique où commencer à chercher.

Pour éviter cette erreur, chaque piste doit être formulée comme une possibilité qui peut être démentie. Les faits observés sont séparés des suppositions et des accusations. Une heure, une adresse réseau ou un nom de fichier ne suffisent pas à identifier une personne responsable. Il faut comparer plusieurs sources et vérifier si leurs dates, leurs identifiants et leurs informations concordent.

Les logiciels d’analyse aident à trier beaucoup de données, mais ils peuvent se tromper si leurs règles sont mal réglées ou si des informations manquent. Les actions faciles à annuler peuvent être lancées automatiquement. Les actions qui coupent un accès, effacent des données ou arrêtent un service demandent une vérification supplémentaire.

Les traces doivent être conservées sans modification, avec des accès limités et des sauvegardes testées. Si une trace manque, il faut le signaler au lieu d’inventer ce qu’elle aurait montré. Une enquête défendable explique ce qui est établi, ce qui reste probable et ce qui ne peut pas être démontré.

À lire aussi

• Culture juste après un incident de sécuritéMettre en œuvre une culture juste après un incident de sécurité sans dissoudre la responsabilité ni détruire le signal de terrain.
• Comment dire non en comité de sécurité sans perdre sa crédibilitéDire non en comité de sécurité exige une décision traçable, fondée sur un risque mesuré et assortie d'une voie de sortie exploitable.
• Ce qui n’est pas écrit n’a pas été décidéDocumenter le doute plutôt que le subir : un registre de décisions et d’exceptions de sécurité qui fait porter les objections sur le mécanisme, pas sur la personne.
• Pourquoi un analyste SOC rate une alerte critiqueCharge cognitive en SOC : comprendre pourquoi une alerte critique échappe à l’analyste et comment concevoir une détection exploitable.

Pages voisines

La citent

• Gérer un désaccord technique sans bloquer un projet
• AI Act : contrôle humain d'une IA à haut risque (article 14)
• Evals LLM comment mesurer qu'un assistant IA répond juste

Biais cognitifs en investigation de sécurité

Elle cite

• Comment attribuer techniquement une cyberattaque
• EDR : fonctionnement, angles morts et contournements
• NTLM : protocole authentification LAN Manager New Technology Microsoft
• Reconstruire une timeline d'attaque après incident