La sécurité informatique
publicité
Sécurité logicielle Jean-Marc Robert Génie logiciel et des TI Plan de la présentation Introduction Les vulnérabilités logicielles Développement de logiciels sécurisés Le cycle de développement logiciel Les bases de connaissance Le rôle des participants Conclusions Jean-Marc Robert, ETS Sécurité logicielle A08 2 Approche traditionnelle La sécurité informatique considère généralement la sécurisation du périmètre d’un réseau. Pare-feu Systèmes de détection ou de prévention d’intrusions Pots de miel … Réaction plutôt que prévention à la source! Jean-Marc Robert, ETS Sécurité logicielle A08 3 Approche préventive La sécurité logicielle a pour but de comprendre les risques de sécurité dus aux failles des logiciels, de proposer de bonnes pratiques de développement logiciel. Dans ce cadre, sécurité est synonyme à robustesse. Comment s’assurer qu’un logiciel utilisé dans un environnement hostile n’ait pas de faille de sécurité et réponde toujours selon les spécifications. Éliminons les failles à la source! Jean-Marc Robert, ETS Sécurité logicielle A08 4 Approche préventive La difficulté provient du fait que: La sécurité est une propriété pas une fonctionnalité! Jean-Marc Robert, ETS Sécurité logicielle A08 5 Sécurité logicielle: Pour y parvenir Microsoft’s Trustworthy Computing Initiative Mémo de Bill Gates en janvier 2002 présente la nouvelle approche de Microsoft de développer des logiciels sécurisés. Microsoft aurait dépensé plus de 300 millions USD. The Trusthworhty Computing Security Development Lifecycle. Publications de Gary McGraw – CTO de Cigital Sécurité = Robustesse du logiciel Jean-Marc Robert, ETS Sécurité logicielle A08 6 Cycle de développement du logiciel L’objectif est d’intégrer de bonnes pratiques simples tout au long du cycle de développement logiciel afin de produire des logiciels plus robustes donc plus sécurisés. Cette liste de bonnes pratiques est relativement courte. I. II. III. IV. V. VI. VII. Cas abusifs Spécifications de sécurité Analyse des risques Revue de code Plan de tests de sécurité Tests d’intrusions Sécurité opérationnelle Jean-Marc Robert, ETS Sécurité logicielle A08 7 Cycle de développement du logiciel •Analyse des risques •Cas abusifs •Spécifications de sécurité •Analyse des risques Spécification Cas d’usage Architecture •Tests sécurité basés sur les risques Plan de tests •Revue code (outils) Code •Analyse des risques •Tests intrusion Tests •Tests intrusion •Sécurité opérationnelle Déploiement Adapté de Software Security de McGraw Jean-Marc Robert, ETS Sécurité logicielle A08 8 I. Cas abusifs Entrée: Documents de spécification et de cas d’usage. Exemple de résultats Cas abusifs – scénarios d’utilisation malveillante. Pour atteindre l’objectif de cette phase, il peut être nécessaire de recourir à divers intervenants. Experts en sécurité Experts en fiabilité (reliability) Concepteurs du système Analystes fonctionnels Jean-Marc Robert, ETS Sécurité logicielle A08 9 I. Cas abusifs Comment? Répertorier les divers interfaces. Chercher les hypothèses faites au sujet des usagers. Les usagers ne peuvent faire … Les attaquant peuvent le faire! Les usagers ne feront pas … Les attaquant vont le faire! Définir ce que le logiciel ne doit pas faire. Lorsqu’un usager peut interagir avec le système, l’attaquant peut essayer d’abuser de cet interface. Aussi important que de définir ce que le logiciel doit faire. Utiliser des listes de modèles d’attaque. Jean-Marc Robert, ETS Sécurité logicielle A08 10 I. Cas abusifs – Exemple Conduire Inclus Barrer véhicule Inclus Voler véhicule Inclus Court-circuiter allumage Barrer la direction Cas d’utilisation Cas abusifs I. Alexander, Misuse cases: use cases with hostile intent. IEEE Software, janvier 2003. Jean-Marc Robert, ETS Sécurité logicielle A08 11 II. Spécifications de sécurité Entrée: Documents de spécification, de cas d’usage et de cas abusifs. Exemple de résultats Pas de description de comment préserver l’intégrité des actifs. Pas de description de comment préserver la confidentialité des actifs. Cette phase doit faire partie intégrante de la phase de spécification du système. Une erreur typique est de développer les spécifications indépendamment des spécifications du système. Jean-Marc Robert, ETS Sécurité logicielle A08 12 II. Spécifications de sécurité – SQUARE Security Quality Requirements Engineering Développé à CMU – Software Engineering Institute Neufs étapes Établir les définitions Identifier les objectifs de sécurité Développer les artéfacts (cas d’utilisation, cas abusifs, arbres d’attaque) pour définir les spécifications Effectuer une analyse des risques Choisir une méthode pour expliciter les spécifications Expliciter les spécifications Catégoriser les spécifications Prioriser les spécifications Revue des spécifications Jean-Marc Robert, ETS Sécurité logicielle A08 13 III. Analyse des risques Entrée: Documents de spécifications et d’architecture, de cas d’usage et de cas abusifs. Exemple de résultats Mauvais contrôle d’accès. Mauvaise protection de la confidentialité ou de l’intégrité des actifs. Aucune moyen d’assurer la disponibilité des actifs. L’objectif est d’identifier les erreurs de conception. Documenter les hypothèses. Identifier les attaques possibles. Établir une liste des attaques usuelles. Définir les objectifs de sécurité. Jean-Marc Robert, ETS Sécurité logicielle A08 14 III. Analyse des risques – Méthodologie Plusieurs méthodes existent. La méthode retenue par les auteurs de Software Security Engineering – A guide for project managers: NIST SP800-30 Risk management guide for information technology systems Cours no 5 Jean-Marc Robert, ETS Sécurité logicielle A08 15 IV. Revue de code Entrée: Code du logiciel. Exemple de résultats Débordement de tableaux Utilisation de fonctions à risque (p.e. strcat, strcpy) Cas d’erreur non traités Tests insuffisants … L’objectif est d’identifier les erreurs d’implémentation. Outils d’analyse statique (spécialement pour C et C++) Coverity, Fortify Software, Ounce Labs, Secure Software Revue de code humaine Jean-Marc Robert, ETS Sécurité logicielle A08 16 IV. Revue de code : à la recherche de … Common Weakness Enumeration – cwe.mitre.org Improper access of indexable resource Use of insufficiently random values Interaction error Insufficient control of resource through its lifetime Incorrect calculation Insufficient control flow management Protection mechanism failure Insufficient comparison Failure to handle exceptional conditions Use of incorrectly-resolved name or reference Failure to enforce that messages or data are well-formed Coding standards violation Cours no 2 enrichi Classification des vulnérabilités répertoriées par cve.mitre.org Jean-Marc Robert, ETS Sécurité logicielle A08 17 V. Plan de tests de sécurité Entrée: Modules et système Documents d’architecture et d’analyse des risques. Exemple de résultats Erreurs d’implémentation. Erreurs fonctionnelles. Deux aspects doivent être considérés. Tests fonctionnels de sécurité. Tester les fonctionnalités de sécurité comme toute autre fonctionnalité. Tests malveillants de sécurité Tester en se basant sur les attaques habituelles, l’analyse des risques et les cas abusifs. Tester comme une personne malveillante voulant exploiter une faille de sécurité. Toutefois, la personne effectuant les tests a plus d’information qu’un attaquant. Jean-Marc Robert, ETS Sécurité logicielle A08 18 V. Plan de tests de sécurité Objectif: S’assurer qu’un logiciel est robuste et peut continuer de fonctionner de façon acceptable malgré la présence d’attaques malveillantes. Comment? Les tests doivent débuter au niveau des composantes. Les tests doivent se poursuivre lors de l’intégration. Les risques contre les actifs doivent être atténués à ce niveau. Les risques dus aux interactions entre composantes doivent être tester. Par qui? Les responsables QA ont l’habitude d’effectuer des tests de fonctionnalité. Toutefois, ils n’ont pas l’expertise pour effectuer les tests malveillants. Ces tests reposent sur l’expertise et l’expérience en sécurité. Jean-Marc Robert, ETS Sécurité logicielle A08 19 V. Plan de tests de sécurité – Exemple Changement de paradigme: Au lieu de tester ce qu’un logiciel doit faire, il faut tester ce qu’il ne doit pas faire. Exemple: interface demandant d’entrer son identifiant Entre 5 et 32 caractères Caractères alphanumériques plus les caractères ‘-’ et ‘_’ Lettres non accentuées Le premier caractère doit être une lettre Le responsable de QA va tester tous les cas représentatifs respectant les spécifications. Mais il ne va pas tester les débordements de tableaux. 256 caractères! Jean-Marc Robert, ETS Sécurité logicielle A08 20 V. Plan de tests de sécurité Tests fonctionnels Tests classiques validant les fonctionnalités de sécurité. Exemples: Tests malveillants Tests spécifiques validant ce que le logiciel ne doit pas faire. L’accès est bloqué après trois tentatives d’accès invalides. L’information est échangée ou stockée de façon chiffrée. Lorsque qu’un événement X survient, le système réagit de la façon Y. Jean-Marc Robert, ETS Sécurité logicielle A08 Analyse des risques Vulnérabilités classiques Exemple: Tests de la forme: Tests basés: Vérifier l’existence des débordements de tableaux Basés sur l’expérience et une bonne connaissance des vulnérabilités. 21 VI. Tests d’intrusion Entrée: Système déployé dans un environnement d’utilisation. Documents d’architecture et d’analyse des risques. Exemple de résultats Problèmes de configuration (p.e. certificats X.509 absents) Services ouverts inutilement (p.e. interface de débogage) L’objectif est d’identifier les erreurs d’implémentation, de conception et de configuration. Cette étape est essentielle afin de déterminer les failles dues à la configuration et aux autres facteurs environnementaux. Sans analyse des risques, cette étape donne peu de résultats concluants. Un ethical hacker testant un système comme une boîte noire est très limité. Jean-Marc Robert, ETS Sécurité logicielle A08 22 VI. Tests d’intrusion – Pièges Les tests de pénétration sont faits généralement très (trop?) tard. Les erreurs découvertes par les outils ne sont pas priorisées en fonction des risques d’affaire. Il est possible qu’une erreur grave n’expose pas d’actif important. Les erreurs sont souvent corrigées individuellement sans chercher à corriger la cause commune. Les erreurs ne sont pas intégrées au système de gestion d’erreurs (bug tracking) Les erreurs sont généralement coûteuses à éliminer. Les tests de pénétration sont effectués par un équipe indépendante. La couverture des tests est difficile à évaluer. Jean-Marc Robert, ETS Sécurité logicielle A08 23 VI. Tests d’intrusion – Outils Logiciel gratuit nmap nessus nikto … Commercial Core Impact QualysGuard family IBM Internet Scanner HP WebInspect Watchfire Appscan Paros Proxy OWASP WebScarab … https://buildsecurityin.us-cert.gov/daisy/bsi/articles/tools/penetration/657-BSI.html Jean-Marc Robert, ETS Sécurité logicielle A08 24 VII. Sécurité opérationnelle Entrée: Système déployé dans un environnement opérationnel. Exemple de résultats Fichier d’audit ne contient pas suffisamment d’information. Gestion de mots de passe pas assez flexible. L’objectif est d’évaluer comment le système réagi lorsqu’il est déployé dans un milieu « hostile ». Identifier les failles dues aux erreurs d’implémentation ou de conception mais plus particulièrement celles dues aux « carences » ou « insuffisances » du système. Ces informations opérationnelles doivent être incluses dans le prochain cycle de développement du système afin de pallier aux failles découvertes. Jean-Marc Robert, ETS Sécurité logicielle A08 25 Sécurité logicielle ce n’est pas que … Une histoire de codage ou de convention! Une histoire de fonctionnalité! Il y a plus que les débordements de tableaux et d’entiers. Mots de passe, chiffrement, authentification, … Une histoire de listes de contrôle (check lists)! Jean-Marc Robert, ETS Sécurité logicielle A08 26 Bases de connaissance requises Connaissances normatives Principes de la sécurité Guides Règles Interdire l’utilisation des fonctions strcpy, sprintf, … (langage C) Connaissances descriptives Principe du moindre privilège, usage exclusif de clés, méthodes de contrôle d’accès,… Vulnérabilités Exploits Scénarios des attaques Connaissances historiques Base de données des risques et des vulnérabilités Jean-Marc Robert, ETS Sécurité logicielle A08 27 Le rôle de chacun Certaines des bases de connaissance sont traditionnellement du domaine des spécialistes des TI. Exploits Scénarios des attaques Connaissance historique des risques Certaines des activités sont traditionnellement du domaine des spécialistes logiciels. Définition des spécifications et cas abusifs. Tests des fonctionnalités. Revue de code. Jean-Marc Robert, ETS Sécurité logicielle A08 28 Spécialiste des TI •Analyse des risques •Cas abusifs •Spécifications de sécurité •Analyse des risques Spécification Cas d’utilisation Architecture •Tests sécurité basés sur les risques Plan de tests •Revue code (outils) Code •Analyse des risques •Tests intrusion Tests •Tests intrusion •Sécurité opérationnelle Déploiement Adapté de Software Security de McGraw Jean-Marc Robert, ETS Sécurité logicielle A08 29 Spécialiste de génie logiciel •Analyse des risques •Cas abusifs •Spécifications de sécurité Spécification Cas d’utilisation •Analyse de risque •Tests sécurité basés sur les risques Architecture Plan de tests •Revue code (outils) Code •Analyse des risques •Tests intrusion Tests •Tests intrusion •Sécurité opérationnelle Déploiement Adapté de Software Security de McGraw Jean-Marc Robert, ETS Sécurité logicielle A08 30 Conclusions La sécurité est une propriété d’un logiciel et non une fonctionnalité dudit logiciel. La sécurité doit faire partie intégrante du logiciel. Dès sa conception et au cours de chacune des phases subséquentes de son développement. Security is a process, not a product. Bruce Schneier, CTO de BT Counterpane Auteur de nombreux livres de sécurité. Jean-Marc Robert, ETS Sécurité logicielle A08 31 Références Les livres de Gary McGraw Le site Build Security In (http://buildsecurityin.us-cert.gov/) Best Practices Acquisition Architectural Risk Analysis Assembly, Integration, & Evolution Code Analysis Deployment & Operations Governance & Management Incident Management Legacy Systems Measurement Penetration Testing Project Management Requirements Engineering Risk Management Security Testing System Strategies Training & Awareness White Box Testing Outils Jean-Marc Robert, ETS Sécurité logicielle A08 32
