(Microsoft PowerPoint - Cours-10-C-S351curit351_logicielle.ppt)

Document Sample
(Microsoft PowerPoint - Cours-10-C-S351curit351_logicielle.ppt) Powered By Docstoc
					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.      Cas abusifs
     II.     Spécifications de sécurité
     III.    Analyse des risques
     IV.     Revue de code
     V.      Plan de tests de sécurité
     VI.     Tests d’intrusions
     VII.    Sécurité opérationnelle


Jean-Marc Robert, ETS             Sécurité logicielle A08           7
Cycle de développement du logiciel
•Analyse des risques
                                              •Tests sécurité              •Revue code       •Analyse des risques   •Tests intrusion
•Cas abusifs
                       •Analyse des risques   basés sur les                  (outils)        •Tests intrusion       •Sécurité
•Spécifications de
                                              risques                                                               opérationnelle
sécurité




Spécification
                        Architecture          Plan de tests                 Code                  Tests             Déploiement
Cas d’usage




                                                                                         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.
              Lorsqu’un usager peut interagir avec le système, l’attaquant peut essayer d’abuser de
              cet interface.
         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.
              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
                                                              M
                                                                  en
                                                                    ac
                                                                            e
                                      Inclus                                        Voler
                                                                 ct   ion          véhicule
                                                            ot e
                                     Barrer            Pr
                                                                                     Inclus
                                    véhicule                  M
                                                                  en
                                                                     a   ce
                                      Inclus                                    Court-circuiter
                                                                      n           allumage
                                                            te    ctio
                                     Barrer             Pro

                                  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
                                                                    Cours no 2
         Interaction error
                                                                     enrichi
         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
    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 risques contre les actifs doivent être atténués à ce niveau.
         Les tests doivent se poursuivre lors de l’intégration.
              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 malveillants
   Tests classiques validant les                         Tests spécifiques validant ce que
   fonctionnalités de sécurité.                          le logiciel ne doit pas faire.

    Exemples:                                                 Tests basés:
         L’accès est bloqué après trois                          Analyse des risques
         tentatives d’accès invalides.                           Vulnérabilités classiques
         L’information est échangée ou
         stockée de façon chiffrée.
                                                              Exemple:
                                                                 Vérifier l’existence des
    Tests de la forme:                                           débordements de tableaux
         Lorsque qu’un événement X
         survient, le système réagit de la
         façon Y.                                             Basés sur l’expérience et une
                                                              bonne connaissance des
                                                              vulnérabilités.

Jean-Marc Robert, ETS               Sécurité logicielle A08                                   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 sont généralement coûteuses à éliminer.
    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 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                                           Commercial
         nmap                                                    Core Impact
         nessus                                                  QualysGuard family
         nikto                                                   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!
         Il y a plus que les débordements de tableaux et d’entiers.


    Une histoire de fonctionnalité!
         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é
              Principe du moindre privilège, usage exclusif de clés, méthodes de contrôle d’accès,…
         Guides
         Règles
              Interdire l’utilisation des fonctions strcpy, sprintf, … (langage C)

    Connaissances descriptives
         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
                                              •Tests sécurité             •Revue code       •Analyse des risques   •Tests intrusion
•Cas abusifs
                       •Analyse des risques   basés sur les                 (outils)        •Tests intrusion       •Sécurité
•Spécifications de
                                              risques                                                              opérationnelle
sécurité




 Spécification
                        Architecture          Plan de tests                Code                  Tests             Déploiement
Cas d’utilisation




                                                                                        Adapté de Software Security de McGraw




Jean-Marc Robert, ETS                           Sécurité logicielle A08                                                      29
Spécialiste de génie logiciel
•Analyse des risques
                                             •Tests sécurité             •Revue code       •Analyse des risques   •Tests intrusion
•Cas abusifs
                        •Analyse de risque   basés sur les                 (outils)        •Tests intrusion       •Sécurité
•Spécifications de
                                             risques                                                              opérationnelle
sécurité




 Spécification
                        Architecture         Plan de tests                Code                  Tests             Déploiement
Cas d’utilisation




                                                                                       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 fonction-
    nalité 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

				
DOCUMENT INFO
Shared By:
Stats:
views:53
posted:5/21/2010
language:French
pages:32