Gestion des vulnérabilités en environnements virtualisés

Tout le monde le sait (et bien sur le fait) : Dès qu'une nouvelle vulnérabilité est annoncée, une cellule se constitue et mène une étude d'impact pour définir la stratégie de réponse afin de minimiser les potentiels effets néfastes qu'une exploitation de cette faille pourrait avoir.
Dans le cadre d'une grande entreprise, on retrouve classiquement deux "équipes" suivant ce processus en parallèle : D'un coté l'équipe réseau et de l'autre ; celle en charge des serveurs et applicatifs. La 2nde équipe gère typiquement des environnements hétérogènes et très variés ; la charge induite par ce processus d'analyse de risque (et de déploiement des contre-mesures) est clairement un challenge sans cesse renouvelé.
Dans le contexte des infrastructures de type IaaS, cet exercice "gestion des vulnérabilité" est encore plus complexe : La couche de virtualisation ajoute une complexité supplémentaire que l'on ne retrouve pas ailleurs. Comme nous le verrons, les entreprises ayant fait le choix des cloud privés ainsi que celles utilisant massivement la virtualisation en interne ont un certain avantage.
Rappel de la problématique
Mettons-nous dans la situation ou une vulnérabilité est annoncée au niveau de la couche de virtualisation. Pour simplifier, nous considérerons que cette faille est assez critique et nécessitera tôt ou tard une mise à jour des systèmes concernés.
Décomposition en 3 couches d'un environnement virtualisé
Dans un environnement virtualisé de type IaaS, la gestion des vulnérabilités peut être décomposée selon 3 grands niveaux (chacun d'entre-eux ayant un nombre distintc d'instances) :
Couche #3 : Les services applicatifs ("n" services localisés au sein d'un même hôte/système virtuel)
Couche #2 : Les systèmes d'exploitation ("p" systèmes virtuel contrôlés via un même hyperviseur)
Couche #1 : Le logiciel de virtualisation ("1" seul et unique logiciel sur une machine physique)

Etude d'impact : Tout commence par l'identification des biens ou "assets"
Dès le démarrage de l'étude d'impact, on identifie les ressources ou biens ("assets") à protéger et c'est au regard du niveau d'importance qu'ont ces biens pour l'activité de l'entreprise que les conclusions de l'analyse d'impact vont pencher pour une solution ou un autre.
Comme nous allons le voir, c'est ici que la problématique réside
Cas d'une entreprise utilisant la virtualisation
Dans le cas d'une société opérant en interne une infrastructure virtualisée pour ses serveurs de production, celle-ci devra utiliser les fiches de recensement afin d'apprécier le niveau d'importance d'une plateforme plutôt qu'une autre.
Dans ce cas, l'ensemble des informations nécessaires à la prise de décision sont connues (Couches 1 à 3) et il sera possible de plannifier les interventions programmées en avertissant les directions métiers ou les utilisateurs.
Après un déploiement du correctif sur les environnements de pré-production ; suivi d'une période d'observation ; les environnements de production seront graduellement mis à jour en fonction de leur niveau d'importance.
Intéressant de voir que dans le contexte de la virtualisation, le niveau de criticité d'une instance d'un hyperviseur est au minimum égal à celui de l'application la plus critique. Cela devrait faire "tilt" et donc militer pour un savant regroupement/répartition des applicatifs critiques sur des hyperviseurs différents.

Entreprise utilisant un service de type "cloud privé"
A priori, la société ou le prestataire opérant le cloud privé ne connait pas le niveau de criticité des applicatifs métiers déployés par le client sur ses systèmes virtuels. Le niveau de granularité que le prestataire possède pour réaliser son analyse de risque s'arrête à la couche "2" ou bien à d'autres informations utiles connues préalablement.
Classiquement, le prestataire va travailler selon le nombre de VM (éléments de couche 2) pour définir de l'ordonnancement de ses travaux. Les éléments contractuels rentrerons bien évidemment en ligne de compte.
Selon le niveau de service souscrit et le niveau de maturité et de transparence du prestataire, le client sera partie prenante de la prise de décision. C'est l'un des "plus des clouds privés.
Une fois l'innocuité du correctif testé par ses ingénieurs, le déploiement pourra par exemple débuter graduellement par les environnements les moins critiques jusqu'au moment ou les équipes seront pleinement confiantes et procéderont au déploiement plus général.
Le sérieux et la réputation du prestataire font ici toute la différence : Une société ayant des années d'expérience dans le domaine du management de plateformes d'hébergement sera clairement plus à même de faire cela correctement que le premier venu dans le marché du cloud. Après, ne pas céder aux chants des sirènes ou au "fuzz marketing".
Entreprise s'appuyant sur un cloud public
Dans un contexte de service, les liens entre le prestataire et le client sont des plus ténus et se limitent à des interfaces web, des factures et à des interventions uniquement au niveau des VM.
Le prestataire n'a aucune visibilité (et ne doit d'ailleurs pas en avoir) sur les applicatifs déployés au sein ds VM hébergées. La "mixité" de VM de différents clients (et donc de niveau de criticité différentes) au sein d'un même hyperviseur rends l'exercice d'analyse d'impact très proche d'un jeu de colin-maillard
En effet, dans un cloud public, seul le nombre de VM ou des caractéristiques externes mesurables par le prestataire (nbre d'I/O, débit réseau, usage CPU, ...) pourront lui permettre d'apprécier qu'une telle VM est plus "utilisée" qu'une autre... une application critique peu gourmande en ressources verra donc son important "sous-estimée" par rapport à un système hébergeant une application en cours de développement et présentant des problèmes de performance...
Les niveaux de service sont génériques pour tous les clients et impossible de "plaider son cas" pour un traitement spécifique. Assez souvent, pas ou très très peu de visibilité sur ce qui est fait ou pas au sein du prestataire.
En conclusion
La mise en perspective de la gestion des vulnérabilités dans le contexte des services de type IaaS lève un certain nombre de problématiques qui sont loin d'être aussi faciles que cela à résoudre.
La solution du "cloud privé" ou d'un "cloud semi-privé" réservé à des usages de niveau de criticité similaires peut aider à trouver des réponses pragmatiques aux besoins de sécurité tout en restant économiquement viables.
Dans tous les cas, il est important de préciser quelles sont les pratiques de son prestataire et de s'assurer que les éléments clefs sont contractuellement spécifiés et qu'ils sont l'objet d'un reporting régulier.
Certains diront que la sécurité a un coût et ils ont bien raison : A chacun de souscrire au service correspondant au niveau de sécurité attendu et leur appétence au risque.