CSI4139 / CEG4399 Concep1on de systèmes informa1ques sécurisés Assurance & Évaluation

Transcription

1 CSI4139 / CEG4399 Concep1on de systèmes informa1ques sécurisés Assurance & Évaluation Préparé par Guy- Vincent Jourdan et Marc- André Paris- Clou9er, avec l aide des notes de Bishop pour Introduc9on to Computer Security

2 Confiance Une en9té digne de confiance(fiable) a suffisamment de preuves crédibles pour convaincre que le système sa9sfera un ensemble d exigences La confiance est une mesure de la fiabilité qui s appuie sur les preuves Assurance est la cer9tude qu une en9té sa9sfera les exigences de sécurité, cer9tude basée sur l applica9on de techniques d assurance

3 Rela9ons Policy Assurance Mechanisms Statement of requirements that explicitly defines the security expectations of the mechanism(s) Provides justification that the mechanism meets policy through assurance evidence and approvals based on evidence Executable entities that are designed and implemented to meet the requirements of the policy

4 Sources de problèmes 1. Défini9ons des exigences, omissions et erreurs 2. Défauts de concep9on du système 3. Défauts matériels, tels que mauvais câblage ou électronique défectueuse 4. Erreurs d implémenta9on logiciel, bogues dans le programme ou le compilateur 5. Erreurs lors de l u9lisa9on et l opéra9on du système et erreurs d inauen9on 6. Mauvaise u9lisa9on volontaire du système 7. Défaillance du matériel, de la communica9on 8. Problèmes environnementaux, causes naturels et «ac9on de Dieu» 9. Évolu9on, maintenance, mise à jour défectueuses et décommissions

5 Exemples Challenger explosion Senseurs ont été re9rés des booster rockets pour respecter le calendrier de lancement accéléré Morts à cause de système de radiothérapie défectueux Matériel de verrouillage de sécurité enlevé Défauts dans la concep9on du logiciel Intel 486 chip Bogue dans les fonc9ons trigonométriques

6 Rôle des exigences Les exigences sont l énoncés des buts à aueindre Elles vont des exigences génériques de haut niveau aux exigences spécifiques de as niveau Objec6fs de sécurité sont des ques9ons de sécurité de haut niveau Exigences de sécurité sont des problèmes spécifiques et concrets

7 Types d assurance L assurance de la Poli6que est la preuve établissant que les exigences de la poli9que de sécurité sont complètes, consistantes et techniquement solides L assurance du Design est la preuve établissant que la concep9on est suffisante pour respecter les exigences de la poli9que de sécurité L assurance de l implémenta6on est la preuve établissant que la mise en œuvre est cohérente avec les exigences de sécurité de la poli9que de sécurité

8 Types d assurance L assurance opéra6onnelle est la preuve établissant que le système respecte les exigences de la poli9que de sécurité tout au long de l installa9on, de la configura9on et du fonc9onnement quo9dien

9 Cycle de vie Concep9on Fabrica9on Distribu9on U9lisa9on

10 Le modèle en cascade (waterfall) Waterfall SDLC example proposed by Boehm in 76. System (user) requirements Software requirements Preliminary conceptual design Detailed design Code and debug Integrate and test Operation and maintenance Barry W. Boehm. Software engineering. IEEE Transactions on Computers, C-25(12): , December 1976.

11 Sécurité: Intégrée ou Add On? Pensez à la sécurité comme vous pensez à la performance On ne construit pas un système puis on y ajoute de la performance plus tard On peut op9miser le système pour améliorer les performances un peu Beaucoup plus efficace de remplacer les algorithmes fondamentaux et modifier la concep9on Vous devez le planifier et le concevoir dès le départ Autrement, le système ne disposera pas des concepts fondamentaux et structurels nécessaire à une assurance de haute qualité

12 Techniques de test De bonnes techniques de test aideront l assurance Test par boîte blanche: u9liser le code source Test par boîte noire: u9liser les spécifica9ons U9liser des ou9ls pour automa9ser l exécu9on des tests Ré- exécu9on des tests sur une base régulière tests de non régression) Tests unitaires, tests du système, tests d intégra9on et tests de charge

