Cartographies et Normes

1. Cartographies et Normes Mercredi 10 novembre 2004

2. Ordre du jour • 9h00 – 9h40: Hexagram – Jean-Luc Marini • Enjeux relatifs aux normes et à l’identification des risques en SSI • 9h40 – 10h20: Silicomp – Samuel Janin • Les normes et standards employés pour gérer la SSI • Quelques spécificités sectorielles dans l’emploi des normes • 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. Préambule • 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 • 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 • 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. Une incitation à la certification • Les problématiques de sécurité des systèmes d'information font l'objet d'un mouvement similaire à celui de la démarche qualité • Conscientes d'enjeux plus importants encore, de nombreuses entreprises entament de leur propre chef une démarche visant la certification à terme • 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. Les questions liées à la certification • Sur quel périmètre obtenir une certification ? • Quelle certification ? • Quelles exigences en matière de système de management de la sécurité des informations ? • Quelle norme utilisée pour auditer et certifier le système de management ?

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. L'importance d'une gestion des risques • 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. 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. Une cartographie des pratiques de sécurité • Toutes ces méthodes se présentent généralement sous forme de documents, de questionnaires et de bases de connaissances faciles à personnaliser • 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" • 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. Méthodes et normes ad hoc • Les méthodes d'analyse des risques s'avèrent complexes pour établir un référentiel de sécurité • 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é) • 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. Garantir de bonnes pratiques • 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 • 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 • 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 duBS 7799 qui n'a pas été adoptée dans le cadre de l'ISO 17799).

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. Le constat … • 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. • 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. Stratégie Politique &Organisation Pratiques & Procédures Infrastructures Les sources de la SSI • Méthodes d’analyse 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. Illustrations • DCSSI : • www.ssi.gouv.fr • CERT : • www.cert.org • NIST : • csrc.nist.gov • CNRS : • www.sg.cnrs.fr/fsd • ISACA : • www.isaca.org • ITIL : • www.itil.co.uk • ISF : • www.securityforum.fr

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. But de la présentation • Fournir une présentation générale des évaluations sécuritaires • Faciliter la compréhension des déclarations des fournisseurs • Ce n’est pas : • Une présentation exhaustive voire approfondie de telle ou telle méthode d’évaluation • Un guide pour le passage des évaluations • La présentation est donc rapide et assez superficielle.

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

22. Définition des évaluations sécuritaires • L’évaluation sécuritaire d’un produit a pour but de donner à un utilisateur un certain niveau de confiance dans un produit/système (la cible). • L’évaluation sécuritaire est conduite par un tiers (ni client, ni fournisseur). • Une évaluation peut être initiée par un fournisseur mais également par un client. Généralement, c’est le fournisseur. • 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. Intérêt pour les clients • Permet d’avoir rapidement une assurance de qualité d’un produit/système logiciel ou matériel. • Permet de sélectionner rapidement des produits/systèmes • Limite le besoin de tests/audits d’un produit/système car la tâche a déjà été réalisée. • Permet de prouver à ses propres clients la sécurité que l’on utilise.

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

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

26. FIPS 140-1 (présentation) • Security Requirements for Security Modules • Norme américaine issue du ministère de l’industrie • Surtout utilisé pour les cartes/boitiers de sécurité d’origine anglo-saxone • Peu utilisé pour les logiciels

27. FIPS 140-1 (niveaux) • Level 1 : Niveau minimal contenant des exigences sécuritaires de base sans contrainte matérielle • Level 2 : Inclut des contraintes de résistance à des attaques en imposant des vérifications d’intégrité et d’authentification d’opérateurs avec des rôles. • Level 3 : Ajoute des contraintes physiques (détection physique d’intrusion comme l’ouverture d’un capot). • 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. FIPS 140-1 (commentaires) • Dans la pratique, les cartes/boitiers de sécurité courants sont au niveau 3. • Le niveau 4 est très rarement atteint car les contraintes sont très fortes mais la sécurité est très forte. • MSI a utilisé la carte IBM 4758 (Level 4) pour le stockage des secrets des cartes bancaires.

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

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

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

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

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

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

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

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

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

38. En bref … • Les évaluations apportent une garantie de confiance au client. • Comme c’est é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