AS « Sécurité des Logiciels Embarqués » Axe 3 : Modèles pour la Disponibilité et la Survivabilité Frédéric Cuppens Directeur de recherches

Sécurité Informatique = Garantir 3 propriétés Introduction Traditionnellement, Sécurité Informatique = Garantir 3 propriétés Confidentialité Pas de divulgation non autorisée d ’information Intégrité Pas de modification non autorisée d ’information Disponibilité Pas de déni d’accès non autorisé aux informations ou aux ressources (Définitions ITSEC)

Confidentialité Nombreux modèles Mise en œuvre de techniques de preuve Bell et LaPadula Non Interférence Non Déduction Non Inférence Causalité … Mise en œuvre de techniques de preuve Preuve statique de code Validation de mécanismes de contrôle d ’accès

Intégrité Moins de modèles Biba Dual de Biba pour l ’intégrité Clark-Wilson Transactions bien formées Séparation des tâches Contrôle d ’accès Cuppens-Saurel Gestion des droits des utilisateurs Gestion de l ’intégrité des informations Crédibilité des sources Règles de propagation de l ’intégrité entre concepts Evolution de l ’intégrité aux cours du temps

Disponibilité Beaucoup moins de modèles ! Yu et Gligor (1990) Expression de propriétés de disponibilité Millen (1992) Modèle de disponibilité orienté allocation de ressources Cuppens-Saurel (1999) Expression d ’une politique de disponibilité Model checking pour analyser la disponibilité d ’un système

Disponibilité : définitions Deux Définitions possibles Définition 1 Pas de « déni de service » Déni de service = réduction des performances du système, intentionnelle ou accidentelle Disponibilité = « Safety property » Définition 2 Capacité du système à fournir des services aux utilisateurs autorisés dans des conditions d ’utilisation données Disponibilité = « Liveness property » Remarque : Définition 2  Définition 1

Définition 1 : disponibilité = pas de déni de service Objectif Protéger le système contre les attaques en déni de service Une des problématiques de la détection d ’intrusion Dans la pratique On a des protocoles vulnérables On sait qu’ils vont subir des attaques Conséquences On n ’essaye pas de prouver que ces protocoles satisfont des propriétés de disponibilité On essaye plutôt de détecter des attaques contre ces protocoles

Détection des attaques en déni de service En général, on suppose que l ’on « connaît » les attaques en déni de service On spécifie la signature de l ’attaque Permet de détecter l ’attaque On spécifie ensuite que « Attaque  Deny » Mais, on ne précise pas la sémantique du prédicat « Deny »

« Attaque1  Attaque2  …  Attaquen Besoin de formaliser le « Deny » Problème ouvert Détection des dénis de service distribués (DDOS) . . . « Attaquei  Deny » Mais : « Attaque1  Attaque2  …  Attaquen  Deny » Besoin de formaliser le « Deny » Attaque2 Attaquen Attaque1

Définition 2 : disponibilité = capacité de fournir des services Capacité du système à fournir des services aux utilisateurs autorisés dans des conditions d ’utilisation données Conditions d ’horaires, de délai et de performances Conditions sur le système et l ’utilisation des ressources Concept de politique de disponibilité A.P : Availability Policy Exemple : R1 : Le sujet S doit pouvoir commencer à réaliser la tâche TT au plus tard 6 unités de temps après sa requête R2 : Le sujet S doit pouvoir disposer de la ressource nécessaire à TT au plus tard 4 unités de temps après l ’avoir demandée R3 : La durée maximale de réalisation de la tâche TT est de 9 unités de temps

Etude de la disponibilité : les problèmes Définition Formalisation Vérification cohérence POLITIQUE DISPONIBILITE SYSTEME REEL Formalisation Dérivation PROPRIETES DISPONIBILITE FORMALISATION SYSTEME REEL Validation

Langage pour représenter une politique de disponibilité Concepts de base à exprimer : Ressource : type (mémoire, CPU…), attributs (taille…), état (occupé, libre), structure (décomposition en ressources élémentaires) Tâche : ressources nécessaires, durée nécessaire d’utilisation de chaque ressource, ordre de passage entre ressources Sujet : ressources consommées, état (attente, choisi, en cours de réalisation…) actif ou pas (CPU) Notions temporelles : événements (réalisation d ’une tâche), intervalles (délais d ’attente), durée, date (points temporels) Concepts déontiques : droits des sujets sur les ressources ou les tâches formulés en termes d ’obligations, de permissions et d ’interdictions

