Détection — voir, et prouver qu'on voit encore¶

La prévention répond à « peut-on entrer ? ». La détection répond à la question suivante, celle qui compte le jour où la première a échoué : quelqu'un est-il entré, et que fait-il ?

Cette page décrit les moteurs de détection du parc, la question à laquelle chacun répond, et surtout la façon dont on s'assure qu'ils détectent encore — parce qu'un détecteur en panne ne produit pas d'erreur : il produit du silence, et le silence ressemble exactement à « rien à signaler ».

Les termes techniques renvoient au glossaire.

Une question, un moteur¶

Le piège d'une panoplie d'outils de sécurité est de la prendre pour une couverture. Dix outils qui répondent à la même question laissent les neuf autres questions sans réponse. Le parc part donc des questions, et attribue à chacune un moteur — un seul.

La question	Le moteur	Hors de sa question
Cette image contient-elle une CVE connue ?	Trivy	Ce que le conteneur fait une fois lancé
Ce code a-t-il un défaut, une dépendance vulnérable, un secret ?	Semgrep, Trivy (dépendances), trufflehog	Le comportement du programme à l'exécution
Cet hôte est-il durci, intègre, à jour ?	Wazuh — SCA, FIM, rootcheck, vulnérabilités	Un comportement anormal, en temps réel
Qu'est-ce qui se lance tout seul sur cette machine ?	osquery (dans Wazuh), KnockKnock sur le poste macOS	—
Ce processus fait-il quelque chose d'anormal ?	Falco (eBPF)	Le trafic réseau
Que transite-t-il sur le réseau ?	Suricata (IDS)	Le contenu d'un flux chiffré de bout en bout
Ce fichier est-il un malware connu ?	ClamAV	Un malware inédit
Qu'y a-t-il dans ce fichier, à tous les niveaux ?	Strelka + YARA	Ce que le fichier ferait si on l'exécutait
Qui attaque le périmètre ?	CrowdSec + blocage communautaire	Ce qui n'est pas du HTTP
Que s'est-il passé sur cette machine ?	Velociraptor — voir Réponse	—

La colonne de droite n'est pas un aveu : c'est ce qui délimite chaque outil. Elle dit où s'arrête sa réponse, donc où commence celle d'un autre.

La règle d'autorité

Trivy fait autorité sur ce qui est construit et versionné. Wazuh fait autorité sur l'état d'un hôte vivant. Falco, Suricata et Velociraptor font autorité sur le comportement et les flux. Aucun ne refait le travail d'un autre ; quand deux moteurs remontent la même observation, on la filtre par identifiant de règle, jamais en éteignant l'un des deux.

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef det fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef hub fill:#0f766e,stroke:#0f766e,color:#fff

    subgraph sources["Ce qu'on observe"]
        img["Images et dépôts"]:::src
        host["Hôtes<br/>fichiers · configuration · paquets"]:::src
        proc["Processus et conteneurs"]:::src
        net["Trafic réseau"]:::src
        file["Fichiers déposés"]:::src
        logs["Journaux du proxy"]:::src
    end

    subgraph moteurs["Les moteurs"]
        trivy["Trivy · Semgrep · trufflehog<br/>scanner de vulnérabilités"]:::det
        wazuh["Wazuh<br/>SIEM · osquery · listes d'IOC"]:::det
        falco["Falco<br/>appels système"]:::det
        suri["Suricata<br/>signatures réseau"]:::det
        av["ClamAV + Strelka<br/>verdict · analyse profonde"]:::det
        cs["CrowdSec<br/>comportement HTTP"]:::det
    end

    tri["Tableau de triage<br/>score · exposition · journal"]:::hub
    hub["Répartiteur d'alertes"]:::hub

    img --> trivy --> tri
    host --> wazuh
    proc --> falco
    net --> suri
    file --> av --> wazuh
    logs --> cs
    wazuh -->|"identifiant de règle"| hub
    falco -.->|"après mesure du bruit"| hub
    suri -.->|"après mesure du bruit"| hub
    cs -->|"403"| logs

