Détecter, c’est parier : un SIEM qui alerte sur tout finit par ne plus alerter sur rien, noyé sous son propre bruit, et un SIEM trop silencieux rate l’essentiel en donnant un faux sentiment de calme. La théorie de la détection le dit clairement, même si personne ne l’affiche en salle SOC : sous un certain taux de base, même un excellent détecteur produit surtout des fausses alertes, et le vrai travail consiste à calibrer les seuils plutôt qu’à empiler les règles.
La donnée de sécurité, avant d’être analysée, doit d’abord être collectée, normalisée, rendue comparable entre les sources, et ce travail d’ingénierie coûte souvent plus cher que les outils qui l’exploitent ensuite. Le machine learning appliqué à la sécurité promet de trouver ce que les règles ratent ; en pratique, il échoue de façon assez classique, sur des données d’entraînement biaisées ou des menaces qui évoluent plus vite que le modèle.
Répondre à un incident, c’est une autre discipline : la forensics qui reconstruit ce qui s’est passé, la chaîne de conservation qui garantit qu’une preuve reste une preuve, le confinement qui doit stopper l’hémorragie sans détruire ce qu’on a besoin de comprendre après coup. Et la crise qui suit, souvent négligée, mérite le même sérieux : communiquer sans mentir, faire un retex sans chercher un coupable, parce qu’une analyse qui s’arrête à « une personne a cliqué » n’explique jamais rien de systémique.
De l’autre côté, il y a l’attaquant : son économie, ses courtiers d’accès qui revendent une porte d’entrée sans jamais l’utiliser eux-mêmes, un marché des exploits qui fixe un prix précis à chaque zero-day. Comprendre cette économie éclaire la détection bien mieux qu’une signature de plus.
Une organisation qui néglige détection et réponse n’échappe pas aux incidents : elle les apprend par un tiers, client, partenaire ou autorité. Entre l’intrusion et sa découverte, l’accès a eu le temps d’être revendu, parfois plusieurs fois, et chaque acheteur a pu installer sa propre porte de retour. Sans journaux conservés ni preuves préservées, impossible ensuite de dire ce qui est sorti, depuis quand, ni si le nettoyage est complet ; le confinement se fait à l’aveugle en éteignant large, et la reprise s’accompagne d’une question que personne ne sait trancher : l’attaquant est-il encore là ?
La détection commence par la collecte. Chaque machine et chaque logiciel produit des journaux, c’est-à-dire des lignes qui enregistrent ce qui s’est passé. Il faut les rassembler, les mettre dans un format commun et les rendre comparables entre sources, ce qui demande souvent plus d’efforts que les outils d’analyse. Un logiciel central, appelé SIEM, applique ensuite des règles et lève des alertes. Tout le problème est le réglage : quand les vraies attaques sont rares, même un très bon détecteur produit surtout de fausses alertes, et trop d’alertes finissent ignorées ; trop peu laissent passer l’essentiel. L’apprentissage automatique promet de repérer ce que les règles ratent, mais il échoue quand ses données d’entraînement sont biaisées ou quand les attaques changent plus vite que lui. Quand un incident survient, l’analyse technique reconstitue ce qui s’est passé. La chaîne de conservation note qui a manipulé chaque preuve et quand, pour qu’elle reste valable. Le confinement stoppe l’attaque sans détruire les traces nécessaires à la compréhension. La gestion de crise impose de communiquer honnêtement, puis de tirer les leçons sans chercher un coupable, car accuser une personne n’explique pas la faiblesse du système. Enfin, les attaquants forment une économie : certains vendent des accès sans les utiliser, et un marché fixe un prix aux failles encore inconnues des éditeurs.