Global Security Mag Online

Jean-Marc Gremy, Cabestan Consultants : Et si les questions de sécurité du Cloud Computing n'étaient pas encore dans les nuages ... mais bien toujours sur terre ?

Marc Jacob — 2010-09-03T14:18:55Z

Depuis maintenant plusieurs mois, nous entendons parler de Cloud Computing et de sécurité. Au-delà des effets de mode portés par ce nouveau concept, et des opportunités qu'il a fait naître tant pour les offreurs historiques de ressources informatiques que pour les acteurs de la SSI, le Cloud Computing semble bien parti pour s'imposer comme un « nouveau quelque chose » pour nos entreprises, institutions et collectivités. Ce « quelque chose » reste à définir, je ne me risquerai donc pas à le décrire dans ces quelques lignes mais juste à me poser en observateur, curieux, du phénomène. Ce « bidule » comme aurait dit notre général, semble s'imposer à nombre d'entreprises et organismes comme étant l'étape suivante dans l'évolution de leur SI. A voir le marché évoluer, celui de la virtualisation des serveurs et des postes de travail comme des services, on peut même se demander si demain, nos DSI auront encore des investissements à faire dans le hardware tellement les offreurs de technologies (logicielles et matérielles) tendent vers les offres de Cloud Computing. N'y aurait il pas là une transformation du modèle économique des équipementiers qui ferait que l'adoption du Cloud Computing ne sera plus une question de choix à termes ?

Fermons cette introduction sur une présentation du ou des Clouds, et revenons à une préoccupation bien légitime pour le moment : celle de la sécurité des informations hébergées, confiées, stockées donc « cloudisées ». De nombreux ouvrages traitent de la sécurité dans le Cloud : la Cloud Security Alliance, l'ENISA, les constructeurs, les offreurs de service et d'excellentes publications de mes pairs. L'association Cloud Security Alliance a même créé une certification professionnelle pour la sécurité basée sur un corpus de connaissance issue de ses publications et celles de notre chère agence européenne pour la SSI, l'ENISA. Mon propos n'est donc pas de traiter dans ces quelques lignes des risques pesant sur les données cloudisées, sur les infrastructures gérées, sur les problématiques de législations internationales posées, mais d'aborder un point qui est trop rarement évoqué ou laissé à l'abandon par d'autres préoccupations : la question de la résilience du média d'accès aux informations cloudisées, je veux parler de l'Internet !

Bien sûr ce point est évoqué lorsque nous abordons avec nos clients le besoin de sécurité en termes de Disponibilité du FAI, en considérant que cette question ne se pose pas pour le fournisseur de Cloud ; un des axiomes du Cloud Computing est bien que les ressources sont toujours accessibles.

Dans l'esprit de chacun l'Internet, devenu un peu partie de l'éther avec les réseaux ambiants, est une ressource toujours disponible, omniprésente. Jamais dans l'histoire de l'humanité un tel sentiment n'a existé, l'immortalité d'un « être » enfin atteint, le mouvement perpétuel enfin trouvé.

Mais regardons la réalité de plus près de l'Internet. Qu'est ce réseau ? Comment est-il gouverné ? Comment parcourrons nous le « chemin » depuis notre poste de travail vers un serveur web ou celui hébergeant nos données cloudisées ?

A bien y regarder cela n'est pas si simple. Evacuons tout de suite le cas du client qui a un accès Internet chez un opérateur X avec ses données/applications/services « cloudisées » chez ce même opérateur X, opérateur devenu offreur de services de Cloud Computing par ailleurs. Pas de souci ! Un vrai contrat avec des SLA, des engagements et des pénalités et le tour est joué. Non, intéressons nous au cas de la société/organisme ayant décidé de cloudiser son SI vers un opérateur de services de Cloud de classe mondiale. Le contrat prévoit des SLA, des exigences de sécurité, une clause de réversibilité et la prise en compte des contraintes réglementaires et juridiques inhérents au pays. Mais quid du moyen d'accès ? Entre l'opérateur Internet et celui de l'opérateur du service de Cloud ? Quelle idée de la garantie de la disponibilité de ce réseau ? La réponse aujourd'hui : aucune !

les remèdes aux problèmes techniques peuvent être trouvés, par contre, il n'en est pas de même pour l'organisation et la gouvernance de l‘Internet

La résilience du réseau Internet repose sur quels éléments ? Plongeons nous dans ses entrailles et son histoire proche, sous ses dimensions techniques et organisationnelles.

Technique : l'interconnexion entre opérateurs se fait pas le biais d'accords spécifiques ou par le biais de point de peering internet, les Internet eXchange Point . Par qui et comment sont gérés ces services techniques ? Comment ses services vont évoluer avec les choix, ou les non choix de migration, d'intégration d'IPv6 ? La gestion de l'Internet est techniquement confiée à plusieurs entités, de gouvernements différents, souvent des opérateurs télécoms historiques et des carriers IP. Alors souvenons-nous du cas de « l'erreur » de configuration BGP par Pakistan Telecom et son impact sur le trafic pour les services YouTube™ début 2008 . Imaginons la même « erreur » pour votre service de Cloud Computing préféré ? Votre PCA/PRA intègre t'il ce scénario ? Avez-vous un Datatcenter dupliquant vos données/applications/services au fond de la cave ? Plus récemment, fin août 2010, le cas du bug dans le système d'exploitation de l'équipementier de routeurs CISCO™ mis en évidence par des chercheurs lors de tests BGP du RIPE NCC, accidentels ... Les routeurs, ces dispositifs plus qu'au cœur de l'Internet : ce sont là la fois le système nerveux central, le système cardio-vasculaire, le squelette, le système respiratoire et musculaire de l'Internet. Leur compromission ou indisponibilité ébranlent l'usage du réseau. Il en est de même pour les mécanismes DNS pour la résolution des noms et leur conversion en adresses IP : L'architecture DNS doit être disponible et les informations cohérentes pour accéder à mes services de Cloud Computing, mais voilà l'architecture DNS qui représente peut-être les yeux de l'Internet n'est pas indemne de toutes vulnérabilités et menaces .

