Germanwings : Les enseignements en matière de sécurité

Quel rapport y-a-t-il entre le crash de l’Airbus A320 de la Germanwings et la sécurité informatique ? A priori aucun d’autant que la cause d’origine technique semble définitivement écartée. Il y a cependant beaucoup d’enseignements à retenir lors d’un tel accident que l’on peut appliquer directement à la sécurité de l’information.

J’anime depuis plus de 20 ans des séminaires sur la sécurité informatique et j’utilise bien souvent dans mes exemples des analogies avec la sécurité routière car à y regarder de plus près les principes fondamentaux sont les mêmes : Il y a des risques (accidents), des mesures de sécurité (ceinture de sécurité, ABS, campagne TV de prévention, etc…), des contrôles (gendarmes, radars, alcotest, etc…) mais aussi hélas des impacts potentiels (contraventions, blessures, décès). Dans le domaine de la sécurité aérienne, on retrouve les mêmes concepts et tout comme dans le domaine de la SSI, après chaque catastrophe, on essaie d’en tirer les leçons pour diminuer les accidents sachant que la probabilité d’occurrence est faible mais que les impacts sont très lourds (150 morts dans le cas du drame de la Germanwings). Ainsi, après les attentats du 11 septembre, les autorités aériennes, EASA (Agence de sécurité aérienne européenne) et FAA (agence américaine) ont demandé aux acteurs de l’aérien de travailler ensemble sur un système permettant de verrouiller le cockpit afin que personne de l’extérieur ne puisse ouvrir la porte même sous la contrainte d’une arme. C’est la raison pour laquelle les cockpits disposent aujourd’hui d’une porte blindée et d’une option de verrouillage (Lock). Lorsque la porte est verrouillée, même le code confidentiel connu exclusivement par le personnel habilité (PNC) ne permet pas d’entrer dans le cockpit. Le problème évidemment est que si la menace est à l’intérieur même du cockpit et que le mécanisme de sécurité est enclenché, on court tout droit à la catastrophe. C’est ce que l’on appelle dans le jargon de la SSI : une menace liée à une malveillance interne (malicious insider threat). Cette menace existe partout (dans l’administration, la police, l’armée, les entreprises privées, etc…) et il ne faut jamais la négliger au risque d’en payer le prix fort. Le cas d’Edward Snowden à la NSA l’illustre très bien même si Snowden n’était pas un agent de la NSA mais un simple prestataire externe.
Et qu’en est-il chez un prestataire de Cloud me direz-vous ? Et bien exactement la même chose ! Même si l’on recrute avec la plus grande prudence (enquête de moralité, antécédents judiciaires inscrits au TAJ, etc…) et que l’on rajoute des clauses de confidentialité dans le contrat de travail, le risque existe toujours. Mais ce risque existe aussi bien sûr lorsque nos données sont gérées en interne. J’ai d’ailleurs rencontré récemment une entreprise française qui désirait externaliser des données dans le Cloud car elle estimait que le risque lié à des administrateurs indélicats était supérieur aux risques induits par le Cloud. Les données en question concernaient un projet de plan social et les dirigeants ne souhaitaient pas que des fuites d’information puissent parvenir aux syndicats de l’entreprise.
Revenons à la sécurité aérienne, on a donc mis en œuvre une mesure de sécurité pour réduire le risque lié à une menace externe (des terroristes en cabine) mais dont les conséquences entrainent une augmentation du risque lié à la malveillance interne. C’est bien toute la difficulté de la sécurité : une mesure de sécurité n’annule pas un risque, elle le diminue et il reste toujours un risque résiduel. Ce risque résiduel sera-t-il acceptable ? Si tel est le cas, la mesure de sécurité sera suffisante. Dans le cas contraire, on devra songer à une autre mesure de sécurité en complément ou en remplacement de la première. D’autre part et on le voit bien dans l’exemple aéronautique, une mesure de sécurité peut entrainer de nouveaux risques. Il convient alors de bien identifier tous les effets de bord d’une mesure de sécurité pour s’assurer qu’un risque nouvellement créé ne soit pas supérieur au risque initialement traité. Dans le contexte actuel où la menace terroriste est particulièrement forte, il est évident que les passagers sont plus en sécurité dans un avion équipé d’un cockpit sécurisé. Pour autant, peut-on accepter qu’un des deux pilotes puisse à lui tout seul décider de la vie ou de la mort de 150 personnes ? Et voilà que les compagnies aériennes se précipitent vers une nouvelle mesure de sécurité : La présence obligatoire d’une hôtesse de l’air ou d’un steward dans le cockpit lorsqu’un pilote s’absente. Première interrogation : la mesure de sécurité est-elle efficace ? Une hôtesse sera-t-elle en mesure d’empêcher le pilote de « crasher » l’appareil ? A priori non, le risque résiduel est donc inacceptable. J’entendais un expert en sécurité aéronautique dire ce matin sur BFMTV : « Cela n’empêchera sans doute pas le pilote d’agir mais la mesure apportera un réconfort psychologique auprès des passagers ». En d’autre terme, ce qui compte ce n’est pas d’être sécurisé mais simplement le sentiment d’être sécurisé et il y a de fortes chances que cette mesure soit adoptée par toutes les compagnies aériennes. En effet, si les clients ont peur, ils auront une tendance naturelle à éviter de prendre l’avion. Pour les trajets courts, ils pourront par exemple privilégier le train. Pour les compagnies aériennes comme pour les fournisseurs de Cloud, un client qui a peur est un client qu’il sera difficile de convaincre ou de fidéliser et donc un réel frein au business. Il faut donc rassurer et donner le sentiment de sécurité même si le niveau réel n’a pas vraiment évolué. Mais le fait de faire rentrer une autre personne dans le cockpit n’entraine-t-il pas un nouveau risque ? Sachant qu’il y a, dans le cockpit, une hache (destinée en cas d’accident à arracher une cloison), on peut facilement imaginer un scénario dans lequel un steward terroriste pourrait s’isoler dans le cockpit et se débarrasser facilement du pilote avec cette arme. Ce nouveau risque a-t-il été soigneusement étudié ? Il serait certainement plus sage que tous les acteurs de la navigation aérienne se concertent et définissent ensemble la mesure la plus appropriée. On peut en effet imaginer d’autres réponses comme par exemple un code spécifique pour les pilotes ou un lecteur biométrique (iris) pour déverrouiller la porte même en position lock. Pourquoi ne pas envisager une reprise du contrôle à distance de l’avion par les autorités lorsque les pilotes ne répondent plus et que l’avion part visiblement au crash. On n’imagine bien sûr dans ce cas, un niveau de sécurité comparable au pilotage d’un drône militaire et les actions possibles limitées à faire atterrir l’avion sur l’aéroport le plus proche. Bien sûr aucune mesure n’est infaillible et le risque zéro n’existe pas mais à chaque incident ou accident, on doit toujours prendre le temps de bien analyser toutes les causes et en tirer les conséquences afin d’améliorer sans cesse la sécurité. Et s’il faut encore se rassurer, il suffit de regarder les chiffres pour constater que le transport aérien reste encore un des moyens de transport le plus sûr au monde.




