Politiques de sécuritéPolitiques de sécurité11e cours (hiver 2014)

Louis Salvail

OrganisationOrganisationPolitique de sécuritéPolitique de sécurité

Une description simple des Une description simple des objectifs de sécuritéobjectifs de sécurité d’un d’un système et une système et une stratégie de stratégie de haut niveauhaut niveau pour les satisfaire. pour les satisfaire.

Politique de sécuritéPolitique de sécurité

Une description simple des Une description simple des objectifs de sécuritéobjectifs de sécurité d’un d’un système et une système et une stratégie de stratégie de haut niveauhaut niveau pour les satisfaire. pour les satisfaire.

Modèle des menacesModèle des menaces

Une description des attaques Une description des attaques contre lesquelles le système doit contre lesquelles le système doit être en mesure de se défendre.être en mesure de se défendre.

Modèle des menacesModèle des menaces

Une description des attaques Une description des attaques contre lesquelles le système doit contre lesquelles le système doit être en mesure de se défendre.être en mesure de se défendre.

Mécanismes de sécuritéMécanismes de sécurité

Les solutions techniques utilisées Les solutions techniques utilisées pour satisfaire les objectifs.pour satisfaire les objectifs.

Mécanismes de sécuritéMécanismes de sécurité

Les solutions techniques utilisées Les solutions techniques utilisées pour satisfaire les objectifs.pour satisfaire les objectifs.

Nous avons traité surtout

de mécanismes jusqu’à

maintenant...

Nous avons aussi traité

des modèles de menaces

classiques

Nous allons maintenant

voir cet aspect important

Les objectifs définissent les états autorisés d’un système.La stratégie indique comment on compte satisfaire les objectifs.

Pour définir les états autorisés d’un système, encore faut-il décrire le système sur lequel ces politiques vont s’appliquer.

Les politiques dépendent d’éléments de la sécurité des systèmes. Le TCB doit satisfaire une politique bien structurée.

C’est quoi un TCB?(base informatique sécurisé)

Ex: Le contrôle d’accès du serveur WEB est Ex: Le contrôle d’accès du serveur WEB est considéré comme une partie du TCB du considéré comme une partie du TCB du

système qui comprend le serveur UNIX, la système qui comprend le serveur UNIX, la navigateur d’un usager et l’application WEB.navigateur d’un usager et l’application WEB.

Pour les langages de programmation avec des Pour les langages de programmation avec des fonctions de sécurité intégrées (Java par exemple), fonctions de sécurité intégrées (Java par exemple),

leur TCB est formé des librairies standards ainsi leur TCB est formé des librairies standards ainsi que de l’environnement d’exécution.que de l’environnement d’exécution.

Modèles pour les politiques Modèles pour les politiques de sécuritéde sécurité

Nous débutons en voyant comment énoncer une politique de sécurité.

Nous appelons modèle de politiques de sécurité une définition abstraite de la façon de définir une politique. Un tel modèle ne décrit pas un système particulier, mais souvent un modèle de menaces.

Une politique de sécurité est une réalisation d’un modèle pour un système particulier. Une politique peut aussi être basée sur plusieurs modèles ou même sur aucun modèle.

Les treillisLes treillisAvant de voir des exemples de modèles de politique, nous étudions le concept de treillis utilisé dans beaucoup de modèles.

Un treillis (S, ≤) est un ensemble fini S avec une relation ‘≤’ tel que a,b,c∈S :

a≤a,

Si a≤b et b≤a alors a=b,

Si a≤b et b≤c alors a≤c.

De plus, pour a,b∈S :

Il existe une borne inférieure maximum pour a,b : un c∈S tel que c≤a et c≤b et, pour chaque c’ avec cette propriété, c’≤c.

Il existe une borne supérieure minimum pour a,b : un d∈S tel que a≤d et b≤d et, pour chaque d’ avec cette propriété, d≤d’.

Exemple :Exemple :

S={public, délicat, secret, top S={public, délicat, secret, top secret}secret}

public≤top secretpublic≤top secretsecret≤top secretsecret≤top secretdélicat≤top secretdélicat≤top secret

public≤délicatpublic≤délicat

Exemple :Exemple :

S={public, délicat, secret, top S={public, délicat, secret, top secret}secret}

public≤top secretpublic≤top secretsecret≤top secretsecret≤top secretdélicat≤top secretdélicat≤top secret

public≤délicatpublic≤délicat

Le ≤ n’a pas à être défini Le ≤ n’a pas à être défini pour chaque paire.pour chaque paire.

Le ≤ n’a pas à être défini Le ≤ n’a pas à être défini pour chaque paire.pour chaque paire.

