Vous êtes sur la page 1sur 52

Politiques de sécurité

11e cours (hiver 2014)



Louis Salvail
Organisation
Nous allons maintenant
Nous avons aussi traité

voir cet aspect
des modèles de menaces

important classiques

Politique de sécurité
Modèle des menaces

! !
Une description simple des objectifs Une description des attaques contre
de sécurité d’un système et une lesquelles le système doit être en
stratégie de haut niveau pour les mesure de se défendre.
satisfaire.

Les objectifs définissent


les états autorisés d’un
système.
Nous avons
Mécanismes de sécurité

La stratégie indique !
traité surtout

Les solutions techniques utilisées pour
comment on compte de mécanismes

satisfaire les objectifs.
satisfaire les objectifs. jusqu’à maintenant...
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é)
TCB: L’ensemble des mécanismes de protection d’un
système informatique incluant matériel, logiciel
interne (firmware) et logiciels qui ont pour but de
réaliser une politique de sécurité du système.

Ex: Le contrôle d’accès du serveur WEB est


Les capacités d’un TCB à
considéré comme une partie du TCB du système
satisfaire les exigences d’une
qui comprend le serveur UNIX, la navigateur d’un
politique de sécurité générale
dépend de la fiabilité de ses usager et l’application WEB.
mécanisme, de leur protection
contre les vices de Pour les langages de programmation avec des
fonctionnement et la bonne fonctions de sécurité intégrées (Java par exemple), leur
désignation des paramètres en TCB est formé des librairies standards ainsi que de
vertu de la politique de sécurité. l’environnement d’exécution.
Modèles pour les politiques 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 treillis
Avant 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 :

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

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

Si a≤b et b≤a alors a=b,
!
public≤top secret
n’a pas de
secret≤top secret

Si a≤b et b≤c alors a≤c.
délicat≤top secret

borne inférieure
maximum pour
public≤délicat
secret
De plus, pour a,b∈S :
secret

!
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’.

Les droits d’accès comme
treillis
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 treillis
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).

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.

Les deux approches ont des similitudes. Les classifications dans un treillis
impliquent un flux (des directions de circulation) d’information.
L’importance des bornes
infé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-Lapadula
Le 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
Un chercheur secret L’idée est d’éviter que
l’objet o.
peut lire des documents
l’information circule d’un niveau élevé vers un
secrets ou publics, mais pas
top secret! niveau moins élevé.
Deux règles sont alors définies (*-properties) :

Pas de lecture en haut : Le sujet s peut lire l’objet o seulement si


Un chercheur secret
C(s)≥C(o).
peut écrire des documents
secrets ou top secret, mais
pas publics!
Pas d’écriture en bas : Le sujet s peut écrire sur l’objet o
seulement si C(s)≤C(o).
À propos de Bell-Lapadula
Les 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 Biba
Ce 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.
Exemple
Niveau 2

???

Niveau 2 ou 3
Niveau 1
Extensions
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èles
Muraille 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)
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)
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ès
Les 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ès
En 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ès
Dans 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 pratique
Pour 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
dynamique
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
dynamique
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)
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)
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...
Java
Le 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 plateforme
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
Computer Emergency Response Team (CERT) sont causées
au moins en partie par des débordements de tampons...
Applet La plateforme

Machine
Programme Java
Serveur Fureteur

Programme Java

Application
Le 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 1.0
Les applications ont accès a toutes les ressources vitales du
système.

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

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.

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

Machine
Applet Java
Serveur Fureteur
Vérificateur de bytecode
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 types
Le 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.1
En 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.1
Code local Code externe
Code signé de

confiance

Carré de sable :
accès restreint

Accès

non restreint
!
!

Gestionnaire de Sécurité
Ressources système

!
!
!
(fichiers, connexions réseau...)
Java 2 - Contrôle d’accès fin
L’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 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éfinissables
JDK 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)
Voici comment une applet ou application est manipulé :

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 und’accès


groupe contenant un code
statiques (c.-à-d. indépendants de la
source avec ses permissions.
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.
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.
Exemple
Un 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 Java
Est-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...
Attaques
DATE APPLET Cible
February 1996 MÉCHANTE
Jumping the Firewall Netscape2.0 : attaque un RP

March 1996 Slash and Burn Netscape2.01 : Applet -> trust

March 1996 Applets Running Wild ByteCodeVerifier,Netscape2.01

May 1996 Casting Caution to the Wind Netscape2.02,Explorer3.0b3

June 1996 Tag-Team Applets Netscape3.0b3

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

Casting Caution to the Wind


July 1996 Interprete Java, Netscape3.0b5
(reprise)
Big Attacks Come in Small Explorer3.0b3,bug implement.
August 1996
Packages Java de Microsoft

February 1997 Steal This IP Number Netscape3.x

February 1997 Cache Cramming Explorer3.x

March 1997 Virtual Voodoo bug JVM

JDK1.1 -> bug signature de


April 1997 The Magic Coat
code
27 erreurs dans vérificateurs de
May 1997 Verifying the Verifier
codes commerciaux

July 1997 The Vacuum Bug trou précédent lancé contre


Netscape3.x :SSL

August 1997 Look Over There Explorer3.x et Netscape3.x

Netscape4.0x eploitable ->


July 1998 Beat the System
ClassLoader JDK1.1 et 1.2b3
Politiques de sécurité pour les
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.pdf

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 TI
Revenons 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 politique
Donne 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)
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)
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)
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)
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)
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)

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 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 pour


d’autres exemples...

Vous aimerez peut-être aussi