Comment analyser et mesurer les risques liés au Cloud ?

A ce jour, il n’existait aucune méthode d’analyse des risques de sécurité spécifiques au Cloud. Ce dernier suscite un engouement important au sein des entreprises, mais freiné par l’existence de risques de sécurité inquiétant fortement les actuels et futurs utilisateurs.

Tandis qu’un engouement majeur et incontestable soutient le développement du Cloud, des doutes liés aux questions sécuritaires freinent son essor. Répondre à ces doutes devient un enjeu crucial.
Les fournisseurs y répondent par deux stratégies distinctes.
La première consiste à fournir un service Cloud dédié à la sécurité et appelé Security As A Service.
La seconde concerne tous les engagements pour tenter de démontrer leur capacité à garantir la sécurité des données clients. Toutefois à ce jour, aucune méthode pour qualifier et contrôler efficacement le niveau de sécurité d’un service Cloud n’avait été développée.
La méthode décrite ci-après offre un moyen aux entreprises de maîtriser les risques sécuritaires liés au Cloud. Elle les aide alors à décider si elles se lanceront ou non dans un tel projet, les soutient dans l’analyse des différentes offres du marché et surtout les guide pour maintenir un bon niveau de sécurité malgré la transformation totale ou partielle de leur SI.
Bâtir une méthode d’évaluation des risques d’un service de Cloud demande de franchir un certain nombre de difficultés :
1.Construire un Référentiel de risques spécifiques au Cloud, qui permette à chaque entreprise de disposer d’un catalogue de risques le plus complet possible tandis que le recul sur cette nouvelle façon de fournir des services est faible.
2. Évaluer la fréquence ou la probabilité des risques liés aux Cloud dans un contexte qui démontre que le niveau de maturité est très hétérogène en fonction des risques ou des fournisseurs.
3.Fournir la capacité à comparer le Cloud par rapport à un existant, afin d’offrir aux DSI mais surtout aux utilisateurs finaux la faculté à comprendre ce qui change lorsque tout ou partie de son SI est transformé par un passage dans le Cloud.
4.Proposer des mesures de traitements des risques pour disposer d’une approche holistique, mais également ciblée sur le Cloud, puisque pour certaines entreprises la question du Go-NoGo dans le Cloud ne se pose plus et la question du Comment devient majeure.
5. Maintenir une logique de réduction du coût dans la construction de cette méthode, tandis que l’atout principal de Cloud reste la capacité à optimiser ses coûts, et qu’il est alors nécessaire de délivrer une méthode tout aussi efficace sur ce point.
La démarche suivie pour bâtir cette méthode d’évaluation des risques a permis de contourner ces difficultés.

Dans un premier temps, les étapes de la méthode d’analyse de risque ont été définies, ainsi que les règles d’évaluation des risques en croisant le niveau d’impact et le niveau de probabilité de survenance du risque. Cette méthode d’analyse de risques s’inspire des méthodes répandues telles que la méthode EBIOS[1] ou MEHARI[2] et sera ainsi compréhensible par un grand nombre d’interlocuteurs. L’identification des risques ou la construction du Référentiel de risques a été menée grâce à la consolidation des résultats des travaux de recherche, et en particulier des documents de l’ENISA, du CSA et du NIST ; à partir de cette base de référentiels et de la constitution d’une bibliographie, un certain nombre de brainstormings ont été organisés.
Ces brainstormings avec des experts reconnus dans les domaines du Risk Management et des Audits de Sécurité ont enrichi significativement le référentiel de risques  « Cloud Computing ». Ce référentiel a également été partagé avec un panel de nos clients pour recueillir leurs retours tant sur son contenu que son usage dans leurs secteurs.
Ensuite, une évaluation « générique » des risques a été proposée pour permettre une utilisation immédiate de la méthode. Elle donne deux niveaux de risques généraux, l’un estimant le cas d’une migration dans le Cloud et l’autre estimant le cas d’une solution gardée dans le périmètre interne d’une organisation. Cela permet à une entreprise donnée de comparer son analyse de risques liés au Cloud à une analyse générique d’une part, mais aussi de comparer le niveau de risques d’un périmètre donné dans le Cloud au même périmètre gardé en interne.
La méthode d’évaluation des risques repose ensuite sur la connaissance du contexte du client, les niveaux d’impact et de probabilité étant adaptés aux enjeux métiers et sécuritaires de l’entité qui souscrit à un service Cloud.
Enfin, pour construire la base de connaissance des mesures permettant de traiter les risques identifiées, la norme ISO 27002:2008 a servi de structure. Un certain nombre de consultants certifiés Lead implementer ou Lead auditor ISO 27001 ont contribué à l’enrichissement de cette base en listant les mesures associés à chaque risque et en évaluant l’effort associé à la mise en place de ces mesures.
Cette méthode a la capacité de s’auto alimenter pour se maintenir à l’état de l’art à travers les diverses analyses de risques qui vont être menées dans différents contextes.
La méthode O.S.C.A.R. pour Optimisation de la Sécurité du Cloud par l’Analyse de Risques, issue de ces travaux, est composée des 4 étapes distinctes suivantes :

