protection des systèmes d’informations : mena ces et solutions actuelles frédéric cuppens

117
Centre de Toulouse BDA’02 21 Octobre 2002 Protection des systèmes d’informations : Menaces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA Toulouse (et IRIT Toulouse à partir de Novembre 2002)

Upload: jovan

Post on 19-Mar-2016

16 views

Category:

Documents


0 download

DESCRIPTION

Protection des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA Toulouse (et IRIT Toulouse à partir de Novembre 2002). Plan. A. Contexte 1. Introduction 2. Exemples d’attaques B. Démarche pour la sécurité des systèmes d’information - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Protection des systèmes d’informations :Menaces et solutions actuelles

Frédéric CuppensMaître de recherches

ONERA Toulouse(et IRIT Toulouse à partir de Novembre 2002)

Page 2: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002Plan

A. Contexte1. Introduction2. Exemples d’attaques

B. Démarche pour la sécurité des systèmes d’information3. Politique de sécurité4. Détection d’intrusions5. Authentification6. Sécurité des communications7. Politiques de contrôle d’accès

C. Différents types de politiques de contrôle d’accès8. Approche discrétionnaire9. Approche basée sur les rôles10. Base de données privée virtuelle

D. Conclusion / perspectives

Page 3: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Evolution du contexte

1980 1990 2000

MainframeSystème de gestion indépendant

Gestion centralisée

Chemin d’accès unique

Client/ServeurInfrastructure hétérogèneGestion de données et d’applications

Gestion centralisée

Chemins d’accès multiples

TechnologieInternet

Infrastructure hétérogène

Réseaux avec connections multiplesSystèmes ouvertsSystèmes interropérants

Niv

eau

de c

ompl

exité

1. Introduction

TechnologieInternet future

BlueToothUMTS

Active NetworkWLANHiperlan

WAP I-mode

Oracle2Oracle6

Oracle7Oracle8i

Oracle9i

Page 4: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Quelques statistiques

• 1,2 Milliard $US Pertes d’eBay, Yahoo! and Amazon.com dues aux attaques contre leurs sites en 2000 Attaque contre la disponibilité (DDOS: Distributed Denial of Service) Source : Yankee Group

• 85 % Pourcentage des companies américaines et Canadiennes ayant trouvé un virus dans leur

système Source : CSI/FBI

• 80 % Pourcentage estimé des attaques correspondant aux intrusions internes Source : FBI

1. Introduction

Page 5: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Objectifs de l’intrusion

1. Introduction

Objectifs de l’intrusion

Confidentialité

IntégritéDisponibilité

Accès illégal à certaines informations

Création, modification ou suppression illégale de l’information

Empêche les utilisateurs d’avoir un accès autorisé au système

Exemples : sniffing, cracking, ...

Exemples : altering, spoofing, hijacking, ...Exemples : flooding, smurfing, ...

Page 6: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contexte actuel

1. Introduction

Nouvelles vulnérabilités Nouvelles menaces

Nouveaux risques

Mécanismes de sécurité

Au moins 800 vulnérabilités nouvelles découvertes chaque année dans les

environements Internet

•Hacker amateur• E-crime• Infowarrior• menaces internes• sabotage d’information critique

Nouveaux outils d’intrusion permettant

d’exploiter automatiquement les

vulnérabilités

• Firewall• VPN• Transactions électroniques sécurisées• Secure mail • Détection d’intrusion

Page 7: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Principales “classes” d’attaque

• Sniffing Ecoute

• Spoofing Mascarade

• Flooding Deni de service

• Scanning Balayage des services

• Hijacking Interception / détournement de communication

• Virus et Chevaux de Troie

2. Exemples d’attaques

Page 8: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Internet ou DMZ

Packet sniffing (R-a-Probe)

MM

MM

MM

Emetteur

Attaquant

Destinataire• Intercepter des paquets

transmis via Internet (login, numéro de carte de crédit, autres données sensibles)

• Voler des nom de machines,

• Nom d’utilisateurs, mots de passe (même chiffrés), …

2. Exemples d’attaques

Page 9: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Flooding

• Principe : Envoyer un grand nombre de messages de sorte que le récepteur ne peut plus les gérer Conduit à un déni de service Ce déni de service peut provenir de plusieurs sources (DDOS pour Déni de service

distribué)

• Flooding les plus fréquents Flooding TCP (ou Syn flooding) Flooding UDP Smurfing (exemple de flooding ICMP avec des paquets “Echo Request”)

2. Exemples d’attaques

Page 10: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

SYN flooding (R-a-deny(temporary ou administrative))

•Attaque DoS sur les réseaux IP•Connexion à moitié ouverte : le serveur insère les informations d’ouverture dans sa pile

•Trop de connexions à moitié ouverte peuvent conduire à un déni de service

Nerd

TotoSYN

SYN - ACK

ClientServeur

•Le serveur attend la réponse (ack) du client et conserve dans sa pile des connexions à moitié ouvertes

SYNSYN

SYNSYN

•Le client n’envoie pas de ack pour ouvrir la connexion

2. Exemples d’attaques

Page 11: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Smurfing (R-a-deny(temporary))

Attaquant Victime

Internet

ECHO REQUESTde la victime

vers 192.168.0.255

ECHO REPLYde 192.168.0.20vers la victime

ECHO REPLYde 192.168.0.20vers la victime

ECHO REPLYde 192.168.0.20vers la victime

ECHO REPLYde 192.168.0.20vers la victime

ECHO REPLYde 192.168.0.20vers la victime

ECHO REPLYde 192.168.0.20vers la victime

Existence d ’une adresse « broadcast »en xxx.xxx.xxx.255

Si une machine du sous réseau envoie un message « echo request » à cette adresse,toutes les machines du sous-réseau vont répondre par un « echo reply »

Envoi d ’un message « echo request » forgé avec l ’adress de la victime (spoofing)

Des centaines de messages « echo reply » envoyés à la victime

Principe du smurfing : amplification du floodingJusqu ’à 255 messages reçus par la victime pour un message envoyé par l ’attaquant

2. Exemples d’attaques

Page 12: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Spoofing

• Principe : Masquerade : forger des paquets avec de fausses adresses pour pour se faire passer

pour une autre machine

• Spoofing les plus fréquents : Spoofing ARP (appelé également ARP poison) Spoofing ICMP Spoofing UDP Spoofing TCP

2. Exemples d’attaques

Page 13: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

ARP Poison

• Principle du protocole ARP (protocole non connecté): Dans le protocole ARP, chaque “requête” est diffusée aux autres machines d’un réseau

local Chaque machine conserve dans son cache la correspondance @IP/@MAC Le cache est mis à jour lorsque la machine reçoit un “ARP reply” (même s’il n’a pas

envoyé un “ARP request”)

• Principe de l’attaque : L’attaquant envoie des messages “ARP reply” avec une @IP qui ne correspond pas à une

