Aller au contenu principal

Stratégies – Savoir mesurer les enjeux et les risques du Cloud Computing pour votre direction générale

21 avril 2014

Arnaud Alcabez

Depuis quelques années, je m’occupe d’accompagner les entreprises à mettre en œuvre les services issus du Cloud Computing, et force est de constater que ce domaine ne cesse de me surprendre. Par exemple, dans le dernier numéro, sur un ton humoristique, j’ai évoqué avec vous les problèmes des entreprises à tenter de contrôler la production par les utilisateurs de fichiers de plus en plus nombreux.

Ce que j’oublie souvent de préciser, c’est que mes articles sont la plupart du temps inspirés par les sujets que me confient les entreprises afin d’y apporter un éclairage. C’est ainsi que l’article sur l’infobésité du mois dernier fait suite à un retour d’expérience :

Une entreprise a fait appel à mes services pour comprendre pourquoi l’activité de leurs baies de stockage semblait depuis quelques temps en baisse d’activité ?

Après analyse des journaux et des manifestes de sauvegardes, il s’est avéré que leur ressenti était tout à fait légitime : Une baisse d’activité d’environ 54% a été constatée sur l’utilisation des serveurs de fichiers traditionnels.

Quelques interviews plus tard, cette désertification a pu être reliée à l’utilisation croissante de services de stockage en ligne par les utilisateurs, comme Dropbox, Box, iCloud et autres SkyDrive. Majoritairement favorisée par l’explosion de l’usage de terminaux mobiles professionnels et privés, et ce, à tous les niveaux de l’organisation, nous avons pu mesurer par extrapolation que cela représentait un manque d’environ 1 To de données, vaporisées sur le Cloud Computing, en divers endroits. Une dimension telle qu’il n’est plus désormais plus possible de couper l’accès aux fichiers des utilisateurs.

dg1
Représentation d’une salle informatique d’entreprise en 2020

 

Autre lieu, autre exemple : Une société multinationale commercialise des services collaboratifs sous une forme de « Software as a Service ». Elle vend directement son service aux utilisateurs, mais sa direction générale accepte également de la commercialiser en marque blanche. Un client, ayant contracté le service en marque blanche, et déçu par le support technique du revendeur décide de mettre fin au contrat et de migrer son service vers celui de la société multinationale, perçu plus fiable. Toutefois, lors de la migration des données, les taux de transferts entre les deux entités s’avèrent catastrophiques sans explication…

Les équipes techniques locales des deux organisations cherchent l’origine du problème, sans arriver à mettre le doigt dessus. Après quelques escalades, la réponse tombe comme un couperet : L’accord politique international entre l’éditeur et le revendeur s’est traduit par une réduction volontaire du trafic entre la plateforme du revendeur et celle de l’éditeur afin de rendre presque physiquement impossible le transfert et la récupération d’un client signé par le revendeur, et ce, sans en informer les équipes locales.

Mea culpa de l’éditeur, qui généreux, offre un an de plus d’abonnement chez le revendeur à cause de la date désormais très proche de la répudiation de son contrat, et ce afin que le client ne supporte pas les coûts d’un double abonnement pendant sa période de transition. Donc, fin du problème « technique » me direz-vous…

Oui, mais début des problèmes de fiscalité. En effet, comme toutes ces entreprises pratiquent l’optimisation fiscale appelée communément « le sandwich hollandais », le reversement entre entités se retrouve bloqué. Conclusion, le client est obligé d’avancer les fonds promis afin de ne pas voir sa messagerie brutalement coupée chez le revendeur d’un jour à l’autre.

Certes, j’avoue que majoritairement, l’adoption du Cloud Computing se déroulera sans encombre et que la plupart des entreprises s’avèrera convaincu du rapport entre le coût du service et sa qualité. Cela dit, certaines histoires peuvent rapidement devenir diablement compliquées, voir même finalement dangereuses au point que votre nuage se transforme en celui ci-dessous.

dg2

Le Cloud quand ça ne marche pas – Prise de vue depuis la direction générale

 