• Étape 1 : Évaluation des besoins métiers et contexte de services cloud
• Étape 2 : Analyse de risques (identification des risques, évaluation des risques bruts, traitement des risques, évaluation des risques résiduels)
• Étape 3 : Estimation de l’effort de mise en œuvre des mesures de traitement des risques
• Étape 4 : Plan d’action

Étape 1 : Évaluation des besoins métiers et contexte de services « cloud ».
Dans cette étape, il s’agit de présenter la finalité du service et les éventuelles motivations à utiliser un service de « Cloud », en particulier, les forces et les éventuelles opportunités associées au service de « Cloud ».
Cette étape consiste aussi en la compréhension des enjeux sécuritaires associés aux besoins métiers afin de pondérer l’évaluation des risques en conséquence. Enfin, cette étape a pour objectif sous-jacent de faire discuter le Métier et la DSI sur les besoins fonctionnels et leurs enjeux d’une part et les enjeux sécuritaires associés à cette solution d’autre part. Cet échange est le point de départ pour garantir la maîtrise des risques du projet Cloud.

Étape 2 : Analyse de risques (identification des risques, évaluation des risques bruts, traitement des risques, évaluation des risques résiduels)

Identification des risques
Comme décrit précédemment, un référentiel de risques a été construit. Ils sont au nombre de 44 et sont classés selon 4 thématiques : risques Politiques & Organisationnels, risques Techniques, Risques Juridiques & Réglementaires et Risques Physiques. Ci-dessous sont proposés 4 exemples non détaillés pour illustrer ce Référentiel de risques.

Risques Politiques et Organisationnels	Infrastructure Inaccessible Un événement social, une guerre civile, un changement de régime politique peut rendre l’accès au(x) lieu(x) de stockage du matériel impossible
Risques Techniques	Synchronisation horaire défaillante Un changement de fuseau horaire ou le passage à une heure d’été/hiver peut provoquer une mauvaise synchronisation horaire
Risques Juridiques et Réglementaires	Défaut de responsabilité Une mauvaise définition des responsabilités des acteurs (client/fournisseur) vis-à-vis de tiers peut être problématique
Risques Physique	Catastrophe naturelle Un PRA inexistant ou mal conçu peut stopper ou ralentir l’activité d’un fournisseur temporairement ou pas

Pour chaque risque est mentionné le ou les critère(s) de sécurité impacté(s) (Disponibilité, Intégrité, Confidentialité et Traçabilité). Il est aussi également précisé si le risque est applicable en mode SaaS, PaaS et/ou IaaS et s’il relève du client du Cloud et/ou du fournisseur.

Évaluation des risques
L’évaluation des risques est, comme la majorité des méthodes d’analyses de risque, la combinaison de la probabilité d’occurrence et du niveau d’Impact du risque.
L’évaluation « moyenne » d’un risque (évaluation du risques = probabilité x impact) est une combinatoire des évaluations moyennes fournies par l’ENISA, d’une base d’incident fournies par Devoteam et de tiers (en particulier sur la probabilité d’un risque) et de l’exposition au risque du client.

