Patch management : le jeu du patch et de la souris
Maintenez vos systèmes à jour : voilà bien le seul conseil de sécurité universel que l’on peut donner aux départements IT. Une règle de plus en plus difficile à appliquer alors que les systèmes d’information se complexifient sans que les effectifs ne suivent.
Zero days, vulnérabilité exploitée par un hacker de génie, intrusion dans un système et fuite de données : telle est l’image d’épinal que le grand public se fait de la cyberattaque. La réalité est plus nuancée – et bien souvent moins spectaculaire. Lorsqu’une faille de sécurité est découverte ou rendue publique, c’est rarement la réactivité de l’éditeur de la solution qui pose problème : la mise à disposition d’un correctif est généralement rapide, et la vulnérabilité est labellisée et référencée afin de permettre aux utilisateurs de la solution d’avoir de la visibilité sur la gravité et le risque associés. Reste à appliquer le correctif sur les systèmes concernés, et voilà une affaire rondement menée. Et c’est là que le bât blesse. « La majorité des cyberattaques exploitent des vulnérabilités connues, pour lesquelles un correctif est déjà disponible, nous déclare Maxime Bollia, consultant en cybersécurité chez EY. L’attaquant est rarement le découvreur de la vulnérabilité en question : il se préoccupe surtout de passer les murailles du système pour y déposer le payload qui lui permettra, au choix, de mettre en péril la disponibilité, l’intégrité ou la confidentialité des informations de l’entreprise. Son pari : quoique le correctif existe, il est probable qu’il n’ait pas été appliqué sur les systèmes concernés. »
“Patch fatigue ”
Les raisons sont multiples : le responsable de la gestion des correctifs a parfois des airs de Sisyphe au pied de sa montagne. Le nombre de correctifs appliqués chaque année par une entreprise est conséquent et les ressources qui y sont consacrées sont souvent insuffisantes. L’étude Combating Patch Fatigue de Tripwire sur plus de 450 entreprises apporte un éclairage intéressant sur cette dissymétrie : les équipes interrogées déployaient une moyenne de 188 correctifs par an en 2015, sur un nombre de terminaux qui variait entre 500 et 5 000, en dépit de ressources faibles : moins de cinq personnes dédiées à la gestion et à l’application des correctifs pour plus des deux tiers de ces entreprises.
« La majorité des cyberattaques exploitent des vulnérabilités connues, pour lesquelles un correctif est déjà disponible »
Maxime Bollia consultant en cybersécurité – EY
De fait, la gestion des correctifs est porteuse d’incertitudes pour toute DSI qui gère un parc informatique conséquent :
• le périmètre des actifs est en constante évolution : serveurs, middlewares, terminaux des collaborateurs et collaboratrices, la visibilité nécessaire à l’exhaustivité de la politique de gestion des correctifs ne tolère pas l’approximation ;
• l’efficacité de l’application des correctifs est difficile à déterminer : comment vérifier que le déploiement des correctifs a effectivement fonctionné ? Quels terminaux ont été patchés, lesquels sont en attente de patch ?
• quels correctifs doivent être déployés de manière urgente ?, quitte à interrompre la continuité des activités et risquer des régressions sur le système, et lesquels peuvent supporter une phase de test longue et de la flexibilité dans le déploiement. L’interdépendance des différents composants du système d’information est également un obstacle à une politique cohérente de patch management, comme a pu le constater Maxime Bollia au cours de ses interventions en tant que consultant. « On constate globalement deux freins lorsque l’on analyse la politique de patch en entreprise. Le premier, et certainement le plus important, est lié à l’obsolescence de certains programmes métier qui ne sont plus maintenus par leurs éditeurs. Nous rencontrons régulièrement des systèmes reposant sur des versions obsolètes afin d’utiliser tel ou tel logiciel non maintenu et dont la dernière mise à jour de sécurité date d’il y a plusieurs années. Le second frein est le coût du patch. Il arrive qu’un patch nécessite une refonte applicative ou une migration système ; dans ces cas, le motif financier est souvent avancé afin de justifier l’acceptation du risque. » Que faire dans ce cas là ? « Lorsque le patch est impossible, il est conseiller d’isoler les systèmes au maximum. » Au risque qu’un attaquant parvenant à s’introduire dans le système d’information ait les mains libres sur des vulnérabilités critiques.
Déployer ou ne pas déployer, that is the question
La question de l’urgence du correctif est centrale : l’arbitrage entre les risques liés à l’application et la non application du correctif nécessite une excellente connaissance de son SI et des besoins des collaborateurs et des clients. Matthias Dugué, tech evangelist chez l’hébergeur Alwaysdata, nous explique ainsi que son entreprise doit gérer deux types de déploiements :
« Nous devons gérer un arbitrage fin entre répondre à notre promesse de disponibilité et assurer la sécurité de leurs actifs »
Matthias Dugué tech evangelist – Alwaysdata
ceux qui sont propres à la plate- forme d’hébergement développée en interne, et dont Alwaysdata maîtrise le cycle de release, et ceux qui sont propres à la stack ( PHP, MYSQL, Debian), dont le cycle de releases est maîtrisé par les vendeurs. « Nos clients nous font confiance pour assurer la disponibilité de leurs sites et de leurs applications, et nous devons gérer un arbitrage fin entre répondre à notre promesse de disponibilité et assurer la sécurité de leurs actifs. En cas de découverte d’une faille de sécurité sur la plate- forme, nous commençons par patcher la plate- forme Alwaysdata que nous utilisons en interne, et dont nous sommes les seuls utilisateurs : en fonction de la criticité, la phase de test dure quelques heures à quelques semaines avant le déploiement du patch sur toutes les machines mutualisées, puis sur les clients en VPS ou en dédié. Nous patchons donc progressivement le système existant et une fois que nous avons l’assurance qu’il n’y a pas de régression, nous intégrons le patch à la codebase. C’est une approche hétérodoxe, très inspirée du Devops, mais qui fonctionne depuis 14 ans ! » La gestion des outils externes se fait également sur un souci de priorisation : « Pour la distribution et le noyau, nous privilégions la stabilité, mais nous sommes sur les rolling releases sur PHP ou Python qu’on compile et qu’on déploie, car les besoins clients sont forts sur l’hébergement. »
Patcher le patch management
Alors, comment dompter intelligemment sa gestion des correctifs ? La réponse tient en deux grands principes : anticipation et automatisation. L’anticipation est un aspect clef : les équipes ne doivent pas avoir à se poser les mêmes questions à chaque sortie de correctif – comment et sur qui le correctif va- t- il être testé ?, combien de temps ?, comment mesurer son impact ?, quelle flexibilité laisser sur les terminaux invididuels ?
Une discussion avec vos équipes vous permettra de faire émerger les questions qui se posent en permanence afin de formaliser des réponses et définir des processus de travail robustes et reproductibles. L’automatisation, quant à elle, permet d’améliorer la productivité des équipes IT et de diminuer la réticence au patch management. La dimension manuelle de la gestion des correctifs est aujourd’hui la cause principale du découragement des équipes, malgré les nombreux outils d’automatisation de gestion des correctifs sur le marché. Ces outils automatisent le téléchargement des correctifs et leur déploiement par le réseau, répondant ainsi au besoin de visibilité, de traçabilité des actions effectuées, et de rapidité de déploiement des équipes IT. Une dernière piste prometteuse : les services de predictive patching : ils permettent d’anticiper le taux de réussite de l’application d’un correctif en analysant en amont les causes habituelles d’échec ( terminaux déconnectés, licences expirées, identifiants invalides…) et font gagner un temps précieux aux équipes. Maxime Bollia nous rappelle cependant la limite de toute automatisation de processus. « On ne peut patcher que ce dont on connaît l’existence. La cartographie exhaustive de son SI et la maîtrise de la shadow IT restent des prérequis que la mise en place d’un système d’automatisation ne doit pas faire oublier. » Une leçon à garder en tête à l’heure où les SI se complexifient pour répondre aux nouveaux besoins des collaborateurs et collaboratrices. ✖