Organisationnel : finalement les problèmes techniques ont peut-être l'avantage d'être de « vrais problèmes » tangibles, identifiables, commentés, documentés et corrigés. Mais qu'en est-il de la gouvernance de l'Internet ? A bien y regarder, le problème évoqué précédemment de la révélation du bug BGP, si sa conséquence a été technique par l'exploitation accidentelle d'une vulnérabilité de l'Os, la menace était bien quant à elle d'origine humaine. Pour mémoire le RIPE NCC est une instance de gouvernance de l'Internet en Europe. La réflexion menée à ce jour sur la neutralité des réseaux apportera t'elle des réponses ? La prise en compte de ce point lors du colloque de l'ARCEP en Juillet 2010 tendrait à le prouver. Les enjeux sont, semble t'il, bien plus importants que nous l'imaginons. La partie immergée de l'iceberg. Bien sûr dans l'économie actuelle du cyber-terrorisme et de la cyber-criminalité la résilience du réseau est une nécessité pour ces « utilisateurs ». Pour échanger, fomenter et pilier, le réseau doit être disponible et performant. Mais demain, quand une grande industrie, un état, un organisme ayant cloudisé sont SI, quelles seront les motivations des cyber-criminels, cyber-espions et autres cyber-guerriers ? Déstabiliser, désinformer, interrompre les moyens de communications, ceux-là même que nos entreprises et organismes utilisent pour accéder aux plateformes de Cloud Computing. Dans la presse internationale dernièrement, la description de scénarios catastrophiques à un niveau international laisse dubitatif. Les tests de réponse à une crise majeure réalisés en France en juin 2010 lors de l'exercice PIRANET 2010 évoquent bien cette prise de conscience nationale, tout comme l'identification des opérateurs d'importance vitale (OIV). Comme pour une pandémie, quelles seront nos –entreprises, opérateurs, états- capacités de résistance et de réaction ?

Quelles solutions pour une résilience maîtrisée et prédictible de l'Internet ? Aucune pour le moment, ni du côté de la technologie ni du côté des offreurs de services de Cloud Computing ! Si ce n'est qu'une prise de conscience de cette situation, qui ne trouvera pas de réponse dans la technique fusse t'elle la plus évoluée technologiquement parlant. Les gouvernements, les opérateurs globaux (les carriers IP), les offreurs de services de Cloud travaillent certainement à nous apporter des éléments de réponse à cette question...

L'enjeu majeur de la SSI sera « la confiance numérique ! »

Cette observation nous renvoie finalement à un des enjeux majeurs de la SSI en 2010 et pour les années à venir : la confiance dans le numérique ! L'accès et l'usage des TIC dans nos sociétés modernes ne peut pas être garantie que par la seule réponse technique, il faudra que le politique s'investisse encore davantage pour qu'au fronton de nos mairies nous gravions l'idée de Sécurité, et la confiance qu'elle apporte, à coté des valeurs fondamentales de la République que sont la Liberté, la Fraternité et l'Egalité. Mais cela est sans doute un autre débat...

1 Reste encore à s'entendre sur les définitions des termes SaaS, IaaS, PaaS, private Cloud, public Cloud...
2 CCSK, voir http://www.cloudsecurityalliance.or...
3 http://www.bortzmeyer.org/5963.html...
4 http://www.bortzmeyer.org/pakistan-...
5 https://labs.ripe.net/Members/erik/...
6 http://www.globalsecuritymag.fr/HSC...
7 http://www.forumatena.org/?q=node/255
8 http://www.arcep.fr/index.php?id=8652
9 Courrier International du 26 août 2010, Cyber-Guerre la menace qui vient du Net
10 http://www.ssi.gouv.fr/site_article...

Biographie de l'auteur :

Après une formation initiale militaire dans la Marine Nationale, Jean-Marc GREMY débute sa carrière civile au sein de la R&D d'Alcatel Business Systems puis se tourne rapidement vers les Systèmes d'Information et de télécommunication au sein d'Alcatel puis du Groupe Synthélabo.

En 1997, Il participe à l'éclosion de Cyber-Networks et en devient le Directeur Technique. En 2002, il co-fonde la société Ipelium, intégrateur de solutions de mobilité d'entreprise et sécurisation. Il y dirige la stratégie technique ainsi que les activités de conseil. Fort de cette expérience réussie de 18 années dans la technologie, le management et l'entreprenariat, Jean-Marc GREMY créé en 2007 le cabinet de conseil CABESTAN CONSULTANTS. Résolument tourné vers le conseil et la formation, pour laquelle il est instructeur européen pour le cursus CISSP® et Conférencier pour le Centre de Formation de l'ANSSI (le CFSSI).

Gérôme Billois, SoluCom : « L'été chaud des smartphones »

Gérôme Billois – Manager Sécurité – Solucom — 2010-08-23T12:09:08Z

L'été est décidément toujours une période propice pour la sécurité (certains se souviendront des attaques virales majeurs de 2003 ayant frappé en plein mois d'août). Eh bien le sujet de cet été, ce sont les smartphone et leur sécurité ! Et en quelques semaines se sont enchaînés des évènements importants dans ce secteur.

Du côté de la plateforme de Google Android, un rootkit a fait son apparition : il est possible de le déclencher sur simple appel ou envoi de SMS au terminal ciblé, et permet le vol silencieux de données en tout genre . Son utilisation éventuelle dans une application sur l'Android Market pose une nouvelle fois la question de la grande ouverture de ce dernier. D'autres exemples de menaces cachées dans des applications légitimes on fait leur apparition, comme par exemple Tap Snake, un spyware renvoyant régulièrement la position du téléphone.

La plateforme de Palm, webOS, bien que moins répandue, est également la cible des chercheurs de failles. Et une faille a été trouvée et elle permet d'écouter les appels et les sons ambiants. Il suffit juste d'accepter d'ouvrir une fiche contact vCard.

Vient ensuite l'annonce d'une faille majeure pour l'iPhone, permettant l'exécution de code et la prise de contrôle complète du terminal en utilisant des fichiers PDF malformés. Un exemple concret d'exploitation est évidemment le jailbreak que permet le site jailbreakme.com, qui permet en quelques secondes d'outrepasser les protections mises en place par Apple et d'installer des programmes non autorisés ou piratés. Un paradoxe certain est que le seul moyen de se protéger pendant plusieurs jours contre cette faille était précisément d'utiliser des programmes non autorisés par Apple !

Et finalement est arrivée la nouvelle « affaire BlackBerry » : le smartphone historique est menacé d'interdiction sur le sol de plusieurs pays, car il est trop sécurisé et représente une menace pour les États ! Voilà bien quelque chose d'inattendu, où trop de sécurité nuit finalement nuit au fournisseur du service. Le résultat des tractations sera à suivre de près pour la sécurité des utilisateurs cette fois-ci… Et RIM doit savoir jongler entre plusieurs positions car son service a été déconseillé par le gouvernement allemand du fait des risques d'écoutes et de l'opacité de la solution. De quoi en perdre son latin !

Que retenir de cette série d'évènements ?

Tout d'abord qu'un smartphone se rapproche plus en plus d'un PC et que les menaces que l'on connaissait sur les plateformes historiques commencent à apparaître. L'attrait des informations potentiellement collectées reste forte et motive ces attaques mais c'est surtout la focalisation du marché sur quelques plateformes qui rend « visible » et « rentable » le développement d'attaques. Ces systèmes d'exploitation mobiles sont donc devenus des cibles de choix pour les attaquants en tout genre, voir des vecteurs de nouvelles attaques inquiétant même les opérateurs de téléphonie mobile.