En effet, une mauvaise négociation ou l’absence d’expérience dans ce domaine peuvent vous faire perdre deux ou trois ans avant que vous ne puissiez représenter à la Direction Générale un projet de ce genre, au risque d’accumuler un certain retard sur vos compétiteurs qui n’auront peut-être pas fait les mêmes erreurs et abordé ce sujet avec la même légèreté…

Après tout, on peut toujours dire que ça n’arrive qu’aux autres…

Mes premières années d’obédience technique m’ont tout d’abord convaincu que la sécurité informatique n’était qu’une affaire de technologies, comme les certificats SSL ou de ports TCP/IP à ouvrir ou à fermer, avant que je ne réalise que je courrais derrière une licorne ou à vouloir toucher l’horizon.

Puis, au travers des outils de messagerie et en abordant la chaîne de valeur collaborative dans l’entreprise, j’ai réévalué mon approche, réalisant que la sécurité, c’était avant tout la responsabilité des utilisateurs vis-à-vis de l’entreprise.

Mais ça, c’était avant le Cloud…

En travaillant de plus en plus souvent au sein des directions générales et en animant des séminaires en entreprise sur le Cloud Computing et la législation, j’ai fini par réviser une nouvelle fois mon approche, convaincu que ni les technologies, ni les chartes informatiques ne sont une réponse globale suffisante pour les dirigeants d’une entreprise pour adopter de manière sereine les prochaines technologies émergentes.

En effet, quoi qu’on fasse, le risque sécuritaire pour une société existera toujours, et avec les souhaits des utilisateurs pour une informatique dans le nuage et une totale autonomie d’usage en les équipant de tablettes et de smartphones, le caractère stratégique à la protection de son patrimoine métier et technique est au cœur des préoccupations des dirigeants.

Les atteintes que peut subir une entreprise sur son patrimoine informationnel peuvent tout aussi bien toucher ses données ou ses technologies que ses outils ou moyens scientifiques, techniques et humains, et dans cette perspective, la sécurité des systèmes d’information (SSI) s’impose comme une composante essentielle dans ses intérêts propres et dans ceux pouvant être liés à des enjeux nationaux pour certaines entreprises sensibles.

Bien que cela soit difficile à évaluer, l’insécurité a un coût qui se manifeste lors d’incidents ou de dysfonctionnements. Face aux risques encourus, et dans le contexte fonctionnel et organisationnel propre à l’organisme, il convient d’identifier ce qui doit être protégé, de quantifier l’enjeu correspondant, de formuler des objectifs de sécurité et d’identifier, arbitrer et mettre en œuvre les parades adaptées au juste niveau de sécurité retenu.

Cela passe prioritairement par la définition et la mise en place au sein de l’entreprise d’une « Politique de Sécurité des Systèmes d’Information » (PSSI).

La PSSI relève d’une vision stratégique de l’organisme et traduit un engagement fort de la direction générale. Elle s’inscrit nécessairement sur le long terme.

Elle est conforme aux dispositions législatives et réglementaires et cohérente avec les politiques et directives de niveau supérieur; elle se doit également d’être cohérente avec les politiques de sécurité des organismes partenaires.

Généralement, au niveau de direction générale de l’entreprise, la PSSI se décline en trois parties :

  • Les enjeux de la PSSI, qui consiste à récupérer l’expression des besoins et l’identification des objectifs de sécurité
  • Partie I : Le contexte et les objectifs, c’est-à-dire au niveau de l’organisme par un approfondissement du contexte (enjeux, menaces, besoins) et une explicitation des dispositions de mise en œuvre, au travers d’un Schéma Directeur de la SSI et/ou d’un plan d’action SSI
  • Partie II : Les principes d’organisation et de mise en œuvre, c’est-à-dire au niveau des entités, de leur implémentation, et des pays dans lesquels intervient l’entreprise, par la définition d’une PSSI d’unité tenant compte des particularités propres à chacune d’entre-elles.

