ASafety - AntiSecurity Un projet qui vous tiendra @coeur...

[x[@♥]]

Si la virtualisation introduit bien des risques techniques nouveaux, ce ne sont pas ces attaques là que craignent le plus les RSSI de SecurityVibes. Les vrais problèmes sont à chercher selon eux plutôt du côté de la ré-organisation imposée aux équipes et de leur (non) formation.
Sommaire
Virtualisation : la présentation de Nicolas Ruff
Virtualisation : Les risques humains
Virtualisation : Etat de l'Art des attaques techniques

Quels sont les risques avérés de l'usage de la virtualisation ? Le quatrième petit-déjeuner organisé à Paris par SecurityVibes avait pour objectif de faire le point de manière concrète sur les dangers d'une virtualisation toujours plus courante, et bien souvent imposée aux RSSI. A l'ordre du jour : éviter les lieux communs souvent associés à la question et aborder plutôt des risques moins discutés jusqu'à présent.

Après une présentation consacrée aux risques techniques avérés conduite par Nicolas Ruff, du laboratoire de recherche sécurité d'EADS, les RSSI ont abordé l'aspect organisationnel et les risques humains liés à la virtualisation qu'ils rencontrent au quotidien.

Nouveaux risques techniques parfois très pointus d'un côté, manque de préparation des équipes de l'autre, et au milieu absence de maîtrise des outils, mauvaises configurations et support limité des éditeurs de solutions métier : ce quatrième petit-déjeuner SecurityVibes a montré que le paysage sécurité de la virtualisation est très complexe. Et qu'il a le potentiel de le devenir plus encore si l'on tente d'y ajouter les obligations réglementaires à l'équation.

Virtualisation : Les risques humains

Au delà des failles techniques, les changements dans l'organisation des équipes et leur nécessaire montée en compétence représentent les vrais risques de la virtualisation pour les RSSI de SecurityVibes.
Sommaire : Virtualisation : risques techniques, risques humains
Virtualisation : la présentation de Nicolas Ruff
Virtualisation : Les risques humains
Virtualisation : Etat de l'Art des attaques techniques

"Avec la virtualisation, on donne des responsabilités supplémentaires à des collaborateurs qui ne sont pas forcément taillés pour les assumer", constate l'un des participants. Et de fait un administrateur système à qui l'on confie les clés de l'hyperviseur devient également administrateur réseau... sans y être toujours préparé !

Un nouveau métier

C'est d'ailleurs un tout nouveau métier qui semble naître avec la virtualisation. "Le responsable l'hyperviseur doit connaître à la fois le système, le réseau et le stockage. C'est une nouvelle fonction qui exige de plus grandes compétences que celles qui étaient demandées jusqu'à présent", confirme un autre RSSI.

Mais cette nécessité peut aussi être vue comme une opportunité : "nous ne cherchons pas forcément à reproduire l'organisation existante, avec ses spécialistes isolés. Le passage à la virtualisation peut aussi être l'occasion d'optimiser ou de réduire les équipes", avance un autre participants. Ainsi, avec la consolidation des serveurs viendrait celle des équipes, contraintes de diminuer en taille et de monter en compétence ?

A noter toutefois, signale un membre de SecurityVibes, l'approche à contre courant adoptée par Xen, qui aurait plutôt tendance à dédier un environnement virtuel spécifique et séparé aux administrateurs du réseau virtuel, qui retrouvent alors leurs habitudes et conservent leur rôle.

Pour les plus optimistes, la consolidation des équipes, qui reste la tendance majoritaire, est toutefois bonne nouvelle : "c'est l'occasion de briser le cloisonnement entre les domaines des systèmes, du réseau et du stockage puisque le même expert sera désormais confronté aux contraintes de tous ces spécialistes à la fois", observe un RSSI.

Mais s'il n'est pas possible de trouver la perle rare multi-talents, quel profil privilégier ? "Si je devais recruter une seule personne pour gérer l'hyperviseur, je prendrais un profil réseau / sécurité. Car le reste, si les builds et le provisionning sont bien encadrés, ça marche tout seul", avance un autre participant.

Mais hormis le cumul des compétences exigé des équipes, la virtualisation change-t-elle vraiment quelque chose au quotidien du RSSI ? "Je n'ai pas cette impression : on ajoute certes un composant actif critique. Mais n'a-t-on pas déjà des processus pour garantir la sécurité de tels composants ?". Une approche pleine de bon sens, mais que d'autres RSSI ont tout de même tempéré, notamment à cause de l'incapacité de nombreux éditeurs à assurer aujourd'hui encore le support de leurs solutions en environnement virtualisé. "Beaucoup d'entre nous subissent la roadmap des éditeurs qui ne supportent pas encore la virtualisation, et nous ne pouvons donc virtualiser comme nous le voudrions, ou en toute sécurité", ont fait remarqués deux participants. Les protections logicielles, et notamment les "dongles" physiques, par exemple, posent bien entendu les plus gros casse-tête dans ce domaine.

Et la conformité ?

La question de l'impact de la virtualisation sur les obligations réglementaires a également été abordée grâce à l'expérience de participants ayant eu maintenir leur conformité SOX et PCI-DSS alors que les systèmes cibles étaient virtualisés. "Pour SOX cela ne change pas grand chose", témoigne un participant. "Il faudra toutefois réécrire les procédures liées au stockage, notamment, car la virtualisation change la manière dont les données sont stockées".

