Une configuration modifiée. Personne ne l'a remarqué.

Là où l'écart s'ouvre réellement

Une valeur de registre change sur un contrôleur de domaine à 2h14. Un fichier dans /etc/ssh/sshd_config se voit ajouter une seule ligne. Une ACL de pare-feu sur un switch dans un bureau régional reçoit une nouvelle règle d’autorisation. Aucun de ces événements ne déclenche une alerte SIEM. Aucun ne casse quoi que ce soit. Aucun n’apparaît dans un scan de vulnérabilité, car le scanner a été exécuté hier et ne sera pas relancé avant la semaine prochaine.

La faille est ouverte. L'attaquant la lit avant vous, car il cherche exactement cela, la petite déviation, la modification non enregistrée, la dérive que personne ne possède.

C’est pourquoi file integrity monitoring en tant que réflexion après coup ne fonctionne pas. Extraire les journaux d’événements et rechercher le code 4663 équivaut à regarder le match en différé. Vous ne pressez pas. Vous réagissez. La déviation doit être détectée au niveau E/S, au moment où elle se produit, par rapport à une base de référence en laquelle vous avez réellement confiance.

La presse, au noyau

Le Gen 7 Agent sur Windows enregistre un pilote minifiltre avec le Filter Manager à une altitude de 388790. Chaque opération d'E/S de fichier (création, écriture, suppression, renommage, modification d'attribut) passe par la pile de filtres, et le pilote enregistre les événements correspondant au modèle de suivi dans un tampon mémoire. L'agent interroge le tampon toutes les 100 millisecondes. Pas de verrouillage de fichiers. Pas de modification d'E/S. Pas de redémarrage nécessaire pour l'activer.

C’est la presse. Vous n’attendez pas qu’un journal soit vidé. Vous ne scrutez pas le système de fichiers toutes les cinq minutes en espérant que rien ne se soit passé entre-temps. Vous êtes connecté directement au chemin d’E/S, lisant chaque interaction en temps réel, la comparant à la forme que vous avez définie.

Sous Linux, l'Agent Gen 7 utilise Sysdig pour capturer la même profondeur, les modifications de l'intégrité des fichiers et l'identité de l'utilisateur derrière celles-ci. Qui a effectué la modification. Pas seulement ce qui a changé. Parce que « quelqu'un a modifié /etc/pam.d/sshd » est à moitié une alerte. « Le compte de service svc-backup a modifié /etc/pam.d/sshd à 02:14 depuis une session en dehors de la fenêtre de maintenance » est une décision.

La couverture sans agent gère le reste. Appareils réseau via SSH. Hôtes Windows via le registre distant sur le port 445. Linux et Unix via shell. ESXi et vCenter via PowerCLI. Plates-formes cloud via les API des fournisseurs. Une seule base de référence sur toute la ligne arrière, pas neuf outils différents surveillant neuf positions différentes.

Boucler la boucle

La détection en temps réel sans contexte est comme un milieu de terrain qui fait faute à chaque joueur qui passe en courant. Vingt minutes plus tard, vous êtes à dix et le banc crie.

La plupart des changements dans un environnement réel sont légitimes. Les correctifs sont appliqués. Les administrateurs font leur travail. Les tâches planifiées modifient des fichiers. Un outil FIM qui s’active à chaque fois est du bruit, et le bruit est ignoré, et être ignoré est pire que rien — vous avez maintenant un outil et une fausse impression de couverture.

Change Tracker réconcilie chaque changement détecté avec ce qui était censé se produire. Le Sync Service extrait les demandes de changement approuvées de ServiceNow, BMC Remedy, Cherwell, ManageEngine, ChangeGear, OpenText SMAX et Samanage. Chaque RFC devient un Changement Planifié avec une fenêtre programmée, un élément de configuration et, sur ServiceNow, le champ AssignedTo, afin que les événements puissent être associés à la personne qui aurait dû effectuer le changement, pas seulement au moment où il a eu lieu. Les événements détectés sont évalués selon le jeu de règles du changement planifié et classés.

Planifié. Reconnu. Filtré.

Imprévu. Détecté. Investigé.

C'est la boucle fermée. Savoir quelles exécutions sont des leurres et lesquelles sont la véritable menace, et ne s'engager que sur celles qui comptent.

Lorsqu'il n'y a pas de ticket, lorsque le changement n'a pas de RFC correspondant ni de justification enregistrée, Change Tracker peut automatiquement remonter l'incident dans ServiceNow, acheminé vers le propriétaire de l'élément de configuration. Le changement non autorisé génère l'élément de travail qui le résout. La pression ne se contente pas de gagner la balle. Elle déclenche le compteur.

La ligne de base est la formation

Une défense à quatre sans forme, ce sont quatre joueurs debout sur un terrain. La détection sans référence est la même chose. Vous ne pouvez pas détecter une déviation si vous n'avez pas défini la normale.

La fonction Configuration de Base traite cela comme un entraîneur traite une configuration tactique. Choisissez un appareil source : votre image gold, votre build de référence renforcée. Capturez son état. Intégrité des fichiers. Logiciels installés. Processus en cours. Services et leurs états. Comptes locaux. Ports ouverts. Clés de registre sous Windows. La baseline devient la formation, et chaque autre appareil du groupe est mesuré par rapport à elle. La dérive apparaît comme une exception. Les exceptions sont examinées. La dérive approuvée est promue à la baseline. La dérive non approuvée est corrigée.

Voici ce que NERC CIP-010-4 et 5 veulent lorsqu'ils parlent des configurations de base autorisées et de la surveillance des modifications sur 35 jours. C'est ce que la exigence 11.5 de PCI DSS veut lorsqu'elle parle des mécanismes de détection des changements. C'est ce que CIS Control 4 veut lorsqu'il parle de la configuration sécurisée des actifs d'entreprise. Les cadres décrivent tous la même chose avec des mots différents : définir la forme, maintenir la forme, faire apparaître la déviation. Change Tracker est construit autour de cette boucle exacte, avec plus de 250 rapports de conformité préconstruits qui cartographient la base de référence au cadre que l'auditeur va demander en mars.

Rien ne bouge sans trace

Le tableau de bord est vert. Les tickets sont gérables. L'équipe est à l'aise.

C'est le moment le plus dangereux du match.

Quelque part dans votre environnement, quelque chose vient de changer. La question n'est pas de savoir si vos outils l'ont finalement remarqué. La question est de savoir combien de passages l'attaquant a effectués entre le moment où la faille s'est ouverte et le moment où votre détection s'est réellement déclenchée.

Appuyez plus tôt. Lisez le jeu au moment du changement. Définissez la forme, maintenez la forme et assurez-vous que rien ne bouge sans trace.

C’est le travail. C’est la norme. C’est ainsi que vous défendez ce qui vous appartient.