Pour les enjeux de la PSSI, (dans le schéma, ce qui est représenté par « Etat des lieux ») pour évaluer votre situation actuelle, vous pourrez vous appuyer sur une méthode fiable : EBIOS. Cette méthode a été rédigée par l’ANSSI (L’Agence nationale de la sécurité des systèmes d’information), autorité nationale en matière de sécurité et de défense des systèmes d’information. (Son portail : http://www.ssi.gouv.fr/fr/anssi/)

EBIOS se décline en deux modèles (un simplifié, un complet). Pour débuter, le mieux est de commencer sur le modèle simplifié EBIOS-2010. Bonne nouvelle, les outils méthodologiques sont gratuits et disponibles à cet emplacement : http://www.ssi.gouv.fr/fr/bonnes-pratiques/outils-methodologiques/

L’ensemble des documents pour la méthode est disponible ici : http://www.ssi.gouv.fr/fr/bonnes-pratiques/outils-methodologiques/ebios-expression-des-besoins-et-identification-des-objectifs-de-securite.html.

En bas de la page web, vous trouverez la version logicielle, qui vous guidera dans l’élaboration de la politique de sécurité. Je vous donne le lien direct pour la version Windows : http://www.ssi.gouv.fr/IMG/zip/ebios-v2-win32-2005-06-07.zip

L’opération consiste à installer cet outil sur un poste de travail, puis après avoir lancé EBIOS,

  • Dans le menu principal, choisir « Réalisation d’une étude EBIOS® »
  • Sélectionner Fichier / Nouveau
  • Donner le nom de l’étude : Ex : « Projet PSSI » dans le champ Nom de l’étude
  • Donner le nom de l’organisation : Ex « Ma société » dans le champ Organisation
  • Cliquer sur l’onglet « Base de connaissances »
  • Cliquer sur le bouton « Sélectionner »
  • Dans le dossier French, choisir EBIOS-Base-DCSSI-v2-2004-01-25.ekb
  • Cliquer sur Accepter
  • Le projet est maintenant ouvert, avec l’arborescence complète des chapitres à écrire
  • Cliquer sur Questionnaires et Audités
  • Puis sur Création des questionnaires, cliquer sur le bouton « Sélectionner »
  • Vous avez trois questionnaires à remplir ou faire remplir

o    Questionnaire pour l’étude de l’organisme

o    Questionnaire pour l’étude de la cible de l’étude de sécurité

o    Questionnaire pour l’étude du système cible

 

Schéma de déclinaison d’une PSSI

dg3

Analyse* : Méthodologie d’analyse de risques permettant à chaque unité de conduire une analyse de ses risques et de formuler des recommandations adaptées au contexte de l’unité.

Une fois l’outil installé, et partagé avec vos partenaires si nécessaire, tentez de répondre aux questions qui vous seront posées. Vous vous apercevrez peut-être avec un certain effroi que de nombreuses interrogations restent sans réponse, ou voir pire, que vous aurez du mal à identifier dans votre entreprise qui est censé porter ce sujet. Je vous ne le fais pas dire : Il y a du boulot.

Publié pour IT Pro Magazine, Décembre 2013

 

Annexe : Capture d’écran du logiciel d’assistance à la méthode EBIOS

dg4

Annexe : Plan modèle de la documentation d’une PSSI

A quoi ressemblera le document une fois rempli ? Bien entendu, chaque société aura sa façon de vouloir concevoir le document de PSSI qu’il faudra remettre régulièrement à jour, mais afin de vous guider dans cette tâche, l’exemple ci-dessous vous permettra de disposer d’un modèle standard que vous pourrez adapter à votre situation.

Partie I : Contexte et objectifs

1)     Le contexte

  1. Description de ses missions et de son organisation (nature, individus impliqués directement ou indirectement)
  2. Présentation de sa structure (fonctionnement, localisation)
  3. Description des niveaux de sensibilité
  4. Moyens techniques et financiers
  5. Typologie des données
  6. Contexte législatif et réglementaire

2)     Définition du périmètre de la SSI*

SSI= Sécurité des systèmes d’information

  1. Périmètre physique (nature, RACI)
  2. Périmètre logique (numérique, nature, RACI)
  3. Périmètre fonctionnel (administrateurs, utilisateurs, etc.)
  4. Description des usages et des méthodes
  5. Liaisons externes
  6. Entités non intégrées

3)     Les besoins de sécurité

Objectifs généraux : Protéger l’outil de travail (disponibilité), les données (confidentialité, protection des secrets, disponibilité, intégrité), le personnel des entités et l’organisation

  1. Définition des critères de sécurité
  2. Certifications des critères de sécurité
  3. Tableau : Echelle des niveaux de criticité