Les flèches pointillées ne sont pas un détail de dessin : elles marquent des moteurs qui collectent avant de notifier. La raison est plus bas, dans les principes.

Le SIEM — Wazuh¶

Un SIEM collecte les journaux de tout le parc, les corrèle, et alerte. Ici, c'est Wazuh : un manager, et un agent sur chaque machine — hyperviseur, hôtes de conteneurs, hôte GPU, NAS, serveur hors site et poste de travail. Un hôte hors du LAN parle au manager par le maillage privé, jamais par une adresse locale qui n'existe pas pour lui.

Ce que les agents apportent :

intégrité des fichiers sur les chemins sensibles ;
évaluation de configuration contre les benchmarks CIS ;
recherche de rootkits et de fichiers ou ports cachés ;
vulnérabilités par corrélation entre paquets installés et bases de CVE ;
inventaire du matériel, des paquets et des processus.

osquery, dans le SIEM et pas à côté¶

osquery interroge l'état d'une machine en SQL : services, tâches planifiées, clés SSH autorisées, tout ce qui sert de persistance. Il est branché comme module de Wazuh, pas comme un service séparé : deux inventaires du même parc finissent toujours par diverger, et le jour où ils divergent, personne ne sait lequel croire. Les résultats arrivent dans le même index que le reste, et une sonde vérifie qu'ils arrivent effectivement — un module activé qui n'envoie rien ressemble à un module activé.

Le renseignement sur la menace, consommé¶

Trois listes d'IOC — adresses, domaines, empreintes de fichiers — sont tirées de sources publiques et rafraîchies par une tâche planifiée. Wazuh les consulte au moment où l'événement arrive (listes CDB). La liste des empreintes se nourrit aussi de ce que les moteurs de fichiers du parc ont trouvé : un fichier détecté une fois est reconnu partout ensuite.

Une plateforme de partage de renseignement (du type MISP) a été écartée : elle se justifie quand on produit du renseignement, pas quand on en consomme trois listes. Une sonde surveille la fraîcheur des listes — une liste d'IOC qui a cessé de se mettre à jour ne produit aucune erreur, seulement des détections manquées.

Deux étages d'alerte¶

Des règles nominatives, une par détection qu'on sait vouloir recevoir (un malware trouvé, un canari qui ne répond plus, un conteneur tué faute de mémoire), chacune reliée à son identifiant.
Un seuil général, pour tout ce que les règles nominatives n'ont pas prévu. Il n'est armé qu'après une période de mesure du volume qu'il produirait sur un parc sain.

L'exécution — Falco¶

Le SIEM voit l'état d'un hôte ; il ne voit pas ce qu'un programme est en train de faire. Sans télémétrie des appels système, un attaquant déjà présent dans un conteneur n'est visible que par ce qu'il casse.

Falco comble ce trou sur les hôtes qui font tourner des conteneurs. Les choix de déploiement, chacun avec sa raison :

Choix	Pourquoi
Sonde modern eBPF, pas de module noyau	Rien à compiler, rien qui casse à la prochaine mise à jour du noyau
Paquet système, démarré avant le moteur de conteneurs	Le premier conteneur lancé est déjà observé
Mise à jour automatique des règles depuis Internet désactivée	Les règles changent par le dépôt, relues, jamais en douce
Plafond de processeur et de mémoire	Un outil de sécurité ne doit pas pouvoir coucher l'hôte qu'il protège
Tampon dimensionné pour zéro perte en rafale	Un événement perdu pendant un pic est précisément celui qu'on cherchait

Aux règles stables du projet s'ajoutent des règles maison, écrites pour les gestes d'un attaquant sur ce parc : une écriture dans une tâche planifiée ou dans les clés SSH autorisées, un conteneur qui monte le socket du moteur de conteneurs sans figurer sur la liste nommée de ceux qui en ont le droit, une élévation de privilèges à l'intérieur d'un conteneur.