Il faudra alors certainement recourir à des mécanismes de protections complémentaires, soit au niveau de la plateforme, soit au niveau des applications directement. Cette dernière voie est aujourd'hui la plus simple à gérer et à maintenir sur les nouvelles plateformes, en particulier l'iPhone, elle apporte une réponse qui permet à l'entreprise d'avoir le contrôle des données professionnel mais il est vrai qu'elle ne peut empêcher la compromission du système sous-jacent. Sur le front des outils dédiés à la sécurité, les derniers mouvements du marché, mené par Juniper, Symantec, F-Secure ou encore McAfee, montrent clairement que les éditeurs préparent leur réponse. Pour autant, nous sommes encore loin du niveau de maturité et de capacité d'action connue sur les ordinateurs conventionnels. Et si Android montre son ouverture et va permettre des actions de sécurisation avancées, l'iPhone reste lui sous le contrôle d'Apple, qui peut manquer de réactivité, voire de moyens simples de faire évoluer la sécurité de sa plateforme (par exemple absence de notion de « patch over the air » obligeant une réinstallation de tout le système d'exploitation).

Attention cependant à ne pas reproduire les erreurs du passé, en particulier celles des outils de sécurité pour les plateformes Windows Mobile, qui rendaient les terminaux tout simplement inutilisables. Il faudra donc surveiller à la fois la sécurisation des plateformes, mais aussi et peut être surtout, celle des applications elles-mêmes, au moment de leur acquisition ou lors de leur développement.

Une fois de plus, les RSSI se retrouvent dans une position complexe, soumis d'une part à un besoin légitime et pressant des métiers et du management d'offrir ces nouveaux moyens de communication, et d'autre part à l'apparition rapide de menaces avérées même si encore peu répandues. Les vacances ne sont décidemment pas de tout repos !

PKI (Private Key Infrastructure) et TPC : Tiers Partie de Confiance

Jean-Pierre Cabanel — 2010-08-20T18:50:25Z

Chapitre 3

Sommaire

2. La Notion de TPC : Tierce Partie de Confiance 11

La Notion de TPC : Tierce Partie de Confiance

La loi du 26 juillet 1996, introduit la notion de TPC. Nous avons analysé les principales fonctions relatives à l'utilisation d'une PKI générateur de moyens de signature ou de chiffrement, nous allons maintenant traiter la notion de TPC.

Le certificat d'un utilisateur, ne possède de réalité que par la signature de L'AC, donc par sa clef privée. Il apparaît alors un certain nombre de questions attachées à la fonction PKI :

Comment avoir confiance dans la clef privée de L'AC, ou comment avoir confiance dans une clef de chiffrement fournie. Cela pose principalement plusieurs types de questions :

1. La seconde relève des potentialités que des intrus auraient de modifier la clef de l'AC
2. La troisième traite de l'intégrité des hommes qui gèrent la PKI
3. La quatrième analyse les procédures humaines et techniques qui régissent le fonctionnement de la PKI et la consistance de la clef de l'AC

La notion de TPC propose d'organiser des solutions à ces questions.

La protection physique du site du TPC ainsi que sa protection vis-à-vis des accès réseaux, sont un des premiers éléments à traiter dans la conception d'un TPC.

Sans s'étendre sur la protection physique des bâtiments du TPC, ils doivent garantir une protection élevée contre la pénétration d'intrus humains ou de rayonnement : sas d'entré, pas de fenêtres, système alarme, salle protégée sur le plan électromagnétique, etc. Sur le plan des accès réseaux, aucun accès direct à des machines contenant ou qui génèrent des clefs privés ne sont acceptés.

Le deuxième point, relève des accréditations des personnes qui gèrent le TPC, en effet, la confiance des utilisateurs envers les moyens générés par le TPC, est confortée si le système est sous le contrôle de structure étatique.

Les procédures de génération sont un des points clefs du TPC, elles vont décrire les différentes étapes de génération, le nombre de personnes qui vont intervenir et dans quel ordre.

Les moyens informatiques utilisés, leurs différents constituants autorisés vont être décrits, la technique cryptologique utilisée va être contrôlée afin de garantir la consistance des clefs générées.
Les relations avec les clients sont aussi codifiées afin de structurer les échanges et éviter les litiges : politique de certification.
L'ensemble de ces mesures doivent alors passer les tests d'intrusion et d'analyse de sécurité : chaine des éléments physiques utilisés et des enchainements des procédures.
La fonction de TPC se retrouve soit en interne d'entreprise ou d'entité administrative soit comme système destiné et ouvert au public.

PKI (Private Key Infrastructure) et TPC : Tiers Partie de Confiance

Jean-Pierre Cabanel — 2010-08-20T18:45:45Z

Chapitre 2

Sommaire
1. Description d'une PKI : Private Key Infrastructure 3
C . Les problèmes de sécurité dans une PKI 7

C. Introduction aux problèmes de sécurité dans une PKI

1. La protection de la clef privée de l'AC

Dans cet exemple, il y a séparation physique entre le processeur Signer qui contient le biclef de l'AC et le processeur Accès qui est accédé de l'extérieur de manière contrôlée (population connue).
Les communications entre les deux processeurs sont toujours contrôlées par le processeur Signer, aucun trafic ne peut être initialisé par Accès vers Signer. Les communications entre les deux processeurs sont chiffrées et chaque échange est authentifié. Il existe un seul port utilisable entre les deux processeurs.

Le risque de leurrer le Signer par une autre machine Accès est très faible car en plus des mesures décrites précédemment, il est encore possible de filtrer les communications entre les deux processeurs.
Les risques potentiels peuvent venir des accès extérieurs au processeur Accès : virus, destruction d'Accès et/ou de Signer par l'intermédiaire d'Accès.

2. La protection du serveur Accès

• L'accès des AE est contrôlé par une authentification forte : carte à puce spécifique, identifiant spécifique, certificat qualifié, signature de son certificat par l'AE avant de le présenter au serveur Accès et chiffrement souhaité pour les communications.

• L'accès des Bornes pour le renouvellement des certificats est contrôlé à partir d'une authentification (certificat et signature du certificat). Dans le cas de la création initiale d'un certificat et du chargement dans la carte à puce, l'accès doit être contrôlé par un ensemble de mécanismes. Les communications entre une Borne et le serveur Accès sont chiffrées. Les Bornes peuvent aussi être gérées par les AE, cela améliore la sécurité mais rend plus lourd l'exploitation du système.

3. Les autorités d'enregistrement

Les AE communiquent avec le serveur Accès, afin de fournir au point central l'ensemble des informations concernant l'utilisateur, ces dernières sont de trois types :

• Les informations propres au certificat
• Les informations relatives à l'identification de l'utilisateur
• Les informations sur les droits d'accès (si utilisation)

Une AE est gérée par le serveur Accès, et elle utilise une carte à puce qualifiée AE, avec son identifiant.

Dans cet exemple, les fonctions de base d'une AE sont les suivantes :

• Après identification d'un utilisateur, émission pour ce dernier d'un formulaire représentant une requête certifiée de certificat au serveur Accès.
• Révocation d'un utilisateur
• Consultation du journal des AE qui présente les informations sur l'ensemble des certificats demandés et générés.

Chaque certificat utilisateur contiendra l'identifiant de l'AE d'authentification.

L'accès des AE est contrôlé par une authentification : carte à puce (code PIN à 8 caractères) spécifique, identifiant spécifique, certificat qualifié, signature de son certificat par l'AE (clef privée gardée en mémoire) avant de le présenter au serveur Accès et chiffrement souhaité pour les communications. Le serveur accès contrôle la signature de l'AC du certificat (intégrité du certificat), sa qualification AE, la signature du certificat par l'AE (authentification du propriétaire) et son existence dans le LDAP (existence non révoqué).
On peut en plus imaginer que l'intégrité de l'authentification d'une AE pendant la durée de sa communication avec le serveur Accès soit sauvegardée, par un mécanisme de référence dynamique, afin d'éviter toute pénétration d'une communication après la phase d'authentification de l'AE par Accès.

4. Nécessité d'une administration et d'une traçabilité des opérations.

Il doit exister plusieurs journaux mémorisant l'ensemble des opérations et des informations :

• Le journal des AE qui mémorisent par AE, les opérations, l'état du certificat, et les informations associées.
• Le journal central qui compile l'ensemble des informations relatives aux AE, plus celles relatives à l'administrateur du site.
• La base des certificats qui mémorise uniquement les informations contenues dans les certificats et leurs états.

Ces journaux et l'ensemble des deux systèmes Signer et Accès doivent être régulièrement sauvegardés et archivés afin de pouvoir restaurer la PKI dans le cas de panne ou de malveillance.

5. Les révocations et les CRL

Les AE et l'administrateur central peuvent révoquer un certificat. L'information de révocation est automatiquement mémorisée dans les différents journaux et le LDAP.
Le Signer génère alors une CRL et la signe, cette dernière peut être émise vers les administrations de serveurs applicatifs, de mail ou vers les utilisateurs. La révocation est protégée par les mécanismes déjà énoncés vis à vis de la protection d'accès des AE et de l'administrateur central

PKI (Private Key Infrastructure) et TPC : Tiers Partie de Confiance

Jean-Pierre Cabanel — 2010-08-20T18:40:44Z

Chapitre 1

Sommaire
1. Description d'une PKI : Private Key Infrastructure 3
A. Introduction à la notion de PKI 3
B. Le mode de fonctionnement d'une PKI 5

1. Description d'une PKI : Private Key Infrastructure

Une PKI est un système dont la fonction principale est de délivrer des moyens de signatures : certificat RSA ou ECC ou des moyens de chiffrement. Pour réaliser cette fonction vis-à-vis de tiers, il faut présenter un certain de niveau de confiance, une carte d'identité possède une valeur par la signature de l'entité de confiance qui est la préfecture, dans le cadre des moyens de signature ou de chiffrement nous avons une problématique identique. Les deux notions sont donc liées et la réalité de l'une est attachée au niveau de confiance de l'autre.

A. Introduction à la notion de PKI

Une PKI type offre les services suivants :

• Un système PKI permet de générer des certificats qualifiés X509v3 En RSA ou ECC utilisés pour les signatures électroniques des personnes ou des serveurs et/ou des moyens de cryptologie pour une utilisation dans un cadre intranet et/ou extranet et ou Internet
• Un agenda/LDAP d'entreprise ou d'administration, centralisé ou distribué géographiquement
• Un Agenda/LDAP accessible par les utilisateurs qui possèdent un certificat signé par l'AC : autorité de certification de référence, et qui peuvent « downloaded » les certificats d'autrui pour réaliser un chiffrement asymétrique, ou connaître l'adresse mail d'un autre utilisateur. L'accès à l'Agenda/LDAP est réalisé à travers la dichotomie choisie par l'administrateur du PKI/LDAP. _• Une description détaillée des pratiques de certification, véritable règle de fonctionnement (horloge, distribution des certificats, révocation, renouvellement etc. : Politique de certification.)

Une unité de système peut être composée des entités suivantes :

• Une machine (Signer) centrale dont la fonction principale est la génération des certificats et des moyens de cryptologie
• Une machine (Accès) centrale qui permet l'interface avec les utilisateurs, gère la fonction d'agenda (LDAP) et intègre l'interface pour les Autorités d'Enregistrement (AE).
• Les postes des Autorités d'Enregistrement (AE), qui permettent d'enregistrer l'authentification des utilisateurs désirant des moyens de signature sur le PKI central et de révoquer des utilisateurs déjà enregistrés.
• Les bornes (BO) qui permettent de télécharger un moyen de signature dans la carte à puce de l'utilisateur.
• Un système de sauvegarde permettant de protéger l'ensemble du système machine Signer et Accès.

Exemple d'architecture d'une PKI

Les utilisateurs n'accèdent pas directement au Serveur Signer, ils déposent leurs requêtes dans le Serveur Accès, et le Serveur Signer vient les chercher. Ceci permet de protéger la clef privée de L'AC : autorité de certification.

Le système permet alors de générer des moyens de signature :

Les moyens de signature comprennent un biclef et un certificat, ils servent à signer des documents et à s'authentifier pour toute opération. Chaque certificat X509V3 peut être qualifié, cela veut dire que ce dernier contient les droits d'accès de l'utilisateur : droits d'accès vis à vis de l'appartenance à un groupe, du type, de l'objet et des fonctions associées sur lesquels des opérations sont autorisées.
Cette qualification permet d'utiliser les mêmes moyens de signatures dans des contextes très différents : accès physique, accès logique à différents objets, signature électronique groupe d'utilisateurs, etc.

B. Schéma de fonctionnement d'une PKI

Cas général de génération de moyens de signature

Après initialisation du PKI/LDAP central : création dynamique de la dichotomie de classement des différents utilisateurs (usine, département, base, escadron etc.) et définition des types de droits d'accés délivrables à ces derniers, les étapes de génération des moyens de signature sont les suivantes :

1. Authentification forte de l'utilisateur par une AE suivant les « Procédures de certification » utilisées : contact visuel, documents d'identification, etc.

2. Connexion en mode sécurisé et avec authentification de l'AE concernée au site du PKI/LDAP central (à la machine Accès). Durant cette connexion l'AE va autoriser l'utilisateur à réaliser une demande de moyen de signature. Pour cela l'AE édite l'ensemble des informations relatives à l'utilisateur qui seront soit contenues dans son certificat ou qui seront mémorisées de manière confidentielle, (journalisation et fiche personnelle). L'AE peut définir les droits d'accés de l'utilisateur qui qualifieront son certificat. L'identité de l'AE est mémorisée et la requête de l'AE est sauvegardée sur le site central.

3. A partir d'une borne (BO), connexion en mode sécurisé et avec authentification de l'utilisateur au site du PKI/LDAP central (à la machine Accès), afin d'obtenir son moyen de signature dans sa carte à puce. Après contrôle du PKI/LDAP, les informations relatives à l'utilisateur et saisies par l'AE sont alors présentées à l'utilisateur, après accord de ce dernier et acceptation des « Procédures de certification » en cours, le bi clefs (clef privée et clef publique) de signature est généré par le logiciel de la borne, et la requête utilisateur (signée) accompagnée de la clef publique générée est communiquée au site central.

Le PKI/LDAP (machine Signer) va après contrôle, générer un certificat et le signer avec sa propre clef privée (clef de l'AC), ce dernier est téléchargé sur la borne (BO) pour acceptation par l'utilisateur et chargement avec la clef privée de l'utilisateur dans sa carte à puce.
Après réussite du chargement de la carte à puce le PKI/LDAP mémorise le certificat généré dans le LDAP, et édite les différents journaux (AE et machine Signer).
A la réception du certificat le système contrôle l'adéquation entre la clef privée de l'utilisateur restée dans la carte à puce et la clef publique retournée avec la clef privée de l'utilisateur restée dans la carte à puce et la clef publique retournée avec le certificat.

Cas de révocation des moyens de signature

La révocation des moyens de signature d'un utilisateur peut être réalisée soit par l'AE qui a authentifié ce dernier ou par l'administrateur central. Ces informations sont alors communiquées au LDAP central et les « CRL » (liste de révocations) sont alors émises vers les différents sites applicatifs qui réalisent un contrôle d'accés.
Dans le cas de nécessité de modification des droits d'accés d'un utilisateur, il est nécessaire de révoquer le certificat et de générer un nouveau moyen de signature.

Cas du renouvellement des moyens de signature

Le renouvellement des moyens de signature est réalisé à partir des bornes (BO), la fréquence de renouvellement peut être choisie par l'administrateur central, et le renouvellement est total : biclefs et certificat.

Laurent Charveriat, I-TRACING : Les risques majeurs de la virtualisation

Laurent Charveriat, Directeur Technique et cofondateur d'I-TRACING — 2010-08-09T17:06:59Z

La virtualisation n'est pas un terme récent ou un effet de mode, contrairement à ce que l'on pourrait penser. IBM a inventé ce concept dans les années 1960 en embarquant une couche de virtualisation dans ses supercalculateurs MAINFRAME. Ces puissants centres de calcul pouvaient faire fonctionner plusieurs instances de système d'exploitation afin de gérer plusieurs tâches simultanément. Dans les années 1990, VMware ajoute la virtualisation aux architectures matérielles x86 dans le but d'optimiser les ressources. Aujourd'hui VMware fait partie des leaders du marché de la virtualisation en environnement x86 qui est en pleine explosion. Des avantages indéniables…

Les bénéfices de la virtualisation sont tellement évidents que de nombreuses organisations l'ont rapidement adoptée, sans parfois prendre le temps d'analyser toutes les implications de sécurité liées à cette technologie. Faire fonctionner plusieurs systèmes d'exploitation sur un seul ordinateur, comme s'ils fonctionnaient sur des ordinateurs distincts présente de nombreux avantages mais aussi certains pièges à éviter.

La virtualisation transforme, pour les machines virtuelles, la gestion hardware en gestion software. Il devient alors possible d'ajouter, par exemple, de la mémoire, de la puissance CPU, une carte réseau ou de l'espace disque à un serveur fonctionnant dans une machine virtuelle sans devoir intervenir physiquement sur le serveur. Une fois les serveurs hôtes physiquement connectés aux réseaux, aux baies de stockage… aucune opération de connexion supplémentaire n'est nécessaire, ce qui réduit d'autant les besoins de câblage et simplifie les branchements. Mettre à disposition un nouveau serveur pour l'installation de nouvelles applications ne demande donc que quelques heures.

Dès lors que l'infrastructure de virtualisation est correctement dimensionnée et qu'elle s'appuie sur différents serveurs physiques, la mise à jour des serveurs physiques (drivers ou composants VMware eux-mêmes) s'effectue très simplement, ce qui garantit une haute disponibilité des services supportés par ces serveurs. Les VM sont indépendantes du hardware sur lequel elles s'exécutent et transforment un serveur en un ensemble de fichiers. Aussi, la gestion des Plans de Continuité d'Activité se trouve grandement simplifiée. Le redémarrage sur un site distant des serveurs ne fonctionnant plus à la suite de la destruction d'un data center ou de son isolation sur le réseau est simple. La mise en service d'un nouveau serveur pour l'installation de nouvelles applications devient rapide. Accompagner la montée en charge d'un nouveau service est simplifiée.

Les avantages sont aussi d'ordre financier car le hardware est optimisé. En effet, dans la situation « classique » d'un serveur physique qui supporte un serveur « logique », le serveur physique n'est que très rarement utilisé juste à hauteur de ses capacités. Il est souvent surdimensionné. Dans le cas contraire, il serait tôt ou tard « upgradé ». Les frais de maintenance, consommation électrique et climatisation, tout comme la place occupée par les matériels dans le data center, sont donc optimisés.

Mais des risques subsistent…

Malgré de nombreux atouts, une infrastructure de virtualisation présente des risques intrinsèques à sa raison d'être. En consolidant la charge de travail de différents serveurs sur une même machine, on augmente la criticité de la machine. La panne matérielle d'un serveur hôte entraîne l'arrêt de l'ensemble des services consolidés sur la machine.

Il existe des problèmes d'étanchéité entres les machines virtuelles et la machine hôte, rendant possible l'accès au système physique.
La virtualisation entraîne une augmentation des risques de sécurité informatique. La principale raison réside dans le fait qu'une machine supportant plusieurs serveurs virtuels est forcément plus vulnérable qu'un seul serveur physique. Au sein des entreprises, les directions des systèmes d'information et des risques commencent à en prendre conscience.

Sécurité des accès

Pour faire dialoguer deux serveurs réels, il faut préalablement réaliser des opérations physiques sur les serveurs. On les connecte physiquement à l'aide de câbles réseaux, classiquement par l'intermédiaire de commutateurs. De même, l'ajout d'une carte réseau nécessite d'accéder physiquement au serveur et de la placer dans le châssis. Avec la virtualisation, ces opérations sont faites à distance et de manière logicielle. Le fait qu'il soit beaucoup plus facile (et c'est un véritable atout pour l'administration) d'établir une connectivité entre des VM qu'entre des serveurs physiques, présente un risque supplémentaire en cas d'erreur ou de malveillance de configuration.

Il ne faut pas négliger l'aspect critique des serveurs de virtualisation. Toute personne non autorisée qui obtient l'accès au serveur peut copier des informations sensibles d'une infrastructure. La console est une machine virtuelle, particulièrement sensible puisque les opérations exécutées peuvent impacter l'ensemble des VM supportées. Il est donc indispensable d'en contrôler parfaitement les accès. Des accès illicites seraient lourds de conséquences !

Par ailleurs, des utilisateurs mal intentionnés ou maladroits peuvent, perturber et interrompre le service, voire modifier certains paramètres de configuration. Les atouts véritables de l'administration d'une infrastructure complexe formée de nombreux serveurs du fait de la virtualisation, peuvent se retourner et présenter des risques, si les administrateurs (légitimes ou illégitimes) ont des droits trop importants sur l'ensemble de l'infrastructure. Un administrateur ayant tous les droits sur l'infrastructure de virtualisation pourrait par exemple, en quelques clics, stopper des VM. Ce qui reviendrait à couper l'alimentation d'une partie d'un data center ! Il lui serait aussi possible de supprimer purement et simplement, tout ou partie des VM. Ce qui reviendrait à détruire des serveurs physiques et les données associées !

Accès aux VM à partir du système hôte

Le système supporte un ensemble de machines virtuelles. De fait, l'administrateur du système hôte peut accéder aux serveurs fonctionnant dans les machines virtuelles. Cependant, être administrateur du système hôte ne veut pas dire être administrateur - au sens système - des serveurs contenus dans les VM (ce qui est d'ailleurs rarement le cas). Toutefois, rien ne l'empêche de récupérer les fichiers des VM ou tenter un accès console.

Certaines failles de la couche de virtualisation et des services associés ou composants annexes, peuvent se traduire par des risques d'élévation de privilèges au sein des serveurs hôtes. Les fonctionnalités d'administration des VM, pourraient être sources de vulnérabilités en favorisant des évasions et des élévations de privilèges au sein des VM.

Suivi des performances et du service

Il est possible pour un programme malicieux d'affecter la charge d'une machine virtuelle et d'impacter l'ensemble des performances des différentes machines. Indisponibilité des serveurs

Le principe de la virtualisation est de mutualiser un serveur physique pour faire fonctionner plusieurs serveurs réels, dans le sens qu'ils supportent des applications et/ou des services bien réels, s'exécutant au sein de machines virtuelles supportées par ce serveur physique. L'indisponibilité du serveur physique provoque de fait l'indisponibilité de l'ensemble des serveurs supportés et donc des services et applications associés.

Ouverture de l'espace de stockage des VM

Dès lors que des serveurs physiques supportent les mêmes machines virtuelles (en particulier pour gérer la haute disponibilité en cas de panne hardware), il est nécessaire qu'ils accèdent au même espace de stockage. Plus on souhaite mutualiser (et donc optimiser) l'usage de serveurs physiques, plus on doit ouvrir l'accès à l'espace de stockage de ces VM.

Prise de contrôle du système par l'hôte

Un programme exécuté sur une machine hôte peut effectuer des actions sur le système lui-même, voire en prendre le contrôle. Ce type de vulnérabilité est particulièrement critique.

Quelques conseils pour réduire les risques liés à la virtualisation

L'entreprise est amenée à respecter certaines règles. Elle doit déterminer les services à virtualiser en intégrant dans sa réflexion, l'analyse des risques pour chaque application et chaque service concerné et l‘interdépendance avec l'infrastructure existante. Il lui faut aussi mesurer l'impact d'un dysfonctionnement ou de l'arrêt du serveur hôte. L'intégration et l'administration des serveurs hôtes dans l'infrastructure sécurisée existante est une sage précaution et la mise en place d'un processus de surveillance de type « sécurité système et applicatif » une impérieuse nécessité.

Etablir une politique des privilèges, définir les processus et rédiger les procédures sont indispensables. Il faut aussi informer et former le personnel. L'entreprise doit rester vigilante.

La prise en compte de ces quelques règles apportera des améliorations.

Cyrille Barthélémy, Intrinsec : Audit de sécurité dans le cloud computing, de nouvelles pratiques en émergence

2010-04-23T09:56:20Z

Considérons les modèles de services SaaS, Paas et IaaS posés depuis 2009 par le NIST[1]. Prenons les quatre modèles de déploiement privé, public, communautaire ou hybride. Chaque couple modèle de service/modèle de déploiement a des spécificités qu'il faut prendre en compte dans le plan d'audit général ou les expressions de besoins ponctuelles afin d'évaluer ou de contrôler la sécurité.

Les cercles de réflexion déjà sensibilisés au sujet du Cloud s'accordent à dire qu'il s'agit d'une agrégation de technologies disposant de bonnes pratiques, pour autant la sécurité de l'ensemble (et la façon de l'évaluer) n'est pas perçue de manière aussi transparente ("le tout est plus grand que la somme des parties").