13 Techniques de test Généra9on de tests automa9sée Fonc9onne avec les tests par boîte blanche et noir Pas encore très pra9que U9lise des muta9ons pour évaluer l efficacité d une session de test Techniques formelles BAN logic Model checking Scanners

14 Arbres d auaque hup:// auacktrees- ddj- s.html

15 Arbres d auaque hup:// auacktrees- ddj- s.html

16 Méthodologies Capability Maturity Model (CMM) ISO 9001 ISO/IEC 27005:2011

17 Mais Voir Why Good Sosware Engineering Prac9ces Osen Do Not Produce Secure Sosware

18 Évalua9on: Buts Démontrer qu un système sa9sfait des exigences de sécurité spécifiques dans des condi9ons spécifiques Appelé un système digne de confiance Basé sur des preuves d assurance spécifiques Méthodologie d évalua6on formelle Technique u9lisée pour fournir des mesures de confiance basées sur des exigences de sécurité et des preuves d assurance spécifiques

19 La méthodologie d évalua9on Fournit l ensemble des exigences qui définissent les fonc9onnalités de sécurité du système Fournit l ensemble des exigences d assurance qui délimitent les étapes nécessaires pour pouvoir établir que le système sa9sfera ses exigences fonc9onnelles Fournit la méthodologie permeuant de déterminer qu un système respectera ses exigences fonc9onnelles d après l analyse des preuves d assurance Fournit une mesure indiquant à quel point un système est fiable en ce qui concerne ses exigences fonc9onnelles de sécurité Appelé niveau de confiance

20 Pourquoi évaluer? Fournit une évalua9on indépendante et une mesure d assurance par des experts Inclut une évalua9on des exigences pour vérifier si elles sont consistantes, complètes, techniquement solides et suffisantes pour contrer les menaces Inclut l évalua9on de la documenta9on administra9ve, de l u9lisateur, de l installa9on et tout autre document qui fournit de l informa9on pour configurer, administrer ou u9liser le système Cri9que indépendante Experts apportent un nouveau regard et une nouvelle perspec9ve sur l évalua9on

21 Un peu d histoire Le gouvernement et les militaires sont la raison à l origine des premiers processus d évalua9on Leur désir d u9liser des produits commerciaux a mené à la créa9on d entreprises développant des méthodologies pour évaluer la sécurité et la fiabilité des systèmes Méthodologies fournissent une combinaison de Exigences fonc9onnelles Exigences d assurance Niveaux de confiance

22 TCSEC: «Trusted Computer System Evalua9on Criteria» Aussi connu comme le Orange Book» Les séries qui développaient des aspects par9culier du Orange Book étaient appelés Rainbow Series Développé par Na9onal Computer Security Center, US Département de la Défense Grandement influencé par le modèle de Bell- LaPadula Met l accent sur la confiden9alité Intégrité assurée par la propriété- *

23 Classe d évalua9on A et B A1 B3 B2 B1 Protec6on vérifié; u9lisa9on significa9ve de méthodes formelles; distribu9on fiable; correspondance entre le code et FTLS Domaines de sécurité; mécanismes de valida9on complète des références; augmente les exigences du chemin de confiance, limite le développement du code; plus d exigences DTLS; documenta9on Protec6on structuré; modèle formel de poli9que de sécurité; MAC pour tous les objets, é9quetage; chemin de confiance; privilèges minimums; analyse des canaux cachés, ges9on des configura9ons Protec6on de la sécurité é6quetée; poli9que informelle de sécurité; MAC pour quelques objets; é9quetage; tests de sécurité plus strictes November 1, 2004

24 Classes d évalua9on C et D C2 Protec6on d accès contrôlé; réu9lisa9on d objet, vérifica9on, tests de sécurité plus strictes C1 Protec6on discré6onnaire; fonc9onnement minimum, exigences d assurance; contrôles I&A; DAC D Ne rencontre pas les exigences d aucune autre classe

