École de technologie supérieure (ÉTS)
Sécurité logicielle
Automne 2012
1
Yosr Jarraya Chamseddine Talhi
Chargé de cours Responsable du cours
MGR850 – Automne 2012
Plan• Motivations & contexte
• Développement de logiciels sécurisés– Le cycle de développement logiciel
– Les bases de connaissance
– Le rôle des participants
• Conclusion
Chamseddine Talhi, ÉTS
2
MGR850 - A12
Réaction plutôt que prévention à la source!
Sécurité – approche classique 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
Jean-Marc Robert, ÉTS
3
Motivation & contexte
MGR850 - A12
Éliminons les failles à la source!
Sécurité – approche préventive• La sécurité logicielle a pour but de
– comprendre les risques de sécurité dus aux failles des logiciels,
– proposer de bonnes pratiques de développement logiciel.
• Dans ce cadre, sécurité est synonyme de 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.
Motivation & contexte
Jean-Marc Robert, ÉTS
4
MGR850 - A12
La sécurité est une propriété pas une fonctionnalité!
Sécurité – approche préventive• La difficulté provient du fait que:
Motivation & contexte
Jean-Marc Robert, ÉTS
5
MGR850 - A12
Cycle de développement
Sécurité = Robustesse du logiciel
• 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 Trustworthy Computing Security Development
Lifecycle.
• Publications de Gary McGraw – CTO de Cigital
Jean-Marc Robert, ÉTS
6
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
• L’objectif : 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
7
MGR850 - A12
Jean-Marc Robert, ÉTS
SpécificationCas d’usage
Architecture Plan de tests Code Tests Déploiement
Adapté de Software Security de McGraw
•Analyse des risques•Cas abusifs•Spécifications de sécurité
•Analyse des risques•Tests sécurité basés sur les risques
•Revue code (outils)
•Analyse des risques•Tests intrusion
•Tests intrusion•Sécurité opérationnelle
8
Cycle de développement
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
I. Cas abusifsEntré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
9
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
I. Cas abusifs - Comment?– Répertorier les diverses interfaces.
• Lorsqu’un usager peut interagir avec le système, l’attaquant peut essayer d’abuser de cette interface.
– Chercher les hypothèses faites au sujet des usagers.• Les usagers ne peuvent faire … � Les attaquants peuvent le faire!
• Les usagers ne feront pas … � Les attaquants 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 modèles d’attaque.10
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
I. Cas abusifs – Exemple 1
Court-circuiterallumage
I. Alexander, Misuse cases: use cases with hostile intent. IEEE Software, janvier 2003.
Conduire
Barrervéhicule
Barrerla direction
Volervéhicule
Inclus
Inclus
Inclus
Cas d’utilisation Cas abusifs
11
MGR850 - A12
Cycle de développement
Chamseddine Talhi, ÉTS
I. Cas abusifs – Exemple 2
I. Alexander, Misuse cases: use cases with hostile intent. IEEE Software, janvier 2003.12
MGR850 - A12
Cycle de développementII. Spécification de la sécurité• Entrées: Documents de spécification, cas d’usage et cas abusifs.
• Exemple de résultats– Identification des information critiques à protéger
– Spécification des propriétés de sécurité à faire respecter
– Dépendamment des ressources disponibles: spécification des mécanismesde sécurité à déployer.
• 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 de sécurité indépendamment des spécifications du système.
Chamseddine Talhi, ÉTS
13
MGR850 - A12
14
?Sécurité
Prendre en charge la
sécurité durant la conception?
Cycle de développementII. Spécification de la sécurité
Chamseddine Talhi, ÉTS MGR850 - A12
Concevoir les mécanismes de sécurité?
Spécifier les propriétés de sécurité?
Vérifier le renforcement de la sécurité?
Intégrer la sécurité dans un modèle?Prendre en charge
la sécurité durant la conception?
Caractéristiques des solutions requises:
1. Adoption d’un langage standard de modélisation
2. Méthodes de vérification formelles
3. Outils automatiques de vérification & d’intégrationChamseddine Talhi, ÉTS
II. Spécification de la sécurité
Cycle de développement
15
MGR850 - A12
Chamseddine Talhi, ÉTS
II. Spécification de la sécurité – Ex. admission d’un patient dans une institution médicale
C. Talhi et al. Usability of Security Specication Approaches for UML Design: A Survey. JOT 2009.
Cycle de développement
16
MGR850 - A12
Chamseddine Talhi, ÉTS
II. Spécification de la sécurité – Ex. profile UML
C. Talhi et al. Usability of Security Specication Approaches for UML Design: A Survey. JOT 2009.
Cycle de développement
• Créer de nouveaux types
d’éléments en se basant sur
les types existants
• Chaque nouveau type (e.g.,
privacy) peut être attribué à
n’importe quel éléments d’un
diagramme d’activité
17
MGR850 - A12
Chamseddine Talhi, ÉTS
II. Spécification de la sécurité – Ex. profile UML
C. Talhi et al. Usability of Security Specication Approaches for UML Design: A Survey. JOT 2009.
Cycle de développement
18
MGR850 - A12
Chamseddine Talhi, ÉTS
II. Spécification de la sécurité – Ex. profile UML
Défis:
1. Assister le concepteur NON-EXPERT en sécurité
2. Interpréter les annotations
3. Vérifier automatiquement les propriétés
4. Interagir avec le concepteur afin d’interpréter les résultats de l’analyse et modifier le modèle
Cycle de développement
19
MGR850 - A12
III. Analyse de 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.
– Aucun 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, ÉTS
Cycle de développement
20
MGR850 - A12
IV. Revue du codeCycle de développement
Entrée: Code du logiciel.
Exemple de résultats– Débordement de tableaux
– Utilisation de fonctions à risque (e.g., 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, ÉTS
21
MGR850 - A12
IV. Revue du code – à la recherche de ..Cycle de développement
Jean-Marc Robert, ÉTS
• 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
• Classification des vulnérabilités répertoriées par cwe.mitre.org22
MGR850 - A12
V. Test de sécuritéCycle de développement
Jean-Marc Robert, ÉTS
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. 23
MGR850 - A12
V. Test de sécuritéCycle de développement
Jean-Marc Robert, ÉTS
• 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 testés.
• Par qui?– Les responsables QA (assurance de la qualité) 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é.24
MGR850 - A12
V. Test de sécuritéCycle de développement
Jean-Marc Robert, ÉTS
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!
25
MGR850 - A12
V. Test de sécuritéCycle de développement
Jean-Marc Robert, ÉTS
Tests fonctionnels• Tests classiques validant les
fonctionnalités de sécurité.
• Exemples:– 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.
• Tests de la forme:– Lorsque qu’un événement X
survient, le système réagit de la façon Y.
Tests malveillants• Tests spécifiques validant ce que
le logiciel ne doit pas faire.
• Tests basés:– Analyse des risques– Vulnérabilités classiques
• Exemple:– Vérifier l’existence des
débordements de tableaux
• Basés sur l’expérience et une bonne connaissance des vulnérabilités.
26
MGR850 - A12
V. Test de sécurité - exempleCycle de développement
Code vulnérable
Cas de test
Chamseddine Talhi, ÉTS
27
MGR850 - A12
VI. Test d’intrusion (penetration testing)Cycle de développement
Jean-Marc Robert, ÉTS
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é.
28
MGR850 - A12
VI. Test d’intrusion - piègesCycle de développement
Jean-Marc Robert, ÉTS
• 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.
29
MGR850 - A12
VI. Test d’intrusionCycle de développement
Jean-Marc Robert, ÉTS
• Logiciel gratuit
– nmap
– nessus
– nikto
– …
• Commercial
– Core Impact
– QualysGuard family
– IBM Internet Scanner
– HP WebInspect
– Watchfire Appscan
– Paros Proxy
– OWASP WebScarab
– …
30
MGR850 - A12
VII. Sécurité opérationnelleCycle de développement
Jean-Marc Robert, ÉTS
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.
31
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
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)!32
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
• 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
Base de connaissances requises
33
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
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.
34
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
Spécialistes des TIs
SpécificationCas d’utilisation
Architecture Plan de tests Code Tests Déploiement
Adapté de Software Security de McGraw
•Analyse des risques•Cas abusifs•Spécifications de sécurité
•Analyse des risques•Tests sécurité basés sur les risques
•Revue code (outils)
•Analyse des risques•Tests intrusion
•Tests intrusion•Sécurité opérationnelle
35
MGR850 - A12
Cycle de développement
Jean-Marc Robert, ÉTS
Spécialistes de génie logiciel
SpécificationCas d’utilisation
Architecture Plan de tests Code Tests Déploiement
Adapté de Software Security de McGraw
•Analyse des risques•Cas abusifs•Spécifications de sécurité
•Analyse de risque•Tests sécurité basés sur les risques
•Revue code (outils)
•Analyse des risques•Tests intrusion
•Tests intrusion•Sécurité opérationnelle
36
MGR850 - A12
Conclusion• 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, ÉTS
37
MGR850 - A12
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
– OutilsJean-Marc Robert, ÉTS
38
MGR850 - A12
Extra• Fonctions vulnérables en C
https://security.web.cern.ch/security/recommendations/en/codetools/c.shtml
• C doc: http://www.cplusplus.com/reference/clibrary/cstring/memset/• Secure Coding Principles: OWASP guide pages 31-38• ERROR HANDLING, AUDITING AND LOGGING 192 - 204
Jean-Marc Robert, ÉTS
39
MGR850 - A12