Bonnes pratiques SSL/TLS : Les Clouds français sont-ils à la hauteur ?

Titre_SSL_Cloud_French

[ Introduction ]             [ Résultats ]            [ Analyse ]             [ Conclusion ]


Introduction

Pour créer et administrer des machines virtuelles dans un IaaS public, les fournisseurs mettent à disposition de leurs clients des interfaces Web accessibles via le protocole sécurisé https. Ces interfaces sont des éléments particulièrement sensibles car elles sont accessibles publiquement sur Internet et leur compromission permettrait à un attaquant de prendre le contrôle total de nos machines dans le Cloud.

Le problème est que le protocole https utilise des fonctions cryptographiques (SSL/TLS), historiquement développées par Netscape au début des années 90 et que ces fonctions cryptographiques ont subi ces dernières années de nombreuses attaques : attaque sur la renegociation, attaque sur RC4, collision MD5, BEAST, CRIME, POODLE, etc… Il y a également d’autres problèmes non pas liés à la cryptographie SSL elle-même mais plutôt à de mauvaises implémentations logicielles comme par exemple le bug dans OpenSSL (Heartbleed) mais aussi celui dans la librairie open source utilisée par Apple (goto fail). Et les problèmes ne sont pas terminés comme en témoigne l’annonce de 8 nouvelles vulnérabilités dans OpenSSL le 8 janvier 2015 dont l’une d’elles permet de réaliser l’attaque SSL/TLS du moment : FREAK (Factoring attack on RSA-Export Keys).