n’a pas de n’a pas de borne borne

inférieure inférieure maximum maximum

pour pour secretsecret,,top top

secretsecret

Les droits d’accès comme Les droits d’accès comme treillistreillis

Une politique de sécurité pour les droits d’accès à des fichiers peut être définie avec le treillis :

S={aucun, lecture, écriture, lesdeux} tel que :

aucun≤lecture, aucun≤écriture, aucun≤lesdeux,

lecture≤lesdeux, écriture≤lesdeux, mais

lecture et écriture ne peuvent être comparées.

Deux façons simples d’utiliser un Deux façons simples d’utiliser un treillistreillis

1.Définissons les sujets comme tous les utilisateurs et processus d’un système. Il s’agit des entités qui peuvent interagir avec les autres parties d’un système que nous nommons objets (ressources, fichiers, unités matérielles, etc.):

Nous pouvons classifier les sujets et les objets en leur assignant des positions dans le treillis. La classification d’un objet ou d’un sujet r est désignée C(r).

1. Nous pouvons énoncer que le sujet s peut appliquer une certaine opération sur l’objet o si et seulement si C(s)≤C(o) (ou C(o)≤C(s)).

2.On donne une position dans un treillis aux différentes parties d’un système. L’information ne peut circuler de a vers b que si a≤b. Ceci s’applique si la position a≤b peut être interprétée par b est plus sûr que a et la politique en est une de confidentialité. Pour l’authenticité, a≤b peut vouloir dire que b est plus fiable que a. L’information peut alors circuler de b vers a que si a≤b.

3. Les deux approches ont des similitudes. Les classifications dans un treillis impliquent un flux (des directions de circulation) d’information.

L’importance des bornes L’importance des bornes inférieures et supérieuresinférieures et supérieuresL’importance des bornes L’importance des bornes inférieures et supérieuresinférieures et supérieures

Supposons qu’une politique soit exprimée dans le modèle avec classification. Supposons que nous avons deux fichiers a et b avec classifications C(a) et C(b) :

Question : Qui peut lire les deux fichiers a et b?

Réponse : Les sujets s tels que C(s)≥d et d est la borne supérieure minimale pour a,b.

La même chose pour le modèle qui spécifie la circulation de l’information quant à l’authenticité :

Question : Quelles parties du système admettent que a et b circulent vers celles-ci?

Réponse : les parties s telles que c≥C(s) et c est la borne inférieure maximum pour a,b.

Le modèle de Bell-LapadulaLe modèle de Bell-LapadulaLe premier modèle pour la formalisation de politique de sécurité. Conçu pour les applications militaires qui traitent de la confidentialité.

Il s’agit de définir des niveaux de sécurité :

Par exemple : public≤secret≤top secret.

La classification C(s) du sujet s indique son niveau de sécurité. La même chose pour un objet o. C(o) est le niveau de sécurité de l’objet o.

Deux règles sont alors définies (*-properties) :

Pas de lecture en haut : Le sujet s peut lire l’objet o seulement si C(s)≥C(o).

Pas d’écriture en bas : Le sujet s peut écrire sur l’objet o seulement si C(s)≤C(o).

L’idée est d’éviter que l’information circule L’idée est d’éviter que l’information circule d’un niveau élevé vers un niveau moins élevé.d’un niveau élevé vers un niveau moins élevé.

L’idée est d’éviter que l’information circule L’idée est d’éviter que l’information circule d’un niveau élevé vers un niveau moins élevé.d’un niveau élevé vers un niveau moins élevé.Un chercheur secret peut lire des Un chercheur secret peut lire des

documents secrets ou publics, documents secrets ou publics, mais pas top secret!mais pas top secret!

Un chercheur secret peut lire des Un chercheur secret peut lire des documents secrets ou publics, documents secrets ou publics,

mais pas top secret!mais pas top secret!

Un chercheur secret peut écrire des Un chercheur secret peut écrire des documents secrets ou top secret, mais pas documents secrets ou top secret, mais pas

publics!publics!

Un chercheur secret peut écrire des Un chercheur secret peut écrire des documents secrets ou top secret, mais pas documents secrets ou top secret, mais pas

publics!publics!

À propos de Bell-LapadulaÀ propos de Bell-LapadulaLes règles de Bell-Lapadula interdisent la circulation de l’information d’un certain niveau vers un niveau moins élevé. L’information circule ver le haut.

Modèle assez rigide et difficile à utiliser dans la pratique. Un système peut être dans l’impossibilité d’effectuer ces tâches, à moins que de l’information circule vers le bas.

