Le manque de visibilité au sein des services dans le nuage est souvent perçu comme une bonne raison de rester sur terre : après tout, se dit le RSSI, si je dois confier mes données – a fortiori sensibles – à un prestataire je m’attends à avoir l’assurance que ce dernier obéi aux bonnes pratiques de sécurité.

Hélas, cette assurance est encore loin d’être banalisée. Certes, une certification telle ISO 27001 est un excellent début. Mais l’intérêt d’un SMSI, c’est d’être « vivant ». Or, comment savoir s’il vit réellement ? Car si le client peut faire confiance à son prestataire le jour de sa certification, qu’en est-il plusieurs mois après, entre deux audits ?

Prenons le cas particulier des vulnérabilités : une analyse régulière est-elle réalisée ? Quelle est la tendance du dernier rapport ? Combien de vulnérabilités critiques, internes et externes, sont-elles encore non résolues sur la plate-forme du prestataire à cet instant ?

Peu, si ce n’est aucun, prestataires ne fournissent un tel rapport à leurs clients, et cela pour une bonne raison : un rapport d’analyse de vulnérabilités contient des informations confidentielles qui ne peuvent être librement publiées.

Ajoutons maintenant à l’équation la conformité réglementaire (« êtes-vous toujours conforme à la réglementation XYZ à cet instant, au moment où je m’apprête à vous confier mes données ? »), voire le patch management, et l’on commence a avoir une idée de la somme des questions qu’un client de service Cloud est en droit de poser à son prestataire. Et la difficulté pour ce dernier à y répondre sans trop exposer ses rouages.

Bien entendu, les fournisseurs de services dans le nuage adressent déjà ces questions, notamment en prévoyant un droit à l’audit (RTA, pour Right to Audit) dans leurs contrats. Toutefois, et c’est une nouveauté, il semble que les clients exercent largement plus souvent cette clause dans le Cloud que dans d’autres secteurs, y compris en infogérance. Et cela génère un coût (et un impact) non négligeable sur les opérations.

Les fournisseurs ont également pris l’habitude de répondre en faisant parvenir les synthèses d’audits tiers (audit de code source des applications SaaS, par exemple). C’est moins cher, mais c’est au mieux une réponse partielle et datée : le client peut tout juste en conclure que le niveau de sécurité était bon au moment de l’audit, qui peut avoir eu lieu il y a plusieurs mois de cela.

La question de la visibilité dans le nuage est ainsi essentiellement celle de la capacité à justifier la confiance que l’on place dans son fournisseur : « je veux bien vous faire confiance, mais il faut me donner de bonnes raisons pour cela », pourrait dire en substance notre RSSI consciencieux. Et nous ajouterons que si ces bonnes raisons sont accessibles de manière automatisée, en self-service, à l’initiative du client, c’est encore mieux pour tout le monde.

C’est là qu’intervient Chris Hoff, gourou ès Cloud & Virtualisation chez Cisco, mais surtout observateur impertinent de l’industrie de la sécurité à travers son blog Rational Survivability .

Hoff et quelques camarades proposent de définir une API standard qui permettrait aux client d’un service Cloud d’interroger ce dernier à tout moment afin de connaître sa posture de sécurité à un instant T.

Baptisé A6, pour « Audit, Assertion, Assessment, and Assurance API », le projet en est encore à ses balbutiements, mais l’idée fait son chemin. Outre Cisco (via Hoff), il est soutenu notamment par Sun, F5 Networks et EMC.

Si le focus est bien entendu de donner accès en temps réel à des informations « fraîches » sur le niveau de sécurité (configurations, vulnérabilités, correctifs), A6 ne fait bien entendu pas l’impasse pour autant sur le déclaratif : les résultats d’audits antérieurs ont également leur place dans le « package » d’informations que renverrait l’API. D’ailleurs l’un des architectes du projet expose ses réflexions en la matière sur son blog , et on peut l’y voir arrêter le travail sur l’API elle-même afin de se concentrer sur une nouvelle syntaxe XML qu’il a baptisé XSRL (eXtensible Security Reporting Language).

Son raisonnement le pousse en effet à regarder ce qui se fait en matière de rapports du côté de la Finance, notamment via XBRL (eXtensible Business Reporting Language). Il s’agit d’une syntaxe qui permet de formaliser des rapports financiers et d’indiquer qui a certifié les informations présentées. L’objectif ici est de créer l’équivalent pour la sécurité, ou, comme il l’explique « apporter le formalisme dans la présentation des rapports de sécurité, sans lequel A6 ne pourra pas décoller ».

A6 serait ainsi une méthode standard, basée sur REST, dont l’accès serait contrôlé et qui renverrait sur demande un document structuré (XML) contenant des informations détaillées sur le niveau de sécurité d’un fournisseur à un instant donné, basé à la fois sur des données en temps réel (vulnérabilités, correctifs) mais également déclaratives (audits). Le tout sans révéler d’informations précises exploitables par un attaquant : on rassure, mais on n’expose pas la mécanique (ou, en l’occurence ici, les rapports eux-même).

Il serait toutefois bien entendu naïf d’imaginer que A6 – ou tout autre projet du même acabit – pourra résoudre la question de la sécurité dans le nuage. La conformité n’est pas la sécurité. Mais il permettra au moins de baser la décision d’aller vers le nuage (ou d’y rester) sur des critères objectifs et surtout mesurables, ce qui est loin d’être encore le cas aujourd’hui.

Cela permettra peut-être même d’intégrer le recours au Cloud Computing dans une analyse de risque. Après tout si la « feuille de santé » du fournisseur indique régulièrement une conformité à ISO 27001, l’absence de vulnérabilité de niveau 4 ou 5 sur sa plate-forme, un parc au meilleur niveau de patch et un audit de code en cours de validité pour l’application SaaS, il sera probablement plus simple de faire la comparaison avec son propre état de santé et décider en toute connaissance de cause où se trouve le risque.