Nous avons donc décidé de vérifier si les interfaces d’authentification de 4 fournisseurs IaaS français (OVH, Numergy, Cloudwatt et Nuage_Made_in_FranceOutscale) étaient correctement paramétrées d’un point de sécurité. En d’autres termes, les fournisseurs nationaux respectent-ils les bonnes pratiques de sécurité concernant les flux chiffrés SSL/TLS.

Nos tests ont porté exclusivement sur la gestion des flux chiffrés. Il ne s’agit en aucun cas d’un audit de sécurité, ni d’un test d’intrusion mais tout simplement d’une vérification de la configuration SSL/TLS. Les vulnérabilités spécifiques aux applications Web (XSS, CSRF, SQL injection, etc…) n’entrent pas dans le périmètre de notre étude.

Pour ce faire, nous avons utilisé sur www.ssllabs.com, un outil gratuit et disponible publiquement sur Internet proposé par Qualys. Il a été développé par Ivan Ristic, le concepteur du pare-feu applicatif mod_security.

Son utilisation est très simple. On soumet le nom du serveur à tester à ssllabs et le service effectue une vérification approfondie de la configuration SSL/TLS de la cible et délivre une note globale de sécurité sous forme d’une lettre de A à F.

Il faut ensuite interpréter les résultats de la façon suivante :

ssllabs_A+   ssllabs_A   ssllabs_A-
Excellente configuration SSL/TLS
Aucune vulnérabilité connue n’est exploitable

ssllabs_B   ssllabs_C   ssllabs_D   ssllabs_E
Mauvaise configuration SSL/TLS
Une ou plusieurs vulnérabilités peuvent compromettre la session

ssllabs_F
Très mauvaise configuration SSL/TLS
Une ou plusieurs vulnérabilités facile à exploiter peuvent compromettre la session

Compte tenu de la criticité de ces interfaces Web dans l’infrastructure Cloud, il va sans dire que pour un fournisseur de IaaS public, on ne s’attend pas à autre chose que la lettre A. Une note A+ serait bien sûr idéale mais un A- sera tout à fait acceptable. Les lettres B, C, D et E indiquent quelques lacunes en matière de sécurité sur lesquelles le fournisseur doit agir assez rapidement. La lettre F traduisant quant à elle de graves lacunes de sécurité sur lesquelles le fournisseur n’a apparemment réalisé aucune évaluation de sécurité et doit maintenant intervenir dans les plus brefs délais. Précisons enfin qu’il n’y a aucun coût financier pour passer de la lettre F à la lettre A (Pas d’obligation d’acquérir un certificat SSL EV ou un boitier HSM). Il faut simplement effectuer quelques modifications dans les paramètres SSL/TLS des serveurs et l’opération ne prend que quelques minutes.

Nous avons également regardé comment les clients arrivent sur la page d’authentification du service. Si le lien vers la page d’authentification s’effectue via le site Web du fournisseur lui-même accessible uniquement en https alors l’accès à l’interface d’administration est correctement sécurisée. Par contre si l’accès se fait via une page Web en http alors la connexion sera potentiellement vulnérable. Pourquoi ? Parce qu’un site Web accessible via le protocole http signifie qu’aucune authentification du serveur n’est réalisée par le navigateur. L’attaquant peut ainsi très facilement réaliser une attaque de type Man In The Middle (MITM) et substituer ainsi la page d’authentification originale par une page frauduleuse par une simple réécriture d’URL à la volée. Une telle attaque ne pose pas aucune difficulté et plusieurs outils existent pour la réaliser comme par exemple sslsnif et sslstrip de Moxie Marlinspike.

D’autre part, tout site Web accessible via http est beaucoup plus vulnérable aux opérations de phishing toujours en raison de l’absence d’authentification du serveur. En conclusion, même si son contenu n’est pas confidentiel (chiffrement des flux non nécessaire) l’intégralité du site Web du fournisseur doit être uniquement accessible via le protocole https.


Résultat des tests

Classement CSP

Les copies d’écran du test ssllabs.com sont disponibles sur cette page.


Analyse des résultats

