Politiques de sécurité

Présentation au sujet: "Politiques de sécurité"— Transcription de la présentation:

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

2 Organisation Nous allons maintenant voir cet aspect important Nous avons aussi traité des modèles de menaces classiques 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. 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. Les objectifs définissent les états autorisés d’un système. Nous avons traité surtout de mécanismes jusqu’à maintenant... 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.

3 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.

4 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.

5 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 : 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’. Le ≤ n’a pas à être défini pour chaque paire. Exemple : S={public, délicat, secret, top secret} public≤top secret secret≤top secret délicat≤top secret public≤délicat n’a pas de borne inférieure maximum pour secret,top secret

6 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.

7 Deux façons simples d’utiliser un treillis
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)). 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.

8 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.

9 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 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). Un chercheur secret peut lire des documents secrets ou publics, mais pas top secret! L’idée est d’éviter que l’information circule d’un niveau élevé vers un niveau moins élevé. Un chercheur secret peut écrire des documents secrets ou top secret, mais pas publics!

10 À 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.

11 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.

12 Exemple Niveau 2 ??? Niveau 2 ou 3 Niveau 1

13 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.

14 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.

15 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é.

16 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.

17 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.

18 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.

19 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.

20 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.

21 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?

22 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.

23 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!

24 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...

25 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.

26 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...

27 La plateforme Applet Machine Fureteur Serveur Programme Java 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é.

28 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 Machine Fureteur Serveur Applet Java

29 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.

30 Vérification des types
Le code est vérifié pour s’assurer que : Il n’y ait pas de conversion de types illégale, Il n’y ait pas de pointeur falsifié (il n’y a pas de pointeur en Java), 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. 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. 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.

31 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.

32 Modèle de sécurité JDK 1.1 Gestionnaire de Sécurité Ressources système
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...)

33 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...

34 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.

35 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.

36 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.

37 Sommaire de l’architecture (I)
Voici comment une applet ou application est manipulé : Un fichier de classe est obtenu et accepté s’il passe la vérification du bytecode préliminaire. Le code source de la classe est déterminé. S’il est signé alors la signature est vérifiée. 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. 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. La classe peut être instanciée en objet et ses méthodes invoquées. La vérification des types continue. un groupe contenant un code source avec ses permissions.

38 Sommaire de l’architecture (II)
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é. 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. Si une exception a été levée et non interceptée, la machine virtuelle avorte.

39 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!

40 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...

41 Attaques APPLET MÉCHANTE Cible DATE February 1996 Jumping the Firewall
Netscape2.0 : attaque un RP March 1996 Slash and Burn Netscape2.01 : Applet -> trust Applets Running Wild ByteCodeVerifier,Netscape2.01 May 1996 Casting Caution to the Wind Netscape2.02,Explorer3.0b3 June 1996 Tag-Team Applets Netscape3.0b3 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 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 July 1998 Beat the System Netscape4.0x eploitable -> ClassLoader JDK1.1 et 1.2b3

42 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 : La page principale au sujet de la sécurité à l’UdeM est : Voir la page Web du cours pour d’autres liens à ce sujet....

43 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.

44 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.

45 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.

46 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.

47 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?

48 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»), ...

49 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.

50 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...

51 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.

52 Rappel : Voir le site Web pour d’autres exemples...
Quelques politiques Politiques diverses : Sauvegardes : DMZ : Mots de passe : Rappel : Voir le site Web pour d’autres exemples...