SchildmarkGuide
XDR avec gestion des correctifs intégrée : détection et correctifs vérifiés dans un seul produit
Une solution XDR avec gestion des correctifs intégrée trouve une vulnérabilité, la corrige et prouve la correction depuis la même console : rien ne se perd entre deux outils. Le point clé est la vérification : un correctif n’est terminé que lorsqu’un nouveau scan confirme que la vulnérabilité a disparu, pas quand l’installateur annonce un succès.
Pourquoi détection et correctifs vont ensemble
Beaucoup d’attaques exploitent des vulnérabilités déjà corrigées par l’éditeur ; l’agence américaine CISA tient justement un catalogue public des vulnérabilités activement exploitées. Le plus dur n’est pas le correctif, mais de savoir quelle machine en a besoin en premier, et d’être sûr qu’il est installé.
Avec deux produits, l’outil de sécurité voit l’attaque, tandis que l’outil de correctifs a son propre inventaire, ses propres priorités et sa propre définition de « terminé ». Quelqu’un rapproche les deux, souvent à la main, et c’est dans cet écart qu’un serveur exposé le reste un mois de plus.
Dans un seul produit, le même agent signale le paquet vulnérable, la même console le classe à côté des alertes de cette machine, les vulnérabilités exploitées en premier, le correctif y est planifié et approuvé, et le scan suivant clôt la vulnérabilité. L’auditeur dispose d’une seule trace, de la détection à la correction vérifiée. La page correctifs le montre dans la console, et l’analyste IA trouve le paquet vulnérable et propose le correctif.
Ce que veut dire « correctif vérifié »
Installé ne veut pas dire corrigé. Un correctif vérifié suit six étapes, et la dernière est un nouveau scan, pas le code de retour de l’installateur.
Confirmer
Partir d’une vulnérabilité confirmée par les données des éditeurs et de la NVD, et lire l’état actuel de la machine.
Choisir la version
La version exacte du paquet, ou le KB Windows, qui la corrige. Pas « la plus récente ».
Simuler
Une installation à blanc sur la machine, sans la modifier.
Approuver
Une personne, ou une politique que vous avez activée. Une machine critique exige deux personnes.
Installer
Dans la fenêtre de maintenance, avec redémarrage seulement s’il est autorisé.
Rescanner
Terminé seulement quand la version est en place et que le scan confirme la correction.
Dans Schildmark, une tâche ne se termine en Remediated que si la version installée atteint au moins la cible, si la liste des logiciels de la machine l’indique et si la vérification déclare corrigée chaque vulnérabilité corrigible de la tâche. Sinon, elle indique Not verified ou Reboot required, jamais terminée.
Approbation automatique des correctifs : ce qui peut s’en passer, et ce qui jamais
L’approbation automatique retire la routine, pas le jugement. Une bonne politique la limite par environnement, criticité et paquet, et chaque décision reste tracée.
- Correctifs courants
- Approbation automatique seulement dans les environnements que vous désignez, sur des machines qui ne sont ni hautes ni critiques, et pour des plans sans élément restreint. Ces tâches portent la mention Approved automatically by policy et restent simulées et rescannées.
- Machines hautes et critiques
- Jamais approuvées automatiquement. Les machines critiques exigent deux personnes différentes.
- Paquets restreints
- Les paquets comme les runtimes de conteneurs exigent une approbation de niveau supérieur, quelle que soit la politique.
- Fenêtres et redémarrages
- Les tâches planifiées attendent la fenêtre de maintenance ; les redémarrages hors fenêtre sont refusés. Sans autorisation, ni un correctif ni une personne ne peut redémarrer la machine.
- Anneaux
- Un paquet déployé par anneaux de machines ; l’anneau suivant ne démarre qu’une fois le précédent réussi.
- Correctifs impossibles
- Enregistrez un risque accepté, avec responsable, justification et échéance, plutôt qu’une vulnérabilité laissée ouverte sans explication.
- Les limites
- Une simulation détecte dépendances manquantes et conflits, pas chaque régression applicative. Tenez la criticité à jour, et classez haute ou critique toute machine dont la panne arrêterait l’activité.
Correctifs pour Windows, Linux et macOS : les sources d’installation
Demandez ce tableau à chaque éditeur, avec le statut de chaque canal, plutôt qu’une rangée de logos. Voici celui de Schildmark aujourd’hui.
| Canal | Statut |
|---|---|
| apt, dnf (Linux) | Disponible |
| KB Windows Update | Pilote |
| winget, pip | Pilote |
| Homebrew (macOS) | Pilote |
| Mises à jour système macOS, autres applications tierces | Installées sur la machine ; la console les affiche comme corrigées dès que le scan le confirme |
Les correctifs passent par le même Schildmark Agent, installé avec --patching. Il ne fait que des connexions sortantes, signe chaque requête et n’exécute que des tâches signées par votre console, parmi une liste fixe d’actions : versions exactes de paquets, KB Windows, redémarrage, démarrage, arrêt, désinstallation. Il n’y a ni shell ni « exécuter une commande ».
Les questions à poser à un éditeur XDR sur les correctifs
Six questions qui distinguent une fonction de correctifs d’une gestion des correctifs fiable.
- Quand un correctif est-il « terminé » ?
- Au code de retour de l’installateur, ou quand un nouveau scan confirme que la vulnérabilité a disparu ? Demandez à voir une tâche qui a échoué à la vérification.
- Puis-je voir la simulation ?
- Une simulation sur la machine avant toute approbation montre ce qui changerait.
- Qu’est-ce qui n’est jamais approuvé automatiquement ?
- Quelles machines, quels environnements et quels paquets sont exclus, et une seule personne peut-elle lever ces exclusions ?
- Quels canaux sont disponibles en production ?
- Par système et source de paquets : disponible, pilote ou non pris en charge.
- Que peut-on demander à l’agent ?
- Un agent qui exécute n’importe quelle commande est une porte d’entrée sur chaque machine. Demandez la liste fixe des actions et la façon dont les tâches sont signées.
- Quelles preuves obtient-on ?
- Approbations, refus, exécutions et corrections vérifiées sur une période, dans des fichiers qu’un auditeur peut ouvrir.
Preuves de correctifs pour NIS2, ISO 27001 et PCI DSS
Les trois parlent de gestion des vulnérabilités. NIS2, article 21, paragraphe 2, point e), couvre le traitement et la divulgation des vulnérabilités ; l’annexe A 8.8 d’ISO/IEC 27001:2022 demande la gestion des vulnérabilités techniques ; l’exigence 6.3.3 de PCI DSS 4.0.1 impose les correctifs critiques dans le mois suivant leur publication. Le guide d’hygiène informatique de l’ANSSI recommande lui aussi une politique de mise à jour des composants du système d’information.
Le pack de preuves de Schildmark contient, pour la période choisie, vulnerabilities_fixed.csv, avec la preuve de chaque vérification, et patch_activity.csv, avec approbations, refus et exécutions. Voir la page conformité et la page NIS2.
Questions fréquentes
Qu’est-ce qu’une solution XDR avec gestion des correctifs intégrée ?
Une solution XDR qui détecte les attaques et installe aussi les correctifs des vulnérabilités trouvées, avec le même agent et la même console. Elle n’a d’intérêt que si chaque correctif est vérifié par un nouveau scan et tracé.
Peut-on automatiser entièrement l’approbation des correctifs ?
Pour les correctifs courants sur des machines ordinaires, oui, si une politique l’encadre. Dans Schildmark, elle ne vaut que pour les environnements désignés, jamais pour les machines hautes ou critiques ni pour un plan contenant un paquet restreint. Les machines critiques exigent toujours deux personnes, et les tâches automatiques restent simulées et rescannées.
Comment vérifier qu’un correctif a vraiment fonctionné ?
Sur trois points : la version installée est au moins la version corrigée, l’inventaire logiciel de la machine l’indique, et un nouveau scan de vulnérabilités ne signale plus la faille. Un installateur qui se termine sans erreur ne prouve rien de tout cela à lui seul.
Quels systèmes d’exploitation Schildmark sait-il corriger ?
Les paquets Linux via apt et dnf sont disponibles. Les KB Windows Update, winget, pip et Homebrew sous macOS sont en pilote. Les mises à jour système macOS et les autres applications tierces s’installent sur la machine elle-même ; la console les affiche comme corrigées dès que le scan le confirme.
Faut-il encore un outil de gestion des correctifs séparé ?
Peut-être. Si un autre outil déploie déjà vos mises à jour Windows ou macOS, gardez-le : Schildmark voit aussi ces correctifs et les compte dès que le scan les confirme.
Voir une tâche, de la vulnérabilité à la correction vérifiée
Dites-nous quels systèmes vous exploitez et comment vous les corrigez aujourd’hui. Nous vous montrons simulation, approbation et vérification sur une machine comparable. L’essai de 30 jours couvre jusqu’à 25 machines.