Quant aux analystes, ils observent que la réticence à mettre en œuvre une solution de Cloud computing vient du manque de visibilité sur la sécurité des clouds : cette observation est renforcée par la multiplication des audits, tests d'intrusion et contrôles de conformité sur ces environnements mutualisés.

Enfin le retour d'expérience des prestataires de services de sécurité en termes d'audits ou de tests d'intrusion sur « les nouveaux clouds » montrent que l'infrastructure sous-jacente, les couches de virtualisation du réseau, du stockage et des systèmes sont le plus souvent laissés de côté ; tant au niveau technique qu'organisationnel.

Considérons votre solution SaaS hébergée sur un cloud :

La forte mutualisation et la grande proximité de données tierces limitent fortement les degrés de liberté des campagnes de tests et ne permettent pas de faire une évaluation réaliste de la sécurité de votre système. Par ailleurs vous n'aviez pas besoin des accès au web service, à l'API, ... Vous n'avez donc pas souscrit à l'option et ne vous souciez pas de sécuriser les accès… Pourtant ils présentent un risque et devraient faire partie de l'évaluation !

Prenons maintenant votre solution IaaS hébergée sur un cloud privé externe :

Vos systèmes s'exécutent à l'extérieur de votre entreprise, confinés dans le cloud privé de votre prestataire, sur des infrastructures mutualisées avec d'autres clients. L'évaluation classique se concentrera sur l'infrastructure que l'on vous fournit. Cependant le contrôle des systèmes mutualisés est majeur et doit être décrit dans les scénarios de test :

