Approches développéesApproches développéesau LAAS :au LAAS :

Tolérance aux intrusionsTolérance aux intrusionsÉvaluation quantitative de la sécuritéÉvaluation quantitative de la sécurité

Yves DeswarteLAAS-CNRS, Toulouse, France

Approches développéesau LAAS :

Tolérance aux intrusionsTolérance aux intrusionsÉvaluation quantitative de la sécurité

Yves Deswarte & David PowellLAAS-CNRS, Toulouse, France

Utilisateurs InternetUtilisateurs Internet

Utilisations :B2B, B2C, C2A, e-government,associations, communautésvirtuelles, usage privé…

Buts :commerce, administration,démocratie, société, culture,loisirs, …

On ne doit pas exclure une catégoried’utilisateurs au bénéfice d’une autre

Différents besoins !différents niveaux de sécurité

État de fait1. Il y a des machines mal administrées qui peuvent être exploitées par des

attaquants pour accroître leurs capacités et cacher leurs traces2. Il y a des centaines de millions d’utilisateurs d’Internet dont une très

petite proportion sont des attaquants potentiels

Dissuasion " Punition " Détection

Techniques classiques de la sécuritéTechniques classiques de la sécurité

Authentification! Identifier les utilisateurs! Les tenir responsables (audit)

Autorisation! Empêcher les actions illégitimes! Principe du moindre privilège

légitime # nécessaire

! Inefficace dans le contexte Internet :o Authentification forte infaisable pour les sites publicso Applications et OS sur étagères :

• nombreuses failles• rustines non appliquées : manque de temps ou de compétence, crainte de

perdre des fonctionnalités nécessaireso Les protocoles Internet sont vulnérables (héritage Arpanet)o La pression économique ne favorise pas (encore) des défensesconnues :" filtrage d’entrée (ingress filtering), capacité de traçage, …

ErreurErreur

DéfaillanceDéfaillance

Cause(supposée oureconnue)d’une erreur

partie de l’état du système qui estdifférente de ce qu’elle devrait être

Faute

survient lorsque le service dévie de sa fonction

Concepts de base de la Concepts de base de la SdFSdF

Faute HWBugAttaqueIntrusion

autres fautes(non-maveillantes)

intrusion erreur défaillance

Ivulnérabilité

attaque

attaquant

attaquant,concepteur

ou opérateur

V

A

# attaque - activité malveillante externe visant à violer une ou plusieurs propriétésde sécurité; une tentative d’intrusion

# vulnérabilité - faute (par malveillance ou maladresse), dans les spécifications, laconception, la réalisation, l’installation ou la configuration du système, ou dans lafaçon de l’utiliser, qui peut être exploitée pour produire une intrusion

# intrusion - faute (malveillante) résultant d’une attaque qui a réussi à exploiter unevulnérabilité

V

Modèle de fauteModèle de faute

FOURNITURE

VALIDATION

Prévention des fautes - comment empêcher quedes fautes surviennent ou soient introduites

Tolérance aux fautes - comment fournir unservice conforme à la fonction en dépit des fautes

Élimination des fautes - comment réduire laprésence (en nombre ou en gravité) des fautes

Prévision des fautes - comment estimer laprésence, la création et les conséquences des fautes

Méthodes de sûreté de fonctionnementMéthodes de sûreté de fonctionnement

Accepterles fautes

Éviterles fautesTolérance aux fautes - comment fournir un

service conforme à la fonction en dépit des fautes

Prévision des fautes - comment estimer laprésence, la création et les conséquences des fautes

Prévention des fautes - comment empêcher quedes fautes surviennent ou soient introduites

Élimination des fautes - comment réduire laprésence (en nombre ou en gravité) des fautes

préventiond’intrusion

Prévention, tolérance et éliminationPrévention, tolérance et élimination

prévention devulnérabilité

intrusion erreur défaillanceattaque

vulnérabilité

tolérancedes intrusions

attaquant

concepteur/opérateur

préventiond’attaque

élimination de faute

éliminationde vulnérabilité

Tolérance aux intrusionsTolérance aux intrusions

# Les intrusions sont des fautes# Les fautes peuvent être tolérées

#Mais:! on ne peut pas se reposer sur la faible probabilité d’attaques

presque simultanées sur différentes parties du système !

# Il faut donc s’assurer que :! chaque partie est suffisamment protégée (pas d’attaque triviale)! l’intrusion d’une partie ne facilite pas l’intrusion d’autres parties

" une intrusion ne doit pas révéler des données confidentielles

Masquage dMasquage d’’intrusionintrusion

#Une intrusion dans une partie du système ne doitdonner accès qu’à des informations non-significatives

# FRD : Fragmentation-Redondance-Dissémination# Fragmentation: fragmenter l’information de telle sorte qu’un

fragment isolé ne contienne pas d’info sensible : confidentialité

# Redondance : ajouter de la redondance de telle sorte que lamodification ou destruction de fragments n’empêche pas lesaccès légitimes : intégrité + disponibilité