25 Processus d évalua9on Administré par le gouvernement, pas de frais pour le vendeur 3 étapes Applica9on: demande d évalua9on Peut être refusé si le gouvernement n a pas besoin du produit Examen technique préliminaire Discuter du processus d évalua9on, des horaires, des processus de développement, du contenu technique, etc. Déterminer le calendrier de l évalua9on Phase d évalua9on

26 FIPS 140: 1994 Présent Évalua9on standard pour les modules cryptographiques (implémente la logique ou les processus cryptographiques) Ins9tué par les agences gouvernementales des États- Unis et le Centre de la sécurité du Canada Mis à jour en 2001 faire face aux changements dans les processus et les technologies Officiellement, FIPS Évalue seulement les modules cryptographiques Si c est un logiciel, le processeur qui l exécute est également inclut, ainsi que le système d opéra9on

27 Critères communs: 1998 Présent Commencé en 1998 avec la signature du Common Criteria Recogni9on Agreement par 5 signataires US, UK, Canada, France, Allemagne Depuis mai 2002, il y a 10 signataires de plus Australie, Finlande, Grèce, Israël, Italie, Pays- Bas, Nouvelle- Zélande, Norvège, Espagne, Suède; Inde, Japon, Russie, Corée du Sud développant des systèmes appropriés Voir hup:// Standard de l Organisa9on interna9onale de normalisa9on (ISO) Standard De facto pour l évalua9on de la sécurité aux États- Unis

28 Méthodologie d évalua9on Documents CC Aperçu de la méthodologie, exigences fonc9onnelles, exigences de l assurance Méthodologie d évalua9on CC (CEM) Lignes directrices détaillées pour l évalua9on de chaque EAL; actuellement seulement EAL1 EAL4 sont définis Grille d évalua9on Infrastructures spécifiques à chaque pays implémentant CEM Aux États- Unis, c est le Schéma d évalua9on et de valida9on CC; NIST accrédite laboratoires commerciaux pour faire les évalua9ons

29 SSE- CMM: 1997 Présent Basé sur le Capability Maturity Model (SE- CMM ou juste CMM) Définit les exigences du processus pour développer des systèmes sécurisés et non les systèmes eux- mêmes Fournit des niveaux de maturité, non des niveaux de confiance U9lisé pour évaluer de la sécurité d une organisa9on

30 Modèle SSE- CMM Process capability: fourcheue des résultats auendus qui peuvent être aent en suivant le processus Prédit les résultats futures d un projet Process performance: mesure des résultats réels Process maturity: mesure dans laquelle un processus est explicitement défini, géré, mesuré, contrôlé et efficace Divises le processus en 11 domaines, et 11 de plus pour le projet et les pra9ques organisa9onnelles Chaque domaine du processus con9ent un but et un ensemble de processus de base

31 Niveaux de maturité des capacités informelle: exécute les processus de base Planifié et suivi: s occupe de la défini9on du projet, planning, performance, vérifica9on Défini: se concentre sur la défini9on et l améliora9on de la pra9que courante. Effort coordonné à travers l organisa9on Contrôlé quan6ta6vement: établit des buts de qualités mesurables, gère la performance de manière objec9ve Améliora6on con6nue: améliore systéma9quement les capacité de l organisa9on et ses processus

32 Autres DO- 178B PCI (hups://

33 Limita9ons des méthodes formelles Généralement coûteuses, donc ne peuvent pas être u9lisées pour tous les projets Assez lourde (ou très lourde), vous ralen9ront et vous feront manquer des opportunités de marché Laquelle choisir? Comment est- ce que l évalua9on fonc9onne? Est- ce que le processus d évalua9on lui- même est en conflit d intérêt?

34 Méthodes informelles Est- ce que vos méthodes d assurance peuvent aider l évalua9on? Open source Mécanismes de vérifica9on généraux Bonne réputa9on en général de votre compagnie et de vos logiciels dans le milieu de la sécurité (Bugtraq etc.)