Les faux positifs — les sondes de santé des bases de données, à elles seules plusieurs dizaines de milliers d'événements par jour — sont traités par des exceptions nommées, une par cas, jamais en désactivant une règle.

Une règle peut se charger sans erreur et ne plus jamais correspondre

Une montée de version peut changer le sens d'un champ qu'une règle utilise. La règle se charge, aucune erreur n'apparaît au démarrage, et elle ne se déclenchera plus jamais. Relire la configuration n'y voit rien : elle est correcte, pour la version précédente.

D'où le témoin : une sonde lance un conteneur jetable, y ouvre un shell interactif et y lit un fichier sensible, puis vérifie que les deux gestes ont été vus, sur chaque hôte. Sa vérification inverse a consisté à désactiver une règle, et à voir la sonde passer au rouge.

Le réseau — Suricata¶

Suricata applique des signatures d'attaques connues au trafic qui passe devant lui. Sa sortie, en JSON, part vers le moteur de recherche des journaux.

Un IDS ne voit que ce qui passe devant lui : son placement est donc la vraie décision. Un réseau maillé domestique n'offre pas de port miroir sur lequel écouter ; le point retenu est celui où le trafic converge — un pont réseau virtuel voit à la fois les échanges entre machines et leurs sorties vers Internet, sans équipement de plus.

Comme Falco, il collecte avant de notifier, et son témoin est une signature de test déclenchée volontairement depuis une machine, puis retrouvée dans les alertes.

Les fichiers — deux moteurs, deux questions¶

L'architecture de la chaîne antivirus — un moteur central, un miroir de signatures, le client qui journalise — est décrite dans la note d'architecture. Ici, la question est celle des témoins.

ClamAV répond à « est-ce un malware connu ? ». Le service de partage de fichiers refuse le dépôt d'un fichier détecté.
Strelka répond à « qu'y a-t-il là-dedans, à tous les niveaux ? » : il déplie récursivement archives, documents et objets embarqués, et passe des dizaines de scanners sur chaque morceau, dont plusieurs milliers de règles YARA publiques. Il analyse chaque nuit une sélection de chemins choisis.

Le pire mode de panne du parc — et pourquoi un compteur ne l'attrape pas

YARA compile son répertoire de règles en un seul bloc. Un seul fichier de règles invalide fait tomber tout le jeu : le conteneur reste en bonne santé, les analyses continuent, et plus rien n'est détecté.

Un compteur de règles chargées semble suffire. Il ne suffit pas : il dit combien de règles sont en mémoire, pas si elles reconnaissent encore quelque chose. Le témoin retenu est une règle canari : une règle maison, placée dans le même répertoire que les autres, réinjectée à chaque rafraîchissement, et un fichier conçu pour la déclencher. Une sonde soumet ce fichier et exige une détection. Si le jeu ne compile plus, le canari tombe avec lui — c'est exactement ce qu'on veut.

Vérification inverse : un fichier de règles volontairement cassé a fait partir une alerte critique, puis le retour à la normale.

Pour ClamAV, le témoin est le fichier EICAR, soumis chaque jour.

Une vérification inverse doit casser ce qu'elle prétend tester

Pour éprouver le témoin EICAR, la première idée est d'ignorer la signature de test. Elle ne casse rien : le moteur reconnaît le même fichier sous un second nom de signature, qui prend le relais, et le témoin reste vert. Une vérification inverse qui ne fait pas échouer le témoin ne prouve pas que le témoin marche — elle prouve seulement qu'on n'a pas su le faire échouer.

Ce qui a été écarté, et pourquoi.

Un bac à sable dynamique : le volume de fichiers ne le justifie pas, et il ajouterait une machine lourde, exposée par construction à du code hostile. La question se rouvrira le jour où un échantillon réel passera les deux moteurs.
Un troisième moteur à règles YARA : il lirait le même corpus de règles publiques. Un second outil qui lit les mêmes règles n'est pas un second avis.

Le périmètre — CrowdSec¶

