Cartographies et Normes Mercredi 10 novembre 2004.

Présentation au sujet: "Cartographies et Normes Mercredi 10 novembre 2004."— Transcription de la présentation:

1 Cartographies et Normes Mercredi 10 novembre 2004

2 2 Ordre du jour n 9h00 – 9h40 : Hexagram – Jean-Luc Marini –Enjeux relatifs aux normes et à lidentification des risques en SSI n 9h40 – 10h20 : Silicomp – Samuel Janin –Les normes et standards employés pour gérer la SSI –Quelques spécificités sectorielles dans lemploi des normes n 10h20 – 11h00 : MSI – Philippe Perret –Les labels de sécurité pour les produits

3 Présentation des Enjeux La conformité de l'entreprise à un référentiel reconnu

4 4 Préambule n Il y a une vingtaine d'année, apparaissaient les premières normes donnant un cadre à la sécurité des données et systèmes informatiques n Aujourd'hui le sujet évolue vers la sécurité des systèmes d'information, un enjeu de dimension plus globale lié à l'avènement des réseaux ouverts sur l'extérieur et à la généralisation d'Internet n D'un point de vue organisationnel, la notion de "processus sécurité" s'impose progressivement depuis quelques années avec la généralisation de la fonction de RSSI (Responsable de la Sécurité des Systèmes d'Information)

5 5 Une incitation à la certification n Les problématiques de sécurité des systèmes d'information font l'objet d'un mouvement similaire à celui de la démarche qualité n Conscientes d'enjeux plus importants encore, de nombreuses entreprises entament de leur propre chef une démarche visant la certification à terme n D'autres font de même pour des raisons d'ordre commercial et marketing, d'autres encore subissent des pressions en ce sens de la part de leurs clients, à mesure que se développent entre eux des liens dématérialisés

6 6 Les questions liées à la certification n Sur quel périmètre obtenir une certification ? n Quelle certification ? n Quelles exigences en matière de système de management de la sécurité des informations ? n Quelle norme utilisée pour auditer et certifier le système de management ?

7 7 Normes et méthodes pour un langage commun "L'abondance de normes et de méthodes est souvent source de confusion" Etude 2002 du CIGREF (Club Informatique des Grandes Entreprises Françaises) sur la sécurité des systèmes d'information

8 8 L'importance d'une gestion des risques n Normes et méthodes sont complémentaires : Elles témoignent de la prise de conscience de l'importance d'une gestion des risques –Marion a été poussée au début des années quatre-vingt par le secteur des assurances, qui ne savait pas comment mesurer le risque informatique –Melisa a été élaborée par la direction des constructions navales dans le souci d'évaluer la sécurité des industries de l'armement –Ebios a été créée par l'administration française pour accompagner les projets informatiques et prendre en compte les aspects sécuritaires

9 9 Pas de méthode sans norme Taux d'utilisation des normes et méthodes d'organisation et d'évaluation de la sécurité du système d'information dans les entreprises françaises - Etude 2002 du CIGREF sur la sécurité des systèmes d'information

10 10 Une cartographie des pratiques de sécurité n Toutes ces méthodes se présentent généralement sous forme de documents, de questionnaires et de bases de connaissances faciles à personnaliser n Leur rôle consiste à mesurer les pratiques de sécurité existantes et à en dresser une cartographie que l'on va ensuite rapprocher d'un référentiel extérieur dit de "bonnes pratiques" n Une méthode aide également à identifier les processus vitaux de l'entreprise et propose des métriques afin de chiffrer les conséquences de leur perte (partie analyse des risques)

11 11 Méthodes et normes ad hoc n Les méthodes d'analyse des risques s'avèrent complexes pour établir un référentiel de sécurité n D'où, la multiplication de méthodes et normes ad hoc à base de profils de détection (nombre minimum de défenses à appliquer et prise en compte des besoins relatifs à un environnement donné) n A titre d'exemple, le Comité Français d'Organisation et de Normalisation Bancaire a ainsi établi un profil répondant précisément aux besoins des établissements du secteur

12 12 Garantir de bonnes pratiques n Une norme vise essentiellement à fournir un référentiel de bonnes pratiques de sécurité, aptes à assurer à n'importe quelle entreprise un niveau de sécurité acceptable et surtout reconnu n La norme ISO 17799 reproduit à l'identique la première moitié du standard britannique BS7799 et se présente sous la forme d'objectifs à atteindre dans chaque domaine du système d'information n En revanche, si la norme ISO 17799 détaille les mesures à adopter en matière de sécurité, elle reste totalement muette sur la façon de les mettre en œuvre (c'est le rôle de la deuxième partie du BS 7799 qui n'a pas été adoptée dans le cadre de l'ISO 17799).

13 13 La mise en œuvre d'une norme La difficulté : "Traduire les exigences de la norme en métriques et outils de sécurité concrets"

14 14 Le constat … n Dans sa phase de mise en œuvre, la norme n'est généralement appliquée qu'à des sous ensemble de l'entreprise : un serveur, un département, une chaîne logique, etc. n Dans son approche globale, elle ne concerne souvent que les grands groupes, auxquels elle apporte un référentiel de sécurité commun entre des entités de nature et de structure différentes

15 Emploi des normes sur le marché Généralités et spécificités sectorielles

16 16 Les sources de la SSI Stratégie Politique & Organisation Pratiques & Procédures Infrastructures Méthodes danalyse des risques Besoins standards Référentiels de menaces Contraintes du marché et obligations réglementaires Référentiels de bonnes pratiques généralistes Pratiques sectorielles et fonctionnelles Directives administratives Normes dévaluation Offres du marché

17 17 Illustrations n DCSSI : –www.ssi.gouv.frwww.ssi.gouv.fr n CERT : –www.cert.orgwww.cert.org n NIST : –csrc.nist.govcsrc.nist.gov n CNRS : –www.sg.cnrs.fr/fsdwww.sg.cnrs.fr/fsd n ISACA : –www.isaca.orgwww.isaca.org n ITIL : –www.itil.co.ukwww.itil.co.uk n ISF : –www.securityforum.frwww.securityforum.fr

18 18 La sécurité est-elle définie par une norme ?

19 Les labels SSI Présentation générale des évaluations sécuritaires

20 20 But de la présentation n Fournir une présentation générale des évaluations sécuritaires n Faciliter la compréhension des déclarations des fournisseurs n Ce nest pas : –Une présentation exhaustive voire approfondie de telle ou telle méthode dévaluation –Un guide pour le passage des évaluations n La présentation est donc rapide et assez superficielle.

21 21 Identification du besoin n Client : n Comment trouver un bon produit de sécurité ? n Comment identifier les produits existants ? n Comment connaître la valeur réelle dun produit de sécurité ? n Comment éviter de passer du temps à tester tout un tas de produit ? n Fournisseur : n Comment prouver que mon produit de sécurité est bon ? n Comment faire connaître mon produit ? n Comment montrer la valeur de mon produit ? n Comment limiter les activités de support et de tests lors des avant-vente ?

22 22 Définition des évaluations sécuritaires n Lévaluation sécuritaire dun produit a pour but de donner à un utilisateur un certain niveau de confiance dans un produit/système (la cible). n Lévaluation sécuritaire est conduite par un tiers (ni client, ni fournisseur). n Une évaluation peut être initiée par un fournisseur mais également par un client. Généralement, cest le fournisseur. n Généralement, une évaluation porte sur le produit lui- même, mais également sur sa conception, son environnement de développement, ses procédures de livraison…

23 23 Intérêt pour les clients n Permet davoir rapidement une assurance de qualité dun produit/système logiciel ou matériel. n Permet de sélectionner rapidement des produits/systèmes n Limite le besoin de tests/audits dun produit/système car la tâche a déjà été réalisée. n Permet de prouver à ses propres clients la sécurité que lon utilise.

24 24 Intérêt pour les fournisseurs n Faire connaître ses produits. n Promouvoir auprès de ses clients la valeur de ses produits n Se démarquer de produits concurrents ne disposant pas dévaluation. n Améliorer la qualité de ses produits en mettant en place une organisation nécessaire à la réussite dune évaluation (cela peut être très léger [fournisseurs organisés] à très lourd [startup au fond dun garage]).

25 25 Cible de lévaluation (TOE) n Une évaluation a toujours une cible : le produit/système sur lequel porte lévaluation. n Une cible peut être une partie dun système (problème du coût humain et financier dune évaluation) n Lorsquun produit est annoncé comme évalué, il faut sinformer de la cible réelle de cette évaluation (commercialement, les amalgames sont tellement vite faits). n Lorsque la cible est une partie dun produit, il est important den valider sa pertinence tant par rapport au produit lui-même que par rapport à ses propres besoins.

26 26 FIPS 140-1 (présentation) n Security Requirements for Security Modules n Norme américaine issue du ministère de lindustrie n Surtout utilisé pour les cartes/boitiers de sécurité dorigine anglo-saxone n Peu utilisé pour les logiciels

27 27 FIPS 140-1 (niveaux) n Level 1 : Niveau minimal contenant des exigences sécuritaires de base sans contrainte matérielle n Level 2 : Inclut des contraintes de résistance à des attaques en imposant des vérifications dintégrité et dauthentification dopérateurs avec des rôles. n Level 3 : Ajoute des contraintes physiques (détection physique dintrusion comme louverture dun capot). n Level 4 : Ajoute de très fortes contraintes au niveau physique sur la détection des intrusions (enceinte blindée, détection des percages, des variations de pression…).

28 28 FIPS 140-1 (commentaires) n Dans la pratique, les cartes/boitiers de sécurité courants sont au niveau 3. n Le niveau 4 est très rarement atteint car les contraintes sont très fortes mais la sécurité est très forte. n MSI a utilisé la carte IBM 4758 (Level 4) pour le stockage des secrets des cartes bancaires.

29 29 ITSEC (présentation) n Méthode assez ancienne (1991) n Issue de lOrange Book (DOD) (correspondance avec les niveaux définis dans lOrange book n Définit les niveaux de confiance mais également la méthode dévaluation n A la réputation davoir une valeur variable selon les pays : –France : puriste intégriste (très dur à obtenir) –UK : laxisme n Une grande partie des produits évalués lont été en UK n Norme européenne

30 30 ITSEC (niveaux) n E0 : Tout ce qui nest pas ailleurs n E1 : Conception générale informelle, tests fonctionnels n E2 : Conception détaillée informelle, évaluation des tests fonctionnels, gestion de configuration n E3 : Evaluation du code source/schéma matériel lié à la sécurité, évaluation des tests correspondants n E4 : Modèle formel de la politique de sécurité. Mode semi-formel pour la conception générale, conception détaillée et fonctions de sécurité. n E5 : Preuve de la liaison entre conception détaillée et code source/schéma matériel n E6 : Mode formel pour la conception générale et les fonctions de sécurité compatible avec la politique de sécurité

31 31 ITSEC (commentaires) n Généralement, les produits logiciels de sécurité sont au niveau E3 n Les niveaux inférieurs ne sont pas suffisants n Les niveaux supérieurs sont très délicats à obtenir (plutôt du matériel que du logiciel)

32 32 Critères communs (présentation) n Successeurs de lITSEC. n Cherchent à corriger les faiblesses (homogénéisation des évaluations) n Monstrueux en volume de documentation n Reconnus internationalement (pas uniquement européen) n Définissent des classes dassurance (développement, tests, vulnérabilités…). n Lobtention dun niveau global (EAL) se fait par lobtention dun niveau minimal dans chaque classe.

33 33 Critères communs (niveaux) n EAL 1 : testé fonctionnellement n EAL 2 : testé structurellement n EAL 3 : testé et validé méthodiquement n EAL 4 : conçu, testé et revu méthodiquement n EAL 5 : conçu à laide de méthode semi-formelles et testé n EAL 6 : conception vérifiée à laide de méthodes semi- formelles et testé n EAL 7 : conception vérifié à laide de méthodes formelles et testé

34 34 Critères communs (commentaires) n Le niveau 4 est considéré comme le plus haut pour du logiciel n Le niveau 4 est néanmoins très utilisé car il est le seul nécessitant le code pour lévaluation n Les premiers niveaux sont généralement très marketings (on est certifié mais sans dire le niveau).

35 35 Critères communs (niveau augmenté) n EAL X correspond à un niveau dans chaque classe dévaluation n EAL X+ indique que certaines classes ont un niveau supérieur n Cela permet daugmenter le niveau de sécurité sur un point particulier.

36 36 Qualification administrative n Il y a trois niveaux : –Standard –Renforcé –Élevé n Le niveau à utiliser dépend de : –Le niveau de confidentialité des informations –Si les informations sont ou non de défense n Les niveaux sont définis en fonction des critères communs n Niveau standard EAL 2+ (avec des items niveau EAL 4) n Niveau renforcé EAL 4+ (avec des items EAL 6) n Le confidentiel défense nécessite le niveau renforcé. n Validation par la DCSSI de la pertinence de la cible.

37 37 Maintenance des évaluations n Les produits évoluent : –Évolutions techniques, –Evolutions fonctionnelles, –Correction danomalies. n Nécessité de mettre à jour les évaluations périodiquement pour en tenir compte une évaluation se périme.

38 38 En bref … n Les évaluations apportent une garantie de confiance au client. n Comme cest également un élément commercial, il faut faire attention : –Niveau réel de lévaluation, –Cible dévaluation, –Adéquation de la cible avec ses propres besoins, –Péremption de lévaluation.

39 Conclusion 1/3 des entreprises Françaises ne connaît pas la norme de sécurité ISO 17799 6% visent la certification 8% estiment être en conformité Enquête réalisée par l'AFAI en partenariat avec le CIGREF, le CLUSIF et le Monde informatique