« Nous patchons régulièrement » est une affirmation qui, dans de nombreuses PME, est considérée comme la preuve d’une bonne sécurité informatique. Et en effet : le patching est important. Mais il ne représente qu’une partie de l’équation. Ceux qui pensent que les mises à jour régulières suffisent à elles seules négligent une grande partie de la surface d’attaque.
Cet article montre pourquoi la gestion des correctifs est certes nécessaire, mais pas suffisante, et comment le scan de vulnérabilités apporte le complément décisif.
Ce que le patching apporte — et ce qu’il n’apporte pas
Les patches comblent les vulnérabilités connues dans les logiciels. Lorsque Microsoft, Apache ou un autre éditeur publie une mise à jour de sécurité, celle-ci corrige une ou plusieurs CVEs documentées. C’est essentiel et doit être fait de manière fiable.
Mais les patches ne traitent qu’un type spécifique de vulnérabilité : les erreurs de codage logicielle. Or, de nombreux problèmes de sécurité parmi les plus critiques dans les réseaux de PME ne sont pas des bugs logiciels, mais des erreurs de configuration, et il n’existe aucun patch pour cela.
Les erreurs de configuration : la surface d’attaque invisible
Les erreurs de configuration ne résultent pas de logiciels défectueux, mais d’une mise en place ou d’une maintenance inadéquate. Exemples typiques :
- Identifiants par défaut : Routeurs, switches, imprimantes, NAS et pare-feu encore exploités avec les noms d’utilisateur et mots de passe d’usine. « admin/admin » ou « admin/password » sont d’une fréquence alarmante.
- Interfaces d’administration ouvertes : RDP, SSH, interfaces web d’équipements réseau ou de bases de données directement accessibles depuis Internet, souvent sans que l’administrateur le sache.
- Absence de chiffrement : Services internes communiquant en clair. HTTP au lieu de HTTPS, LDAP non chiffré, Telnet au lieu de SSH.
- Permissions trop permissives : Partages SMB sur lesquels « Everyone » a un accès en écriture. Bases de données acceptant les connexions depuis n’importe quelle adresse IP.
- Configurations TLS obsolètes : Serveurs web supportant encore TLS 1.0 ou des cipher suites faibles.
- Absence de sécurité e-mail : Domaines sans SPF, DKIM et DMARC, permettant l’usurpation d’adresses e-mail.
Pour aucune de ces vulnérabilités, un patch ne sera jamais publié. Elles ne peuvent être corrigées que par des modifications de configuration délibérées, et pour cela, il faut d’abord les connaître.
Le Patch Gap : le délai dangereux
Même si une PME pratique un patching exemplaire, il existe un délai inévitable entre la publication d’une vulnérabilité et l’installation du patch. Ce délai, le Patch Gap, est un risque réel.
Le déroulement typique :
- Jour 0 : La vulnérabilité devient publique (publication CVE)
- Jour 0-7 : L’éditeur publie un patch (dans le meilleur des cas)
- Jour 7-14 : La PME évalue le patch et le teste
- Jour 14-30 : Le patch est installé sur tous les systèmes concernés
En pratique, il s’écoule donc 2 à 4 semaines entre la divulgation d’une vulnérabilité et sa correction, même dans les PME bien organisées. Pour les systèmes moins prioritaires ou les processus de mise à jour complexes (par exemple les applications métier devant être testées après une mise à jour du système d’exploitation), cela peut prendre des mois.
Parallèlement, les études montrent que les attaquants sont de plus en plus rapides. Le délai moyen entre la publication d’une CVE et la première tentative d’exploit observée est inférieur à 15 jours. Pour les vulnérabilités hautement critiques, les attaques automatisées commencent souvent en quelques heures.
Que se passe-t-il pendant ce délai ?
Pendant le Patch Gap, deux éléments sont décisifs :
- La connaissance : La PME sait-elle seulement qu’elle est concernée ? Sans scan de vulnérabilités, l’équipe informatique doit se fier aux communications des éditeurs et aux sites d’actualités.
- La compensation : Des mesures de protection temporaires (règles WAF, restrictions pare-feu, désactivation de services) peuvent-elles réduire le risque en attendant le patching ?
Un scanner de vulnérabilités qui vérifie régulièrement l’infrastructure rend ces deux aspects possibles : il identifie automatiquement les systèmes concernés et fournit la base pour des mesures compensatoires ciblées.
Patch installé — problème résolu ? Pas toujours.
Une réalité souvent négligée : tous les patches installés ne sont pas efficaces. Il existe de nombreux scénarios où un patch a été installé, mais la vulnérabilité persiste :
- Le patch nécessite un redémarrage : Les mises à jour Windows en particulier sont souvent installées, mais le redémarrage est reporté — parfois pendant des semaines. Jusqu’au redémarrage, la vulnérabilité reste ouverte.
- Le patch a été installé de manière incorrecte : Des conflits de dépendances, un espace disque insuffisant ou des problèmes de permissions peuvent faire qu’une mise à jour soit marquée comme « installée » sans être effective.
- Le patch ne couvre qu’une partie du problème : Certaines vulnérabilités nécessitent des modifications de configuration supplémentaires après l’installation du patch. La célèbre vulnérabilité Exchange ProxyNotShell, par exemple, nécessitait une règle de réécriture d’URL après le patch.
- Le service n’a pas été redémarré après le patch : Un serveur web Apache patché dont le processus n’a pas été redémarré continue de fonctionner avec l’ancien code vulnérable en mémoire.
La seule méthode fiable pour vérifier l’efficacité réelle d’un patch est un nouveau scan de vulnérabilités après l’installation.
Comparaisons de scans : la vérification des patches
Les comparaisons de scans sont un outil puissant pour la gestion des correctifs. Le principe est simple : vous comparez les résultats d’un scan avant le patching avec un scan après. Le résultat montre :
- Vulnérabilités corrigées : Elles étaient présentes dans le scan précédent et ont disparu. Le patch a fonctionné.
- Vulnérabilités persistantes : Elles étaient présentes avant et le sont toujours. Le patch n’a pas fonctionné ou n’a pas été installé.
- Nouvelles vulnérabilités : Elles n’étaient pas présentes dans le scan précédent. Soit de nouvelles CVEs ont été publiées, de nouveaux systèmes ont été ajoutés, soit le patch a involontairement introduit de nouveaux problèmes.
Cette comparaison avant-après rend le succès des mesures de patching mesurable et donne à l’équipe informatique un retour clair sur le travail qui a réellement porté ses fruits.
Une approche globale pour les PME
Une gestion efficace des vulnérabilités combine la gestion des correctifs avec un scan régulier. Les deux disciplines se complètent :
La gestion des correctifs assure que :
- Les vulnérabilités logicielles connues sont comblées
- Les systèmes d’exploitation et applications sont à jour
- Les recommandations des éditeurs sont appliquées
Le scan de vulnérabilités assure que :
- Les erreurs de configuration sont détectées, pour lesquelles il n’existe pas de patches
- Les logiciels en fin de vie sont identifiés
- L’efficacité des patches est vérifiée
- Les nouvelles vulnérabilités sont détectées rapidement
- Les systèmes inconnus ou oubliés sont découverts
Recommandations pratiques pour les PME
- Automatisez votre patching — Windows Server Update Services (WSUS), Intune ou des solutions tierces de gestion des correctifs réduisent l’effort manuel.
- Scannez après chaque cycle de patching — pour vous assurer que les patches ont effectivement fonctionné.
- Scannez les erreurs de configuration — mots de passe par défaut, ports ouverts, chiffrement manquant et services non sécurisés ne seront corrigés par aucun patch.
- Définissez un rythme — des cycles de patching mensuels combinés à des scans de vulnérabilités hebdomadaires ou mensuels.
- Mesurez vos progrès — les comparaisons de scans montrent si le nombre total de vulnérabilités diminue ou augmente.
Les erreurs les plus courantes de l’approche « patching uniquement »
Pour conclure, un aperçu des situations que la gestion des correctifs seule ne couvre pas, et qui apparaissent régulièrement dans les scans de vulnérabilités :
- Serveurs web avec directory listing activé
- Bases de données écoutant sur 0.0.0.0 au lieu de localhost uniquement
- Installations WordPress avec xmlrpc.php désactivé mais encore accessible
- Services SNMP avec community string « public »
- Serveurs SSH avec connexion root autorisée et authentification par mot de passe
- Certificats SSL wildcard sur des systèmes qui n’ont pas besoin de HTTPS
- Fichiers de sauvegarde (.bak, .old, .sql) dans le répertoire web public
Aucun de ces problèmes ne sera résolu par un patch. Tous sont détectables par un scan.
Conclusion
Le patching est indispensable, mais ce n’est que la moitié du travail. Les erreurs de configuration, le Patch Gap et l’absence de vérification des mises à jour créent des failles que les attaquants exploitent de manière ciblée. Seule la combinaison d’une gestion rigoureuse des correctifs et d’un scan régulier des vulnérabilités donne une image complète de sa propre posture de sécurité.
ExposIQ offre avec plus de 35 moteurs de scan et 11’700 templates Nuclei une vérification complète qui va bien au-delà de la simple détection de CVEs : erreurs de configuration, identifiants par défaut, logiciels en fin de vie et problèmes DNS sont détectés de la même manière. Les comparaisons de scans montrent si vos patches ont réellement fonctionné. Le tout hébergé en Suisse, conforme à la nLPD, à partir de CHF 99 par mois. En savoir plus sur exposiq.ch.