Un autre problème est de déterminer quoi faire lorsque les classifications changent.

Bell-Lapadula a servi de point de départ pour la conception de systèmes où la confidentialité est la condition la plus importante à satisfaire.

Le modèle de BibaLe modèle de BibaCe modèle est semblable au modèle de Bell-Lapadula avec l’accent mis sur l’intégrité.

Dans ce modèle, l’information la plus intègre est celle du niveau le plus haut. Pour maintenir cet état, le modèle Biba a les deux règles suivantes :

Pas de lecture en bas : Le sujet s peut lire l’objet o seulement si C(s)≤C(o).

Pas d’écriture en haut : Le sujet s peut écrire sur l’objet o seulement si C(s)≥C(o).

L’information ne doit pas circuler d’un bas niveau à un niveau élevé. Ceci assure que l’information n’est pas contaminée avec de l’information moins intègre.

ExempleExemple

???

Niveau 1

Niveau 2

Niveau 2 ou 3

ExtensionsExtensions

Bell-Lapadula et Biba peuvent être étendus dans un modèle appelé modèle compartimenté.

Les différents niveaux sont séparés en compartiments.

L’information ne peut circuler entre les compartiments de même niveau.

Ceci entraîne une généralisation des treillis. Les approches suivantes reposent sur autre chose que les treillis.

Autres modèlesAutres modèlesMuraille de Chine : Modèle inspiré du commerce. Une compagnie C a différents clients. Certains de ces clients sont en compétition entre eux. Nous voulons une politique qui assure qu’aucune information à propos d’un client n’est donnée (par un employé de C) à un autre avec lequel il est en compétition.

Un prédicat comp(c,c’) est vrai si et seulement si c et c’ sont en compétition.

La règle est alors qu’un sujet s a accès à c si et seulement s’il n’a jamais eu accès à c’ tel que comp(c,c’)=vrai.

Cette règle est dynamique : aussitôt que s accède à c, il devient impossible d’accéder à c’ tel que comp(c,c’)=vrai.

Autres modèles (II)Autres modèles (II)Prévenir-Détecter-Récupérer : Ce type de modèle demande de séparer la politique en 3 parties :

Description des méthodes utilisées pour se prémunir contre les attaques.

Description des mécanismes de détection des attaques dangereuses.

Description de ce qui doit être fait lorsqu’une attaque est détectée.

Un exemple de ce type de politique est la protection antivirus.

Il est possible de se prémunir contre ces attaques en autorisant la réception de courriels provenant seulement de certains serveurs.

Comme cette méthode risque d’être insuffisante, les filtres antivirus peuvent être utilisés pour détecter les courriels infectés.

Finalement, la politique peut assurer qu’un courriel infecté est automatiquement éliminé.

Autres modèles (III)Autres modèles (III)Séparation de tâches : Ce modèle vient en deux saveurs :

Contrôle dual : Certaines actions sont seulement possibles si elles ont été autorisées par plusieurs personnes.

Un exemple de cette approche est le recours à l’arme nucléaire comme montré dans plusieurs films.

Séparation fonctionnelle : Certaines actions sont possibles lorsqu’elles sont autorisées par plusieurs personnes, mais à différents moments.

Pour pouvoir se présenter à l’examen, l’étudiant doit avoir fait ses devoirs. Le démonstrateur doit évaluer les devoirs de l’étudiant et en rendre compte au professeur. Le professeur en avertit le bureau des études. De plus, l’étudiant lui-même doit s’enregistrer.

Contrôle d’accèsContrôle d’accèsLes modèles que nous avons vus permettent la description de haut niveau des règles pour la circulation de l’information et les contrôles entre les différentes parties d’un système.

Les modèles supposent implicitement que lorsqu’un utilisateur veut opérer sur un objet, le système peut vérifier l’identité de l’utilisateur et déterminer ses droits et privilèges.

Vérifier l’identité d’un utilisateur peut se faire à l’aide d’un mot de passe, de sécurité matérielle, ou biométrie comme nous l’avons vu.

Déterminer les droits et privilèges courants est un problème différent. C’est le contrôle d’accès.

Contrôle d’accèsContrôle d’accèsEn général, les droits et privilèges peuvent être déterminés à partir de l’identité de l’utilisateur et de la politique de sécurité.

Déterminer l’accès sur le moment pendant que l’utilisateur attend nécessite que l’information soit organisée de la bonne façon.

Une façon canonique d’organiser l’information consiste à définir une matrice de contrôle d’accès. Cette matrice A contient une rangée pour chaque sujet et une colonne pour chaque objet :