Langage pour représenter une politique de disponibilité Logique du premier ordre avec égalité Logique temporelle (temps discret) hold-at(p,t), hold(p, [t1,t2]) (cf Sripada, 1993) Modalités déontiques Op : p est obligatoire Fp : p est interdit (O¬p) Pp : p est permis (¬O¬p) permission implicite (hypothèse facile à lever) Prédicats dédiés pour représenter les concepts relatifs à la disponibilité subject(s), task(t), resource(r), use(s,r), asks(s,r), gets(s,r), release(s,r) ... task-duration(t,d), max-task-duration(t,d), resource-needs(t,rt,d,q) ...

Spécification d’une politique de disponibilité Droits d ’accès aux ressources Please Thank You Bye Subject s asks for an access to resource r s gets an access to resource r s releases resource r Waiting time for r Use time of r Constrained by predicate disposal-right Constrained by predicate use-right

Spécification d’une politique de disponibilité Droits associés aux tâches Please Thank You Bye

Spécification d’une politique de disponibilité Priorités entre (sujet, tâche) priority ([s1,t1],[s2,t2]) : (s1,t1) est prioritaire sur (s2,t2) expression de conditions de priorité (urgence, hiérarchie…) dans des formules du langage Conventions d ’utilisation (user agreements) ex : Quand un sujet a fini une tâche consommant une ressource, il doit abandonner cette ressource.

Cohérence d’une politique de disponibilité Principe : si l ’ A.P. spécifie qu’un sujet a la permission / l ’obligation de faire quelque chose, alors elle doit spécifier que ce sujet a la permission d ’avoir les moyens pour le faire Définition d ’un ensemble de contraintes devant être vérifiées par l ’A.P. Une A.P. est cohérente s ’il est possible de montrer que ces contraintes sont des théorèmes de l ’A.P.

Conformité entre un système et sa politique de disponibilité Principes : 1- Toute opération réalisée dans le système est autorisée dans la politique de disponibilité 2- Toute opération obligatoire dans la politique de disponibilité est réalisée dans le système Dérivation de contraintes de conformité entre le système et la politique Hypothèse : on dispose d ’une spécification logique du système Un système est conforme à une A.P. s’il est possible de montrer que ces contraintes de conformité sont des théorèmes de cette spécification logique

Vérification d ’une propriété de disponibilité Contrôle de la disponibilité des ressources, et de la réalisation des tâches Cas particuliers : Politique de temps d ’attente maximum (Yu et Gligor) Propriétés de disponibilité Toute requête sur une ressource sera satisfaite en temps fini. Tout sujet demandant la réalisation d ’une tâche la verra se réaliser en temps fini. Montrer que ces contraintes sont des théorèmes de la spécification logique du système

Application sur des algorithmes d’allocation de ressources Hypothèse : travail sur la spécification logique de l ’algorithme Méthodologie : spécification des « cas pires » : il y a toujours des processus en attente dès qu ’un processus a fini une tâche, il en redemande une autre choix des « tâches pires » (vis à vis de la disponibilité) dépend de l ’algorithme analysé (exemple : la tâche la plus longue pour FIFO) Résultat : Vérification de la propriété recherchée, par simulation dynamique des cas pires avec les tâches pires Applications : FIFO, Round Robin, Shortest Job First….

Conclusion Définition et formalisation de la notion de politique de disponibilité Analyse de la cohérence d ’une politique de disponibilité Dérivation de propriétés de disponibilité à partir d ’une politique de disponibilité Modèle extensible à des types de ressources différents

Perspectives / Problèmes à étudier Définition 1 Modélisation de la notion de « Deny » Définition 2 Prise en compte de la notion de mode dégradé Cohérence d’une politique de disponibilité Méthodologie pour vérifier des propriétés de disponibilité Analyse des cas moyens (fautes accidentelles) Applications : analyse des mécanismes pour la survivabilité Protocoles d ’allocation de ressources critiques Gestion de trafic Mécanismes de tolérances aux fautes Redondance en cas d ’attaques malveillantes Redondance passive / redondance active Choisir une étude de cas