CloudwattCloudwatt propose un accès correctement sécurisé pour ses services. Toutes les erreurs classiques de paramétrage d’un serveur https ont été évitées. On regrettera cependant l’absence de certificat à validation étendue (Certificat SSL EV) permettant d’accroître la confiance dans le site. En effet avec un certificat SSL, identifiable par le cadenas en vert dans la barre d’adresse, l’utilisateur connaît immédiatement quelle société se trouve derrière le site par l’affichage de son nom et du pays dans lequel elle réside. D’autre part, la délivrance d’un certificat SSL EV par une autorité de certification fait l’objet de contrôles bien plus rigoureux sur l’organisme demandeur (existence juridique de 3 ans minimum, inscription au RCS, etc…) que pour un certificat SSL classique ou seule la possession du nom de domaine peut s’avérer suffisante.

4 recommandations pour améliorer la sécurité de Cloudwatt :

  • Remplacer les certificats X509 standards par des certificats SSL EV
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur le serveur
  • Ne pas se contenter de faire un http redirect vers https et forcer le protocole sécurisé avec HSTS (Strict Transport Security – RFC 6797)

Outscale

Outscale n’utilise pas non plus de certificat SSL EV. D’autre part, la configuration laisse apparaître la disponibilité du protocole SSL v3 qui est obsolète et surtout extrêmement vulnérable depuis la découverte en octobre 2014 d’une vulnérabilité dénommée POODLE.

5 recommandations pour améliorer la sécurité de Outscale :

  • Corriger immédiatement les problèmes de configuration SSL/TLS sur toutes les interfaces Web en particulier désactiver le protocole SSLv3
  • Remplacer les certificats X509 standards par des certificats SSL EV
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur le serveur
  • Ne pas se contenter de faire un http redirect vers https et forcer le protocole sécurisé avec HSTS (Strict Transport Security – RFC 6797)

OVHOVH dispose d’une configuration SSL correcte et utilise de plus des certificats SSL EV. Dommage que le site www.ovh.com soit toujours accessible via http.

5 recommandations pour améliorer la sécurité du Cloud OVH :

  • Mettre l’intégralité du site accessible uniquement via https
  • Pour les accès en http sur la page d’accueil, faire une redirection (HTTP redirect) vers https
  • Positionner le flag HSTS (RFC 6797) pour forcer le navigateur à utiliser exclusivement https
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur le serveur

Numergy

Pour Numergy, tout commence bien avec l’apparition d’un certificat SSL EV sur la page d’accueil du site (www.numergy.com). On passe ensuite sur la page d’authentification (login.numergy.com) qui elle n’utilise pas de certificat EV. Les choses se compliquent ensuite puisque l’analyse détaillée de la configuration révèle de graves lacunes de sécurité.

Pour la page d’authentification du service (login.numergy.com – 87.255.157.62), on dénombre pas moins de 7 problèmes de sécurité dont 3 très graves :

  • Utilisation d’algorithme asymétrique (DH) vulnérable pour l’échange des clés
  • Support d’anciens algorithmes vulnérables et exploitables via l’attaque FREAK publiée le 3 mars 2015 et découverte par Antoine Delignat Lavaud chercheur à l’INRIA.
  • Le protocole SSL v3 est activé et le site est vulnérable à l’attaque POODLE sans aucune contre-mesure permettant d’en limiter l’impact (TLS_FALLBACK_SCSV)

Devant une telle situation, nous avons souhaité voir ce qui se passait derrière la page d’authentification. Nous avons donc crée un compte utilisateur avec nos informations carte bancaire pour la facturation. Pour la petite histoire, on notera que la saisie des informations carte bancaire s’effectue sur un site de paiement de la société générale (paiement.socgenactif.com) qui n’est pas non plus un modèle de sécurité puisqu’il obtient la même note (F) dans le test ssllabs.

Après le paiement, le service nous indique que notre compte a été créé et que notre mot de passe nous sera envoyé par SMS. Le mot de passe arrive et surprise, il ne tient que sur 8 caractères (6 caractères alphabétiques, un caractère numérique et un seul caractère spécial). Nous essayons alors d’utiliser ce même mot de passe pour la création d’un compte chez le concurrent (Cloudwatt), pour voir ce que ça donne :

Check-PWD

