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

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

Emploi des normes sur le marché

Généralités et spécificités sectorielles

16

Les sources de la SSI

Stratégie

Politique &Organisation

Pratiques & Procédures

Infrastructures

• 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

Identification Désignation Source EBIOS Méthode DCSSI MEHARI Méthode CLUSIF OCTAVE Méthode CERT PSSI Guide méthodologique DCSSI TDBSSI Guide méthodologique DCSSI PC2 Guide méthodologique DCSSI DSIS Guide méthodologique DCSSI Memento DeP Guide méthodologique DCSSI sp800-60 Guide méthodologique NIST PSC-SI Guide de bonnes pratiques GMSIH PAU Guide de bonnes pratiques GMSIH ITIL Guides de bonne pratiques itSMF – BSI Guide SMSI Guide de bonnes pratiques CNRS CobIT Guide de bonnes pratiques ISACA - ITGI ISF Guide de bonnes pratiques ISF ITSEC Norme d’exigences DCSSI ISO 15408 Norme d’exigences DCSSI EESSI Normes d’exigences MINEFI NF Z 42-013 Normes d’exigences AFNOR 21 CFR Part 11 Norme d’exigences FDA ISO 13335 Norme de bonnes pratiques ISO ISO 13569 Norme de bonnes pratiques ISO ISO 17799 Norme de bonnes pratiques ISO PRIS Politique de référencement DCSSI sp800-45 Guide technique NIST PPnc004 Guide technique DCSSI

18

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

Référentiel Principes D I C Autres critères

Critères Communs

Conceptuellement la sécurité est vue comme une relation rationnelle entre des propriétaires de biens et des agents menaçants

Intègre les notions de contre-mesures, de vulnérabilités et de risques

Présente concrètement des ensembles cohérents d’exigences de sécurité

Oui, mais non spécifiés

ISO 13335

Démarche ou action permettant de définir, d’obtenir et de maintenir des propriétés du SI

Présente une définition des concepts de management de la sécurité des SI : risques, principes d’organisation, fonctions de management, mesures

Non-répudiation Traçabilité Authenticité Fiabilité

N°901/DISSI/SCSSI

Etat de protection, faisant face à des risques, qui résulte de mesures visant à garantir des critères

Présente des recommandations applicables pour les administrations : principes généraux de sécurisation, classification des informations, moyens de protection, rôles et responsabilités

Non

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

Identification du besoin

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 ?

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.

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