@MAC Applications:

• Deni de service • Hijacking

2. Exemples d’attaques

Page 14: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Hijacking ARP (R-m-Intercept)

Cache ARP :@IP 192.16.1.2@MAC 00:00:00:02

(1)Communication

Cache ARP :@IP 192.16.1.1@MAC 00:00:00:01

@IP 192.16.1.1@MAC 00:00:00:01

@IP 192.16.1.2@MAC 00:00:00:02

Cache ARP :@IP 192.16.1.2@MAC 00:00:00:03

(2)ARP Poison

Cache ARP :@IP 192.16.1.1@MAC 00:00:00:03

ARP Reply :192.16.1.2 is-at

@MAC 00:00:00:03

ARP Reply :192.16.1.1 is-at

@MAC 00:00:00:03

Man In the Middle (MiM)@MAC

00:00:00:03Cache ARP :@IP 192.16.1.2@MAC 00:00:00:03

Cache ARP :@IP 192.16.1.1@MAC 00:00:00:03

(3)Hijacking

2. Exemples d’attaques

Page 15: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Scanning: exemples

• Objectif général : Obtenir la liste des ports ouverts d’un système

• TCP SYN scanning (half-open scanning) Envoyer un message SYN, attendre un SYN-ACK et ensuite envoyer un RESET

• TCP FIN scanning Envoyer un message FIN et attendre un RESET (port fermé) sinon le port est ouvert

• UDP ICMP port unreachable scanning Pour scanner les services UDP Envoyer un paquet et attendre ensuite un message “ICMP_PORT_UNREACH” (port

ouvert) sinon le port est fermé

2. Exemples d’attaques

Page 16: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Virus et Chevaux de Troie

• Il y a des milliers de virus et de Chevaux de Troie• Exemple : Back Orifice 2000 (bo2k)

Création d’une porte dérobée (back door) Pour prendre le contrôle d’un système

2. Exemples d’attaques

Page 17: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Back Orifice 2000

• Etape 1: Encapsuler bo2k dans un fichier « attractif » pour que la victime installe bo2k sur son

système

• Etape 2: Connexion entre l’attaquant et bo2k via un port particulier (par exemple: 8080)

• Etape 3: Prendre le contrôle de la victime

• Lancer ou arrêter des services• Modifier ou télécharger des fichiers• Etc.

2. Exemples d’attaques

Page 18: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple d’attaque pour obtenir les droits d’accès root

• ShellCode (R-b-S) Effectue un Buffer Overflow Exemple: Red Code

• Principe : Mauvaise gestion de la mémoire dynamique Pas de séparation entre le code du programme et les données stockées dans la pile Le volume des données insérées est plus volumineux que l’espace mémoire alloué

• Pendant l’exécution, une sous-routine écrase l’adresse de retour• Ce qui permet l’exécution d’un shellcode

Vulnérabilité classique exploitée :• Fonctions sur les chaînes de caractères (sprintf)

2. Exemples d’attaques

Page 19: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

ShellCode

• Gestion de la pile Appel fonction

• Début : – Sauvegarde du contexte– Création statique du domaine

• Exécution du programme• Fin :

– Restoration du contexte

• Problème : L’adresse de retour peut être écrasée

2. Exemples d’attaques

Page 20: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Schéma d’un ShellCode

• Trois parties : NOP

• Padding• Car l’attaquant ne connait pas précisément la

position du ShellCode• Problème pour positionner exactement l’adresse

de retour au début du ShellCode Instructions principales exécutées par le ShellCode Adresse du Shellcode

• Commentaires : La partie NOP est facilement détectée Mais existence de ShellCodes Polymorphiques

• Utilisation de biblothèques d’instructions équivalente

NOPNOP

…NOPNOP

shellcode

adresse du shellcode…

adresse du shellcode…

adresse du shellcode…

adresse du shellcode

Début du shellcode

2. Exemples d’attaques

Page 21: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque par injection de code SQL

• Attaque due au pirate Rain Forest Puppy

• Attaque contre une base données via une application proxy

Username:

Password:

Base de

données

Page ASP

Active Server Page

Script Visual Basic

Réponse du SGBD

2. Exemples d’attaques

Page 22: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque par injection de code SQL (suite)

• Exemple de Script Visual Basic exécuté par le serveur :Dim sqlsql = "SELECT * FROM Users WHERE username = ' "& username &" ' ANDpassword = ' "& password &" ' ; "Set rs = Comm.OpenRecordset(sql)If not rs.eof() then

' user connected successfully 'end if

• Si un utilisateur fournit Eric comme Username et duratrouver comme mot de passe, la requête suivante est envoyée au SGBD :

SELECT * FROM Users WHERE username = 'Eric' AND password = 'duratrouver' ;

Si la base retourne un n-uplet• Connection ok

2. Exemples d’attaques

Page 23: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque par injection de code SQL (suite)

• Réalisation de l’attaque : L’attaquant fournit le mot de passe suivant :

Toto ' OR TRUE OR '

Dans ce cas, la requête suivante est envoyée à la base :SELECT * FROM Users WHERE username = 'Eric' AND

password = 'Toto' OR TRUE OR ' ' ;

Dans ce cas, le SGBD retourne l’ensemble des n-uplets de la relation Users• L’attaquant va se retrouver connecté en tant que premier utilisateur de la base • En général, il s’agira de l’administrateur de la base

2. Exemples d’attaques

Page 24: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque par injection de code SQL (suite)

• Autre possibilité d’attaque

Numero dossier : 1234Base de

données

Script Visual Basic

Réponse du SGBDRésultat analyse :

2. Exemples d’attaques

Page 25: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque par injection de code SQL (suite)

• Script Visual Basic exécuté par le serveur :Dim sqlsql = "SELECT resultat FROM Dossier_analyse

WHERE username = ' " & username & " 'AND numero_dossier = " & numero-dossier & " ; "

Set rs = Comm.OpenRecordset(sql)

• Si Eric demande à connaître les résultats de ses analyses correspondant au numéro de dossier 1234, la requête suivante est envoyée au SGBD :

SELECT resultat FROM Dossier_analyse WHERE username = 'Eric'

AND numero_dossier = 1234 ;

2. Exemples d’attaques

Page 26: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque par injection de code SQL (suite)

• Réalisation de l’attaque : L’attaquant fournit le numéro de dossier suivant :

1234 OR TRUE

La requête suivante est envoyée à la base :SELECT resultat FROM Dossier_analyse

WHERE username = 'Eric' AND numero_dossier = 1234 OR TRUE ;

Le SGBD retourne l’ensemble des n-uplets de la relation Dossier_analyse• L’attaquant connaît les résultats d’analyse de tous les utilisateurs de la base

2. Exemples d’attaques

Page 27: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques

Patient H/F Age Mutuelle Leucocyte

