génie logiciel et des ti - cours par sigle · jean-marc robert, ets sécurité logicielle a08 8...
TRANSCRIPT
Sécurité logicielle
Jean-Marc Robert
Génie logiciel et des TI
Sécurité logicielle A08 2 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 3 Jean-Marc Robert, ETS
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!
Sécurité logicielle A08 4 Jean-Marc Robert, ETS
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!
Sécurité logicielle A08 5 Jean-Marc Robert, ETS
Approche préventive
La difficulté provient du fait que:
La sécurité est une propriété pas une fonctionnalité!
Sécurité logicielle A08 6 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 7 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 8 Jean-Marc Robert, ETS
Cycle de développement du logiciel
Spécification
Cas 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
Sécurité logicielle A08 9 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 10 Jean-Marc Robert, ETS
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.
Sécurité logicielle A08 11 Jean-Marc Robert, ETS
Court-circuiter
allumage
I. Cas abusifs – Exemple
I. Alexander, Misuse cases: use cases with hostile intent. IEEE Software, janvier 2003.
Conduire
Barrer
véhicule
Barrer
la direction
Voler
véhicule
Inclus
Inclus
Inclus
Cas d’utilisation Cas abusifs
Sécurité logicielle A08 12 Jean-Marc Robert, ETS
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.
Sécurité logicielle A08 13 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 14 Jean-Marc Robert, ETS
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é.
Sécurité logicielle A08 15 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 16 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 17 Jean-Marc Robert, ETS
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
Classification des vulnérabilités répertoriées par cve.mitre.org
Cours no 2
enrichi
Sécurité logicielle A08 18 Jean-Marc Robert, ETS
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.
Sécurité logicielle A08 19 Jean-Marc Robert, ETS
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é.
Sécurité logicielle A08 20 Jean-Marc Robert, ETS
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!
Sécurité logicielle A08 21 Jean-Marc Robert, ETS
V. Plan de tests de sécurité
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.
Sécurité logicielle A08 22 Jean-Marc Robert, ETS
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é.
Sécurité logicielle A08 23 Jean-Marc Robert, ETS
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.
Sécurité logicielle A08 24 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 25 Jean-Marc Robert, ETS
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.
Sécurité logicielle A08 26 Jean-Marc Robert, ETS
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)!
Sécurité logicielle A08 27 Jean-Marc Robert, ETS
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
Sécurité logicielle A08 28 Jean-Marc Robert, ETS
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.
Sécurité logicielle A08 29 Jean-Marc Robert, ETS
Spécialiste des TI
Spécification
Cas 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
Sécurité logicielle A08 30 Jean-Marc Robert, ETS
Spécialiste de génie logiciel
Spécification
Cas 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
Sécurité logicielle A08 31 Jean-Marc Robert, ETS
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é.
Sécurité logicielle A08 32 Jean-Marc Robert, ETS
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