A[s,o] contient une liste de toutes les opérations que le sujet s peut effectuer sur l’objet o.

Sur la plupart des systèmes, la matrice de contrôle d’accès est trop grande pour être stockée en un seul endroit central.

Contrôle d’accèsContrôle d’accèsDans la pratique, deux approches sont utilisées pour représenter la matrice A :

Liste des droits d’accès («access control list», ACL) : La colonne d’un objet est rangée avec celui-ci. Une telle liste permet de facilement déterminer qui a accès à un objet. Il est cependant plus difficile de déterminer les droits d’un utilisateur. C’est l’approche du système d’exploitation Unix.

Capacités d’utilisateur («User capabilities») : Pour chaque sujet, sa rangée est enregistrée. Il est facile de déterminer ce qu’un utilisateur peut faire, mais plus difficile de déterminer qui peut accéder à un certain objet. C’est l’approche du système d’exploitation Windows.

ACL en pratiqueACL en pratiquePour les systèmes de bonne taille, les ACL deviennent beaucoup trop longs.

Pour résoudre ce problème, les sujets sont habituellement classés par groupes prédéfinis. Les ACL disent seulement ce que les sujets de chaque groupe peuvent faire.

Par exemple, Unix sépare les sujets du point de vue d’un utilisateur en :

l’utilisateur lui-même,

le groupe de l’utilisateur et

les autres.

Une variante de l’idée de groupe d’utilisateurs est appelée droits d’accès basés sur les rôles.

Des rôles sont prédéfinis comme utilisateurs normaux, admin, etc., et des droits sont donnés pour chaque rôle. Lorsqu’un utilisateur se connecte, alors un rôle lui est attribué.

Ceci est un peu différent de l’approche par groupes d’utilisateurs, car le même utilisateur peut jouer différents rôles à des moments différents.

Matrice de contrôle d’accès Matrice de contrôle d’accès dynamiquedynamique

Comment peut-on mettre à jour une matrice de contrôle d’accès? Il y a deux approches :

Mandatory Access Control : Les sujets ne peuvent pas changer la matrice de contrôle d’accès.

Discretionary Access Control : Les sujets peuvent modifier des parties de la matrice de contrôle d’accès.

Puisque le matrice de contrôle d’accès peut changer en fonction du temps, il est naturel de demander quel type de circulation d’information peut ainsi être produit :

Ex. : Est-ce qu’un certain sujet peut éventuellement avoir accès à un certain objet en supposant que nous partions d’une situation où ce n’est pas le cas?

Analyse du contrôle d’accès Analyse du contrôle d’accès dynamiquedynamique

Harrison, Ruzzo, et Ullman ont étudié le problème suivant :

Les opérations suivantes sur la matrice A sont supportées :

Créer/Détruire sujet s,

Créer/Détruire objet o,

Ajouter/Détruire l’accès r dans A[s,o].

Une commande est de la forme suivante :

Une liste de conditions (du genre droit r est dans A[s,o]) et

Une liste ordonnée d’opérations.

Si les conditions sont toutes vérifiées alors les opérations sont exécutées dans l’ordre.

Décider de l’accès (I)Décider de l’accès (I)Supposons maintenant que nous disposions d’un ensemble de commandes C et d’une matrice de contrôle d’accès A.

Pour un droit r, existe-t-il un ensemble de commandes dans C qui transforment A en une matrice A’ telle que r∈A’[s,o] pour certains s,o t.q. r∉A[s,o]?

Si la réponse est non, alors nous dirons que A est sûre pour r.

Il est possible de prouver que :

Si les commandes dans C ne contiennent qu’une seule opération, alors il peut être décidé si A est sûre pour r.

Si les commandes dans C peuvent contenir plus d’une opération, alors il est indécidable de déterminer si A est sûre pour r.

Si le nombre de sujets est fini alors la question est toujours décidable!

Décider de l’accès (II)Décider de l’accès (II)En pratique, les commandes peuvent certainement contenir plus d’une opération.

De plus, il semble difficile de limiter le nombre de sujets d’avance.

➡La conclusion est que les résultats précédents indiquent un problème important.

L’indécidabilité ne fait qu’indiquer qu’il n’y a pas de procédures générales qui répondront à la question, peu importe le système. Dans la pratique, un système peut très bien permettre de répondre à la question.

Cependant, les résultats précédents indiquent certainement que le problème de l’analyse des systèmes de contrôle d’accès dynamiques est très difficile...

JavaLe langage Java a toujours misé sur sa sécurité pour son déploiement. Ce langage est reconnu comme l’un des plus sûrs (sinon le plus sûr) pour la programmation sur l’Internet.