Tiens, il semblerait que les deux fournisseurs n’aient pas la même approche sur la robustesse des mots de passe. On se dit que tout ceci n’est pas bien grave et que Numergy va évidemment nous imposer dès la première connexion de changer ce mot de passe. Et bien pas du tout ! Le mot de passe envoyé par mail est utilisable en permanence sur la console d’administration du service IaaS. Nous avons essayé l’option « j’ai oublié mon mot de passe » et une fenêtre nous demande notre e-mail et nous renvoi un nouveau mot de passe par SMS. Ce mot de passe est toujours aussi faible avec 8 caractères (dont un numérique et un spécial) et toujours permanent.
Ce choix technique n’est évidemment pas judicieux quand on sait que de nombreuses vulnérabilités (sous iOS et Androïd en particulier) permettent de récupérer les SMS des smartphones. On peut par exemple récupérer en quelques secondes l’intégralité des SMS dans un iPhone lorsque celui-ci est jailbreaké. D’autre part, sur de nombreux téléphones, tout SMS reçu s’affiche en clair sur l’écran même si le téléphone est verrouillé. Pour prendre le contrôle d’un compte administrateur sur Numergy, il suffit donc de saisir l’adresse email de la victime et d’avoir l’écran de son téléphone en visuel. Scénario, on ne peut plus simple à réaliser. Ensuite, on constate que le mot de passe a été créé par Numergy et une règle de base en sécurité est qu’il ne faut jamais conserver un mot de passe généré par un algorithme inconnu. D’autre part, ce mot de passe est potentiellement connu de l’opérateur Télécom puisqu’il est envoyé par SMS et éventuellement d’un autre fournisseur Cloud si l’administrateur a synchronisé son smartphone dans le nuage. Ca fait quand même beaucoup de monde qui peuvent potentiellement avoir accès à nos données dans le Cloud Numergy sans pour autant avoir besoin de faire appel aux services du GCHQ ou de la NSA…

Tant qu’à être connecté, nous avons également testé la gestion de session. Nous ouvrons donc une session dans un navigateur que nous laissons ensuite en totale inactivité pendant plus de 4 heures. Nous revenons ensuite sur le navigateur et nous constatons que la session d’administration est toujours active.

Nous vérifions maintenant les mécanismes anti « brute force ». On tente de se connecter avec notre identifiant valide en injectant une trentaine de mots de passe erronés. L’interface réagit à chaque fois immédiatement en nous indiquant l’échec d’authentification et en nous invitant à recommencer. Aucun délai entre les mires de login et aucun CAPTCHA ne viennent perturber notre test. Nous essayons maintenant de nous connecter pour voir si notre compte n’est pas verrouillé et là encore pas de problème, ça passe. Une fois connecté, aucun message d’alerte ne vient nous informer des tentatives infructueuses que vient de subir le compte.

Pour terminer cette très rapide évaluation de sécurité, nous avons lancé deux autres tests ssllabs :

ssllabs_F
Site d’administration des machines virtuelles
mon2.numergy.com – Adresse IP : 87.255.151.7

 

ssllabs_F
API Rest du service Numergy
api2.numergy.com – Adresse IP 87.255.151.6

 

6 recommandations pour améliorer la sécurité SSL/TLS chez Numergy :

  • Corriger immédiatement les problèmes de configuration SSL/TLS sur toutes les interfaces Web du Cloud Numergy et en particulier celles accessibles publiquement via Internet (login.numergy.com, mon2.numergy.com)
  • Même chose avec les API Rest du service (api2.numergy.com)
  • Ne pas se contenter de faire un http redirect vers https et forcer le protocole sécurisé avec HSTS (Strict Transport Security – RFC 6797)
  • Remplacer la signature sha1 des certificats par une signature sha2
  • Activer le support du Forward Secrecy sur les serveurs
  • Généraliser l’usage des certificats SSL EV sur l’ensemble des serveurs

+ 7 recommandations complémentaires pour Numergy :

  • Ne pas générer de mot de passe permanent pour les clients
  • Imposer au strict minimum 10 caractères avec minuscules, majuscules, chiffres et caractères spéciaux
  • Ne jamais envoyer un mot de passe permanent par SMS
  • Gérer un timeout d’inactivité sur la session
  • Intégrer un mécanisme anti brute force et en cas d’attaque verrouiller le compte et informer le client
  • Proposer une option d’authentification à deux facteurs (comme le font tous les leaders mondiaux du Cloud)
  • Prendre en compte plus rapidement les alertes de sécurité en provenance des clients (suivi d’incident détaillé en fin d’article)

Conclusion