Eval moyenne d’un risque = F (Eval moyen risque ENISA, Prob base incidents externes, Dégré exposition au risque client)

Cette base d’évaluation des risques doit pouvoir s’enrichir en fonction des évolutions technologiques et de la maturité côté fournisseurs et clients (sur les besoins et les services proposés).

Afin d’accroître l’aide à la décision, la méthode permet :

• d’évaluer le niveau de risque d’une offre de Cloud,

• d’évaluer le niveau de risques de plusieurs offres et de les comparer

• de comparer le niveau de risques sécurité du service de Cloud par rapport au même service si ce dernier était internalisé.

Une évaluation générique des risques est proposée pour une entreprise souhaitant avoir un aperçu global des risques liés au Cloud. Une évaluation affinée est effectuée grâce à la première étape et à des échanges entre l’évaluateur et l’entité qui souscrit un service Cloud.

Traitement des risques
Les mesures identifiées pour diminuer le niveau de risque sont issues de l’ISO 27002, et pour certaines déclinées opérationnellement pour répondre aux spécificités du Cloud Computing.
La méthode propose dans un premier temps de déterminer qui peut mettre en place ces mesures (le client du Cloud et/ou fournisseur du Cloud ?) et de quelle manière ces mesures agissent sur les risques. Les mesures retenues sont sélectionnées par l’entité à partir de la liste des mesures applicables associées aux  risques qu’elle juge inacceptables en l’état.
Le choix d’appliquer telle ou telle mesure permet de mettre en avant le risque résiduel.

Étape 3 : Estimation de  l’effort de mise en œuvre des mesures de traitement des risques.
Une fois la liste des mesures retenues par le client du Cloud identifiée, O.S.C.A.R. se propose d’évaluer les « coûts » de mise en œuvre de ces mesures.
L’estimation des coûts des mesures est établie sur la base de connaissance construite telle qu’expliqué précédemment. Elle propose un « coût » basé sur l’effort que doit supporter l’organisation afin de mettre en œuvre ces mesures en termes de charge de travail nécessaire, de complexité de la mesure mais aussi du contexte politique et organisationnel rencontré et de délais d’implémentation.

Étape 4 : Plan d’action
L’objectif final est de fournir les résultats sous forme d’une synthèse d’aide à la décision présentant l’évaluation des risques bruts, les risques qui doivent faire l’objet d’un traitement, la liste des mesures applicables et retenues, l’effort de mise en œuvre associé et l’évaluation des risques résiduels cibles.
Ces éléments peuvent faire l'objet d'une comparaison soit entre plusieurs fournisseurs de Cloud, soit par rapport à une autre solution interne.

En conclusion, O.S.C.A.R. est une méthode spécifique au Cloud qui permet de fermer la brèche qui existe entre l’engouement suscité par le Cloud et les craintes associées en offrant la capacité à :

• sécuriser sa solution Cloud,  
• évaluer les « coûts cachés » du Cloud, c’est-à-dire l’effort associé à la mise en œuvre des mesures de sécurité nécessaires pour garantir un niveau de risque acceptable d’une solution Cloud,
• et garder la maîtrise de son SI externalisé.

O.S.C.A.R., compte-tenu de l'objectif d'efficacité et de simplicité identifié préalablement, est en cours d'intégration dans un outil pour industrialiser le déroulement de la méthode ; cette phase d'industrialisation permet de réduire de façon très significative la durée d'une évaluation en diminuant la charge de travail nécessaire pour mener à bien cette évaluation des risques et de faciliter la mise en œuvre des mécanismes de type "What If".

------------------------
[1] EBIOS ou Expression des Besoins et Identification des Objectifs de Sécurité, développée en 1995 par l’ANSSI et remise à jour en 2010 http://www.ssi.gouv.fr/fr/bonnes-pratiques/outils-methodologiques/ebios-expression-des-besoins-et-identification-des-objectifs-de-securite.html
[2] MEHARI est une méthode d’analyse de risques développée par le CLUSIF dont la nouvelle version date de 2010 www.clusif.asso.fr/fr/production/mehari/