Chapitre 15.2 — Détection, monitoring & alerting

⏱️ TL;DR — Des logs (chapitre 15.1) ne servent que si on les exploite. La détection transforme les logs en signaux : pics d’échecs de login (bruteforce/stuffing), rafales de 403 en changeant des ids (IDOR tenté), dépassements de rate limit, salves de payloads d’injection, connexions depuis des lieux/horaires anormaux, exfiltration (volume de données sortant inhabituel). Le monitoring surveille en continu (logs centralisés, métriques, uptime, erreurs), et l’alerting te prévient à temps — l’enjeu étant d’alerter sur ce qui compte sans noyer sous le bruit (fatigue d’alerte). L’objectif : réduire le temps de détection, qui décide de la gravité d’un incident.

🎯 Objectifs

• Transformer les logs en signaux de détection (motifs d’attaque, anomalies).
• Mettre en place un monitoring continu (logs centralisés, métriques, erreurs).
• Configurer l’alerting utile et éviter la fatigue d’alerte.
• Comprendre pourquoi le temps de détection est un facteur clé de gravité.

Des logs aux signaux

Journaliser ne détecte rien en soi : il faut analyser les logs pour en tirer des signaux d’attaque. Quelques signaux classiques, directement issus des événements du chapitre 15.1 :

La détection consiste à rechercher ces motifs dans les logs — par des règles (seuils : « N échecs en M minutes »), de la corrélation (relier des événements à travers services via le requestId), et parfois des approches par anomalie (écart au comportement normal). On n’a pas besoin d’un SIEM sophistiqué pour commencer : des requêtes/règles sur des logs centralisés couvrent déjà beaucoup.

Monitoring : surveiller en continu

Le monitoring (cours Serveur Linux) rassemble et surveille en continu :

• Logs centralisés : agréger les logs de tous les services en un endroit requêtable (c’est ce qui permet la détection). Des solutions vont du simple (logs centralisés + requêtes) au SIEM (corrélation avancée).
• Métriques : CPU, mémoire, trafic, taux d’erreurs, latence — des anomalies (pic de 500, de trafic, de CPU) peuvent signaler une attaque (DoS, exploitation).
• Disponibilité (uptime) et santé des services.
• Supervision applicative des erreurs (ex. Sentry) : les erreurs peuvent trahir des tentatives d’exploitation.

Le but : ne pas être aveugle. Une intrusion qui provoque des erreurs, un pic de trafic, un volume sortant anormal doit se voir sur un tableau de bord.

Alerting : être prévenu à temps (sans se noyer)

Détecter ne sert à rien si personne ne réagit à temps. L’alerting notifie les bonnes personnes quand un signal significatif apparaît. Le défi est le dosage :

• Alerter sur ce qui compte : les signaux à fort indice d’attaque (pic d’échecs de login, exfiltration probable, violations en masse), routés vers le bon canal (astreinte pour le critique).
• Éviter la fatigue d’alerte : trop d’alertes (ou trop de faux positifs) → on les ignore, et la vraie alerte passe inaperçue. Mieux vaut peu d’alertes pertinentes que beaucoup de bruit. On règle les seuils, on regroupe, on priorise.
• Rendre l’alerte actionnable : une alerte doit dire quoi regarder et quoi faire (pas juste « anomalie »).

⚠️ Piège — La fatigue d’alerte est aussi dangereuse que l’absence d’alerte. Une équipe noyée sous des centaines de notifications (dont 99 % de bruit) finit par toutes les ignorer — et le jour où l’alerte critique tombe, elle se perd dans le flux. Un système qui « alerte sur tout » n’alerte, en pratique, sur rien. Vise la pertinence : moins d’alertes, mieux ciblées, actionnables, avec des seuils réglés et priorisés. Une alerte doit être un signal, pas un bruit de fond.

Le temps de détection décide de la gravité

Le message central : ce qui distingue un incident maîtrisé d’une catastrophe, c’est souvent le temps de détection (et de réponse). Une intrusion repérée en minutes (grâce à une bonne détection/alerting) est contenue avant de faire des dégâts ; la même intrusion découverte des mois plus tard (par un tiers, parce qu’on ne surveillait rien) a eu tout le temps d’exfiltrer, de pivoter, de persister. Investir dans la détection, c’est réduire la fenêtre pendant laquelle un attaquant agit sans être vu.

💡 Réflexe — Pour chaque défense mise en place dans le cours, demande-toi : « et si elle échoue, le verrai-je ? ». Une protection anti-bruteforce plus une alerte sur les pics d’échecs ; une CSP plus un suivi des violations ; un rate limiting plus une alerte sur les dépassements massifs. La détection est le filet du filet : elle rattrape ce qui a franchi les défenses préventives, à condition d’être branchée sur des signaux pertinents et de réveiller quelqu’un à temps.

🎯 Côté attaquant — L’attaquant mise sur la lenteur de détection : il agit bas et lent (bruteforce sous les seuils, exfiltration progressive), efface ses traces (chapitre 15.1), et compte sur l’absence de monitoring ou la fatigue d’alerte de la victime (ses actions se noient dans le bruit). Plus ton temps de détection est long, plus il exfiltre, pivote et persiste (backdoors) tranquillement. Une détection réactive et un alerting pertinent cassent son avantage : dès que son activité génère un signal (pic d’échecs, 403 en série, volume sortant), quelqu’un est prévenu et l’horloge tourne contre lui.

🧭 Sur FormaCampus — FormaCampus centralise ses logs (chapitre 15.1) dans un système requêtable et y applique des règles de détection : pics d’échecs de login (par IP et par compte → bruteforce/stuffing), rafales de 403 en changeant des ids (IDOR tenté), salves de payloads d’injection, dépassements de rate limit en masse, connexions depuis des lieux inhabituels, et volume sortant anormal (exfiltration). Le monitoring (métriques, erreurs via Sentry, uptime) complète. L’alerting est dosé : seules les alertes à fort indice partent vers l’astreinte (le reste alimente des tableaux de bord), avec des seuils réglés pour éviter la fatigue. L’objectif affiché : un temps de détection court, pour contenir un incident avant qu’il ne devienne une violation de données majeure (chapitre 15.3).

✏️ Exercices

Exercice 1 — Conçois une détection. À partir des logs, comment détecter (a) un bruteforce ciblé sur un compte, et (b) une tentative d’IDOR ? Décris le signal et le seuil.

Exercice 2 — Faux positifs. Une équipe reçoit 500 alertes/jour, presque toutes bénignes, et a fini par les ignorer. Un vrai incident est passé inaperçu. Que faire ?

🧠 Quiz de révision

Chapitre suivant : Réponse à incident & notification — quand la détection sonne : contenir, éradiquer, rétablir, apprendre, et notifier une violation de données (RGPD).