# Dissémination : isoler les fragments individuels• topologie/fréquences• temps• privilèges

Fragmentation-Redondance-DisséminationFragmentation-Redondance-Dissémination

Projet MAFTIAProjet MAFTIA

Malicious- and Accidental-Fault Tolerance forInternet Applications

FP5 IST Dependability InitiativeCross Program ActionDependability in services and technologies

University of Newcastle (UK) Brian Randell, Robert StroudUniversity of Lisbon (P) Paulo VerissimoDSTL + QinetiQ (ex-DERA) (UK) Tom McCutcheon, Sadie CreeseUniversity of Saarland (D) Birgit PfitzmannLAAS-CNRS, Toulouse (F) Yves Deswarte, David PowellIBM Research, Zurich (CH) Marc Dacier, Michael Waidner

~ 55 personnes-ans, finacement CE ~2.5M!Jan. 2000 -> Déc. 2002 (Fév. 2003)

Résultats obtenus par MAFTIARésultats obtenus par MAFTIA

# Cadre conceptuel et modèle d’architecture

#Mécanismes et protocoles :! Intergiciel (middleware) pour la tolérance aux intrusions

# communications multicast (ordre causal, temps-réel) sécurisées! Système de détection d’intrusion à large échelle! Tierces parties de confiance tolérant les intrusions! Mécanismes d’autorisation distribuée (TAI)

#Validation et évaluation

http://www.maftia.org/

authorizationrequestpermissions

Authorization Server

fs2

f3

ps1 p4u

JavaCard

ReferenceMonitor

JavaCard

ReferenceMonitorJavaCard

ReferenceMonitor

Schéma dSchéma d!’!’autorisation MAFTIAautorisation MAFTIA

Projet DITProjet DIT

#DIT = Dependable Intrusion Tolerance

# Programme DARPA OASIS (Organically Assured andSurvivable Information Systems)

# En partie sous-contracté au LAAS par SRI-International

# Conception et réalisation d’un serveur Web tolérant lesintrusions

COTS Application Servers

HP/UX/Openview Server

Linux/Apache

Solaris/Enterprise Server

WinNT/IIS ServerFirewall

Internet

Intrusion Tolerance Proxies

Architecture DITArchitecture DIT

! Proxies avec logiciel spécifique(matériel diversifié)

!Un leader, les autres sont des “monitors”

!Diversification: HW (Sparc, Pentium,PowerPC, etc), OS et logiciel d’application

!Même contenu (web pages ou databases)

!Niveau de redondance adaptatif (simplex, duplex,TMR, tous), selon le niveau d’alerte

!Niveau d’alerte : info venant des CERTs… + détec-tion en ligne : comparaisons, test d’intégrité, IDS…

ConclusionConclusion

# Étant donnés! le taux d’attaques actuel sur Internet! le grand nombre de vulnérabilités des systèmes courants

# la tolérance aux intrusions est une technique prometteuse! compatible avec les systèmes classiques (COTS)! avec une redondance matérielle modérée et peu de logiciel spécifique

# mais coûteuse! support de plateformes multiples et diversifiées

! indépendance de vulnérabilité! opérateurs/administrateurs indépendants

! tolérance des attaques internes

# Est-ce le prix de la sécurité dans un monde ouvert et incertain?

Approches développéesApproches développéesau LAAS :au LAAS :

Tolérance aux intrusionsTolérance aux intrusionsÉvaluation quantitative de la sécuritéÉvaluation quantitative de la sécurité

Yves DeswarteLAAS-CNRS, Toulouse, France

Approches développéesau LAAS :

Tolérance aux intrusionsÉvaluation quantitative de la sécuritéÉvaluation quantitative de la sécurité

Méthodes classiques d'évaluation - 1Méthodes classiques d'évaluation - 1

#Analyse de risque! Identifier les vulnérabilités! Identifier les menaces! Identifier les attaques possibles

# Imaginer des scénarios permettant d'exploiter les vulnérabilités# Estimer leur fréquence, en fonction des capacités de l'attaquant# Estimer les dommages correspondants

! Calculer les espérances de pertes (fréquence x dommages)! Identifier des contre-mesures et leur coût

#Méthodes analytiques (MARION, MELISA, MEHARI,…),mais paramètres estimés par les experts

# Processus long et coûteux

Méthodes classiques d'évaluation - 2Méthodes classiques d'évaluation - 2

# Critères d'évaluation (TCSEC, ITSEC, CC)! Fonctionnalités de sécurité

# Définition des besoins# Caractérisation des mécanismes répondant à ces besoins# Estimation de la force des mécanismes

! Niveaux d'assurance (confiance)# Exigences sur les méthodes de développement et de vérification# Documentation

! Profils de protection

#Qualitatif plutôt que quantitatif

#Vision plutôt statique: comment le système a été conçu,plutôt que comment il est utilisé

Mesures sur le système en opérationMesures sur le système en opération

#Objectifs :! surveiller les évolutions de la sécurité en fonction des