En ce qui concerne PCI-DSS en revanche les choses peuvent être différentes. "Parce que la virtualisation touche aux politiques d'accès et de journalisation, et donne beaucoup plus de pouvoir à l'administrateur, l'impact sur la norme peut être plus important selon les cas", met en garde un participant.

Et cela sans compter la segmentation des réseaux, une notion-clé dans PCI-DSS, qui pourra être modifiée par la virtualisation : si une seule machine virtuelle traite des données bancaires, faut-il alors considérer tout le châssis (et donc les autres machines virtuelles) comme faisant partie du périmètre PCI ? Personne n'a semblé avoir de réponse définitive à cette question lors de notre débat. Toutefois, selon Eric Domage, d'IDC a prévenu : "certains QSA en Angleterre commencent à demander une cartographie des machines virtuelles, même si le conseil PCI ne le demande pas encore".

Cela pourrait cependant être bientôt le cas : le conseil PCI s'est penché sur le sujet de la virtualisation et il est censé rendre ses premières observations ce mois-ci.

Virtualisation : Etat de l'Art des attaques techniques

La présentation de Nicola Ruff à l'occasion du petit-déjeuner SecurityVibes consacré à la sécurité de la virtualisation. Des attaques complexes, mais bien réelles.
Sommaire : Virtualisation : risques techniques, risques humains
Virtualisation : Les risques humains
Virtualisation : Etat de l'Art des attaques techniques

Nicolas Ruff, chercheur au laboratoire de R&D sécurité d'EADS, a ouvert ce quatrième petit-déjeuner SecurityVibes par une présentation des risques techniques spécifiques aux environnements virtualisés.

Argument principal : l'incroyable quantité de lignes de code ajoutée par la virtualisation augmente naturellement la probabilité d'une vulnérabilité exploitable. "La virtualisation augmente la surface d'attaque du sytème invité, ne serait-ce qu'à cause des outils qui lui sont ajoutés", explique le chercheur. Des additions tels les VMware Tools, par exemple, peuvent affaiblir le sytème invité. Un attaquant qui aurait obtenu un accès non privilégié à un système via la vulnérabilité d'une application web, par exemple, pourrait exploiter une faille d'un outil tel les VMware Tools afin d'augmenter ses privilèges sur le système, chose impossible si ce dernier n'est pas virtualisé (et il s'agit là d'un scénario déjà rencontré). Cas isolé pour autant ? Même pas : l'ajout par VMware de code spécifique au support 8086 dans les environnements 64 bits a, là aussi, déjà donné lieu à une vulnérabilité d'élevation de privilèges de ce type.

Nicolas Ruff est ensuite revenu sur le rôle central joué par l'hyperviseur, autre source de vulnérabilités potentielles. "Même si l'hyperviseur est conçu pour être sûr et fiable, il ne faut pas oublier qu'il fonctionne le plus souvent sur un système d'exploitation complet, qui souffre des vulnérabilités qui lui sont propres" poursuit le chercheur. Et s'il n'ignore pas, comme sa présentation le rappelle très justement, que les puristes préféreront séparer l'hyperviseur de l'hôte (selon le concept du "Bare-Metal Hypervisor"), c'est en pratique peu souvent le cas et c'est plutôt un bon vieux Windows ou Linux complet qui anime le tout. Et ces systèmes ne sont pas toujours adaptés aux exigences de la tâche : des vulnérabilités telles le bug WxH, qui permettait de faire crasher l'hyperviseur de différentes manières depuis un invité, ou encore la vulnérabilité du vénérable éditeur ed qui a étonamment impacté VMware, ont montré qu'un système d'exploitation traditionnel n'était pas forcément le bon choix pour animer l'hyperviseur en toute sécurité.

Bien entendu, encore faut-il à l'attaquant être en mesure d'accèder au dit hyperviseur. Qu'à cela ne tienne : plusieurs attaques permettant l'évasion d'une machine invitée vers la machine hôte ont également été démontrées par le passé (Joanna Rutkowska sur Xen, ou la vulnérabilité VMware automatisée par Cloudburst, par exemple).

Enfin, toutes ces attaques peuvent être amplifiées, ou facilitées, par le manque de maîtrise de l'outil, devenu très complexe : "VMware, par exemple, dispose de très nombreuses options non documentées, au point qu'il faille analyser le code binaire pour découvrir le nom de ces options", poursuit Nicolas Ruff. Et parmi les options pourtant documentées, certaines peuvent avoir un impact sur la sécurité sans que les opérateurs n'en maîtrisent les détails. Qui fait par exemple la différence entre virtualisation logicielle ou matérielle, plutôt que de laisser le réglage "automatique" par défaut ? "On ne comprend rien à la configuration et on ignore l'impact sur la sécurité d'une erreur de configuration" confirmera d'ailleurs plus tard un participant lors du débat.

Ces risques, toutefois, sont à temperer par la complexité des opérations nécessaires à une exploitation réussie. C'est vrai pour la virtualisation basée sur du logiciel (VMware), mais plus encore pour les solutions basées sur de la virtualisation matérielle (Hyper-V). Toutefois là aussi, les attaques existent (voir le bug du chipset Q35 publié par Joanna Rutkowska, ou les discussions autours d'attaques contre le CPU lui-même) et il serait dangereux de les ignorer.

Pour autant, inutile de paniquer : les vulnérabilités traditionnelles des systèmes virtualisés, les failles liées à l'humain (manque de formation) ou les erreurs de configuration sont encore tellement présentes que les attaques pointues décrites ici seront a priori encore difficiles à observer à grande échelle pour un certain temps.

La présentation ici!

Source de SecurityVibes par Jerome Saiz.