Dupont H 30 MMA 6000

Durand F 25 LMDE 3000

Dulac F 35 MMA 7000

Duval H 45 IPECA 5500

Dubois H 55 MGEN 3500

Dumont H 38 MMA 7500

Dupré F 32 IPECA 7200

Dupuis F 50 MGEN 6800

Dufour H 45 MAAF 4000

Dumas H 40 Rempart 3800

• Exemple : Relation Analyse(Patient,H/F,Age,Mutuelle,Leucocyte)

2. Exemples d’attaques

Page 28: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques (suite)

• Base de données statistique Base de données qui permet d'évaluer des requêtes qui dérivent des informations

d'agrégation Par exemple : des totaux, des moyennes Mais pas des requêtes qui dérivent des informations particulières

• Exemple : La requête « quelle est la moyenne du taux de leucocytes des patients ayant plus de 30

ans ? » est permise La requête « quel est le taux de leucocytes de Dupont ? » est interdite

2. Exemples d’attaques

Page 29: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques (suite)

• Exemple d’attaque simple : U veut découvrir le taux de Leucocyte de Dubois U sait par ailleurs que Dubois est un adhérent masculin de la MGEN.

• Requête 1SELECT COUNT ( Patient )FROM Analyse WHERE H/F = 'H' AND Mutuelle = 'MGEN' ; Résultat : 1

• Conséquence : Le système doit refuser de répondre à une requête pour laquelle la cardinalité du résultat

est inférieure à une certaine borne b Par exemple 2

• Requête 2 SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' AND Mutuelle = 'MGEN' ; Résultat : 3500

2. Exemples d’attaques

Page 30: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques (suite)• Requête 3

SELECT COUNT ( Patient ) FROM Analyse Résultat : 10

• Requête 4SELECT COUNT ( Patient ) FROM Analyse WHERE NOT ( H/F = 'H' AND Mutuelle = ‘MGEN’ ) ;Résultat: 9 ; 10 - 9 = 1

• Conséquence : Le système doit aussi refuser de répondre à une requête pour laquelle la cardinalité du

résultat est inférieure à N - b N est la cardinalité de la relation initiale

• Requête 5SELECT SUM ( Leucocyte ) FROM Analyse Résultat : 54300

• Requête 6SELECT SUM ( Leucocyte ) FROM Analyse WHERE NOT ( H/F = 'H' AND Mutuelle = ‘MGEN’) ;Résultat : 50800 ; 54300 – 50800 = 3500

2. Exemples d’attaques

Page 31: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques (suite)• Problème :

On peut montrer que limiter les requêtes à celles pour lesquelles le résultat a une cardinalité c telle que b c N - b n'est pas suffisant pour éviter la compromission

Exemple : si b = 2, les requêtes auront une réponse si c est telle que 2 c 8

• Requête 7SELECT COUNT ( Patient ) FROM Analyse WHERE H/F = 'H' ; Résultat : 6

• Conséquence U peut déduire qu'il existe exactement un patient masculin qui a la MGEN comme

mutuelle, Il s’agit de Dubois, puisque U sait que cette description correspond à Dubois

• Requête 8SELECT COUNT ( Patient ) FROM Analyse WHERE H/F = 'H' AND NOT (Mutuelle = ‘MGEN’) ;

Résultat : 5

2. Exemples d’attaques

Page 32: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques (suite)• Conséquence (suite)

Le taux de Leucocyte de Dubois est facilement découvert de la façon suivante :

• Requête 9SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' ;

Résultat : 30300

• Traqueur individuel pour Dubois L'expression booléenne H/F = 'H' AND Mutuelle = ‘MGEN’ permet à l'utilisateur d'obtenir

des informations concernant Dubois C’est un traqueur individuel pour Dubois

• Requête 10SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' AND NOT (Mutuelle = ‘MGEN’) ;

Résultat : 26800 ; 30300 - 26800 = 3500

2. Exemples d’attaques

Page 33: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Attaque contre les bases de données statistiques (suite)• Remarque

Un traqueur individuel ne fonctionne que pour des requêtes faisant intervenir une certaine expression inadmissible particulière

• Traqueur global Expression booléenne qui peut être utilisée pour trouver la réponse à toute requête

inadmissible

• Résultat de D. Denning et P. Denning Data Security. ACM Computer Survey, 11(3), 1979

Toute expression ayant un ensemble résultat de cardinalité c telle que 2b c N - 2b est un traqueur global

b doit être inférieur à N/4, ce qui sera en général le cas quand N est grand

• [DD79] suggère qu’un traqueur global existe « presque toujours » Et il est habituellement facile à trouver

2. Exemples d’attaques

Page 34: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

B. Démarche pour la sécurité des systèmes d’information

Modèles de sécurité

Mécanismes de sécurité Détection d ’intrusion

Approche protection

Approche détection

Politique de sécurité

Propriété (ou objectif)de sécurité

Règlement particulierappliqué à un système d ’information

Garantit que le système ne violepas la politique de sécurité

Mécanismes logiciels ou matérielsqui implantent la politique de sécuritédans le système conformément auxpropriétés de sécurité

Techniques pour détectertoute tentative de violationde la politique de sécurité

Page 35: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Méthodologie informelle

Périmètrede sécurité

Analysede risques

Politique desécurité interne

Politique desécurité système

Politique desécurité technique

Architecture desécurité

Fonctions etMécanismesde sécurité

Politique de sécurité Conception du système sécurisé

3. Politique de sécurité

Page 36: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Etape 1 : Définition du périmètre de sécurité

• Périmètre du système à protéger Fonctions du système Utilisateurs du système

• Recensement des biens à protéger Biens matériel, logiciel et humain

3. Politique de sécurité

Page 37: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Etape 2 : Analyse de risque

• Recenser les vulnérabilités du système• Recenser les menaces du système

Risque = Vulnérabilité Menace

Un risque existe s ’il existe une vulnérabilité et une menace potentielle qui cherche à exploiter la vulnérabilité

• Recenser les éléments de confiance

3. Politique de sécurité

Page 38: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

•Exemples de vulnérabilités

• Matériel non protégé

• Chiffrement des données médicales par le médecin sans séquestre de clé

• Manque de protection des communications

• Pas d ’utilisation d’anti-virus

•Exemples de menaces

• Feu, inondation, détérioration intentionnelle ou non

• Indisponibilité ou décès du médecin rendant inaccessible les données

• Possibilité d ’écoute dans le but de récupérer des données confidentielles

• Virus venant modifier les données médicales

3. Politique de sécurité

Page 39: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité• Etape 3 : Définition de la politique de sécurité

Idée de base : la politique de sécurité doit être globale

Politique desécurité interne

Politique desécurité système

Politique desécurité technique

Politique de sécurité

Etape 3.1

Etape 3.2

Etape 3.3

