Sécurité du Cloud : to patch or not to patch…

spam Trend Micro a publié un livre blanc, intégrant les recommandations de Gartner en matière de sécurité du Cloud, et plus précisément d’AWS. Véritable vademecum pour toutes les organisations qui veulent comprendre les principes de sécurité de ce cloud et mettre en place les bonnes pratiques qui s’imposent, ce document se veut avant tout didacticiel. Parmi les recommandations, il y en a une à priori quelque peu étonnante sur les opérations de patching…

Revenons en avril 2014. La vulnérabilité Heartbleed est rendue publique et ce n’est guère un poisson d’avril. Elle permet aux cybercriminels de détourner des informations sensibles à partir de ressources mémoire, en utilisant un défaut dans le handshake SSL avec toute application utilisant OpenSSL. Une réelle problématique, la bibliothèque OpenSSL étant utilisée dans de très nombreuses applications dans le monde!

En premier lieu, bien sûr, vous devez savoir si vous êtes affectés par une telle vulnérabilité, via un outil ou service d’analyse de vulnérabilités qui permet d’identifier les environnements ou applications impactés. Mais que faire après ? Les experts de Gartner recommandent … ne pas déployer de patch !

Livrée telle quelle, cette recommandation est quelque peu troublante. Mais à vrai dire, elle ne signifie pas que vous ne devez pas restaurer les vulnérabilités identifiées et laisser vos serveurs vulnérables. Il s’agit en fait de ne pas patcher les systèmes en environnement de production! Gartner incite ainsi les équipes informatiques à tester les patchs avant tout déploiement, pour éviter tout risque d’indisponibilité fortuite sur les systèmes en opération. L’idée est en fait que les templates à partir desquels sont dérivées les charges de travail doivent être patchés en permanence. Lorsqu’un système en production doit être patché à son tour, il est remplacé/régénéré à partir des templates sous-jacents, dans l’idéal via des scripts d’automatisation.

Mais qu’en est-il de la vulnérabilité pendant cette période de test ?

C’est tout l’intérêt du virtual patching, grâce à un système de prévention des intrusions comme Deep Security, capable d’identifier les vulnérabilités et neutraliser toute fenêtre de vulnérabilité. L’application d’un patch virtuel permet de prévenir rapidement toute exploitation de vulnérabilité et neutralise les tentatives d’intrusion et d’exfiltration de données.
Si ce mode opératoire est valable pour nombre d’applications, il peut néanmoins présenter certains freins pour les applications existantes qui ont migré dans le cloud. Dans ce cas, l’application de patchs virtuels peut s’effectuer sur l’environnement de production, tandis que le test des patchs officiels s’effectuera sur un espace de staging.

Pour accéder à ce livre blanc et découvrir les autres recommandations et bonnes pratiques de Gartner, c’est par ici (en anglais).

Leave a Reply

Your email address will not be published. Required fields are marked *