Premier constat et ce n’est pas pour nous une véritable surprise : La seule société à ne pas être certifiée ISO 27001, Cloudwatt, est celle qui obtient la meilleure note de sécurité. Rappelons encore une fois qu’une certification ISO 27001 ne garantit pas un niveau de sécurité. Elle ne garantit pas non plus que les solutions de sécurité ont été déployées conformément aux bonnes pratiques et à l’état de l’art. La norme ISO 27001 atteste simplement que le fournisseur a mis en œuvre un processus de gestion de la sécurité de son système d’information (SMSI) conforme à la politique de sécurité qu’il a lui-même défini. Elle ne certifie donc en aucun cas que les données du fournisseur ou celles de ses clients seront correctement sécurisées et notre étude en est une parfaite illustration.

Second constat, de nombreux clients font une confiance aveugle aux fournisseurs de services Cloud. Les labels de sécurité, les discours marketing et l’opacité des infrastructures de Cloud public rendant les audits indépendants impossibles sont d’autant de moyens pour convaincre les clients de la sécurité du service. Nous recommandons donc naturellement à tous les clients d’aller plus loin dans l’évaluation de la sécurité de leur fournisseur avant de leur confier leurs données.

Et pour finir, que faut-il penser de la sécurité des Clouds souverains ? En effet, Numergy est une société française créée en 2012 par SFR, Bull et l’état français dans le cadre du projet de Cloud souverain français (Andromède).
Pour beaucoup de fournisseurs et de médias français, la souveraineté se réduit trop souvent à deux choses. Une menace clairement identifiée : l’USA PATRIOT Act et une réponse imparable : la localisation des datacenters en France. Les fournisseurs français ont-ils bien intégré que le Patriot Act n’était pas la seule menace qui pèse sur les entreprises françaises et qu’il fallait agir en conséquence pour démontrer leur capacité à contrer toutes les menaces potentielles dans le Cloud ?

Et si l’on en revient un instant au Patriot Act et plus généralement à la menace en provenance des USA, posons-nous les bonnes questions :

  • Peut-on véritablement être souverain lorsque l’infrastructure de sécurité réseau s’appuie sur les technologies israélo-américaines de Cisco, F5, Fortinet et Checkpoint ? Qui pourrait imaginer un seul instant un pare-feu Airbus Defense & Space dans un GovCloud AWS ?
  • Peut-on assurer la sécurité de nos données face à une puissance étrangère si les flux de communication chiffrés sont affectés par de multiples vulnérabilités ?
  • Peut-on assurer la sécurité de nos données, si l’on envoie les mots de passe d’administration par SMS que la NSA peut intercepter facilement tant sur le réseau de l’opérateur que sur les terminaux mobiles ?

Note importante

Vendredi 13 mars 2015 à 20h30 : Ouverture Ticket d’incident Numergy
Plus de 3 jours avant la publication de cet article, nous avons ouvert un ticket incident (Priorité 1 : Very high) au support Numergy pour les informer des vulnérabilités sur leurs interfaces Web. Nous réactualiserons ci-dessous cet article dès que Numergy nous fera un retour.

Message dans le ticket d’incident :
En tant que nouvel utilisateur du Cloud Numergy (compte crée ce jour – 13/03/2015), je me suis permis de vérifier si vos interfaces Web étaient correctement paramétrées d’un point de vue sécurité.
A l’aide du service sslabs.com, j’ai testé :
login.numergy.com, mon2.numergy.com et api2.numergy.com.
Il apparait que ces 3 systèmes sont extrêmement mals configurés avec pour conséquence la possible compromission de toutes nos machines virtuelles dans le Cloud Numergy.
Je vous invite à remédier à ces problèmes dans les plus brefs délais et de me tenir au courant dès que cela sera fait.
Je vous remercie de votre compréhension.

Samedi 14 mars 2015 à 12h33 : 1ère réponse de Numergy
Bonjour,
Dans un premier temps nous vous remercions de votre vigilance .
Sachez que Numergy porte une attention particulière à la sécurité .
Tout nos systèmes sont régulièrement scanné pour en vérifier la sécurité .
Dans ce sens , votre remarque a été remontée a notre équipe de supervision et sécurité qui vous recontactera dans les plus brefs délais.
Cordialement,
L’Equipe Numergy

Mercredi 23 mars 2015 à 15h33 : 2eme message de Numergy
Monsieur, je vous remercie de votre retour.

Nous mettons tout en œuvre au quotidien pour assurer la sécurité de la plateforme et des environnements clients.
Certains des points remontés ont été jugés pertinents et les actions associées ont été menées.