3. Politique de sécurité

Page 40: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Etape 3.1 : Définition de la politique de sécurité interne Règlement de sécurité utilisé dans l ’organisation dans laquelle le système va fonctionner

• Exemples d ’exigences de la politique de sécurité interne Règles définissant le secret médical Règles de déontologie du médecin Conditions à remplir pour faire partie du personnel du groupe médical Règles à respecter pour accéder au groupe médical

• Accueil des patients, accès à la salle d ’attente, etc. Règles à respecter lorsque le groupe médical est fermé

• Fermeture et protection des locaux• Procédure pour contacter un médecin en cas d ’urgence

etc.

3. Politique de sécurité

Page 41: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Etape 3.2 : Définition de la politique de sécurité système Plus large que le système informatique Doit être compatible avec la politique de sécurité interne Prévoir une sensibilisation du personnel aux risques informatiques

• Exemple d ’exigences de la politique de sécurité système Règles pour contrôler l ’accès physique au serveur d ’informations du groupe médical

• Choix du local, protection du local, contrôle d ’accès au local Règles à respecter pour choisir et gérer son mot de passe Règles pour gérer les sauvegardes du système d ’information médical etc.

3. Politique de sécurité

Page 42: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Etape 3.3 : Définition de la politique de sécurité technique Spécifique aux systèmes informatiques Fait partie de la politique de sécurité système Inclut une politique de contrôle d ’accès au système d ’information

3. Politique de sécurité

Page 43: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Comment construire une politique de sécurité

• Etape 4 : Définition de l ’architecture de sécurité Choix des composants de sécurité

• Exemple : router, firewall, SGBD, etc Définition d ’une architecture intégrant ces composants

• Etape 5 : Définition des mécanismes et fonctions de sécurité Choix des mécanismes d ’authentification

• Exemple : mot de passe, carte à puce, biométrie, etc Définition des besoins de chiffrement et choix des fonctions de chiffrement Définition et mise en œuvre des mécanismes de contrôle d ’accès Etc.

3. Politique de sécurité

Page 44: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Détection d’intrusions

• Plusieurs IDS (Intrusion Detection System) sont disponibles prototypes de recherche produits commerciaux

• Plusieurs approches Détection basée sur les signatures

• Détection de scénario d’attaque Détection d’anomalies: approche comportementale

• Détection de comportement anormal Approche politique de sécurité

• Détection de la violation de la politique de sécurité

• Plusieurs moyens « Host based » « Network Based »

4. Détection d’intrusions

Page 45: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002Détection de scénarios d ’attaques

Fichiersd ’audit

Systèmecible

Analyseurd ’audit

IHM

BD designaturesd ’attaques

Alarmes Commandes

Journalisation

Insertion/Mise a jour

Attaquesdétectées

Page 46: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Détection de scénarios d ’attaques (suite)

• Avantages Possibilité d ’expliquer le raisonnement

• Causes de l ’incident• Conséquences• Remèdes possibles

Possibilité de réactions (contre-mesures)

• Inconvénients Difficulté d ’acquisition et d ’actualisation de la connaissance

• Base de signatures incomplètes et signatures « faibles » Seules les attaques décrites dans la base de signatures peuvent être détectées Puissance de calcul nécessaire

• Limitation en capacité de traitement Nécessite des audits de sécurité détaillés

4. Détection d’intrusions

Page 47: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Fichiersd ’audit

Détection de comportements anormaux

Systèmecible

Analyseurd ’audit

IHM

BD decomportements

normaux

Mise à jour descomportements

Alarmes

Journalisation

Anomaliesdétectées

Page 48: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

• Avantages Outil générique

• Ces outils s ’adaptent facilement aux données d ’audit• Ils demandent moins de précision que les approches par reconnaissance de

scénarios Possibilité de détecter de nouvelles attaques

• Inconvénients Nécessite un comportement stable du système modélisé Apprentissage éventuel de mauvais comportements ou de comportements intrusifs Taux de fausses alarmes élevé Temps d ’apprentissage élevé

• De 1 semaine à un mois est nécessaire pour construire le modèle de référence• Il est nécessaire que le système soit protégé pendant cette période

En général, pas de diagnostic précis en cas d ’alarme

Détection de comportements anormaux (suite)

4. Détection d’intrusions

Page 49: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Détection d’intrusion

• Les limites actuelles de la détection d’intrusion Faible taux de détection

• Faux négatifs Trop de fausses alertes

• Faux positifs• Plus de 100 000 alertes générées en une semaine (source IBM USA)

Le niveau de granularité d’une alerte est trop faible• Pas de vision globale• Difficile de détecter une attaque distribuée

Difficile de détecter les attaques nouvelles• C’est un avantage des approches comportementales

4. Détection d’intrusions

Page 50: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Outils de protection d’un système d’information

• Authentification

• Confidentialité et intégrité des données transmises

• Contrôle des accès

• Bases de données virtuelles

• Audit

Page 51: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Authentification

• Authentification par le SGBD ou par le système d’exploitation

Authentification par le SGBDSGBD BD

Authentification par l’OS

Profil des utilisateur

s

5. Authentification

Page 52: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Création d’un profil d’utilisateur

• Permet d’associer différents paramètres au protocole d’authentification et à la gestion des mots de passe

• Par exemple, sous ORACLE 8 : REMOTE_OS_AUTHENT = True : l’authentification aura lieu par l’OS FAILED_LOGIN_ATTEMPTS : nombre d’échecs de tentative d’accès avant que le compte

ne soit verrouillé PASSWORD_LIFE_TIME : durée de vie en jours d’un mot de passe

5. Authentification

Page 53: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Risques liés à l’authentification

• Existence d’utilisateurs par défaut Possibilité d’attaques contre ces comptes s’ils n’ont pas été reconfigurés Exemple : utilisateur SCOTT (mot de passe TIGER) sous ORACLE

• Gestion des mots de passe Distribution du mot de passe lors de la création du compte Transmission du mot de passe entre le client et le serveur Administrateur malveillant

• Pour limiter ces risques, possibilité d’utiliser SSL sous ORACLE Secure Sockets Layer Gestion de certificats via un tiers de confiance Authentification mutuelle via le protocole Kerberos

5. Authentification

Page 54: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Confidentialité et intégrité des données transmises

• Risques lors de la transmission des requêtes et des résultats entre le client et le serveur

SGBDBD

EcouteInterceptionAltérationMascaradeRejeu

6. Sécurité des communications

Page 55: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Chiffrement et signature

• Exemple : Sous Oracle, utilisation de Oracle Advanced Security

• Chiffrement avec OAS Chiffrement de bout en bout Pas de chiffrement des données stockées Chiffrement symétrique Supporte le triple DES avec clés de 168 bits

• Signature Pour éviter des manipulations des données lors de la transmission Message Digest Value

