Génie logiciel et des TI - Cours par sigle · Jean-Marc Robert, ETS Sécurité logicielle A08 8...

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


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!


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!


Approche préventive

La difficulté provient du fait que:

La sécurité est une propriété pas une fonctionnalité!


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


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


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)


•Tests intrusion

•Tests intrusion

•Sécurité

opérationnelle


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


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.


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


II. Spécifications de sécurité

Entrée: Documents de spécification, de cas d’usage et de cas

abusifs.


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.


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


III. Analyse des risques

Entrée: Documents de spécifications et d’architecture, de cas

d’usage et de cas abusifs.


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é.


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


IV. Revue de code

Entrée: Code du logiciel.


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


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

cwe.mitre.org

cve.mitre.org



Entrée: Modules et système

Documents d’architecture et d’analyse des risques.


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.



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é.


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!



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.


VI. Tests d’intrusion

Entrée: Système déployé dans un environnement d’utilisation.

Documents d’architecture et d’analyse des risques.


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é.


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.


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


VII. Sécurité opérationnelle

Entrée: Système déployé dans un environnement opérationnel.


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 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)!


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


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.


Spécialiste des TI

Spécification

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



•Cas abusifs


sécurité

•Analyse des risques •Tests sécurité

basés sur les

risques

•Revue code

(outils)


•Tests intrusion

•Tests intrusion

•Sécurité

opérationnelle


Spécialiste de génie logiciel

Spécification

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



•Cas abusifs


sécurité

•Analyse de risque •Tests sécurité

basés sur les

risques

•Revue code

(outils)


•Tests intrusion

•Tests intrusion

•Sécurité

opérationnelle


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é.


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

http://buildsecurityin.us-cert.gov/



Génie logiciel et des TI - Cours par sigle · Jean-Marc Robert, ETS Sécurité logicielle A08 8...

Documents

Transcript of Génie logiciel et des TI - Cours par sigle · Jean-Marc Robert, ETS Sécurité logicielle A08 8...