Nous vous souhaitons une excellente journée.
 
Cordialement,
Service Support


Suite à la prise en compte de notre message au support Numergy, deux interfaces (mon2.numergy.com et api2.numergy.com) ont été corrigées le 18 mars et sont maintenant classées « A » par ssllabs. La troisième interface (login.numergy.com) a été corrigée le 23 mars et obtient également la même note pour la configuration SSL/TLS. Nous ne pouvons que féliciter le support Numergy qui a pris en compte notre alerte.
Si le comparatif avait lieu aujourd’hui, Numergy obtiendrait désormais la meilleure note avec la lettre A pour configuration SSL/TLS et https pour l’intégralité du site Web.




Encore une faille critique dans l’hyperviseur Xen

Cela fait déjà plusieurs jours que le monde du Cloud s’agite autour d’une nouvelle vulnérabilité critique de l’hyperviseur Xen. De nombreux fournisseurs Cloud sont concernés : Amazon WS, Rackspace, IBM, Linode, etc…
Et ce n’est hélas pas la première fois qu’une faille extrêmement critique nécessite le redémarrage en urgence de l’hyperviseur Xen et donc le reboot de milliers de machine virtuelles. Le dernier problème similaire remonte seulement à septembre 2014 c’est à dire il y a moins de 6 mois (CVE-2014-7188).

Pour cette nouvelle faille, le correctif est disponible depuis plus de 10 jours. Les fournisseurs ont donc pu planifié son déploiement avec une certaine sérénité car ce n’est qu’aujourd’hui que les détails de la vulnérabilité (CVE-2015-2151) sont dévoilés et que d’éventuels Exploit pourraient voir le jour.
Pour les clients, l’impact aura été très variable selon le fournisseur Cloud. Pour certains CSP, le reboot systématique s’impose. Amazon avait annoncé dans un premier temps que seulement 10% des instances EC2 devraient rebooter. Finalement, Amazon a annoncé que grâce à leur Live update seulement 0,1% des instances AWS ont dû redémarrer.

Que risque-t-on si le fournisseur de Cloud n’applique pas le correctif ?
Pour cela, il suffit de lire la section « Impact » du bulletin de sécurité :
A malicious guest might be able to read sensitive data relating to other guests, or to cause denial of service on the host. Arbitrary code execution, and therefore privilege escalation, cannot be excluded.

En d’autres termes dans un Cloud public comme Amazon AWS, un locataire du service IaaS pourrait potentiellement réaliser un « hypervisor escape », c’est à dire accéder à des données dans une VM invitée voisine (i-e celle d’un autre client), faire un deni de service (arrêter des services), exécuter du code et éventuellement réaliser une élévation de privilège.

La faille est donc critique et prend une importance considérable dans un contexte de Cloud public. Il est donc important pour les clients de savoir quels sont les hyperviseurs utilisés par leurs fournisseurs et quels sont leurs engagements en matière de gestion des correctifs.


Autres ressources :




Cheops Technology certifié ISO 27001

Après Numergy, Outscale et OVH, un nouveau fournisseur de Cloud français, Cheops Technology, vient d’obtenir la certification ISO 27001. A cette occasion, Nicolas Leroy-Fleuriot, PDG de l’entreprise, déclare dans un communiqué de presse diffusé aujourd’hui :

«Les opérateurs de Cloud doivent rassurer leurs clients en validant des certifications de pointe en matière de sécurité, telle la certification ISO 27001 qui est une norme drastique en matière de sécurité des Systèmes d’Information»

Les fournisseurs se servent en effet de toutes les certifications de sécurité disponibles pour rassurer leurs prospects ou clients qui n’ont bien souvent qu’une vague connaissance de ces certifications. Peut-on par exemple dire que l’ISO 27001 est une norme drastique en matière de SSI ? Rappelons qu’une certification ISO 27001 ne garantit en aucun cas un bon niveau de sécurité. Elle ne donne également aucun élément pour réaliser une analyse de risques pertinente et ne garantit pas non plus la pertinence des solutions de sécurité mises en œuvre. En fait, la norme ISO 27001 atteste simplement que l’organisme a mis en œuvre un processus de gestion de la sécurité de son système d’information (SMSI) conforme à la politique de sécurité qu’il a lui-même défini. Elle ne certifie donc en aucun cas que le SI du fournisseur et les données de ses clients sont correctement sécurisés.


 Autres ressources :