6. Sécurité des communications

Page 56: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Politique de contrôle d’accès = ensemble de règles

• Format des règles

Sujet

Permission

Interdiction

Obligation

Action

Objet

Ensembled ’objets

avoir

avoir

avoir

réaliser

réaliser

réaliser

agirsur

agirsur

7. Politique de contrôle d’accès

Page 57: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Concept de base d’une politique de contrôle d ’accès

• Sujets = Entités actives du SI Inclut toujours les utilisateurs Inclut souvent les processus travaillant pour le compte des utilisateurs

• Objets = Entités passives du SI Contiennent les informations à protéger Exemple :

• les relations dans une base de données relationnelle

• Actions = permettent aux sujets de manipuler les objets Exemple

• Requête SQL dans une base de données relationnelle

Sujet Action ObjetRéaliser Agir sur

7. Politique de contrôle d’accès

Page 58: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple : Système d ’information d ’un groupe médical

• Sujets = personnels du groupe médical

JeanJeanne

Médecin

Nadine

Secrétairemédical

• Objets : Dossiers des patients

7. Politique de contrôle d’accès

Page 59: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple (suite)

• Objets (plus détaillés)

Dossier_Patient

Dossier_Admin

Dossier_Médical

Dossier_Soins_Infirmiers

Partie_Admin

Partie_Secu_Sociale

7. Politique de contrôle d’accès

Page 60: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple (suite)

• Actions (exemples)

Ausculter un patient

Créer le dossier d ’un nouveau patient

Consulter le dossier

Mettre à jour les parties« Dossier_médical » et

« Dossier_soins_Infirmiers »

Renseigner « Dossier_Admin »

7. Politique de contrôle d’accès

Page 61: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple de règles

• Règles indépendantes du contenu Les plus simples Règle qui permet d’accéder à un objet indépendamment du contenu de cet objet

• Exemple :• R1 : La secrétaire médicale a la permission de gérer le

« Dossier_Admin » d ’un patient du groupe médical Permet de consulter et de mettre à jour n ’importe quelle information du

« Dossier_Admin » d ’un patient

7. Politique de contrôle d’accès

Page 62: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple de règles (suite)

• Règles dépendant du contenu La permission d’accéder à un objet dépend du contenu de cet objet

• Exemple :• R2 : Le médecin a la permission de consulter l ’intégralité du dossier

d ’un de ses patients Permet de consulter un dossier médical à condition qu’il s ’agisse d ’un patient de ce

médecin

• R3 : Le médecin a la permission de mettre à jour les parties « Dossier_Medical » et « Dossier_Soins_Infirmiers » d’un de ses patients

7. Politique de contrôle d’accès

Page 63: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple de règles (suite)

• Règles dépendant du contexte La permission d’accéder à un objet dépend d’une condition indépendante du contenu de

cet objet

• Exemples :• R4 : En l ’absence de la secrétaire médical, le médecin a le droit de

créer le « dossier_admin » d ’un nouveau patient

7. Politique de contrôle d’accès

Page 64: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple de règles (suite)

• Délégation et transfert de droit

• Exemple :• R5 : Un médecin du groupe médical a la permission d ’autoriser la

secrétaire médicale de mettre à jour la prescription contenue dans le « Dossier_médical » du patient

• Contrepartie de la délégation• R6 : La secrétaire médicale ayant reçu autorisation a la permission de

mettre à jour la prescription du « Dossier_médical » du patient

7. Politique de contrôle d’accès

Page 65: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Modèle discrétionnaire (DAC)

• DAC = Discretionary Access Control Contrôle d ’accès discrétionnaire

• Objectif de DAC Garantir que tous les accès directs aux objets correspondent à des accès permis par la

politique de sécurité

• Principes de DAC Les sujets ont des permissions de réaliser des actions sur les objets

• Typiquement, consultation (lecture) ou modification (écriture) de l ’objet Les sujets ont l ’autorisation de transférer certaines permissions à d ’autres sujets

• Droits discrétionnaires de donner des permissions à d ’autres sujets

8. DAC

Page 66: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple typique de DAC

• Gestion des droits dans UNIX

Répertoire

F

Contenudu fichier F

User Group Other

R W E R W - R - -

Owner

Jean

• Concept de propriétaire Dans UNIX, chaque objet a un propriétaire C ’est le propriétaire qui a les droits discrétionnaires

sur l ’objet• Le propriétaire décide des droits des autres sujets

8. DAC

Page 67: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Principe du modèle DAC proposé par SQL

UUtilisateur

PPermission

VVue

AAction

OObjet

= N-uplet

8. DAC

Page 68: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Notion de vue

• Vue = relation dérivée Toute expression relationnelle à laquelle on a donné un nom

• Exemple Soit la relation dossier_patient

• Relation qui contient les dossiers de tous les patients du cabinet médical Soit la vue :

CREATE VIEW dossier_patient_de_Jean ASSELECT *FROM dossier_patientWHERE dossier_patient.medecin_traitant = ”Jean” ;

La vue   dossier_patient_de_Jean contient tous les dossiers des patients de Jean

8. DAC

Page 69: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Définition d ’une politique de sécurité dans DAC-SQL

• Basée sur le concept de « Vue » Permet de diviser la base de données en plusieurs parties

• Instruction GRANT Permet de spécifier les privilèges que certains utilisateurs ont la permission d’exécuter

• Instruction REVOKE Permet d ’enlever un privilège que possède un utilisateur

8. DAC

Page 70: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Définition d ’une politique de sécurité dans DAC-SQL

• Principaux privilèges possibles SELECT : permet la consultation de la table INSERT : permet l ’insertion de nouvelles données dans la table UPDATE : permet la mise à jour de n ’importe quelle colonne de la table UPDATE(nom_colonne) : permet la mise à jour d ’une colonne spécifique de la table DELETE : permet de supprimer n ’importe quelle donnée de la table ALTER : Modifier la définition d’un objet EXECUTE : Compiler et exécuter une procédure utilisée dans un programme REFERENCE : Créer une contrainte sur une relation INDEX : Créer un index sur une relation

8. DAC

Page 71: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Instruction GRANT

• Format de l ’instruction :

GRANT <liste privileges>ON <table ou vue>TO <liste utilisateurs>[ WITH GRANT OPTION ] ;

WITH GRANT OPTION • est optionnel• signifie que l ’utilisateur qui obtient le privilège peut ensuite accorder ce privilège à un

autre utilisateur

8. DAC

Page 72: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Instruction REVOKE

• Format de l ’instruction :REVOKE [ GRANT OPTION FOR ] <liste privileges>

ON <table ou vue>FROM <liste utilisateurs><option> ;

GRANT OPTION FOR• est optionnel• signifie que seul le droit de transfert est révoqué