La sécurité Java offre deux caractéristiques importantes :

La plateforme Java (par l’utilisation du kit SDK «Software Development Kit») en est une sûre et complète pour rouler les applications.

Des utilitaires en Java qui permettent une gamme d’applications sûres.

Le langage et sa Le langage et sa plateformeplateforme

Java est indépendant de la plateforme sur laquelle il tourne. Un programme sûr sur une plateforme le sera aussi sur une autre.

Le langage est fortement typé. Il n’a pas de construction de types qui ne soit pas sûre. Ex. : Il n’y a pas de tableau sans vérification des indices.

L’administration de la mémoire est automatique via un ramasse-miettes («garbage collection»).

De plus, il évite les problèmes de sécurité des langages comme C et C++ quant à la libération de la mémoire. Elle n’est pas requise en Java.

Une étude conclut que 50 % des alertes émises par le Une étude conclut que 50 % des alertes émises par le Computer Emergency Response Team (CERT) sont Computer Emergency Response Team (CERT) sont

causées au moins en partie par des débordements de causées au moins en partie par des débordements de tampons...tampons...

Une étude conclut que 50 % des alertes émises par le Une étude conclut que 50 % des alertes émises par le Computer Emergency Response Team (CERT) sont Computer Emergency Response Team (CERT) sont

causées au moins en partie par des débordements de causées au moins en partie par des débordements de tampons...tampons...

Mach

ine

La plateformeLa plateforme

FureteurFureteur

Programme Java

ServeurServeur

Programme Java

Applet

ApplicationLe langage Java, la machine virtuelle (JVM) et l’interface de

programmation d’application («API library») forment la plateforme Java.

La JVM est une machine virtuelle, indépendante de la technologie et de la plateforme hôte.

JVM ne connaît pas Java mais exécute les instructions («bytecode») à l’aide d’une table de symboles et d’information auxiliaire.

Le bytecode peut être aussi bien compilé qu’interprété.

L’architecture de sécurité pour JDK L’architecture de sécurité pour JDK 1.01.0

Les applications ont accès a toutes les ressources vitales du système.

Ce n’est pas le cas pour les applets...

Mach

ineFureteurFureteurServeurServeur

Applet Java

Apple

t Ja

va

Apple

t Ja

va

Un applet est restreint à jouer dans le carré de sable fourni par le fureteur.

Les fichiers de la machine hôte ne sont pas accessibles par l’applet.

Un environnement très restrictif pour le code non fiable obtenu d’un réseau ouvert.

Vérificateur de Vérificateur de bytecodebytecode

L’architecture de sécurité repose sur plusieurs mécanismes :

Gestion de mémoire automatique,

Le vérificateur de bytecode s’assure que le code est du Java légitime,

Il vérifie aussi les débordements, soupassements de capacité («underflow») de piles et les conversions de types illégales.

Le vérificateur de bytecode et la JVM sont construits pour s’assurer que les types soient utilisés de façon sûre à l’exécution.

Vérification des typesVérification des typesLe code est vérifié pour s’assurer que :

1.Il n’y ait pas de conversion de types illégale,

2.Il n’y ait pas de pointeur falsifié (il n’y a pas de pointeur en Java),

3.Il n’y a pas de violation des restrictions d’accès. Ex.: les champs privés ne doivent pas être consultés de l’extérieur.

4.Les objets sont consultés de la façon prévue. Ex. : il faut s’assurer qu’un objet InputStream soit toujours utilisé comme tel.

5.Les appels aux méthodes se font avec les types appropriés. Pas de débordement et les méthodes retournent ce qu’elles doivent retourner.

Extension JDK 1.1Extension JDK 1.1En JDK 1.0, le principe du carré de sable est trop restrictif :

Un applet téléchargé à partir d’un réseau local pourrait très bien fournir un service fiable même s’il utilise des ressources du système hôte à l’extérieur du carré de sable.

JDK 1.1 supporte les signatures numériques :

Un applet peut être signé et rangé avec sa signature dans un fichier JAR.

Pour chaque installation JDK, il est possible de spécifier quels signataires sont dignes de confiance.

Si la signature peut être vérifiée et reconnue comme fiable alors l’applet est traité comme une application.

Modèle de sécurité JDK 1.1Modèle de sécurité JDK 1.1

Ressources systèmeRessources système

(fichiers, connexions (fichiers, connexions réseau...)réseau...)

Gestionnaire de SécuritéGestionnaire de Sécurité

Carré de sable : Carré de sable : accès restreintaccès restreintAccèsAccès

non restreintnon restreint

