cartographies et normes mercredi 10 novembre 2004
TRANSCRIPT
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