. les attaques latérales (lancés depuis l'infrastructure d'un autre client),

. les capacités de malveillances internes sur les données,

. les capacités d'attaques de backoffice de gestion du cloud (ingénierie sociale sur le système de gestion du changement, attaques des zones d'administration privilégiés).

L'audit effectif des systèmes mutualisés sera sans aucun doute un point de friction à venir avec votre hébergeur : Il est déjà compliqué d'effectuer totalement et sans retenue l'audit d'un système mutualisé simple (un DNS ou un relai de messagerie) ; L'audit (ou pire, le test d'intrusion) sur un hyperviseur ou un SAN mutualisé sera encore plus complexe à réaliser.

Votre hébergeur solutionnera le problème par des revues théoriques ou des extractions de configuration qui sont moins probantes sur ces points stratégiques. Assurez vous donc lors de la revue de votre contrat avec votre hébergeur d'avoir pris en compte toute les considérations de sécurité, pour faire autoriser ce type de contrôle par la suite ou obtenir une transparence sur les mesures de sécurité déployées.

Heureusement certains organismes travaillent sur un début de solution à toutes ces problématique de sécurité sur le Cloud :

L'analyse de risque publiée par l'ENISA [2] et le guide de bonnes pratiques préparé par la Cloud Security Alliance [3] mettent en avant un certain nombre de risques spécifiques ou génériques, des listes de contrôles ainsi qu'un ensemble de bonnes pratiques qui peut être dérivé en liste de contrôle vis à vis de l'état de l'art du moment. Outil prometteur, la matrice de contrôle en cours de construction par la CSA [4] viendra d'ici quelques mois compléter ce premier arsenal.