Code externe

Code local

Code signé de

confiance

Java 2 - Contrôle d’accès finJava 2 - Contrôle d’accès finL’architecture de sécurité en Java2 corrige les limites des versions antérieures.

Dans les versions précédentes, les applets sont toujours limités dans ce qu’ils peuvent faire. Ceci même si certains applets sont plus dignes de confiance que d’autres.

Avec JDK 1.1, des applets signés permettent en partie de régler ce problème. Cependant, l’utilisateur doit donner un chèque en blanc à la compagnie, ce qui n’est peut-être pas toujours une bonne idée.

Pour remédier à ce problème, Java 2 autorise un contrôle d’accès flexible pour permettre aux applets de jouer à l’extérieur de leur carré de sable...

Vérification flexible de politiques Vérification flexible de politiques de sécurité de sécurité

Java 2 élimine le besoin d’écrire du code de sécurité en spécialisant le SecurityManager et le ClassLoader,

Ceci est la façon de procéder avec les versions précédentes.

Java 2 offre une infrastructure qui supporte différentes politiques de sécurité facilement configurables.

Java 2 sépare les mécanismes de vérification de ceux qui expriment la politique de sécurité.

Des mécanismes de contrôle d’accès typés sont utilisables, en plus d’un mécanisme de vérification des droits d’accès qui soit extensible et flexible.

La classe SecurityManager n’a pas être mise à jour avec de nouvelles méthodes. La nouvelle méthode CheckPermission est assez générale pour à peu près toutes les situations.

Politiques de sécurité flexibles et définissablesJDK 1.x fait toujours l’hypothèse que les applications ont tous les privilèges. Le carré de sable ne s’applique qu’aux applets.

Cependant, des applications installées localement ne devraient pas toujours avoir tous les droits d’accès sur le système hôte.

Des démos sont souvent lancées pour un essai. Il est prudent de ne pas laisser à celles-ci un accès illimité.

En mettant en cache un applet, on obtient une exécution plus efficace. Mettre en cache ne devrait pas transformer un applet en code de confiance même s’il réside en mémoire.

La différence entre code local et externe n’est pas claire.

En Java 2, le code local, externe ou signé est sujet au même contrôle de sécurité. L’utilisateur peut indiquer accès complet ou limité basé sur les propriétés du code et sur l’identité de celui qui l’exécute. Ce choix consiste à établir une politique de sécurité appropriée.

L’architecture de sécurité en Java 2

Java 2 utilise la politique de sécurité pour déterminer les droits d’accès qui sont donnés au code exécuté.

Ces permissions sont basées sur les caractéristiques du code, qui roule le code, d’où il vient, s’il est signé et si oui, par qui.

Les demandes d’accès aux ressources protégées invoquent une vérification qui compare la demande aux droits donnés.

Si une politique n’est pas explicitement donnée, alors la politique du carré de sable s’applique.

Sommaire de l’architecture (I)

1.Un fichier de classe est obtenu et accepté s’il passe la vérification du bytecode préliminaire.

2.Le code source de la classe est déterminé. S’il est signé alors la signature est vérifiée.

3.L’ensemble des droits d’accès statiques (c.-à-d. indépendants de la politique), s’il y en a, sont donnés selon le code source de la classe.

4.Un ProtectionDomain est créé pour marquer le code source et pour contenir les droits d’accès statiques. La classe est chargée et associée au domaine de protection. Si un domaine approprié a déjà été créé, alors ce ProtectionDomain est réutilisé à la place.

5.La classe peut être instanciée en objet et ses méthodes invoquées. La vérification des types continue.

Voici comment une applet ou application est manipulé :

un groupe contenant un un groupe contenant un code source avec ses code source avec ses

permissions.permissions.

un groupe contenant un un groupe contenant un code source avec ses code source avec ses

permissions.permissions.

Sommaire de l’architecture (II)6.Lorsqu’une vérification de sécurité est invoquée et au

moins une méthode de cette classe est sur la chaîne des appels, le contrôle d’accès examine le domaine de protection. La politique de sécurité est consultée et l’ensemble des droits d’accès à être donnés est déterminé basé sur le code source et le principal qui indique qui roule le code. L’objet Policy est aussi construit s’il ne l’a pas déjà été. Cet objet maintient une représentation à l’exécution de la politique de sécurité.

7.L’ensemble des droits d’accès est évalué pour décider si suffisamment ont été donnés pour satisfaire les requêtes d’accès. Si oui, alors l’exécution continue sinon une SecurityException est levée.

8.Si une exception a été levée et non interceptée, la machine virtuelle avorte.