<option> = RESTRICT ou CASCADE• Supposons que A accorde le privilège p à B et B accorde ensuite p à C• CASCADE : si A révoque p à B alors C perd aussi le privilège• RESTRICT : si A révoque p à B alors la révocation échoue

8. DAC

Page 73: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Application du modèle

• Politique de sécurité du groupe médical

• Sujets = Utilisateurs

• Objets 3 relations :

• dossier_admin• dossier_medical• dossier_soins_infirmiers

8. DAC

Page 74: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Application du modèle (suite)

• Définition du dossier du patient

CREATE VIEW dossier_patient ASSELECT *FROM dossier_admin, dossier_medical, dossier_soins_infirmiersWHERE dossier_admin.id_patient = dossier_medical.id_patientAND dossier_admin.id_patient = dossier_soins_infirmiers.id_patient

8. DAC

Page 75: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemples d ’expression de règles

R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » d ’un patient du groupe médical

GRANT ALL PRIVILEGESON dossier_adminTO Nadine ;

8. DAC

Page 76: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Expression des règles (suite)

R2 : Le médecin a la permission de consulter l ’intégralité du dossier d’un de ses patients

Définition d ’une vueCREATE VIEW dossier_patient_du_medecin AS

SELECT *FROM dossier_patientWHERE dossier_patient.medecin_traitant = CURRENT_USER ;

CURRENT_USER : opérateur prédéfini géré par SQL

GRANT SELECTON dossier_patient_du_medecinTO Jean, Jeanne ;

8. DAC

Page 77: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Expression des règles (suite)

• R3 : Le médecin a la permission de mettre à jour les parties « Dossier_Medical » et « Dossier_Soins_Infirmiers » d’un de ses patients

Définition d ’une vueCREATE VIEW dossier_medical_du_medecin AS

SELECT *FROM dossier_medicalWHERE dossier_medical.medecin_traitant = CURRENT_USER ;

GRANT INSERT, UPDATE, DELETEON dossier_medical_du_medecinTO Jean, Jeanne ;

Règle similaire pour « dossier_soins_infirmier »

8. DAC

Page 78: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Expression des règles (suite)

• R4 : En l ’absence de la secrétaire médicale, le médecin a la permission de créer le « dossier_admin » d ’un nouveau patient

Hypothèse : existence de deux tables• utilisateur : cette table à un attribut « nom » et un attribut « etat »• utilisateur_role(nom,role)

Définition d ’une vueCREATE VIEW dossier_admin_medecin AS

SELECT *FROM dossier_admin

WHERE NOT EXISTS (SELECT * FROM utilisateur, utilisateur_role

WHERE utilisateur.nom = utilisateur_role.nom AND utilisateur_role.role = ”secretaire_medical” AND utilisateur.etat = ”present” ) ;

GRANT INSERTON dossier_admin_medecin TO Jean, Jeanne ;

8. DAC

Page 79: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Règle de délégation• R5 : Un médecin a la permission d ’autoriser la secrétaire médicale de mettre

à jour la prescription contenue dans le « Dossier_médical » du patient

Création d ’une vueCREATE VIEW prescription_du_medecin AS

SELECT dossier_medical.nom_patient, dossier_medical.prescriptionFROM dossier_medical, WHERE dossier_medical.medecin_traitant = CURRENT_USER ;

GRANT SELECT, UPDATE(prescription)ON prescription_du_medecinTO Jean, JeanneWITH GRANT OPTION TO Nadine ; • Il s ’agit d ’un « à peu prêt »

Avec SQL, On ne peut pas préciser que « GRANT OPTION » ne concerne que la secrétaire médicale

8. DAC

Page 80: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Règle de délégation (suite)• R6 : La secrétaire médicale ayant reçu autorisation a la permission de

mettre à jour la prescription du « Dossier_médical » du patient

Pour donner effectivement l ’autorisation de mettre à jour la prescription d ’un patient particulier (par exemple Paul), le médecin doit :

1 : Créer une vue :CREATE VIEW prescription_de_Paul AS

SELECT *FROM prescription_du_medecinWHERE prescription_du_medecin.nom_patient = ”Paul” ;

2 : Donner les privilèges sur la vue à la secrétaire médicale : CREATE PERMISSION R6

GRANT SELECT, UPDATE(prescription)ON prescription_de_PaulTO Nadine ;

Possible car le médecin a le privilège « WITH GRANT OPTION » sur la table prescription_du_medecin

8. DAC

Page 81: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Privilèges système dans DAC-SQL

• Les instructions GRANT et REVOKE s ’appliquent aussi aux fonctions d ’administration, par exemple : CREATE TABLE ALTER TABLE DROP TABLE CREATE USER DROP USER

• Dans notre exemple médical, il faudrait compléter la définition de la politique de sécurité pour définir quels sont les utilisateurs qui ont des privilèges système

8. DAC

Page 82: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Conclusion sur DAC-SQL

• Intérêt du concept de vue Permet d ’exprimer des règles dépendant du contenu Permet d ’exprimer certaines règles dépendant du contexte

• Règle de délégation Incomplet et complexe à gérer « WITH GRANT OPTION » n ’est pas suffisant

• Structuration des objets Grâce au concept de vue

• Contrôle d’accès basé sur l’identité des sujets Pas de structuration des sujets

8. DAC

Page 83: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Modèle RBAC

• Présentation du modèle de base RBAC96 Proposé par Ravi Sandhu

• Gestion des rôles dans SQL3

9. RBAC

Page 84: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Concepts de base de RBAC

• Concept de rôle Permet de représenter la structure d ’une organisation Recouvre plus aspects

Rôle fonctionnel• Permet la réalisation de certaines tâches spécifiques• Exemple : médecin, infirmier, secrétaire médical

Rôle organisationnel• Autorité et responsabilité• Exemple : infirmier chef, responsable du service d ’urgence, directeur de l ’hôpital

Mais aussi, dans certains cas, participation à un projet

9. RBAC

Page 85: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Concepts de base de RBAC (suite)

• Sujet Dans RBAC, Sujet = Utilisateur

• Permission Concept primitif de RBAC Doit ensuite être interprété dans le contexte applicatif considéré Exemples :

• Permission sur des vues dans un SGBD relationnel• Permission sur des fichiers dans un système d ’exploitation

Conséquences :• Pas de concept d ’objet dans RBAC96• Pas de concept d ’action dans RBAC96

• Session Les utilisateurs doivent toujours commencer par activer une session

9. RBAC

Page 86: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Modèle consolidé :Contraintes + Hiérarchie

La famille des modèles de RBAC96

RBAC0

Modèle de base(le plus simple)

RBAC1 RBAC2

RBAC3

ContraintesHiérarchie de rôles

9. RBAC

Page 87: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Modèle de base : RBAC0

UUtilisateurs

RRôles

PPermissions

.

.

. SSessions

AUAffectation

desUtilisateurs

APAffectation

