Patchmanagement: Die unterschätzte Pflicht zwischen Alltag und Angriff

Les grandes vagues d'attaques des dernières années avaient un point commun : elles n'exploitaient pas de failles de sécurité inconnues, mais vulnérabilités connues depuis longtemps pour lesquelles une mise à jour existaitQu'il s'agisse de failles Exchange ou de Log4j, les attaquants ont été plus rapides que les processus de mise à jour des victimes. C'est pourquoi la gestion des correctifs n'est pas une question de maintenance basique, mais la défense efficace la moins coûteuse qui soit.

Pourquoi le patching échoue-t-il dans la pratique

• Pas d'inventaire : Ce que personne ne connaît, personne ne peut le patcher. Cela concerne particulièrement les anciens serveurs, imprimantes, appliances pare-feu et logiciels qui « tournent quelque part ».
• La peur de l'interruption de service : Les mises à jour sont reportées car un redémarrage en journée est impossible — et elles ne sont ensuite jamais effectuées.
• Responsabilité indéterminée : Le prestataire pense que le client s'en occupe ; le client pense que le prestataire s'en occupe.
• Aucune preuve : Le patching est effectué, mais personne n'est capable de démontrer quel système se trouvait à quel niveau de mise à jour et à quel moment.

La norme minimale pour un processus résilient

• Inventaire complet : Chaque appareil, chaque application, chaque firmware — détectés automatiquement, et non gérés via Excel.
• Analyse des vulnérabilités : de manière régulière et automatisée, plutôt que d'attendre les e-mails des fournisseurs.
• Priorisation basée sur l'exploitabilité : Toutes les failles ne se valent pas. Le facteur déterminant est de savoir si une attaque existe déjà dans la nature (cf. listes Known Exploited), et non seulement l'évaluation théorique.
• Mises à jour critiques sous 72 heures, tout le reste dans la fenêtre de maintenance prévue — avec un anneau de test avant le système de production.
• Documentation : Date, système, résultat. Cela constitue simultanément votre preuve de conformité NIS2.

NIS2 transforme le « devrait » en obligation.

La transposition allemande de NIS2 exige des mesures de gestion des risques conformes à l'état de l'art — cela inclut explicitement la gestion des vulnérabilités. Les entreprises concernées ne doivent pas seulement mettre en œuvre le processus, mais aussi justifier sur demande peuvent. La direction générale en assume la responsabilité personnelle.

Ce qu'un prestataire de services prend en charge à cet égard

Un partenaire de services managés prend en charge précisément les points qui échouent en interne : l'inventaire, la mesure des vulnérabilités, les déploiements testés pendant les fenêtres de maintenance et une documentation complète. Votre informatique interne conserve la maîtrise des applications métier et des approbations — le reste est géré comme un indicateur mesurable, et non comme une simple intention.

Remarque : Cet article ne remplace pas un conseil juridique. Il sert d'orientation initiale ; l'examen contraignant de votre situation doit être confié à des experts.

← tous les guides