ExempleUn applet WriteFile est téléchargé de java.sun.com.

Celui-ci veut écrire dans un fichier writetest dans votre répertoire courant.

Lancer l’AppletViewer sur WriteFile signalera une SecurityException.

Le droit d’écrire peut être donné à l’applet en utilisant le PolicyTool pour créer un politique mapolitique.

Rouler l’AppletViewer pour WriteFile avec mapolitique permettra d’exécuter le programme!

La sécurité de JavaEst-ce que Java est tout à fait sûr?

Plus sûr que bien des langages mais probablement pas parfait!

Des failles sont trouvées régulièrement :

Elles ne sont pas (toutes) causées par des applications contenant des bugs. Mais plutôt des failles dans Java!

La plupart du temps, elles apportent une confusion de type pour la JVM. Une telle confusion peut alors être utilisée pour une attaque comme une attaque par débordement.

Voici une liste d’attaques pour des versions antérieures de JDK, la JVM ou les fureteurs Java...

AttaquesAttaquesDATE

APPLET MÉCHANTE

Cible

February 1996 Jumping the FirewallNetscape2.0 : attaque un

RP

March 1996 Slash and BurnNetscape2.01 : Applet ->

trust

March 1996 Applets Running WildByteCodeVerifier,Netscap

e2.01

May 1996Casting Caution to the

WindNetscape2.02,Explorer3.0

b3

June 1996 Tag-Team Applets Netscape3.0b3

June 1996 You're Not My Type Netscape3.05->conf types

July 1996Casting Caution to the

Wind (reprise)Interprete Java,

Netscape3.0b5

August 1996Big Attacks Come in Small

PackagesExplorer3.0b3,bug

implement. Java de Microsoft

February 1997 Steal This IP Number Netscape3.x

February 1997 Cache Cramming Explorer3.x

March 1997 Virtual Voodoo bug JVM

April 1997 The Magic CoatJDK1.1 -> bug signature

de code

May 1997 Verifying the Verifier27 erreurs dans

vérificateurs de codes commerciaux

July 1997 The Vacuum Bugtrou précédent lancé

contre Netscape3.x :SSL

August 1997 Look Over ThereExplorer3.x et

Netscape3.x

July 1998 Beat the SystemNetscape4.0x eploitable ->

ClassLoader JDK1.1 et 1.2b3

Politiques de sécurité pour Politiques de sécurité pour les humainsles humains

Une description de comment spécifier une politique de sécurité pour les systèmes de TI est disponible sur le site du cours.

La politique de sécurité pour les utilisateurs des systèmes informatiques de l’UdeM :

http://secretariatgeneral.umontreal.ca/fileadmin/user_upload/secretariat/doc_officiels/reglements/administration/Ges40_

28-politique-securite-informatique-utilisation-ressources-informatiques-universite-de-montreal.pd

f

La page principale au sujet de la sécurité à l’UdeM est :

http://www.securinfo.umontreal.ca

Voir la page Web du cours pour d’autres liens à ce sujet....

Le contenu d’une politique de TILe contenu d’une politique de TIRevenons sur ce qu’est une politique de sécurité pour un programme de sécurité en technologie de l’information.

La politique est un élément critique d’un tel programme.

Une politique identifie les règles et procédures que toutes les personnes ayant accès aux ressources doivent satisfaire pour garantir la confidentialité, l’intégrité et la disponibilité des données et services.

Elle donne aussi par écrit :

La position de l’organisation sur les questions de sécurité,

La description et l’affectation de fonctions et responsabilités,

L’attribution de pouvoirs aux professionnels,

La procédure de réponse aux incidents.

Bonne politiqueDonne des informations claires, concises et réalistes,

Donne son champ d’action,

Permet sa réalisation,

Identifie les domaines de responsabilité des utilisateurs et des administrateurs,

Donne les orientations pour le développement des procédures prévues,

Concilie protection et productivité,

Identifie les réponses à donner aux incidents et

Est décrétée par un dirigeant de l’institution.

Ses composantes (I)Ses composantes (I)Définition : Une vision bien définie de la sécurité du point de vue de l’organisation. Donne le but de la politique.

Ex. : Le préambule de la politique de sécurité de l’Université de Montréal.

L’exécution : Comment la politique va être exécutée et les réponses aux infractions.

L’accès des utilisateurs aux ressources : Identifie les rôles et les responsabilités des utilisateurs qui utilisent les ressources. Incluant :

