Surveillance de l'Intégrité des Fichiers

La surveillance de l'intégrité des fichiers répond à une question : un fichier qui ne devait pas changer a-t-il été modifié ? Le contrôle enregistre un état de confiance de fichiers, dossiers et paramètres choisis, puis signale chaque écart ultérieur avec l'heure et le compte responsable. Sa valeur tient moins à la détection elle-même qu'au fait qu'un changement inexpliqué devient une trace que quelqu'un doit clore, au lieu d'une modification silencieuse que personne ne remarque.

Le FIM s'appuie sur la vérification de l'intégrité des fichiers, c'est-à-dire l'acte de vérification lui-même. La différence tient à la continuité : une vérification ponctuelle répond une fois à la question, alors que le FIM la pose sans cesse et conserve l'historique de chaque réponse. Cet historique sert à l'enquêteur lorsqu'un fichier de configuration a été modifié des semaines avant que quelqu'un s'en aperçoive.

Chaque chemin surveillé suit la même boucle. Une référence de hachages et d'attributs est établie à partir d'un état connu comme sain. Chaque événement ultérieur est comparé à cette référence, si bien que l'alerte reflète ce qui diffère réellement et indique le fichier, la modification, le compte et l'heure. La qualité du contrôle dépend surtout de la référence et de la rigueur du responsable des alertes, et non du moteur de détection.

La comparaison programmée revérifie la référence à intervalles fixes et signale les écarts. Elle est peu coûteuse et facile à auditer, mais une modification faite juste après un balayage reste cachée jusqu'au suivant. La surveillance en temps réel réagit aux écritures, déplacements et suppressions au moment où ils surviennent, c'est pourquoi un SOC la veut en général pour les binaires système, les scripts de démarrage et les règles d'accès.

Le mode temps réel coûte davantage. Il exige un agent sur l'hôte, produit plus d'événements et demande un réglage dès le premier jour. Beaucoup d'équipes combinent les deux : le temps réel pour les quelques chemins les plus critiques, la comparaison programmée pour le reste du parc, afin qu'un événement manqué par l'agent soit repéré lors du passage complet suivant. Pour la pratique plus large, voir la surveillance continue.

Une alerte de fichier modifié, prise isolément, est pauvre. Elle indique qu'un chemin diffère de la référence, mais rien sur l'intention. Le FIM prend de la valeur lorsque l'alerte rejoint le même flux que tous les autres signaux, afin que l'analyste la lise à côté des connexions, des processus et du ticket qui devrait expliquer le changement. Les équipes qui transmettent déjà leurs événements à une intégration SIEM peuvent placer la modification du fichier sur la même chronologie que les connexions et les sessions.

Le FIM figure parmi les contrôles les plus souvent cités dans les référentiels de sécurité, c'est pourquoi les équipes SOC le déploient même en l'absence d'incident. La plupart des auditeurs demandent les mêmes preuves : une liste définie de fichiers critiques, des alertes sur les modifications non autorisées et la preuve qu'une personne a examiné chaque alerte et l'a close par une décision.

• La norme PCI DSS exige un mécanisme de détection des changements sur les systèmes qui traitent des données de cartes, avec une comparaison des fichiers critiques au moins une fois par semaine.
• Le contrôle SI-7 du NIST SP 800-53 couvre l'intégrité des logiciels, des micrologiciels et des informations.
• La garantie d'intégrité de HIPAA attend des entités couvertes des mécanismes électroniques confirmant que les informations de santé électroniques n'ont pas été altérées ou détruites sans autorisation.
• L'annexe A de l'ISO/IEC 27001 comprend des contrôles de gestion des changements et d'intégrité des systèmes, qu'un processus FIM documenté aide à prouver.
• Les auditeurs demandent en général l'inventaire des fichiers protégés, des échantillons d'alertes et une trace de revue montrant que chaque alerte a été close par une décision, et pas seulement générée.

Anexet ne crée pas de référence pour des chemins système quelconques et ne calcule pas le hachage de chaque fichier d'un serveur, ce n'est donc pas un moteur FIM classique. La console enregistre les opérations sur les fichiers des postes de travail et des partages réseau : pour les fichiers, création, lecture, écriture, suppression, renommage, exécution et modification des droits ; pour les dossiers, un ensemble plus restreint. Chaque profil d'agent choisit les opérations enregistrées. Les partages réseau sont couverts par le contrôle des transferts de fichiers et des partages réseau.

Le plus grand risque opérationnel du FIM n'est pas de manquer un vrai changement. C'est de noyer le SOC sous le bruit, au point que toutes les alertes soient rejetées sans être lues. Les conteneurs changent la donne : les images sont reconstruites plutôt que corrigées sur place, la référence se déplace donc vers le pipeline de construction des images. L'ajustement suit une séquence prévisible :

1. 1

   Capturer la référence

   Relevez-la sur une version connue comme saine du système.

2. 2

   Exécuter en mode rapport seul

   Découvrez ce qui change normalement sur cette classe de système.

3. 3

   Exclure les chemins volatils

   Laissez de côté les chemins qui changent légitimement, comme les caches, les journaux et les métadonnées du gestionnaire de paquets.

4. 4

   Confier les alertes à un responsable

   Le responsable clôt chaque alerte avec un motif consigné.

Le FIM détecte qu'un fichier surveillé a changé. Il ne juge pas si le nouveau contenu est malveillant et n'empêche pas la modification. Il ne voit rien de l'activité qui ne touche jamais un chemin surveillé, comme l'exécution en mémoire, l'usage abusif d'identifiants ou des données copiées sans qu'aucun fichier soit modifié.

Un SOC mature considère donc le FIM comme un contrôle détectif parmi d'autres. Il l'associe à des contrôles d'accès qui limitent qui peut écrire dans les chemins protégés, à la vérification de l'intégrité des journaux, pour que les événements d'intégrité survivent sur une infrastructure que l'attaquant ne contrôle pas, et à des sauvegardes et à la restauration, pour qu'une modification non autorisée confirmée puisse être annulée.

Commencez par les quelques fichiers dont la modification silencieuse ferait le plus de dégâts : les binaires système des serveurs, la configuration des outils de sécurité et les chemins qui contiennent des données protégées. N'ajoutez d'autres chemins qu'une fois que le responsable a expliqué chaque alerte produite par le premier ensemble.

Pour aller plus loin : Mécanismes de sécurité des systèmes d'information; Que sont les systèmes SIEM pour la gestion de la sécurité de l'information ?.