Mes premières règles de détection étaient nulles

L'infra tenait debout et se défendait. Restait la question qui donne du sens au reste : est-ce qu'on saurait qu'il s'est passé quelque chose ?

Deux choses que je confondais

La supervision répond à « est-ce que ça marche ? ». Un service joignable, un disque plein, une latence anormale. C'est Grafana, Loki, Uptime Kuma.

La détection répond à « est-ce que quelqu'un fait quelque chose qu'il ne devrait pas ? ». Une élévation de privilèges, un fichier système modifié, une connexion réussie après vingt échecs. C'est le SIEM, ici Wazuh.

Les deux lisent les mêmes journaux. Un pic de CPU intéresse la supervision. Il intéresse aussi la détection si c'est un mineur de cryptomonnaie.

MITRE ATT&CK

Wazuh pose un agent sur chaque machine. L'agent remonte les journaux, surveille l'intégrité des fichiers, et le serveur applique des règles pour produire des alertes classées par niveau.

Ce qui a changé ma façon de lire un journal, c'est le mapping MITRE ATT&CK. ATT&CK classe les comportements réellement observés chez les attaquants en tactiques, le pourquoi, et en techniques, le comment, avec un identifiant précis.

Concrètement, une alerte ne dit plus seulement qu'un fichier a été modifié dans /etc/cron.d. Elle dit :

« Fichier modifié » est un fait. « Persistance » est une intention. Et si quelqu'un cherche à persister, c'est qu'il a déjà obtenu un accès, donc la question suivante devient évidente : par où est-il entré ?

Ça paraît anodin comme différence. Pour quelqu'un qui débute en détection, ça change tout. On passe d'événements isolés à des étapes dans une progression.

Où je me suis planté

Enthousiaste, j'ai écrit une série de règles personnalisées. Toute connexion SSH réussie déclenchait une alerte. Toute exécution de sudo aussi. Tout démarrage de conteneur également.

Deux jours plus tard : plusieurs centaines d'alertes. Zéro intéressante.

C'est l'erreur classique du débutant, et je l'ai faite en grand. Une alerte qui se déclenche cent fois par jour sur des événements normaux n'est pas une alerte, c'est du bruit qu'on apprend très vite à ignorer. Le jour où la vraie tombe, elle est noyée au milieu.

J'ai tout repris avec une autre question. Pas « quels événements sont sensibles ? » mais « quel événement, s'il se produit, veut dire qu'une de mes hypothèses est fausse ? »

Ce que ça donne :

• ~~une connexion SSH réussie~~ → une connexion SSH réussie depuis une IP hors du VLAN MGMT
• ~~une exécution de sudo~~ → un sudo par un compte de service, qui n'en fait jamais
• ~~un conteneur démarré~~ → un conteneur démarré en mode privilégié, ce qui n'arrive jamais chez nous
• ~~un échec d'authentification~~ → un échec suivi d'une réussite depuis la même source dans la minute

On est passés à quelques alertes par semaine. Chacune méritait qu'on la regarde.

Une bonne règle de détection ne décrit pas un événement technique, elle décrit la violation d'une hypothèse qu'on a posée sur son infrastructure. Et ces hypothèses, on ne pouvait les écrire que parce que la matrice de flux du premier chantier les avait posées noir sur blanc. Les deux sujets ne sont pas séparés du tout.

Loki, et le choix de ne pas indexer

Côté supervision, Promtail collecte, Loki stocke, Grafana affiche.

Le parti pris de Loki m'a d'abord dérouté. Contrairement à Elasticsearch, il n'indexe pas le contenu des lignes, seulement des étiquettes (job, container, level). La recherche plein texte se fait au parcours, sur le sous-ensemble déjà filtré par les étiquettes.

{container="traefik"} |= "401" | json | status >= 400

Pour notre échelle, le compromis est très favorable : beaucoup moins de ressources, ingestion plus simple, en échange de recherches plus lentes sur de longues périodes. En revanche le choix des étiquettes devient structurant. Une étiquette à forte cardinalité, genre une adresse IP, dégrade fortement les performances. Ça se comprend avant, pas après.

Ce que ça a changé chez moi

Avant, je regardais des journaux quand quelque chose cassait. C'est de l'archéologie.

Maintenant je pose la question dans l'autre sens : de quoi est-ce que je voudrais être prévenu, et est-ce que je le verrais aujourd'hui ? Sur mon homelab, la réponse honnête était non. J'y ai installé un agent Wazuh en rentrant, et j'ai trouvé deux conteneurs qui tournaient avec des privilèges dont ils n'avaient aucun besoin.