i.    Perte de confidentialité sans conséquence

Sinistre ne risquant pas de provoquer une gêne notable dans le fonctionnement ou les capacités de l’organisme (ex : données publiques, visibles par tous)

ii.    Perte de confidentialité entraînant des gênes de délai ou de fonctionnement

Susceptible de provoquer une diminution des capacités de l’organisme. (ex : données liées aux compétences ou savoir-faire internes, dans un contexte de groupe de confiance, dont vous protégez toutes les traces écrites.)

iii.    Perte de confidentialité entraînant des conséquences dommageables

Susceptible d’amoindrir les capacités de l’organisme, sans conséquence vitale, avec des conséquences telles que des pertes financières, sanctions administratives ou réorganisation. (Exemple : données liées à un engagement de confidentialité dans un contrat)

iv.    Perte de confidentialité entraînant des conséquences graves

  1. Susceptible de provoquer une modification importante dans les structures et la capacité de l’organisme comme la révocation de dirigeants, la restructuration de l’organisme, des pertes financières sévères)
  1. Définition des besoins de sécurité

i.    Concernant la protection de l’outil de travail

ii.    Concernant la protection des données

  1. Données métiers
  2. Données de gestion
  3. Donnés nominatives
  4. Données stratégiques

iii.    Concernant la protection juridique

  1. Propriété intellectuelle du patrimoine
  2. Protection de la vie privée
  3. Documents juridiques (charte informatique, CGU – conditions générales d’utilisation, etc.)
  4. Contexte international

4)     Menaces et impacts (méthode EBIOS)

  1. Identification des menaces générales
  2. Identifications des menaces spécifiques
  3. Tableau : Critères / Attaques / Impacts
  4. Analyse des risques (devra être réalisée ultérieurement, hors PSSI)

Partie II : Principes d’organisation et de mise en œuvre

1)     Organisation de la SSI

  1. Pilotage
  2. Mise en œuvre

i.    Chaîne organique

ii.    Chaîne fonctionnelle spécialisée de la SSI

  1. Au niveau international
  2. Au niveau national
  3. Au niveau sous-national (à adapter)
  4. Au niveau local

iii.    Identification des CSSI (Chargés de la Sécurité des Systèmes d’Information)

2)     Coordination avec les entités externes ou sous-traitantes

  1. Principes généraux

i.    Dans le cas d’entités externes

ii.    Dans le cas de sous-traitants

  1. Procédures en cas d’incidents
  2. Procédures en cas de litiges
  3. Procédures exceptionnelles

3)     Déclinaison d’une PSSI au sein d’une entité

  1. Stratégies globales (Policies)
  2. Stratégies locales

4)     Principes de mise en œuvre de la PSSI

  1. Organisation et responsabilité

i.    Responsabilité des différents acteurs

ii.    Accès aux ressources informatiques

iii.    Charte informatique

iv.    Cyber surveillance

v.    Formation, sensibilisation

vi.    Infrastructure de gestion des clés numériques

vii.    Veille technique et juridique

  1. Protection des données

i.    Disponibilité, confidentialité et intégrité des données

ii.    Protection des données sensibles

iii.    Données à caractère personnel

iv.    Chiffrement

v.    Réparation, cession, mise au rebut

  1. Sécurisation du Système d’Information

i.    Administration des serveurs

ii.    Administration des postes de travail

iii.    Sécurisation des postes de travail et des moyens nomades

iv.    Contrôle d’accès

v.    Sécurité des applications

vi.    Maintenance et télé actions internes

vii.    Infogérance et télémaintenances externes

viii.    Clauses dans les marchés

ix.    Réseaux

x.    Maintenance au niveau de sécurité

  1. Mesure du niveau effectif de sécurité

i.    Contrôle de gestion

ii.    Audits

iii.    Journalisation, tableaux de bord

iv.    Fichiers de traces

v.    Posture de sécurité

vi.    Mises en garde

vii.    Gestion des incidents

viii.    Gestion des crises

ix.    Plan de continuité

Les commentaires sont fermés.

%d blogueurs aiment cette page :