Considérant les technologies en place, de nombreuses bonnes pratiques et outils de contrôle sont déjà disponibles. Les référentiels et les compétences adaptés aux exigences de sécurité et aux modèles de déploiement restent à développer, pour fournir un cadre minimal pour évaluer la sécurité de ces infrastructures.

[1] http://csrc.nist.gov/groups/SNS/clo...
[2] http://www.enisa.europa.eu/act/rm/f...
[3] http://www.cloudsecurityalliance.org/
[4] http://www.cloudsecurityalliance.or...

Gérôme Billois, Solucom : Sécurité des iPhone, la solution est dans l'application !

Gérôme Billois – Manager Sécurité – Solucom — 2010-04-12T16:24:59Z

L'iPhone est par définition un terminal grand public et multimédia. Il exerce de plus en plus une très forte attirance auprès des grandes organisations et des populations d'utilisateurs friandes d'innovation. Cependant, en terme de sécurité, l'iPhone connait des lacunes importantes qui freinent son déploiement dans un contexte professionnel, en particulier car il est difficile de déployer des solutions tierces au cœur même du terminal du fait du verrouillage d'Apple. En outre, les solutions fournies pour le durcissement du terminal ou la gestion de parc sont largement perfectibles et difficiles à maintenir à grande échelle. Même si très récemment, Apple a annoncé avec la version 4.0 d'iPhone OS des nouveautés intéressantes, ils restent à en mesurer concrètement l'efficacité.