CrowdSec lit les journaux du proxy interne, reconnaît les comportements hostiles (balayage, force brute, exploitation connue), et fait appliquer sa décision par un module intégré au proxy, qui répond 403. Il consomme aussi une liste de blocage communautaire, alimentée par l'ensemble des installations qui la partagent.

Pourquoi en couche applicative plutôt qu'au pare-feu : voir la note d'architecture. Son témoin vérifie que le module applique réellement une décision, pas seulement qu'il est chargé.

Les vulnérabilités — le scanner et ses axes¶

Un scanner de vulnérabilités maison agrège plusieurs outils et, surtout, trie :

Axe	Outil	Ce qu'il apporte
Images en service, sur chaque hôte de conteneurs	Trivy	CVE connues, chaque jour
Dépôts de code	Trivy (dépendances, IaC) + Semgrep (SAST)	Défauts et dépendances vulnérables avant le déploiement
Secrets restés sur les hôtes	trufflehog	Sévérité portée par les permissions du fichier : un secret lisible par tous est plus grave que le même secret réservé à son service
Actionnabilité	comparaison avec l'image amont	Une correction existe-t-elle déjà ?
Exposition	configuration du proxy	Public, derrière le fournisseur d'identité, ou interne
Exploitation	EPSS + KEV	Probable, ou déjà constatée ailleurs

Le score croise sévérité, exploitation et exposition : une CVE critique sur un service interne passe après une CVE moyenne, déjà exploitée, sur un service public. Chaque décision de triage est inscrite avec son auteur.

OpenCVE complète le tableau pour ce qui n'est pas une image de conteneur — le système de l'hyperviseur, celui du NAS : il croise les CVE publiées avec l'inventaire versionné des composants du parc.

Deux compléments :

Un SBOM par image en service, régénéré chaque semaine. Quand une nouvelle vulnérabilité est publiée, la question « sommes-nous touchés ? » se tranche dans l'inventaire, pas en relançant un scan.
Le délai de correction est lui-même un contrôle. Scanner sans mesurer le temps de correction, c'est produire une liste qui grandit. Voir Conformité.

Le durcissement, et le second avis¶

L'évaluation de configuration du SIEM tourne en continu. Un second outil (Lynis) a été passé ponctuellement, pour comparer. Là où les deux se contredisaient — un module de confinement déclaré inactif par l'un, actif par l'autre — la question a été tranchée par un témoin fonctionnel : tenter l'action que le module doit interdire, et constater le refus. Le contrôle automatique se trompait.

Les chasseurs de rootkits dédiés n'ont pas été ajoutés : ils refont ce que fait déjà le module du SIEM, et produisent sur des hôtes à conteneurs un bruit qui noierait le reste.

Ce que ces choix ont en commun¶

1. Des témoins fonctionnels, pas des compteurs. « Le service est en vie », « 5 000 règles chargées », « l'agent est connecté » : ce sont des compteurs, et un détecteur peut les satisfaire tous en ne détectant plus rien. Un témoin injecte un cas connu et exige qu'il soit vu. Chaque moteur de cette page en a un.

2. Mesurer le bruit avant d'armer une alerte. Un nouveau détecteur tourne d'abord en collecte seule, avec une date d'armement fixée d'avance. Une notification armée sans mesure préalable mesure la cadence de l'instrument, pas l'état du parc — et une alerte qui tombe toutes les heures dès le premier jour est filtrée par l'œil avant la fin de la semaine.

3. Filtrer par identifiant de règle, jamais par groupe. Un groupe embarque des règles voisines qu'on n'a pas lues. Un filtre par groupe poste des doublons ; une réponse automatique par groupe agirait sur des détections qu'on n'a jamais choisies.

4. Une exception se nomme. Un faux positif se traite par une exception précise, rattachée à son cas. Désactiver une règle en bloc supprime aussi toutes les vraies détections qu'elle aurait faites.

5. Un moteur par question. Ajouter un outil se justifie par une question sans réponse, pas par la réputation de l'outil.