modifications de configuration et d’usage! identifier les meilleures améliorations possibles! négocier avec les utilisateurs

#Mesure = caractéristique du système! qu’il y ait ou non une attaque, la mesure est la même

#Robustesse du système face à toutes lesattaques possibles! "effort moyen" que doit déployer un attaquant pour mettre en

défaut les objectifs de sécurité! effort = variable pluri-dimensionnelle : temps, compétence

(connaissance, intelligence), équipement nécessaire, …

ApprocheApproche

Interprétationdes résultats

Identification desobjectifs de sécurité

Évaluation quantitativede mesures de sécurité

Modélisation desvulnérabilités Système

Modélisation des vulnérabilitésModélisation des vulnérabilités

#Graphe des privilèges! Nœud = ensemble de droits (d’un utilisateur, d’un groupe

d’utilisateurs…)! Arc = méthode pour acquérir des privilèges (faille ou utile)! Poids/arc = effort pour exploiter la méthode

Pour un arc X$Y :1) X peut deviner le mot de passe d’Y2) X peut installer un cheval de Troie pour Y3) X peut exploiter une faille du mailer d’Y4) Y est un sous-ensemble d’X5) Y utilise un programme qu’X peut modifier6) X peut modifier un programme "s-uid" d’Y7) X est dans le .rhosts d’Y

BP1

A

X admin

Finsider

12

4

5

6

7

3

Recherche des scénariosRecherche des scénarios

BP1

A

Xadmin

Finsider

12

4

5

6

7

3

Hypothèse TM

1

11

1

33

2

2

3

3 3

3 33

3

3

3 6

6

66666

5

5557

6

4 4

4

6 6

Hypothèse ML

3

3

6 5

7

4

12

Différentes mesuresDifférentes mesures

#METF-ML :Effort moyen selon l’hypothèse ML

#METF-TM :Effort moyen selon l’hypothèse TM

#NP : Nombre de chemins

#SP : Plus court chemin

ÉSOPE ÉSOPE (Évaluation de la sécurité opérationnelle)(Évaluation de la sécurité opérationnelle)

#Ensemble d’outils logiciels pour :

! Définir les objectifs de sécurité (outil graphique)

! Identifier les vulnérabilités automatiquement(réseau de machines Unix)

! Calculer les mesures

! Aider à exploiter les résultats

Expérimentation : objectifsExpérimentation : objectifs

#Validation de l’approche :! évaluer la pertinence des mesures en fonction de l’évolution

de la sécurité! étudier la faisabilité sur un système réel

#Ne faisait pas partie des objectifs :! corriger les vulnérabilités identifiées

Contexte de lContexte de l’’expérimentationexpérimentation

Système-cible :• Unix• 700 utilisateurs -

200 machines - réseau local• 13 mois

(juin 1995 - juillet 1996)

13 types de vulnérabilités étudiés(fichiers .rhosts, .*rc, mots de

passe, etc.)

4 niveaux de difficulté :

Objectifs:Type Poids

immédiat 10facile 102

difficile 103très

difficile 104

Attaquant cibleobjectif 1 insider root

objectif 2 insider admin_group

Résultats expérimentaux (1)Résultats expérimentaux (1)

insider ! root

0,1

1

10

100

1000

06/95 08/95 09/95 11/95 12/95 02/96 04/96 05/96 07/96

Number of paths METF-MLMETF-TM METF-SP

#24

#11

E

SPMLTM

NP

Résultats expérimentaux (2)Résultats expérimentaux (2)

Critique des mesuresCritique des mesures

# Le plus court chemin (SP) n’est pas assez sensible pour révéler desévénements importants

# Le nombre de chemins (NP) change souvent et produirait un grandnombre de fausses alarmes.

# METF-ML présente une bonne sensibilité aux événements importants.

# METF-TM permet une interprétation plus facile, mais est parfois tropcomplexe à calculer.

ConclusionConclusion

#Une approche objective pour l’évaluation quantitative dela sécurité

#Des mesures qui ne sont pas absolues :! On ne peut comparer les mesures de systèmes différents

#Outil complémentaire des autres outils de sécurité

#Validation du modèle d'attaques : observations à l'aidede Honeypots (projet CADHo, ACI Sécurité Informatique)

Autres apports Autres apports SdF SdF <-> Sécurité<-> Sécurité

#Application de modèles "security" à la "safety" :co-existence de logiciels de criticités multiples(projet européen GUARDS)! Contrôle de flux (Biba) : haute intégrité basse intégrité! Tolérance aux fautes : basse intégrité haute intégrité! Noyau de sécurité

# Critères d'évaluation de la sûreté de fonctionnementprojet européen SQUALE! Indépendants du domaine d'application, mais compatibles avec les

normes spécifiques aux domaines (CC, DO178B, CEI 880, 61508…)! Couvrant les aspects safety, security, disponibilité, intégrité …! Prise en compte des COTS, de la tolérance aux fautes

< http://www.research.ec.org/squale/ >$/µ 98, SAFECOMP 99