Pour contourner ces limitations, une nouvelle approche s'impose aujourd'hui en entreprise : l'utilisation d'une application dédiée installée sur le terminal. Ce concept simple et efficace consiste à déployer une application qui gérera la sécurité des informations qu'elle contient indépendamment du terminal. Chiffrement, authentification, effacement, contrôle du couple SIM/IMEI… le champ des possibles est très large car l'éditeur a toute latitude à implémenter des solutions de sécurité avancées dans l'application qu'il maîtrise intégralement. La sécurité est donc imposée au seul périmètre de l'usage des données de l'entreprise, tout en permettant tous les autres usages de l'iPhone.

Ces solutions ont un avantage indéniable : elles permettent de laisser à l'utilisateur une latitude très forte sur le terminal. Il peut ainsi installer des applications ou encore profiter des fonctionnalités multimédia. La sécurité est imposée au seul périmètre de l'usage professionnel en permettant un usage personnel ouvert.

Les risques encourus seront faibles car c'est l'application dédiée qui protégera les données et qui en empêchera l'accès. Et finalement, dans ce contexte, les défauts que l'on reproche habituellement à l'iPhone (OS fortement verrouillé, applications vérifiées, multitâche limité et encadré apportés par l'OS .40, …) se transforment en avantages indéniables en termes de sécurité, car ils vont protéger l'application d'éventuelles interactions externes malveillantes !

Bien entendu il faudra évaluer ces applications aussi bien sur les volets ergonomie, impact sur le SI que sécurité ; en particulier pour les fonctions de chiffrement, d'effacement à distance et de gestion des accès. Il est également important de s'assurer que la gestion des paramètres de sécurité propre à l'iPhone est également prise en charge : il s'agit par exemple du blocage des sauvegardes de l'application par iTunes. Cela permettra d'éviter que les données, bien que chiffrées, puissent être capturées et attaquées par des tentatives en brute-force.

Et bien que la sécurité soit dès lors techniquement assurée, la sensibilisation des utilisateurs reste une bonne pratique nécessaire, et ceci à la fois sur la sécurité du terminal (par exemple prohiber les opérations telles que le « jailbreak » qui remettrait en cause certaines fonctions de sécurité) et sur le respect des droits d'auteurs lors des utilisations multimédias.

Aujourd'hui ces applications sont avant tout destinées à permettre l'accès à la messagerie mais des usages métiers peuvent également être envisagés. Le marché est en cours de construction et les premiers retours d'expérience dont nous disposons montrent la facilité d'usage et le bon degré d'adoption des utilisateurs.

Cette solution présente en effet un avantage indéniable pour l'utilisateur : elle lui permet une grande marge de manœuvre sur le terminal. Jusqu'à lors, le déploiement d'iPhone fortement bridé en terme de sécurité en entreprise avait subit des demi-échecs, les utilisateurs étant déçus de ne pas pouvoir avoir les mêmes usages sur les terminaux de leurs proches. Ces applications offrent une nouvelle alternative plus judicieuse : elles répondent en effet à la demande de disposer d'un terminal innovant et performant tout en permettant des usages plus personnels comme l'installation d‘applications tierces ou encore l'utilisation des fonctions multimédia.

Finalement l'utilisation d'une application dédiée peut même permettre l'autorisation d'un nouvel usage encore peu répandu : l'utilisation de smartphone « personnel » pour accéder au SI de l'entreprise. En effet, vu que la sécurité dépend de l'application et non pas du terminal, il est possible d'utiliser un smartphone « non maîtrisé » sur lequel aucun contrôle de l'entreprise n'est nécessaire. Vu les taux de pénétration de l'iPhone chez les cadres, voilà de quoi déployer rapidement un service innovant, visible, accélérateur de productivité et également sécurisé !

Florian Carrière, SoluCom : Pour pérenniser votre PCA, développez sa valeur !

Florian Carrière, SoluCom — 2010-03-18T20:24:24Z

Longtemps considéré comme lourd et coûteux, le plan de continuité d'activité (PCA) doit aujourd'hui se transformer, sous peine de marginalisation et de devenir un outil d'usage courant pour l'organisation. Comment engager cette (r)évolution ?

Nombre de décideurs perçoivent aujourd'hui leur PCA comme un ensemble complexe de documents éloignés de la réalité opérationnelle, plus destinés à se rassurer qu'à servir concrètement le jour J... Vu comme une assurance destinée à couvrir un risque extrêmement improbable, le PCA est donc malheureusement idéalement positionné lorsqu'il s'agit de réduire les dépenses.

Partant de ce constat, si l'on souhaite maintenir un PCA efficient, il n'est plus qu'une seule option sérieuse : convaincre de sa nécessité en augmentant sa valeur pour l'organisation, en le rendant plus utile et plus visible pour ses utilisateurs.

Du PCA vécu comme une assurance peu utile…

La valeur d'un PCA, au-delà des arguments qualitatifs (avantage concurrentiel, impératif réglementaire, etc.), est directement liée à la probabilité d'occurrence des types de sinistre qu'il permet de couvrir, et aux pertes évitées dans ce cas. Les leviers pour augmenter cette valeur sont alors évidents : couvrir plus de cas de sinistres, parmi ceux ayant les fréquences d'occurrence les plus élevées et améliorer les solutions pour limiter toujours plus les pertes.

