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
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
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
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
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
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
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é
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
Cycle de vie Concep9on Fabrica9on Distribu9on U9lisa9on
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):1226-1241, December 1976.
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é
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
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
Arbres d auaque hup://www.schneier.com/paper- auacktrees- ddj- s.html
Arbres d auaque hup://www.schneier.com/paper- auacktrees- ddj- s.html
Méthodologies Capability Maturity Model (CMM) ISO 9001 ISO/IEC 27005:2011
Mais Voir Why Good Sosware Engineering Prac9ces Osen Do Not Produce Secure Sosware
É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
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
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
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
TCSEC: 1983 1999 «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é- *
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
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
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
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 140-2 É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
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://www.commoncriteriaportal.org/ccra/members/ Standard 15408 de l Organisa9on interna9onale de normalisa9on (ISO) Standard De facto pour l évalua9on de la sécurité aux États- Unis
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
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
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
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
Autres DO- 178B PCI (hups://www.pcisecuritystandards.org/)
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?
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.)