← Blog Opérations SOC

FIM avec Wazuh : surveiller les changements qui méritent une enquête

Concevez une surveillance FIM Wazuh ciblée : chemins critiques, contexte utilisateur, changements attendus et protection des contenus.

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Surveiller chaque fichier accessible semble rassurant. En pratique, une surveillance utile commence par une question plus précise : quel changement pourrait modifier la sécurité ou le fonctionnement d’un service, et qui devra l’expliquer ?

Les capacités confirmées

La documentation Wazuh décrit le suivi des créations, modifications et suppressions de fichiers. La fonction « who-data » peut apporter le contexte utilisateur et processus.

L’option de remontée des changements de contenu implique, elle, des copies locales et l’envoi d’informations supplémentaires. Source : documentation FIM Wazuh.

La méthode proposée par Seculogik

Établissez un périmètre à partir des fonctions du système : configuration d’un service exposé, paramètres d’authentification, scripts d’administration ou fichiers qui pilotent un traitement critique. Associez chaque chemin à un propriétaire et à une raison de surveillance.

Définissez ensuite ce qui constitue un changement attendu. Une maintenance peut expliquer une modification, mais elle ne justifie pas automatiquement toute activité pendant la même fenêtre. Vérifiez la correspondance entre le fichier concerné, l’opérateur, le processus et le changement approuvé.

Pour le triage, construisez une fiche courte : chemin, type de modification, heure, machine, informations d’auteur disponibles, contexte de maintenance et effet potentiel. Si l’identité manque, conservez cette incertitude au lieu de la remplacer par une supposition.

Ne pas collecter le contenu par réflexe

Une différence textuelle peut faciliter l’enquête. Elle peut également révéler un secret ou une information métier. Décidez donc fichier par fichier si une empreinte, des métadonnées ou le contenu modifié répondent réellement au besoin.

Les droits d’accès, la rétention et les emplacements de stockage doivent suivre ce choix. Une option techniquement disponible n’est pas une autorisation générale de copier des données sensibles dans le SOC.

Tester avant d’élargir

Sur un environnement adapté, réalisez des changements bénins représentatifs : modification autorisée, création, suppression et intervention par un autre compte de test. Vérifiez les informations réellement remontées, puis mesurez le bruit généré par l’activité normale.

Le mode de surveillance et les prérequis dépendent du système et de la version déployée. Utilisez la documentation correspondant à votre installation plutôt qu’un exemple trouvé hors contexte.

Votre première réussite peut rester modeste : quelques chemins critiques, des événements compréhensibles et une procédure d’escalade claire. Ce périmètre maîtrisé sera plus facile à étendre qu’une collecte massive dont personne ne sait expliquer les alertes.

Sources