En effet, étendre le PCA aux cas d'incidents plus fréquents fournit l'argument idéal pour intéresser les responsables métiers, bénéficiaires finaux du PCA, de l'utilité de la démarche : on leur parle de leur quotidien, pas du cataclysme hypothétique auquel ils ne croient pas. Sur le fond, cela permet donc de remettre le PCA en prise avec la réalité des opérations, de l'obliger à s'adapter aux processus concrets de l'organisation. Quelles peuvent alors être les traductions concrètes de cette approche ?

… au PCA vu comme un service à la demande, plus utile et plus visible

En matière de continuité des opérations, pour couvrir plus de cas de sinistres rendant indisponibles les locaux utilisateurs, il est désormais possible de compléter le classique site de repli. On décide dans ce cas d'établir un « portefeuille de solutions » (incluant le nomadisme, des salles de réunions hors site, etc.), plus facilement mobilisables, car proposant une solution réaliste économiquement en cas d'incident mineur. En matière de continuité informatique, le gisement de progrès semble encore plus important. Car en profitant des récents progrès techniques, il est aujourd'hui possible de faire converger les démarches de secours informatique « classique » et la continuité de fonctionnement, traditionnellement portée par l'exploitation informatique.

L'avantage est évident : en mutualisant les ressources habituellement dédiées à chaque démarche (locales pour la continuité de fonctionnement, distantes pour le secours), on peut aisément limiter les dépenses associées, et donc embrasser un périmètre applicatif plus large. Et ce faisant, on ramène l'exploitation du secours dans le giron de la production informatique, souvent plus industrialisée : on met ainsi le PCA dans un cadre de maintenance plus structuré, ce qui ne peut que favoriser sa pérennité.

Une évolution nécessaire, à viser sur le long terme

Cette transformation est aujourd'hui possible, techniquement et économiquement : elle peut être engagée sur un premier périmètre pour en démontrer rapidement la pertinence, ou bien menée au fil de l'évolution du SI, en assurant que les modifications nécessaires sont bien intégrées lors des changements d'infrastructures (hébergement, réseaux, stockage, serveurs, etc.) et lors de la refonte des architectures.

Dans tous les cas, cette évolution nécessite une vision stratégique, à long terme, et une réelle fermeté, appuyée sur des convictions fortes. Car au-delà des évolutions techniques, c'est probablement en matière d'organisation et de coordination que la souplesse du PCA peut être le plus améliorée : disposer de services activables au besoin est une chose, savoir les orchestrer convenablement en est une autre !

Maître Henri Leben : Les modalités d'évaluation du préjudice en cas de perte de données

Henri Leben, Avocat à la Cour, Of Counsel cabinet ARTEMIA — 2010-03-11T20:53:01Z

Entre l'inondation des serveurs, la faillite du prestataire d'hébergement, l'acte malhonnête ou la maladresse d'un salarié, les causes de perte des données en entreprise sont nombreuses. La responsabilité du professionnel est encadrée par un certain nombre de textes (loi Informatique et Libertés en France, textes équivalents dans le reste de la Communauté européenne ou, prochainement, le Red Flag Identity Theft Rule aux Etats-Unis) mais la réglementation ne s'intéresse pas à l'appréciation du préjudice résultant de la perte des données.

C'est pourtant une question centrale qui a déjà donné lieu à une jurisprudence fournie.

La présente chronique se propose de passer en revue les principaux postes de préjudice consécutifs à la perte de données.

La perte des données traitées par une société, qu'il s'agisse de données personnelles ou de données nécessaires à l'activité, peut entraîner un préjudice direct à l'égard d'au moins deux acteurs :

l'entreprise qui a perdu les données ;
le cocontractant de l'entreprise.

S'agissant de l'entreprise dont les données sont perdues, plusieurs postes de coûts peuvent être identifiés :

* les coûts liés à la prise en charge technique de la perte. Il s'agit d'identifier rapidement l'origine du dysfonctionnement pour pouvoir mettre fin à l'hémorragie.

* Viennent ensuite bien sûr les coûts de « réparation » correspondant aux dépenses engagées pour reconstituer (ou tenter de reconstituer) les données. Ces coûts peuvent s'apprécier en termes de jours-homme si la reconstitution a été traitée par des salariés, ou en fonction de la facture du prestataire.

* Doit également être intégré le coût de la désorganisation de l'entreprise, consécutive à la perte des données. L'appréciation de ce coût peut se faire sur la base de deux méthodes, qui peuvent d'ailleurs être cumulées :

Comparaison du chiffre d'affaires moyen réalisé sur une période de référence, avec le chiffre d'affaires réalisé pendant la période où les données ont été inaccessibles. Ou,
Evaluation des dossiers n'ayant pu être traités du fait de la perte des données.

* On ajoutera également au coût de la désorganisation, les conséquences commerciales de la perte des données, avec en premier lieu, l'atteinte à l'image de marque et à la réputation de la société. Ce dernier coût pourra être mis assez facilement en évidence si la perte de données est suivie de la perte de clients.

* Enfin si dans certains cas seule l'entreprise traitant les données a à déplorer un préjudice, dans de nombreux cas, la perte de données entraine également un préjudice à l'égard des tiers. Lors de l'évaluation du préjudice consécutif à la perte de données, il convient ainsi d'intégrer les éventuelles conséquences judiciaires. Parmi les conséquences possibles, on retiendra :

L'engagement de la responsabilité contractuelle de l'entreprise lorsque la perte des données a retardé ou empêché l'exécution de ses obligations ;
L'engagement de la responsabilité contractuelle de l'entreprise, lorsque les données perdues concernaient l'activité de son cocontractant ;
L'engagement de la responsabilité délictuelle, lorsque la perte des données a entraîné un dommage vis-à-vis d'un tiers, non lié contractuellement à l'entreprise.

Ces différents postes de préjudice se retrouvent également chez le cocontractant.

A noter enfin que la perte de données peut engager la responsabilité du responsable du traitement,

(« Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu'elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès », article 34 de la loi Informatique et Libertés),

ainsi qu'avoir des conséquences sur les salariés de l'entreprise, dès lors que la perte des données résulte d'une faute susceptible de justifier un licenciement ou une mise à pied.

Dernier point, et non des moindres, la preuve du préjudice :

Dans tous les cas, l'identification des postes de préjudice ne suffit pas. Il convient également d'être en mesure de les chiffrer avec précision.

En cas de contentieux l'étendue du préjudice requiert en général le recours à un expert, chargé d'évaluer le dommage à partir des pièces fournies par les parties.

S'agissant de faits, le montant du préjudice peut être prouvé par tous moyens : données comptables, factures, attestations, projections, étude du marché, analyses statistiques, expertise privée, etc.

Pour mémoire, on rappellera également qu'il convient de distinguer le préjudice indemnisable de la simple perte de chance, pour laquelle les tribunaux n'accordent qu'une réparation limitée.

Dans tous les cas, on ne peut que conseiller de mettre en place des mécanismes de garantie efficaces, tant sur le plan technique que sur le plan juridique, afin de minorer au mieux les risques consécutifs à la perte de données.