Ce contenu est une ébauche et ne sera pas inclus dans la version de production.

Menaces, détection & réponse

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.