Transcript powerpoint - Département d`informatique et de recherche

Politiques de sécurité
11e cours (hiver 2014)
Louis Salvail
Nous allons maintenant
voir cet aspect
important
Nous avons aussi traité
des modèles de menaces
classiques
Organisation
Politique de sécurité
Une description simple des objectifs
de sécurité d’un système et une
stratégie de haut niveau pour les
satisfaire.
Les objectifs définissent
les états autorisés d’un
système.
La stratégie indique
comment on compte
satisfaire les objectifs.
Nous avons
traité surtout
de mécanismes
jusqu’à
maintenant...
Modèle des menaces
Une description des attaques contre
lesquelles le système doit être en
mesure de se défendre.
Mécanismes de sécurité
Les solutions techniques utilisées pour
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
considéré comme une partie du TCB du système
qui comprend le serveur UNIX, la navigateur d’un
usager et l’application WEB.
Pour les langages de programmation avec des fonctions
de sécurité intégrées (Java par exemple), leur TCB est
formé des librairies standards ainsi que de
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 :
Si a≤b et b≤a alors a=b,
S={public, délicat, secret, top secret}
Si a≤b et b≤c alors a≤c.
public≤top secret
secret≤top secret
délicat≤top secret
public≤délicat
De plus, pour a,b∈S :
n’a pas de
borne inférieure
maximum pour
secret,top 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 l’objet
L’idée est d’éviter que l’information circule d’un
o.
Un chercheur secret peut lire des
documents secrets ou publics, mais
pas top secret!
niveau élevé vers un 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
C(s)≥C(o).
Un chercheur secret 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
Serveur
La plateforme
Programme
Java
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.
Un environnement très restrictif pour le code
non fiable obtenu d’un réseau ouvert.
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
Accès
non restreint
Carré de sable : accès
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
un groupe contenant un
code source
avec ses(c.-à-d.
d’accès
statiques
permissions.
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.
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
MÉCHANTE
Cible
February 1996
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
July 1996
Casting Caution to the Wind
(reprise)
Interprete Java, Netscape3.0b5
August 1996
Big Attacks Come in Small
Packages
Explorer3.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 Coat
JDK1.1 -> bug signature de
code
May 1997
Verifying the Verifier
27 erreurs dans vérificateurs de
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
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_2
8-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...