desPermissions

AP :• Une permission peut être affectée à plusieurs rôles

• Plusieurs permissions peuvent être affectées à un rôle

AU :• Un rôle peut être

affecté à plusieurs utilisateurs• Plusieurs rôles peuvent

être affectés à un utilisateur

• Une session est activée parun seul utilisateur

• Un utilisateur peut activerplusieurs rôles dans une session

9. RBAC

Page 88: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Moindre privilège dans RBAC0

• Dans une session, l’utilisateur peut choisir les rôles qu’il souhaite activer

• Conséquence : Toutes les permissions de l ’utilisateur ne sont pas nécessairement activées Prise en compte partielle du moindre privilège

• Mais, lorsqu’un rôle est activé, toutes les permissions de ce rôle sont systématiquement activées

9. RBAC

Page 89: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Hiérarchie de rôles : RBAC1

UUtilisateurs

RRôles

PPermissions

.

.

. SSessions

AU AP

HRHiérarchiede rôles

9. RBAC

Page 90: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Hiérarchie de rôles

• R1 est un rôle junior de R2 si R1 est hiérarchiquement inférieur à R2• R2 est un rôle senior de R1 si R2 est hiérarchiquement supérieur à R1

• Notation : R1 R2 : R1 est un rôle junior de R2 R2 R1 : R2 est un rôle senior de R1

et sont des relations d ’ordre partiel sur l ’ensemble des rôles

• Plusieurs interprétations possibles de la hiérarchie : Spécialisation/Généralisation Hiérarchie organisationnelle

9. RBAC

Page 91: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Hiérarchie de rôles (suite)

• Spécialisation/Généralisation R1 est un senior rôle de R2

si chaque fois qu’un utilisateur joue le rôle R1, cet utilisateur joue aussi le rôle R2

Personnel médical

Médecin

Généraliste Spécialiste

Cardiologue Rhumatologue . . .

9. RBAC

Page 92: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Hiérarchie de rôles (suite)

• Hiérarchie organisationnelle R1 est un senior rôle de R2

si un utilisateur jouant le rôle R1 est un supérieur hiérarchique d ’un utilisateur jouant le rôle R2

Médecin

Chef de service

Directeur d ’un département

Directeur d ’un hôpital

. . .

9. RBAC

Page 93: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Hiérarchie de rôles (suite)

• Héritage des permissions

Si R1 est un rôle senior de R2 Alors R1 hérite des permissions affectées à R2

Exemple :• Le Cardiologue hérite des permissions du Spécialiste

Le principe d’héritage est acceptable dans le cas d’une hiérarchie de type Spécialisation/Généralisation

Il est parfois discutable dans le cas d’une hiérarchie organisationnelle• Le directeur de l ’hôpital n ’hérite pas de toutes les permissions du Médecin

9. RBAC

Page 94: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contraintes : RBAC2

UUtilisateurs

RRôles

PPermissions

.

.

. SSessions

AU AP

Contraintes

9. RBAC

Page 95: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contraintes

• Expression logique qui permet de contraindre les différentes affectations :

AU : Utilisateur Rôle

AP : Rôle Permission

AS : Session Rôle

9. RBAC

Page 96: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contraintes (suite)

• Contrainte sur AU : Utilisateur Rôle

Un utilisateur ne peut pas cumuler certains rôles Exemple : rôles anesthésiste et chirurgien

u, ( AU(u,Anesthésiste) AU(u,Chirurgien) ) Contrainte de type « Séparation des pouvoirs »

• Separation of Duty

Contrainte de cardinalité Exemple : le rôle de directeur de l ’hôpital ne peut être affecté qu’à un seul utilisateur

u, u’, ( AU(u,Dir_hopital) AU(u’,Dir_hopital) ) u = u’

9. RBAC

Page 97: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contraintes (suite)• Contrainte sur AP : Rôle Permission

Certaines permissions ne peuvent pas être affectées à certains rôles Exemple : la permission d ’opérer ne peut être affectée au rôle Infirmier Proche de la notion d ’interdiction

Certaines permission de peuvent pas être affectées à plusieurs rôles Exemple : la permission d ’anesthésier ne peut être affectée qu’au rôle Anesthésiste

Un rôle de doit pas pouvoir cumuler certaines permissions Exemple : permission d ’anesthésier et d ’opérer Contrainte de type « Séparation des tâches »

• Plusieurs rôles sont nécessaires pour réaliser une opération• Et plusieurs utilisateurs sont aussi nécessaires si l ’on ajoute une contrainte de type

« Séparation des pouvoirs »

9. RBAC

Page 98: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contraintes (suite)

• Contrainte sur AS : Session Rôle

Similaire aux contraintes sur AU : Utilisateur Rôle Mais contrainte dynamique lorsqu’un utilisateur active une session Exemple :

• Role1 : Directeur d ’un service hospitalier• Rôle2 : Médecin libéral• Un médecin peut cumuler les deux rôles mais pas les activer dans la même session• Plusieurs casquettes mais une seule casquette à la fois

9. RBAC

Page 99: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Modèle consolidé : RBAC3

UUtilisateurs

RRôles

PPermissions

.

.

. SSessions

AU AP

HRHiérarchiede rôles

Contraintes

9. RBAC

Page 100: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Modèle consolidé : RBAC3

• Contrainte sur la hiérarchie de rôle

Contrainte sur HR : Rôle Rôle

Exemple : Médecin spécialiste n ’est pas un rôle senior de médecin généraliste

9. RBAC

Page 101: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Gestion des rôles dans SQL

• Le concept de rôle a été introduit dans SQL3 Par encore pris en compte par tous les SGBD

• Instructions de SQL3 CREATE ROLE <nom_role> ;

• Création d ’un nouveau rôle nom_role

DROP ROLE <nom_role> ;• Suppression du rôle nom_role

SET ROLE <liste_roles> ;• Permet à un utilisateur d ’activer un ensemble de rôle pendant la durée d ’une session

SQL

9. RBAC

Page 102: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Principe de la gestion des rôles dans SQL3

RRôle

PPermission

VVue

AAction

OObjet

=N-uplet

UUtilisateur

9. RBAC

Page 103: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Adaptation de l ’instruction GRANT

• Affectation des privilèges aux rôlesGRANT <liste privileges>

ON <table ou vue>TO <liste roles>[ WITH GRANT OPTION ] ;

• Affectation des utilisateurs aux rôlesGRANT <liste roles>TO <liste utilisateurs>

• Rôle junior et rôle seniorGRANT <role1> TO <role2> Le rôle role2 reçoit tous les privilèges du rôle role1

9. RBAC

Page 104: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Adaptation de l ’instruction REVOKE

• Revocation de privilèges aux rôles REVOKE [ GRANT OPTION FOR ] <liste privileges>

ON <table ou vue>FROM <liste roles><CASCADE ou RESTRICT> ;

