Ce que la vérification compare
Une référence (baseline) est l'enregistrement de l'état attendu des fichiers : une empreinte cryptographique du contenu de chaque fichier, avec sa taille, ses droits, son propriétaire et ses horodatages. Chaque vérification ultérieure compare l'état actuel à cet enregistrement. La question n'est donc pas de savoir si un fichier semble suspect, mais s'il correspond toujours à la référence.
La même approche prend le nom de surveillance de l'intégrité des fichiers (FIM) lorsqu'elle tourne en continu sur un parc de serveurs et de postes. La vérification est identique. Seuls changent la fréquence et la personne qui lit les résultats.
Comment fonctionne la méthode
La comparaison est exacte. Un hachage change complètement dès qu'un seul octet change : il n'existe ni correspondance partielle ni doute sur l'identité du contenu.
La méthode comporte cinq étapes, chacune reposant sur la précédente.
- 1
Création de la référence
Les fichiers à protéger sont inventoriés. Pour chacun, un hachage du contenu est enregistré avec ses métadonnées : taille, droits, propriétaire et horodatages.
- 2
Vérification
Selon un calendrier ou en réaction à des événements, les valeurs sont recalculées et comparées à la référence.
- 3
Signalement
Les écarts sont remontés sous forme d'événements de modification, avec ce qui a changé et quand.
- 4
Tri
Chaque modification est rapprochée de l'activité attendue : correctif approuvé, déploiement de configuration, mise à jour d'application ou cause inexpliquée.
- 5
Mise à jour de la référence
Les changements légitimes sont intégrés dans une nouvelle référence, pour qu'elle reste à jour.
Vérification planifiée ou en temps réel
La vérification planifiée parcourt l'ensemble protégé à intervalles fixes. Elle est simple et prévisible en consommation de ressources, mais elle est aveugle entre deux passages : un fichier peut être modifié, utilisé puis restauré avant le suivant.
La vérification en temps réel s'appuie sur les événements du système de fichiers et signale la modification au moment où elle survient. Le délai de détection diminue et l'identité du processus et de l'utilisateur responsables est connue. Le coût : une activité permanente de l'agent et davantage de bruit à filtrer.
Ce qui est généralement protégé
On protège en général une liste restreinte de cibles, choisies selon le préjudice qu'une modification silencieuse pourrait causer.
| Cible | Pourquoi elle est surveillée |
|---|---|
| Binaires et bibliothèques du système d'exploitation | Composants qu'un attaquant remplacerait pour se maintenir |
| Fichiers de configuration | Une seule ligne modifiée peut désactiver un contrôle ou ouvrir un accès |
| Code applicatif et contenus web | Le code injecté atteint directement les utilisateurs |
| Tâches planifiées, services et entrées de démarrage | Emplacements courants de persistance |
| Outils de sécurité et leur configuration | Désactiver la surveillance est une étape classique |
| Enregistrements qui ne doivent pas changer | Journaux, archives, documents financiers ou probants |
Usages au-delà de la détection d'intrusion
Le même mécanisme sert plusieurs objectifs. Il détecte les modifications non autorisées (usage sécurité), confirme que les changements approuvés ont été déployés comme prévu (usage opérationnel), confirme que les archives conservées ne se sont pas dégradées à cause d'incidents sur les supports (usage de conservation) et démontre que des enregistrements n'ont pas été modifiés a posteriori (usage probatoire). Ce dernier usage compte particulièrement pour les données sensibles soumises à des obligations de conservation.
Vérifier un programme téléchargé par rapport à un hachage publié applique la même idée à un seul fichier, à un instant donné.
Ce que cela donne dans Anexet
Dans la console d'administration d'Anexet, les hash banks sont rattachées au profil de l'agent. L'onglet File system liste les banques appliquées à la surveillance du système de fichiers, avec le nombre de fichiers et de hachages de chacune. La fenêtre de statistiques indique la date de la dernière mise à jour de la banque et celle de sa dernière vérification.
1 / 2
Limites et problèmes pratiques
La méthode présente cinq limites pratiques. Une modification faite par une menace interne disposant de droits légitimes ressemble à n'importe quelle modification approuvée : la vérification seule ne suffit donc pas. Sa valeur dépend de la rapidité avec laquelle quelqu'un trie chaque signalement.
- Volume de modifications : sans périmètre précis, le bruit noie les signalements, qui finissent par ne plus être lus.
- Détection, pas prévention : le signalement montre la modification sans l'arrêter. Le blocage doit venir d'un contrôle distinct, comme une solution de prévention des pertes de données (DLP).
- Confiance dans la référence : une référence prise sur un système compromis considère la compromission comme normale.
- Aveuglement au contenu : la vérification montre qu'un fichier diffère, pas si la différence compte.
- Attaques en mémoire et à l'exécution : les attaques qui ne touchent jamais un fichier surveillé sur disque sont hors périmètre.
Pourquoi elle reste un standard
Malgré ces limites, la plupart des référentiels de sécurité et des normes de paiement et sectorielles exigent la vérification de l'intégrité, qui fait partie des pratiques courantes de surveillance de la conformité.
Elle coûte peu à exécuter et fournit des preuves sans ambiguïté. C'est l'un des rares contrôles capables de prouver une absence : qu'un fichier critique n'a pas changé depuis le dernier état vérifié.
Pour aller plus loin : Mécanismes de sécurité des systèmes d'information; Chiffrement, codage et hachage : quelle différence ?.
Un fichier modifié se signale rarement de lui-même. La référence est ce qui donne un sens au silence.
Anexet Team