Procédures pour obtenir l’accès aux réseaux, et les niveaux de droits pour l’accès aux ressources.Politiques interdisant l’utilisateur à des fins personnelles, procédures pour l’identification des codes de conduite courriel applicables, spécifications pour les utilisations acceptables et inacceptables d’Internet.Mots de passe, procédures pour la fermeture de comptes, procédures pour l’accès à distance, guides pour l’utilisation de machines personnelles.Restrictions pour l’installation d'applications et de matériel, un guide pour les applications.

Procédures pour l’annonce de menaces et la sensibilisation à la sécurité informatique.

Ses composantes (II)Ses composantes (II)Profils de sécurité : Une bonne politique de sécurité devrait inclure de l’information qui identifie comment un profil de sécurité peut être appliqué uniformément sur les différentes composantes matérielles (serveurs, postes, routeurs, coupe-feu...). La politique devrait faire référence à des standards applicables et des procédures pour l’arrêt de composantes matérielles.

Dans bien des cas, la configuration par défaut des appareils n’est pas suffisante. Il faut indiquer pour chaque appareil les configurations nécessaires pour satisfaire les besoins de l’organisation.

Ses composantes (III)Mots de passe : La politique doit clairement indiquer les contraintes imposées pour le choix des mots de passe.

Courriel : Une politique sur l’utilisation du courriel est un plus. Est-ce qu’un filtrage des messages est nécessaire (éliminer les *.bat, *.exe, *.com, ...)?

Internet : Un politique d’utilisation d’Internet doit restreindre l’accès aux sites interdits. Est-ce que des logiciels sont nécessaires pour filtrer les sites interdits? Doit aussi identifier les utilisations personnelles autorisées.

Antivirus : Identifie la fréquence à laquelle la mise à jour de la base de données des virus doit être effectuée. Comment les appareils mobiles sont vérifiés. Si un virus est trouvé quoi faire?

Ses composantes (IV)Ses composantes (IV)Sauvegarde et récupération : Un plan clair pour les sauvegardes et la récupération en cas d’avarie est nécessaire :

La planification des sauvegardes,

L’identification du type de sauvegarde,

L’équipement à utiliser,

L’endroit où les sauvegardes seront rangées

Tests de récupération,

Les journaux («logx»), ...

Ses composantes (V)Ses composantes (V)Détection d’intrusions : Quel genre d’IDS doit être utilisé en fonction des risques. Des procédures standards de fonctionnement doivent être dérivées de la politique pour la mise en place de méthodes de détection d’intrusions ainsi que les procédures.

Accès à distance : La politique doit identifier les procédures qui doivent être suivies pour avoir accès à distance. Vous devez également déterminer dans quelles conditions les ordinateurs personnels peuvent avoir accès aux ressources de l’organisation. Par exemple :

Installer et configurer des coupe-feu personnels sur les machines externes.Forcer l’installation d’antivirus, de correctifs («patches») de sécurité récents.Le partage des fichiers reste inactivé.Les noms d’utilisateur et les mots de passe doivent être chiffrés.Interdire la configuration des machines de l’organisation pour se connecter sur des comptes de SP.

Ses composantes (VI)Ses composantes (VI)Vérification : Les programmes de sécurité doivent être vérifiés de façon aléatoire pour reconnaître leur efficacité. Le responsable de la sécurité doit avoir le droit de conduire des vérifications. Ces vérifications peuvent inclure :

Vérification des mots de passe en essayant de les deviner/casser (LC3 Windows et PWDum sur UNIX et Windows).

Vérifier l’existence de comptes périmés, mais toujours utilisés.

Utilisation de techniques de piratage psychologique («social engineering») pour vérifier s’il est possible d’obtenir les mots de passe d’un employé.

Tester les sauvegardes.

Simulation d’une erreur réseau pour tester la vitesse de réaction...

Ses composantes (VII)Ses composantes (VII)

Formation : Pour assurer le fonctionnement du programme, il est important de former les employés.

La formation se fait à différents niveaux selon le type d’employé.

Un processus de formation des nouveaux employés devrait être donné.

Les employés ayant été formés devraient signer un engagement à se conformer aux règles.

Quelques politiquesQuelques politiques

Politiques diverses : http://dii.vermont.gov/Policy_Central

Sauvegardes : http://its.uncg.edu/Policy_Manual/Computer_Backup/

DMZ : http://www.sans.org/resources/policies/Internet_DMZ_Equipment_Policy.pdf

Mots de passe : http://www.sans.org/security-resources/policies/Password_Policy.pdf

Rappel : Voir le site Web Rappel : Voir le site Web pour d’autres exemples...pour d’autres exemples...Rappel : Voir le site Web Rappel : Voir le site Web pour d’autres exemples...pour d’autres exemples...