• Révocation des utilisateurs aux rôlesREVOKE <liste roles>FROM <liste utilisateurs>

• Mise à jour de la hiérarchie de rôleREVOKE role1 FROM role2 ;

9. RBAC

Page 105: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Application du modèle

• Création des rôles

CREATE ROLE secretaire_medical ;

• R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » d ’un patient du groupe médical

GRANT ALL PRIVILEGESON dossier_adminTO secretaire_medicale ;

• Puis affectation de Nadine au rôle secretaire_medicale

GRANT secretaire_medicale to Nadine ;

9. RBAC

Page 106: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Conclusion sur la gestion des rôles dans SQL

• Conservation des avantages de DAC-SQL Possibilité d ’exprimer des règles dépendant du contenu et du contexte

• Intérêt des concepts de vue et de rôle Les vues permettent de structurer la gestion des objets Les rôles permettent de structurer la gestion des sujets

9. RBAC

Page 107: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Sécurité des applications

• Limite des contrôles d’accès basés sur les vues et les rôles Ne contrôlent pas les accès via des applications

• ODBC• Application ad-hoc• Cf. l’attaque par injection de code SQL

• Il est possible d’associer un rôle à l’application Mais dans ce cas, tous les utilisateurs de l’application disposeront des mêmes droits

d’accès à la base Solution insuffisante

10. Sécurité des applications

Page 108: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Base de données privée virtuelle (VPD)

• Mécanisme fourni par Oracle 8i pour assurer la sécurité des applications

• Principe Possibilité d’associer une règle de sécurité à une relation ou une vue Lorsque la fonctionnalité VPD est activée, toute requête qui accède à cette relation ou

cette vue est automatiquement modifiée en incluant une clause WHERE

• Création du contexte d’une application Permet d’accéder aux attributs spécifiques de l’attribut connecté via l’application La clause WHERE de la requête modifiée est construite en utilisant ce contexte

10. Sécurité des applications

Page 109: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Contexte d’application

• Oracle a prévu un contexte par défaut USERENV : contient des informations système relatives à la session courante Exemple :

• CURRENT_USER• HOST• ISDBA

• Possibilité de créer un nouveau contexte et d’y associer des attributs Exemple :

create context CTX_SEC_MEDICALE using SCHEMA_MED.SEC_MEDICALE CTX_SEC_MEDICALE sera un contexte associé au package PL/SQL nommé

SEC_MEDICALE et stocké dans le schéma SCHEMA_MED

10. Sécurité des applications

Page 110: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Définition des règles de sécurité

• Les règles de sécurité doivent être écrites en PL/SQL

• Exemple :create package body SEC_MEDICALE as

function DOSSIER_SEC return varchar2 isMY_PREDICATE varchar2(2000) ;beginMY_PREDICATE := 'id_patient in (SELECT id_patient FROM dossier_medical WHERE medecin_traitant = sys_context("USERENV", "CURRENT_USER"))' ;return MY_PREDICATE ;

end DOSSIER_SEC ;end SEC_MEDICALE ;

10. Sécurité des applications

Page 111: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Exemple de transformation de requêtes

• Supposons que Jean formule la requête suivante :SELECT * FROM dossier_medical WHERE id_patient = 'Paul'

• L’application de la règle DOSSIER_SEC va automatiquement transformer cette requête en la requête suivante :

SELECT * FROM dossier_medical WHERE id_patient = 'Paul'AND id_patient in

(SELECT id_patient FROM dossier_medical WHERE medecin_traitant = 'Jean' ) ;

Jean ne pourra ainsi accéder qu’aux dossiers médicaux de ses patients

10. Sécurité des applications

Page 112: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Limites des modèles DAC et RBAC

• Hypothèse de DAC L’application s ’exécutant pour le compte de l ’utilisateur hérite des droits de cet utilisateur

• Hypothèse de RBAC L ’application s ’exécutant pour le compte de l ’utilisateur hérite des droits de la session Droit de la session = droits de l ’ensemble des rôles activés par l ’utilisateur

• Dans DAC et RBAC, risque de programmes malveillants Notion de Cheval de Troie

Conclusion/Perspectives

Page 113: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Limites des modèles DAC et RBAC (suite)

• Cheval de Troie = Programme piégé Un Cheval de Troie est un programme qui a une fonctionnalité apparente mais qui

contient des fonctions cachées qui s ’exécutent à l ’insu de l ’utilisateur

• Objectif du cheval de Troie Transmission illégale d ’information vers de bénéficiaire du piège Modification illégale d ’information par le bénéficiaire du piège

• Bénéficiaire du piège Utilisateur qui a installé le Cheval de Troie dans le programme Exemple :

• Concepteur du programme, • Utilisateur qui administre le système• Utilisateur qui assure la maintenance du système• Etc.

Conclusion/Perspectives

Page 114: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Limites des modèles DAC et RBAC (suite)

• Exemple de Cheval de Troie Attaque contre la confidentialité

Dossiersdes

patients

Bénéficiairedu Chevalde Troie

Application piégée

Médecin

L ’application piégée a les droits de lectureet d ’écriture sur les dossiers des patients

Transmission des dossiers des patientsà l ’insu du médecin

Conclusion/Perspectives

Page 115: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Protection contre les Chevaux de Troie

• Modèle MAC Mandatory Access Control Contrôle d ’accès par Mandat

• Politique de sécurité multi-niveaux Niveaux hiérarchiques

• Pour assurer le cloisonnement vertical• Exemple : Confidentiel, Secret, Très Secret

Compartiments• Pour assurer le cloisonnement horizontal• Exemple : cardiologie, pédiatrie, rhumatologie, ...

Conclusion/Perspectives

Page 116: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Gestion MAC dans un SGBD

• Exemple : Trusted ORACLE 7 Niveau de classification associé aux n-uplets Niveau d ’habilitation associé aux utilisateurs Mise en œuvre du modèle de Bell et LaPadula Echec commercial par manque de souplesse

• Aujourd ’hui : ORACLE Label Security Inclus dans ORACLE8i Solution VPD pour gérer les niveaux de sécurité Modèle plus souple

Conclusion/Perspectives

Page 117: Protection  des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens

Centre de Toulouse

BDA’02

21 Octobre 2002

Perspectives

• Prise en compte d ’un système d ’informations qui gère les données de plusieurs organisations ayant des politiques de sécurité différentes Limite du modèle R-BAC Proposition du modèle F-BAC : Function-Based Access Control

• Obligation provisionnelle On accorde une permission à un utilisateur En contrepartie, cet utilisateur a l ’obligation de réaliser une certaine action lorsqu’il utilise

cette permission

• Remettre en cause l ’existence d ’un DBA tout puissant• Evaluer des requêtes sur des données chiffrées

• Sécurité d ’un serveur de documents XML

Conclusion/Perspectives