Security Tool Deployed, Coverage Unknown

Un contrôle de sécurité est considéré comme déployé parce que sa console affiche des agents, des événements ou un taux de couverture. Personne ne compare toutefois cette population à une source indépendante qui décrit ce qui devrait être protégé.

L’organisation sait qu’elle voit 487 actifs. Elle ne sait pas qu’elle devrait en voir 512.

Les écarts apparaissent avec le temps : nouvel équipement jamais intégré, machine restaurée depuis une vieille image, agent brisé ou désinstallé, serveur oublié, appareil rarement connecté, filiale acquise, système exclu temporairement puis jamais réintégré. Le produit fonctionne. C’est la couverture qui ment par omission.

Une console de sécurité ne montre généralement pas ce qu’elle ne connaît pas. Pendant un incident, cette absence est facilement interprétée comme une absence d’activité malveillante.

Les actifs non couverts deviennent les meilleurs endroits pour conserver un accès, déplacer des outils ou relancer une attaque. Ils faussent aussi le périmètre : une recherche effectuée sur « tous les postes visibles » peut produire une conclusion techniquement exacte et opérationnellement fausse.

Le problème ne touche pas seulement l’EDR. Il vaut pour la journalisation, la gestion des vulnérabilités, la sauvegarde, la gestion des correctifs et tout autre contrôle dont la console sert elle-même de preuve de couverture.

• Demander deux nombres produits indépendamment : combien d’actifs devraient être couverts, et combien le sont réellement.
• Réconcilier la console avec au moins une autre source : inventaire, annuaire, plateforme de gestion, hyperviseurs, réseaux, achats ou sauvegardes.
• Chercher les agents silencieux, désactivés, obsolètes, en erreur ou jamais vus depuis une période définie.
• Échantillonner les catégories faciles à oublier : serveurs, machines virtuelles arrêtées, postes distants, équipements de direction, appareils de laboratoire et systèmes hérités.
• Vérifier si une alerte est créée lorsqu’un actif attendu cesse de communiquer. Si le seul moyen de découvrir le trou est d’ouvrir manuellement la console, le pattern est présent.

• Désigner une source d’autorité pour chaque population d’actifs et définir les écarts acceptables.
• Automatiser la réconciliation entre l’inventaire attendu et les consoles de sécurité; alerter sur les actifs absents autant que sur les menaces détectées.
• Donner un propriétaire et un délai de correction aux agents défaillants ou silencieux.
• Intégrer l’installation et la vérification des contrôles aux processus d’ajout, de restauration et de retrait des actifs.
• Mesurer la couverture par population critique, pas seulement avec un pourcentage global qui peut cacher les trois serveurs qu’on ne pouvait justement pas se permettre d’oublier.

• Ne pas traiter l’inventaire de la console compromise ou incomplète comme le périmètre de l’incident.
• Construire une liste consolidée depuis plusieurs sources et marquer chaque actif comme couvert, non couvert ou inconnu.
• Prioriser les actifs inconnus, silencieux et non protégés pour la collecte, la recherche d’indicateurs et, selon le risque, l’isolement.
• Consigner explicitement les limites de couverture dans chaque conclusion d’enquête. « Aucun indicateur trouvé » n’a de valeur que si l’on précise où il était possible de chercher.
• Étendre la chasse aux systèmes restaurés, dormants ou hors ligne avant de déclarer le confinement terminé.